앱보안 실수들 – 1부 : 하나의 테스트 방법만 사용하기

전 세계의 개발자들은 앱 보안(AppSec)의 선제 적용이 항상 성공적으로 결과를 만들어 내지 못한다는 것을 알고 있습니다. 하지만 이러한 과정을 통해서 얻은 경험은 이후 개발자가 보안 측면에서 안전한 애플리케이션을 만들 수 있도록 도움을 줍니다. 본 글에서는 기업이나 개발자가 앱 보안 방법을 구현하면서 일반적으로 저지를 수 있는 여섯 가지 실수에 대해서 자세히 살펴보도록 하겠습니다. 이러한 실수로부터 배우는 모범 사례들은 기업 또는 개발자가 끊임없이 증가하는 사이버 위협에 강력하게 대비할 수 있는 로드맵을 발전시키는 데 도움을 줄 것입니다. 이러한 조치들은 빠르게 진화하는 위협에 맞서서 선제적으로 대응하기 위해서 반드시 수행되어야 합니다.

반복된 실수 중 하나는 애플리케이션을 테스트하면서 부적절한 방법을 사용하는 것과 관련이 있습니다. 일반적으로 개발자와 테스터는 각 테스트 유형의 필요성과 적용 가능성을 고려하지 않은 채 애플리케이션의 한정된 테스트 케이스만을 실행합니다. 정적 분석과 동적 분석은 안전한 소프트웨어 개발 생명 주기(sSDLC)를 적용하고, 효과적인 앱 보안 테스트 방법론을 만드는 데 있어 필수적입니다.

정적 분석과 동적 분석의 상호 보완적인 관계

정적 애플리케이션 보안 테스트(SAST; Static Application Security Testing)는 기본적으로 화이트 박스 테스트이며, 이를 통해 개발자는 애플리케이션의 아키텍처와 소스 코드의 세부 내용을 들여다봅니다. 따라서 SAST는 비실행 환경에서 코드 베이스를 검사하여 보안 결함 및 악성코드를 찾는 과정이라고 할 수 있습니다. 배포 단계에서 웹 사이트의 취약점과 데이터 침해 과정이 발견되는 사례가 늘어남에 따라서, 배포 직전에 보안 취약성에 대한 체크를 수행하는 것은 필수적인 절차로 인식되고 있습니다. 반면 블랙박스 테스트로 알려진 동적 애플리케이션 보안 테스트(DAST; Dynamic Application Security Testing)는 실행 환경에서 수행되며, 애플리케이션의 전반적인 성능을 모니터링하는 데 도움이 됩니다. DAST는 애플리케이션이 배포된 이후에만 실행이 가능하기 때문에 애플리케이션의 소스 코드를 검사할 수 없습니다.

위에서 언급된 정적 분석과 동적 분석은 서로를 보완하며 한 가지 방법의 약점은 다른 방법의 강점이 됩니다. 정적 분석을 통해서 캡슐화, 배포 구성, 크로스 사이트 스크립팅 등에서 발생하는 문제를 파악할 수 없습니다. 짧은 주기의 스프린트와 애자일 개발 방법론의 출현은 애플리케이션의 변경사항을 매일 철저하고 포괄적인 테스트를 통해서 확인하는 과정의 필요성을 더욱 중요하게 여기도록 합니다. 화이트 박스 방식의 정적 분석은 소프트웨어 개발 초기 단계에서 보안 위협 요소를 파악하고 시스템의 잠재적인 버그를 발굴하는 데 있어서 비용 효율이 높습니다.

반면 동적 분석은 앱의 제품화 완료 단계에 도달할 때까지 보안 결함을 들어내지 못하는 정적 분석의 단점을 보완합니다. 애플리케이션이 빌드되고, 배포 준비가 완료된 후 동적 분석을 사용하여 보안 테스트를 수행합니다. 지속적인 통합과 배포(CI/CD; Continuous Integration/Continuous Deployment)를 사용하는 프로젝트의 경우 애플리케이션 코드가 자주 변경되고 빌드가 이루어지기 때문에 실행 시점의 보안 평가 수행이 어렵습니다. 따라서 이러한 경우에는 처음부터 제품화 최종 단계까지의 애플리케이션의 라이프 사이클 전반에 걸쳐 보안을 평가하는 것이 필수입니다.

시너지 효과를 내는 보안 전략

정적 분석은 애플리케이션의 코드 베이스와 바이너리 기반에서 앱의 보안 취약점을 검사하는 반면, 동적 분석은 애플리케이션을 실행한 후 외부에서 애플리케이션의 보안 취약점을 검사합니다. 정적 분석은 애플리케이션 내부에서 외부로, 동적 분석은 애플리케이션 외부에서 내부로 보안을 점검한다고 할 수 있습니다. 결과적으로 이 두 가지는 완벽한 테스트 방법론을 형성합니다. 둘 중 하나라도 실행되지 않으면, 가능한 공격 방법이 테스트 되지 않는다는 의미가 되므로, 애플리케이션의 보안성은 약해진다고 할 수 있습니다.

보안 전략을 수립하기 위해서는 개발자/테스터가 서버와 클라이언트의 취약점을 모두 평가하기 위한 테스트 전략을 구현해야 합니다. 이러한 과정은 개발팀이 CI/CD, 애자일 및 DevOps와 같은 최신 개발 방법론과 보안 프레임 워크를 혼합할 수 있도록 도와줍니다. 자동화된 보안 테스트 도구 사용 외에도 취약점 공격, 검증 및 패치 여부 확인을 위해서는 매뉴얼 한 작업 또한 필요합니다.

해커가 피싱과 같은 단순한 기술을 사용하여 사용자를 속이는 날은 사라졌습니다. 이제는 애플리케이션에 악성코드를 삽입하는 등의 공격이 증가하여, 개발자가 완벽하게 애플리케이션의 테스트 전략을 수립하도록 강요하고 있습니다. 단 한방에 애플리케이션의 모든 보안 위협을 탐지하는 만병통치약과 같은 방법은 없습니다. 정적 분석이나 동적 분석으로도 100% 위협을 탐지할 수 없습니다. 개발과 테스트팀은 두 가지 테스트 기술이 서로 시너지를 만들어 미래에 경쟁력을 갖추도록 발전시켜야 합니다.

앱보안 실수들 – 2부에 대한 기사를 확인하십시오. 여기서 우리는 오픈 소스 라이브러리의 위협과 그것을 극복하는 방법을 이해하도록 도와 드리겠습니다.