애플리케이션 보안 테스트
더 많은 작업
- Application Security Testing; AST, 애플리케이션 보안 시험
- 소스 코드, 실행 중인 애플리케이션, 외부 구성 요소를 정적·동적·계측·구성 분석 같은 여러 방식으로 검사해 보안 약점과 취약점을 찾는 활동과 도구의 총칭
어떤 한 가지 검사도 모든 취약점을 찾지 못한다. 소스 코드를 읽는 도구는 설정 오류를 못 보고, 실행 중인 앱을 두드리는 도구는 코드의 어느 줄이 문제인지 모르며, 둘 다 직접 쓰지 않은 오픈소스 구성 요소의 알려진 취약점은 따로 확인해야 한다. 그래서 애플리케이션 보안 테스트는 여러 기법을 개발 수명 주기의 다른 시점에 겹쳐 배치한다.
CISSP 출제 기준 8.2는 애플리케이션 보안 테스트의 예로 SAST, DAST, 소프트웨어 구성 분석(SCA), IAST를 든다. 미국 NIST IR 8397(2021)은 개발자 검증의 최소 기준으로 위협 모델링, 자동화 테스트, 정적 코드 스캔, 하드코딩 비밀 탐지, 내장 검사·보호 기능 사용, 블랙박스 테스트, 코드 구조 기반 테스트, 과거 사례 테스트, 퍼징, 웹 앱 스캐너, 포함된 코드(라이브러리·패키지·서비스) 관리의 11가지를 권고한다.
| 구분 | SAST | DAST | IAST | SCA | RASP | 퍼징 |
|---|---|---|---|---|---|---|
| 이름 | 정적 애플리케이션 보안 테스트 | 동적 애플리케이션 보안 테스트 | 대화형(계측 기반) 애플리케이션 보안 테스트 | 소프트웨어 구성 분석 | 런타임 애플리케이션 자가 보호 | 퍼즈 테스트 |
| 대상 | 소스 코드, 바이트코드, 바이너리 | 실행 중인 애플리케이션(웹·API) | 테스트 중 실행되는 애플리케이션 내부 | 의존성 목록, 패키지, 컨테이너 이미지 | 운영 중인 애플리케이션 | 입력을 받는 모든 프로그램·프로토콜 |
| 관점 | 화이트박스 | 블랙박스 | 그레이박스 | 구성 요소 목록 | 내부 계측 | 주로 블랙박스, 커버리지 기반은 그레이박스 |
| 시점 | 코딩·빌드 | 테스트·스테이징(운영 점검도 가능) | 통합·기능 테스트 | 빌드와 운영 중 계속 | 운영 | 테스트 |
| 실행 필요 | 아니요 | 예 | 예(에이전트 설치) | 아니요 | 예(에이전트 설치) | 예 |
| 주로 찾는 것 | 주입, 버퍼 오버플로, 위험 함수, 하드코딩 비밀 | 주입, XSS, 인증·세션 문제, 서버 설정 오류 | 실제 실행 경로의 데이터 흐름 취약점 | 알려진 취약점(CVE)이 있는 구성 요소, 라이선스 위반 | 실행 중 공격 시도 차단 | 충돌, 메모리 오류, 예외 처리 결함 |
| 장점 | 이른 발견, 코드 위치 제시, 전체 코드 대상 | 언어 무관, 실제 공격자 관점, 설정·환경 문제 발견 | 오탐 적음, 코드 위치와 요청을 함께 제시 | 빠르고 자동화 쉬움, SBOM과 연계 | 패치 전 보호, 오탐 적음 | 예상 못한 입력 결함 발견 |
| 단점 | 오탐 많음, 설정·인증·접근 통제 결함에 약함, 컴파일 안 되는 코드 분석 어려움 | 늦은 발견, 코드 위치 모름, 커버리지가 크롤링에 좌우 | 지원 언어·플랫폼 제한, 성능 부담, 테스트 커버리지에 좌우 | 직접 작성한 코드는 못 봄, 실제 도달 가능성 판단 어려움 | 성능 부담, 근본 수정이 아님 | 시간·자원 소모, 결과 분석 필요 |
정적 애플리케이션 보안 테스트(SAST, Static Application Security Testing)는 프로그램을 실행하지 않고 소스 코드나 컴파일된 코드를 분석해 보안 결함을 찾는다. 데이터가 외부 입력(소스)에서 위험한 함수(싱크)로 검증 없이 흐르는지 추적하는 오염 분석(taint analysis)이 대표적 원리이다.
- OWASP는 SAST의 강점으로 대량의 코드에 반복 적용할 수 있어 야간 빌드나 지속적 통합에 잘 맞고, 버퍼 오버플로·SQL 주입 같은 잘 알려진 취약점을 찾으며, 파일명·줄 번호까지 짚어 개발자가 고치기 쉽다는 점을 든다.
- 약점으로는 인증 문제, 접근 통제 문제, 잘못된 암호 사용처럼 자동화하기 어려운 취약점이 많고, 오탐이 많으며, 코드에 드러나지 않는 설정 문제를 못 찾는다는 점을 든다.
- IDE 플러그인으로 코딩 중에, 커밋·풀 요청 단계에서 변경분만, 빌드 단계에서 전체를 검사하는 식으로 나누어 배치한다.
- 관련 문서: 정적 테스트, 코드 인스펙션, CWE
동적 애플리케이션 보안 테스트(DAST, Dynamic Application Security Testing)는 실행 중인 애플리케이션에 HTTP 요청 같은 입력을 보내고 응답을 관찰해 취약점을 찾는 블랙박스 방식이다. OWASP는 이런 도구를 웹 애플리케이션 취약점 스캐너로 분류하며, 보통 외부에서 XSS, SQL 주입, 명령 주입, 경로 조작, 안전하지 않은 서버 설정 같은 취약점을 찾는다고 설명한다.
대화형 애플리케이션 보안 테스트(IAST, Interactive Application Security Testing)는 애플리케이션 서버에 에이전트를 넣어(계측, instrumentation) 기능 테스트나 DAST가 실행되는 동안 내부의 데이터 흐름과 함수 호출을 관찰한다.
- 외부 요청과 내부 코드 경로를 함께 보므로 "이 요청이 이 줄의 SQL 실행까지 검증 없이 도달했다"처럼 근거를 제시해 오탐이 적다.
- 별도 공격 트래픽 없이 기존 자동화 테스트를 그대로 활용할 수 있어 CI 파이프라인에 넣기 쉽다.
- 테스트가 실행하지 않은 코드 경로는 보지 못한다. 에이전트가 지원하는 언어·프레임워크에서만 쓸 수 있다.
소프트웨어 구성 분석(SCA, Software Composition Analysis)은 애플리케이션에 포함된 오픈소스·제3자 구성 요소를 식별하고, 각 구성 요소의 알려진 취약점(CVE), 라이선스, 유지관리 상태를 확인한다. OWASP는 제3자·오픈소스 소프트웨어와 하드웨어 구성 요소 사용에서 오는 위험을 찾는 과정을 구성 요소 분석(component analysis)이라 하고, 그 범위를 좁힌 것을 흔히 SCA라 부른다고 설명한다.
- 패키지 관리자 파일, 잠금 파일, 바이너리 지문, 컨테이너 이미지 계층을 분석해 직접 의존성과 간접(전이) 의존성을 모두 찾는다.
- 결과물로 SBOM을 만들고, 새 취약점이 공개되면 이미 배포된 제품 중 영향받는 것을 즉시 찾는 데 쓴다.
- 라이선스 정책 위반(예: 배포 조건이 까다로운 GPL 계열 라이선스를 상용 제품에 포함)도 찾는다. 오픈 소스 라이선스 참고.
- 취약한 함수가 실제로 호출되는지(도달 가능성)까지 분석하는 도구도 있다. 그렇지 않은 도구는 경보가 많아 우선순위 판단에 CVSS와 악용 여부 정보를 함께 쓴다.
- 의존성 혼동, 타이포스쿼팅 같은 공급망 공격 대응은 개발 환경 보안 참고.
런타임 애플리케이션 자가 보호(RASP, Runtime Application Self-Protection)는 테스트 도구라기보다 운영 중 애플리케이션 안에서 동작하는 보호 기술이다. 애플리케이션 런타임에 계측 에이전트를 넣어 실제 실행 맥락(어떤 입력이 어떤 SQL·명령·파일 경로가 되는지)을 보고 공격으로 판단되면 그 호출을 차단한다.
- 웹 방화벽은 네트워크 앞단에서 요청 패턴만 보지만, RASP는 애플리케이션 내부에서 결과를 보고 판단하므로 오탐이 적고 암호화된 트래픽도 문제되지 않는다.
- 패치가 나오기 전의 취약점을 임시로 보호하는 보완 통제로 쓸 수 있다.
- 성능 부담과 안정성 위험이 있고, 결함 자체를 고치지는 않는다. 근본 수정은 코드 변경이다.
퍼징(fuzzing)은 무작위이거나 변형된 대량의 입력을 프로그램에 넣어 충돌, 멈춤, 메모리 오류, 예외 처리 결함을 찾는 방법이다. 파일 파서, 네트워크 프로토콜, 브라우저 엔진처럼 복잡한 입력을 처리하는 코드에 특히 효과가 있다. 자세한 내용은 퍼즈 테스트 참고.
| 단계 | 배치하는 검사 | 목적 |
|---|---|---|
| 코딩 | IDE SAST 플러그인, 비밀 탐지, 의존성 추가 시 SCA | 작성 즉시 피드백 |
| 커밋·풀 요청 | 변경분 SAST, SCA, 비밀 탐지 | 병합 전 차단(품질 게이트) |
| 빌드 | 전체 SAST, SCA와 SBOM 생성, 컨테이너 이미지 스캔 | 산출물 기준선 확보 |
| 테스트·스테이징 | DAST, IAST(기능 테스트와 함께), 퍼징, API 보안 테스트 | 실행 환경 결함 발견 |
| 운영 | RASP, 웹 방화벽, SCA 재평가(새 CVE 공개 대응), 정기 DAST | 운영 중 보호와 새 위협 대응 |
이 배치는 데브섹옵스의 시프트 레프트를 구체화한 것이다. 자동화 도구로 찾지 못하는 비즈니스 로직 결함과 접근 통제 결함은 수동 코드 리뷰와 모의 침투 테스트로 보완한다.
- 오탐(false positive): 문제가 아닌 것을 문제로 보고한다. 많으면 개발자가 결과를 무시하게 되어 진짜 문제도 묻힌다. 규칙 조정, 이전 판정 기억(억제 목록), IAST 같은 근거 기반 도구로 줄인다.
- 미탐(false negative): 실제 취약점을 놓친다. 도구 하나에 의존하지 않고 기법을 조합해 줄인다.
- 결과 관리: 여러 도구의 결과를 한곳에 모아 중복을 제거하고 위험 기준으로 우선순위를 정한다. 수정 기한을 심각도별로 정해 취약점 관리 절차에 넣는다(취약점 관리).
- 소스 코드가 있고 개발 초기면 SAST, 소스 없이 실행 중인 앱이면 DAST, 오픈소스 구성 요소의 알려진 취약점·라이선스면 SCA, 테스트 중 내부 계측이면 IAST를 고른다.
- SAST는 오탐이 많고 설정 문제를 못 찾는다. DAST는 코드 위치를 모르고 늦게 발견한다. 장단점을 짝지어 기억한다.
- RASP와 웹 방화벽은 보호 수단이지 결함 수정이 아니다. "가장 좋은 장기 대책"을 물으면 코드 수정과 보안 개발 절차 개선이 답이다.
- 상용 기성품처럼 소스를 받을 수 없는 소프트웨어는 DAST, 퍼징, 벤더 증빙(인증, SBOM)으로 평가한다.
- 자동화 도구만으로는 비즈니스 로직 결함을 잡기 어렵다. 수동 검토와 모의 침투 테스트를 함께 한다.
- NIST IR 8397, Guidelines on Minimum Standards for Developer Verification of Software – NIST
- Source Code Analysis Tools – OWASP
- Vulnerability Scanning Tools – OWASP
- Component Analysis – OWASP
- Fuzzing – OWASP