SAST(정적 어플리케이션 보안 시험) 완벽 가이드

Dustin Hong

2년 ago

잘못된 소프트웨어 개발은 사이버 범죄자들에게 문을 열어주는 행위입니다. 오늘날 어플리케이션은 독점 데이터나 고객 기록 등 중요한 정보가 담긴 웹 앱에 대한 접근을 내줄 수 있는 취약점을 찾도록 설계된 봇과 자동 스크립트의 공격에 맞서야 합니다.

소프트웨어 개발자와 IT 보안팀이 원활하게 소통하지 못하면 고위험이나 치명적 위험에 해당하는 내부 어플리케이션 취약점이 발생하게 됩니다.

지금까지 웹 개발자들은 정적 어플리케이션 보안 시험(SAST) 기능과 도구를 거의 이용하지 못했으나 이 상황은 변하고 있습니다. 오픈소스 프레임워크와 NodeJS 및 SAST 지원 통합 등 언어와 도구가 등장하면서 SAST가 크게 확산되었지만 아직 충분하지 못합니다.

기업 규모에 따른 취약점 심각도 분류

출처: EdgeScan

정적 애플리케이션 보안 테스트(SAST)

정적 분석이라고도 하는 SAST는 어플리케이션의 소스코드를 시험하여 비즈니스에 심각한 위협이 될 수 있는 명확한 취약점을 찾아냅니다.

SAST의 원리

정적 분석 도구는 코드 가독성과 스타일 등 사소한 문제에서 부적절한 프로그래밍 생성자의 사용이나 환경 변화에 대한 노출 등으로 인해 일어날 수 있는 취약점에 이르는 다양한 코드의 결함을 파악, 분석하도록 설계됩니다.

건물의 보안 경비원이 잘못된 의도를 가진 사람의 진입을 막는 것처럼 정적 코드 분석기는 소스코드를 살펴보면서 익명 사용자가 악성 활동의 징후를 웹사이트나 어플리케이션에 주입할 수 있는 코드 조각을 파악합니다.

SAST의 장점

SAST 검사는 소스코드에서 보안 약점을 나타낼 수 있는 이상 징후를 찾아냅니다.
이러한 도구는 원점 회귀 원칙에 따라 코드 컴파일 전에 SDLC(소프트웨어 개발 수명주기)의 초기에 사용할 수 있어 빌드 단계에서 취약점을 파악하는 것이 가능합니다.
또한 SAST는 실시간으로 버그를 보고합니다.
SAST 도구는 간단하게 개발팀의 기존 도구와 통합할 수 있습니다. 이를 통해 코드베이스에 대해 유연한 시험을 실시할 수 있으므로 부담 없이 어플리케이션에 대한 시험 방법과 시점을 자유로이 결정할 수 있습니다.

SAST의 단점

SAST는 동적 환경 내에서 어플리케이션이나 그 요소가 작동하는 방식에 대한 인사이트를 제공하지 않으므로 가능한 경우에 동적 환경에서 추가 시험을 실시해야 합니다.

SAST는 위양성(false positive) 결과가 나올 확률이 높으며 이로 인해 취약성이 부풀려질 수 있습니다.

SAST는 최종 검사가 핵심이므로 몇 시간마다 새로 검사하여 최근 상황을 추적해야 합니다.

출처

SAST 관련 도구

소프트웨어 엔지니어는 소스 분석용 보안 시험 도구를 이용하여 이미 시험을 통해 신뢰가능한 것으로 승인된 필수 코드 자원의 프레임워크나 라이브러리에서 소스코드의 추가 위험을 찾아냅니다.

특히 앱 구축 시 마치 새로운 페이스북을 만드는 것처럼 집중하여 어플리케이션 보안 시험을 조기에 실시하는 것은 매우 중요할 수 있습니다.

이전에 공개된 감지 도구도 있으며 여기서 SAST 도구들이 빛을 발합니다. 이들은 생산 환경에서 앱이 구현되기 전에 사용함으로써 소프트웨어나 웹사이트의 취약점을 만들어낼 수 있는 결함을 찾아내는 데 도움이 됩니다.

1. SonarQube

SonarQube는 버그를 찾는 데 이용하는 SAST 도구입니다. 디스크 공간과 메모리를 많이 사용하지 않는 경량형 플랫폼입니다. 커뮤니티 에디션 SonarQube는 자바, 자바스크립트, 파이선을 비롯한 약 15개 언어를 지원하며 원하는 클라우드 플랫폼에서 사용할 수 있습니다.

2. Synopsys

보다 혁신적인 솔루션을 제공하기 위해 노력하는 Synopsys는 기업들이 보다 신속하고 저렴한 비용으로 안전한 제품을 개발할 수 있도록 통합 소프트웨어 개발 도구(SDT)와 서비스를 제공합니다.

소프트웨어가 출시되기 전에 버그를 찾아냄으로써 중요한 결함과 취약점을 차단할 수 있습니다. Synopsys는 개발의 기본을 이해하므로 정확한 분석을 제공하여 개발자들이 위양성(false positive) 결과로 혼동하지 않도록 도와줍니다.

3. Veracode

Veracode는 인간보다 월등히 빠른 정적 분석이 가능하며 IDE 및 C/CD 파이프라인에서 직접 보안 피드백을 자동으로 제공합니다. 어플리케이션 구축 및 시험 중에 신속한 보안 피드백을 제공하므로 효율적으로 품질을 관리할 수 있습니다.

Veracode는 기업의 모든 IT 인프라를 검토하는 전체 정책 검사 기능을 제공하며 찾아낸 문제의 해법에 대해 명확한 지침을 제시하므로 신뢰감을 가지고 제품을 개발, 구현할 수 있습니다.

4. Checkmarx

Checkmarx는 프로그램의 취약점을 찾아내는 다양한 기능을 제공하는 어플리케이션 보안 시험 도구입니다.

사용법이 간단하고 별도 구성 없이 여러 언어를 지원하며 사용자가 설정 등에 개입할 필요가 없습니다. 또한 유사 도구들 대비 신호 대 노이즈비가 우수합니다.

5. AppSealing

앱실링(AppSealing)의 SAST 기술은 어플리케이션 소스코드, 바이너리, 바이트 코드를 비구동 상태에서 분석하고 공격에 취약할 수 있는 보안 취약점을 찾아낼 수 있습니다.

앱실링(AppSealing)의 SAST 도구들은 모바일 앱을 공격에 취약하게 만드는 보안 약점들을 찾아냅니다. 모바일 앱을 분석하여 잠재적 코드 기반 취약점을 확인합니다.

SAST 중에 앱의 코드를 실행하지 않으므로 모바일 또는 네트워크 환경에 위협이 발생할 우려도 없습니다.

또한 앱실링(AppSealing)은 개발자에게 실시간 피드백을 제공합니다. 이를 통해 적시에 실수를 제거할 수 있는 기반을 제공함으로써 제품이 안전하면서 최상의 상태로 다음 SDLC 단계로 넘어갈 수 있습니다.

SAST와 DAST의 차이

어플리케이션 보안 시험에는 SAST와 DAST가 있습니다. 둘 다 어플리케이션 보안 시험 방법이며 어플리케이션 내 결함을 찾아낸다는 점에서 유사하지만 차이점이 존재합니다.

어플리케이션에 취약한 부분이 있다는 보고서가 생성될 수 있지만 그렇다고 모든 것이 끝난 건 아닙니다. 사실 이 보고서는 개선이 필요한 측면을 찾아내는 데 도움이 되면서 이 측면을 해소할 수 있는 장기적 전략을 수립하는 데 도움이 됩니다.

SAST와 DAST의 차이를 이해하기 위해 먼저 5가지 핵심 차이와 어플리케이션 내 결함을 파악하는 2가지 방법에 대해 알아보겠습니다.

SAST VS DAST

SAST	DAST
SAST는 일종의 화이트박스 보안 시험입니다. 이는 웹 어플리케이션 서버 소프트웨어와 여러 요소들을 통해 개발자에게 제공되는 코드 실행 기능에 기반합니다.	DAST는 블랙박스 보안 시험으로 어플리케이션을 구성하는 내부 프레임워크와 소스코드, 설계 및 문서에 접근하지 않습니다.
반면 SAST는 어플리케이션 내부에서 실시하여 외부로 향하는 취약점 시험입니다.	DAST는 외부에서 실시하여 내부로 향하는 시험이며 공격자의 생각을 바탕으로 어플리케이션과 그 아키텍처를 분석합니다.
SAST 시에는 어플리케이션을 구현할 필요가 없습니다.	DAST 시에는 어플리케이션을 실행해야 합니다.
SAST 도구는 메모리에 저장된 코드 인스턴스만 검사하므로 코드가 런타임에서 실행될 시 발동할 수 있는 취약점을 찾아내기 어렵습니다.	DAST는 코드가 데이터 및 제어 흐름 등 원래 소스코드에서 수정될 수 있는 것을 찾아내어 실제로 실행될 시 취약점을 찾아내는 방법입니다.
SAST 도구는 다른 정적 도구보다 많은 시간과 비용이 소요됩니다. 개발 플랫폼에서 정적 도구를 사용할 경우 리컴파일링으로 인해 완료가 지연될 수 있습니다.	DAST는 해커처럼 작동하여 취약점을 수색하고 시스템을 취약한 상태로 둘 수 있는 실수에 대해 검사합니다. 또한 SQL 주입 및 관련 결함을 찾아내므로 단시간 내에 백엔드를 악성 공격으로부터 보호할 수 있습니다.

RASP는 어디에서 작동하는가?

런타임 어플리케이션 자가보호(RASP)는 서버 기반 기술이므로 어플리케이션과 함께 작동하여 공격을 방어하며 트래픽 분석 뿐 아니라 사용자 거동 분석에도 효과적입니다.

RASP는 목표물 앱을 장악하려는 악성 활동에 대한 경계 상태를 유지합니다. 의심스러운 흔적을 발견하면 그 실행을 멈춥니다.

RASP의 가장 큰 장점으로 방화벽과 같은 외부 조치가 없이 악성 공격을 막아낸다는 것이 있습니다. 또한 RASP는 어플리케이션 내부에서 작동하여 공격이 확산되기도 전에 막아낼 수 있습니다.

미국 표준기술연구원에 따르면 RASP는 어플리케이션 내에서 사용해야 취약점의 위험을 줄일 수 있습니다.

RASP의 4대 장점

RASP 도구는 코드 리뷰를 자주 해야 한다는 부담을 없애줍니다. 또한 늦기 전에 코드의 취약점을 감지, 제거하기 위한 효과적인 침투 테스트를 도와줍니다.
RASP 도구를 이용하면 신속하게 훼손 징후(IoC)를 찾아내어 기존의 RASP 관측에서 해당 IoC가 발견되지 않았더라도 다시 이 관측에 할당할 수 있어 보다 정확한 보안사고 대응이 가능합니다.
또한 RASP는 언제든지 어플리케이션이 무엇을 하는지 인식할 수 있으므로 보안팀이 대비태세를 갖추는 데에도 도움이 됩니다. 런타임 분석을 통해 개발자는 자원을 과도하게 사용하거나 특정 상황에서 일어나지 않아야 하는 패턴을 찾아낼 수 있습니다. 이 덕분에 이미 진행 중일 수 있는 문제를 제거할 수 있습니다.
원활한 통합과 비코드 구현 등의 특징은 앱의 전반적 성능에 대한 영향을 최소화하므로 RASP는 전천후적인 어플리케이션 보안을 위한 선택이라 할 수 있습니다.

SAST, DAST, RASP를 함께 이용하는 방안

DAST, SAST, RASP 방법론을 이용할 시에는 실제 필요한 침투 테스트가 중요함을 인식해야 합니다.

SAST와 DAST를 병행하면 더 많은 취약점과 익스플로잇을 찾아내서 보안 결함을 줄일 수 있습니다.

SAST는 취약점이 아직 개발 중인 어플리케이션에 발생하지 않도록 막을 수 있는 이상적인 방법입니다. 특히 초기에 취약점을 찾아 제거할 수 있음은 유지보수가 용이해짐을 의미하므로 시험은 항상 좋은 선택입니다.

예를 들어 시험 초기에 취약점을 발견하면 이것이 나중에 발견될 시 여러 문제에 대한 여러 해결책을 만들어내야 하는 대신 1가지 수정만 하면 된다는 장점이 있습니다.

반면 DAST를 이용하면 고객의 데이터를 훼손할 수 있는 가능성에 대해 철저한 검증이 이루어진 최상의 어플리케이션을 고객에게 제공할 수 있습니다.

데브옵스의 핵심은 개발(Dev)와 품질관리(QA) 및 시스템 관리(SysAdmins), 보안팀 등의 인원들 간에 존재하는 새로우면서 세련된 문화적 및 업무적 관계입니다.

기업과 개인들로 하여금 이들의 어플리케이션 코드를 분석할 수 있게 해주는 데이터를 제공하도록 만들기는 대부분 쉽지 않습니다. 이들 중에는 SAST에서 이용할 데이터를 제공하기를 꺼리는 경우도 있고 잠재적 위험이 될 수 있다고 걱정하는 다른 문제로 고민하는 이들도 있습니다.

코드 분석을 동적 어플리케이션에 이용하면 어플리케이션 취약점의 기저 원인에 대한 정보를 구할 시 관련 인원들이 적극적이지 못하며 보안 시험을 보다 쉽게 만드는 데에도 효과적이지 못합니다.

그러나 RASP 솔루션을 이용하면 보다 전통적인 현장 기반 검사를 통해 문제를 파악하여 인프라와 어플리케이션을 신속하고 효과적으로 보호할 수 있습니다.

RASP는 목표 소프트웨어에 예상치 못한 취약성이 발생할 위험을 줄입니다. RASP는 DevSecOps(개발+보안+운용) 인원이 소프트웨어 개발 프로세스의 보안 위험을 이해하고 어플리케이션에 침투 시험을 실시하여 악성 공격을 방지하며 보안 인식을 통해 위험을 완화하고 자신의 환경 내 데브옵스의 채택을 가속화하여 DAST 및 SAST 도구를 보완할 수 있습니다.

DevOps 팀은 기술이 지속적으로 발전하고 하드웨어 및 소프트웨어의 구성이 변화하는 속도만큼 빠르게 작동하는 어플리케이션을 만들어야 합니다. 그리고 RASP는 게임체인저가 될 수 있습니다.

앱실링(AppSealing)의 RASP 기술

앱실링(AppSealing)은 전 세계 800개 이상의 모바일 어플리케이션을 지키고 있습니다. 데모로 확인해 보십시오.