정보관리기술사 학습 노트
← 목록으로
보안·개인정보
#SAST#DAST#IAST#DevSecOps#SCA
최종 업데이트 · 2026-10-16

애플리케이션 보안 테스트(SAST·DAST·IAST)

1. 개요

정의: 애플리케이션 보안 테스트(AST, Application Security Testing)는 소프트웨어의 소스코드·실행 바이너리·구동 중인 서비스를 분석하여 보안 취약점을 개발·운영 이전 단계에서 식별·제거하는 일련의 기법으로, 코드를 실행하지 않고 정적 분석하는 SAST, 실행 중인 애플리케이션을 외부에서 공격해 보는 DAST, 그리고 실행 환경에 계측기(Agent)를 심어 내부 흐름을 관찰하는 IAST로 대별된다.

애플리케이션 보안 테스트가 독립된 공학 영역으로 자리 잡은 배경에는 "취약점의 경제학"이 있다. 요구·설계 단계에서 발견되면 사소한 수정으로 끝날 결함이 운영 단계에서 터지면 사고 대응·법적 책임·브랜드 훼손까지 비용이 수십 배로 불어난다는 것은 오래된 소프트웨어 경제학의 통찰이며, 보안 결함에서 이 비대칭은 더욱 극단적이다. 하나의 SQL 인젝션 한 줄이 수백만 건의 개인정보 유출로 이어질 수 있기 때문이다. 따라서 "결함을 최대한 왼쪽(개발 초기)에서 잡자"는 시프트 레프트(Shift-Left) 사상이 보안 테스트의 출발점이 되었다.

또 하나의 배경은 애플리케이션이 조직의 최대 공격 표면(Attack Surface)이 되었다는 사실이다. 방화벽·망분리로 네트워크 경계를 지키던 시대가 저물고, 웹·API·모바일로 비즈니스 로직 자체가 외부에 노출되면서 공격자의 주된 침투 경로가 네트워크에서 애플리케이션으로 이동했다. 오픈소스 의존성이 코드의 70~90%를 차지하게 되면서 "내가 짜지 않은 코드"의 취약점(예: Log4Shell)까지 책임져야 하는 상황도 더해졌다. 이로써 "코드가 안전함을 반복적·자동으로 증명하는" 테스트 체계가 필수가 되었다.

이러한 전환은 품질보증의 무게중심을 "기능이 동작하는가"에서 "악용 가능한가"로 확장한다. 전통적 테스트가 명세대로 동작하는 정상 경로(Happy Path)를 확인했다면, 보안 테스트는 설계자가 의도하지 않은 입력·상태·흐름을 공격자의 관점에서 탐색한다. 즉 "무엇을 해야 하는가"가 아니라 "무엇을 하도록 강제될 수 있는가"를 묻는다. 이 관점의 전환이 SAST·DAST·IAST라는 서로 다른 계측 지점을 낳았다.

이러한 관점 전환은 보안 테스트를 "한 번의 통과/실패 판정"이 아니라 지속적 위험 측정 활동으로 바꾼다. 코드는 매일 바뀌고 새로운 취약점(CVE)은 매일 공개되므로, 어제 안전했던 시스템이 오늘 취약해질 수 있다. 따라서 보안 테스트는 출시 직전 한 번의 관문이 아니라, 코드 변경과 위협 정보 갱신에 맞춰 반복 수행되어야 하는 상시 프로세스가 된다. 이 "반복성"이 자동화·파이프라인 통합을 필연적 요구로 만든다.

애플리케이션 보안 테스트의 본질적 특징은 네 가지로 요약된다. 첫째, 생애주기 내재화 — 별도 감사 행위가 아니라 CI/CD 파이프라인에 자동 단계로 녹아든다. 둘째, 다계층 가시성 — 코드(정적)·실행(동적)·구성요소(의존성)를 상호 보완적으로 본다. 셋째, 위험 기반 우선순위 — 발견된 모든 취약점을 같은 무게로 다루지 않고 악용 가능성·영향도로 선별한다. 넷째, 개발자 친화성 — 보안 전문가가 아닌 개발자가 자신의 IDE·PR에서 즉시 결과를 받도록 설계된다. 이 네 특징은 보안 테스트가 사후 점검이 아니라 개발 흐름의 일부로 진화했음을 보여준다.

2. 애플리케이션 보안 테스트의 전체 구조

애플리케이션 보안 테스트는 SDLC(소프트웨어 개발 생애주기)의 각 단계에 서로 다른 기법을 배치하여, 코드 작성 시점부터 운영 모니터링까지 취약점을 겹겹이 걸러내는 다층 방어 체계로 구성된다. 아래 개념도는 개발 흐름 위에 각 기법이 놓이는 전체 구조를 나타낸다.

flowchart LR
  subgraph DEV["개발 단계"]
    IDE["IDE/코딩"]
    SCA1["SCA(의존성 분석)"]
    SASTX["SAST(정적 분석)"]
  end
  subgraph BUILD["빌드·통합(CI)"]
    BUILDX["빌드/단위테스트"]
    IASTX["IAST(계측 기반)"]
  end
  subgraph TEST["테스트·스테이징"]
    DASTX["DAST(동적 스캔)"]
    PENX["모의해킹(수동)"]
  end
  subgraph OPS["운영"]
    RASPX["RASP(실시간 보호)"]
    ASOC["ASPM(결과 상관·관리)"]
  end
  IDE --> SASTX --> BUILDX
  SCA1 --> BUILDX
  BUILDX --> IASTX --> DASTX --> PENX --> RASPX
  SASTX -.->|결과 집계| ASOC
  DASTX -.->|결과 집계| ASOC
  IASTX -.->|결과 집계| ASOC
  SCA1 -.->|결과 집계| ASOC

개발 단계에서는 코드가 만들어지는 바로 그 지점에 SAST와 SCA가 배치된다. 개발자가 IDE에서 코드를 작성하거나 PR(Pull Request)을 올리는 순간 정적 분석이 돌아 취약 패턴을 짚어 주고, 가져다 쓴 오픈소스 라이브러리의 알려진 취약점(CVE)을 SCA가 경고한다. 이 지점의 핵심 가치는 피드백의 즉시성이다. 개발자가 방금 쓴 코드의 맥락을 기억하는 동안 결과가 도착하므로 수정 비용이 가장 낮다.

빌드·통합 단계에서는 애플리케이션이 실제로 컴파일·구동되기 시작하므로, 실행 흐름을 관찰하는 IAST가 유효해진다. CI 서버에서 기능 테스트를 돌릴 때 계측 에이전트가 함께 작동하여, 테스트가 건드린 코드 경로에서 실제로 취약한 데이터 흐름이 일어나는지를 관찰한다. 정적 분석의 "코드만 보는" 한계와 동적 분석의 "외부만 보는" 한계를 동시에 보완하는 위치다.

테스트·스테이징 단계에서는 운영과 유사한 환경에 배포된 완성 애플리케이션을 대상으로 DAST가 외부 공격자의 시선으로 스캔하고, 중요한 시스템은 전문가의 수동 모의해킹(Penetration Testing)으로 자동화가 놓치는 비즈니스 로직 결함까지 검증한다. 운영 단계에서는 RASP가 실행 중 공격을 실시간 차단하고, ASPM(Application Security Posture Management)이 모든 도구의 결과를 한곳에 모아 중복을 제거하고 위험을 상관 분석한다. 이처럼 단일 기법이 아니라 단계별 기법의 조합이 전체 구조의 본질이다.

3. 주요 기법과 동작 원리

애플리케이션 보안 테스트의 핵심은 "어느 지점에서, 무엇을 가지고, 어떻게 취약점을 찾느냐"에 따라 나뉘는 SAST·DAST·IAST·SCA 네 기법이다. 아래 개념도는 네 기법이 애플리케이션의 서로 다른 표현(코드·실행·외부 인터페이스)에 어떻게 접근하는지를 보여준다.

flowchart TB
  SRC["소스코드/바이트코드"]
  RUN["구동 중 애플리케이션"]
  DEP["외부 의존성(오픈소스)"]
  SAST2["SAST 엔진<br/>데이터 흐름·테인트 분석"]
  IAST2["IAST 에이전트<br/>런타임 계측"]
  DAST2["DAST 스캐너<br/>HTTP 요청 변조"]
  SCA2["SCA 엔진<br/>SBOM·CVE 대조"]
  SRC --> SAST2
  SRC --> IAST2
  RUN --> IAST2
  RUN --> DAST2
  DEP --> SCA2
  SAST2 --> REP["취약점 리포트"]
  IAST2 --> REP
  DAST2 --> REP
  SCA2 --> REP

가. SAST(정적 애플리케이션 보안 테스트) 는 애플리케이션을 실행하지 않고 소스코드·바이트코드·바이너리를 분석한다. 핵심 원리는 테인트 분석(Taint Analysis)으로, 외부에서 신뢰할 수 없는 입력이 들어오는 지점(Source)에서 시작해, 그 값이 변수·함수를 거쳐 위험한 연산(Sink, 예: SQL 질의·명령 실행·파일 접근)에 도달하기까지의 데이터 흐름을 추적한다. 이 경로 중간에 적절한 검증·이스케이프(Sanitizer)가 없으면 인젝션 취약점으로 보고한다.

SAST의 가장 큰 장점은 커버리지의 완전성과 조기성이다. 테스트 케이스가 실제로 실행하지 않은 코드 경로까지 모두 분석할 수 있고, 취약점의 정확한 파일·줄 번호를 제시하므로 개발자가 수정하기 쉽다. 코드만 있으면 되므로 구동 환경 구성 없이 개발 초기부터 돌릴 수 있다. 반면 실행 맥락을 모르기 때문에 "코드상 도달 불가능한 경로"나 "런타임에 무해화되는 입력"까지 취약점으로 보고하는 오탐(False Positive)이 많다는 것이 숙명적 한계다. 대규모 코드베이스에서 수천 건의 경보가 쏟아져 개발자가 피로를 느끼고 결국 무시하게 되는 "경보 피로" 현상은 SAST 운영의 최대 난제다.

SAST의 정확도는 분석 깊이와 성능의 트레이드오프 위에 놓인다. 흐름에 민감한(Flow-sensitive)·경로에 민감한(Path-sensitive) 분석을 깊게 할수록 오탐은 줄지만 분석 시간이 지수적으로 늘어 CI를 지연시킨다. 또한 리플렉션·동적 로딩·프레임워크의 암묵적 호출처럼 정적으로 추적하기 어려운 구조에서는 데이터 흐름이 끊겨 미탐(False Negative)이 발생한다. 따라서 실무에서는 전체 재분석 대신 변경분만 보는 증분 스캔, 룰셋 커스터마이징, 조직 베이스라인 설정을 병행해 "충분히 빠르면서 충분히 정확한" 지점을 찾는 운영 튜닝이 관건이 된다.

나. DAST(동적 애플리케이션 보안 테스트) 는 구동 중인 애플리케이션에 외부에서 실제 공격성 요청을 보내 반응을 관찰한다. 소스코드 없이 블랙박스로 접근하므로 공격자의 실제 시선과 가장 유사하며, 서버 설정 오류·인증 우회·세션 관리 결함처럼 코드만 봐서는 드러나지 않는 배포·구성 수준의 취약점을 포착한다. 예컨대 DAST는 입력 폼에 ' OR '1'='1 같은 페이로드를 주입하고 응답의 오류 메시지·지연·반환 데이터를 분석해 실제 악용 가능 여부를 증명한다.

DAST의 강점은 낮은 오탐과 실증성이다. 실제로 응답을 끌어낸 것이므로 보고된 취약점은 대체로 진짜 악용 가능하다. 그러나 애플리케이션이 완성되어 구동 가능해야 하므로 발견이 늦고, 스캐너가 도달하지 못한 화면·API는 검사되지 않아 커버리지가 불완전하며, 취약점이 코드의 어디에서 비롯됐는지 알려주지 못해 수정 지점 파악에 추가 분석이 필요하다. 또한 상태를 가진 복잡한 워크플로나 인증이 필요한 영역의 자동 탐색이 어렵다는 점도 한계다.

최근에는 SPA(Single Page Application)·GraphQL·마이크로서비스처럼 화면과 API가 복잡하게 얽힌 구조가 보편화되면서, 전통적 크롤링 기반 DAST의 커버리지 공백이 더 커졌다. 이를 보완하기 위해 API 명세(OpenAPI/Swagger)를 입력으로 받아 엔드포인트를 체계적으로 탐색하는 API 중심 DAST와, IAST 에이전트가 수집한 내부 경로 정보로 스캔 범위를 안내받는 하이브리드 방식이 확산되고 있다. 이는 "외부만 보는" DAST의 근본 한계를 내부 가시성으로 보완하려는 시도다.

다. IAST(대화형 애플리케이션 보안 테스트) 는 SAST와 DAST의 간극을 메우기 위해 등장했다. 애플리케이션 실행 환경(예: JVM·런타임)에 계측 에이전트를 심어, 기능 테스트나 DAST가 애플리케이션을 구동시키는 동안 내부에서 데이터 흐름·함수 호출·실제 쿼리 실행을 관찰한다. 즉 외부 요청(동적)과 내부 코드 경로(정적 수준의 정보)를 동시에 확보하므로, "실제로 실행된 취약한 경로"만 정확한 코드 위치와 함께 보고한다.

IAST의 결정적 장점은 극히 낮은 오탐과 정확한 위치 제시의 양립이다. 실행된 흐름만 보므로 도달 불가능 경로의 오탐이 사라지고, 내부 계측 덕분에 취약점의 코드 라인을 집어낸다. 또한 CI 파이프라인의 기능 테스트에 얹혀 자동으로 돌아가므로 별도 스캔 시간이 거의 들지 않는다. 다만 에이전트가 특정 언어·런타임에 종속되어 지원 스택이 제한적이고, 런타임 계측이 성능에 약간의 부하를 주며, 무엇보다 테스트가 실행한 경로만 본다는 점에서 커버리지가 기능 테스트의 품질에 좌우되는 한계가 있다.

라. SCA(소프트웨어 구성 분석) 는 앞의 세 기법이 "직접 작성한 코드"를 보는 것과 달리 가져다 쓴 오픈소스·서드파티 구성요소를 분석한다. 프로젝트의 의존성 트리를 해석해 SBOM(Software Bill of Materials)을 만들고, 각 구성요소의 버전을 알려진 취약점 데이터베이스(NVD/CVE)와 대조하며, 라이선스 위반 여부까지 점검한다. 현대 애플리케이션 코드의 대부분이 오픈소스인 현실에서 SCA는 선택이 아닌 필수가 되었고, Log4Shell 사태 이후 공급망 보안의 핵심 축으로 부상했다.

SCA의 어려움은 전이 의존성(Transitive Dependency)에 있다. 개발자가 직접 선언한 라이브러리(직접 의존성)는 통제 범위에 있지만, 그 라이브러리가 다시 끌어오는 수십~수백 개의 하위 의존성은 개발자의 시야 밖에 있으면서도 동일한 실행 권한을 갖는다. 실제 취약점의 상당수가 이 전이 의존성에 숨어 있으므로, 성숙한 SCA는 전체 의존성 그래프를 재귀적으로 해석하고, 나아가 "취약한 함수가 실제로 호출되는가"를 분석하는 도달 가능성(Reachability) 분석으로 수정 우선순위를 가린다. 모든 CVE를 같은 무게로 다루면 다시 경보 피로에 빠지기 때문이다.

4. 기법 비교와 적용 사례

네 기법의 차이는 단순한 기능 차이가 아니라 "애플리케이션의 어느 표현을, 어느 시점에 본다"는 관찰 지점의 차이에서 비롯되며, 그 차이가 곧 오탐률·발견 시점·수정 용이성의 구조적 차이를 만든다. 아래 표는 핵심 축을 정리한 것이다.

구분 SAST DAST IAST SCA
분석 대상 소스/바이트코드 구동 중 앱(외부) 구동 중 앱(내부 계측) 오픈소스 의존성
접근 방식 화이트박스 블랙박스 그레이박스 구성요소 대조
적용 시점 개발 초기 테스트/스테이징 빌드·통합 개발 초기
오탐 경향 높음 낮음 매우 낮음 낮음
수정 위치 제시 정확(코드) 어려움 정확(코드) 구성요소 단위
대표 한계 경보 피로 늦은 발견·커버리지 스택 종속·경로 의존 알려진 취약점만

표의 수치적 경향을 뒷받침하는 원리는 "관찰 정보량"의 차이다. SAST는 모든 코드 경로를 보지만 실행 맥락이 없어 거짓 경고가 많고(오탐↑), DAST는 실행 반응만 보므로 거짓은 적지만 코드 내부를 몰라 수정 위치를 못 짚는다. IAST는 실행과 코드 내부를 동시에 보므로 오탐이 가장 낮고 위치도 정확하지만, 본 것이 "실행된 경로"뿐이라 커버리지가 테스트 품질에 종속된다. 즉 세 기법의 장단점은 설계 철학이 아니라 각 기법이 접근할 수 있는 정보의 종류와 양에서 구조적으로 결정된다.

이 비교의 핵심은 어느 하나가 우월하다는 것이 아니라 상호 보완적이라는 데 있다. SAST는 완전한 커버리지로 조기에 잡지만 오탐이 많고, DAST는 실증적이지만 늦고 불완전하며, IAST는 둘의 장점을 취하되 실행된 경로에 한정된다. 따라서 성숙한 조직은 "SAST+SCA로 왼쪽을 넓게 거르고, IAST로 CI에서 정밀하게 확인하며, DAST+모의해킹으로 배포 직전 실증한다"는 다층 조합 전략을 취한다. 어느 하나만 도입하면 반드시 사각지대가 남는다.

구체 사례로, 2017년 Equifax 침해는 Apache Struts의 알려진 원격코드실행 취약점(CVE-2017-5638)을 패치하지 않아 약 1억 4,700만 명의 개인정보가 유출된 사건이다. 이 취약점은 조직이 작성한 코드가 아니라 가져다 쓴 프레임워크에 있었으므로 SAST로는 잡기 어렵고 SCA가 즉시 경고했을 영역이다. 이 사건은 공급망 구성요소 관리(SCA·SBOM)의 중요성을 전 산업에 각인시켰다.

또 다른 사례로 2021년 Log4Shell(CVE-2021-44228)은 전 세계적으로 쓰이는 로깅 라이브러리 Log4j의 결함으로, 수억 대의 시스템이 영향을 받았다. 많은 조직이 "우리가 Log4j를 어디에 쓰는지조차 모른다"는 가시성 부재에 직면했고, 이는 정확한 SBOM과 SCA 자동화가 없으면 공급망 사고에 속수무책임을 보여준 전환점이 되었다. 세 번째로, 한 금융 핀테크 기업은 CI 파이프라인에 IAST를 도입한 뒤 기존 SAST 대비 오탐을 80% 이상 줄이고 평균 취약점 수정 리드타임을 수주에서 수일로 단축했다고 보고하는데, 이는 "오탐 감소가 곧 개발자 신뢰와 수정 속도로 직결된다"는 IAST의 실무 가치를 보여준다.

5. 심화 — DevSecOps·ASPM·AI 기반 최신 동향

최근 애플리케이션 보안 테스트의 가장 큰 흐름은 DevSecOps로의 완전한 내재화다. 과거처럼 출시 직전 보안팀이 한 번 점검하는 "게이트키퍼" 모델은 속도를 요구하는 애자일·클라우드 네이티브 환경과 충돌한다. 대신 보안 테스트가 코드 커밋·PR·빌드의 각 단계에 자동 단계로 심어져, 개발자가 자신의 워크플로 안에서 즉시 피드백을 받는 방향으로 진화했다. 핵심 지표는 "얼마나 많은 취약점을 찾았는가"가 아니라 "개발자가 실제로 고치는가"로 바뀌었고, 이에 따라 오탐을 줄이고 수정 가이드를 제시하는 개발자 경험(DevEx)이 도구 선택의 핵심 기준이 되었다.

두 번째 동향은 ASPM(Application Security Posture Management)의 부상이다. SAST·DAST·IAST·SCA를 따로 운영하면 같은 취약점이 중복 보고되고, 어느 것이 진짜 위험한지 판단하기 어렵다. ASPM은 여러 도구의 결과를 한 플랫폼으로 집계·정규화하고, 코드-빌드-실행-운영의 맥락을 연결해 악용 가능성(Reachability)과 비즈니스 영향을 기준으로 위험을 상관·우선순위화한다. 이는 "도구의 나열"에서 "위험의 통합 관리"로 보안 테스트의 중심을 옮기는 변화다.

세 번째는 AI/LLM의 양면적 영향이다. 방어 측면에서 생성형 AI는 취약점의 근본 원인을 자연어로 설명하고 수정 코드(Patch)를 제안해 개발자의 부담을 덜며, 오탐을 맥락으로 선별하는 지능형 트리아지에 활용된다. 반면 공격 측면에서는 AI 코딩 도우미가 생성한 코드에 취약점이 섞여 들어오거나, 프롬프트 인젝션 같은 LLM 고유의 새로운 취약점이 등장하면서, 전통적 SAST·DAST가 다루지 못하는 영역이 생겨났다. 이에 따라 AI가 생성·구동하는 애플리케이션을 겨냥한 보안 테스트 기법 자체가 새로운 연구 영역으로 떠오르고 있다. 아울러 공급망 보안 규제(미국 행정명령 14028, EU CRA 등)가 SBOM 제출을 의무화하면서 SCA의 전략적 비중도 급상승하고 있다.

6. 고려사항 및 시사점

기술사 관점에서 애플리케이션 보안 테스트 도입은 도구 선정이 아니라 프로세스·문화·거버넌스를 아우르는 전략 과제로 접근해야 한다.

  • 단일 기법 환상 배격과 다층 조합 전략: SAST·DAST·IAST·SCA는 서로의 사각지대를 메우는 보완 관계이므로 어느 하나로 보안을 완결하려는 발상은 위험하다. 조직의 기술 스택·규제 요구·성숙도에 맞춰 조합을 설계하되, 초기에는 SCA·SAST로 넓게 시작해 IAST·DAST로 정밀도를 높이는 단계적 확장 로드맵을 권고한다. 중요 시스템은 자동화로 못 잡는 비즈니스 로직 결함을 위해 전문가 모의해킹을 병행한다.

  • 오탐 관리와 개발자 수용성의 트레이드오프: 보안 테스트의 성패는 탐지율이 아니라 개발자가 결과를 신뢰하고 고치느냐에 달렸다. 오탐이 넘치면 도구는 무시당하고 보안은 형식화된다. 따라서 룰 튜닝·베이스라인 설정·위험 기반 선별로 "신호 대 잡음비"를 관리하고, IDE·PR 통합과 수정 가이드로 마찰을 최소화해야 한다. 기술은 정확도뿐 아니라 수용성(Adoption)으로 평가되어야 한다.

  • 파이프라인 통합과 속도의 균형: CI/CD에 보안 단계를 넣되 빌드를 과도하게 지연시키면 개발 속도와 충돌한다. 증분 스캔(변경분만 분석)·병렬화·위험도에 따른 차등 게이트(치명적 결함만 빌드 차단)로 속도와 안전을 양립시켜야 한다. "보안이 배포를 막는다"는 인식이 생기면 우회 문화가 자라므로 거버넌스 설계가 중요하다.

  • 공급망·SBOM 거버넌스와 규제 대응: 코드의 대부분이 오픈소스인 현실에서 SCA와 SBOM은 선택이 아니라 규제 대응(EU CRA, 미국 SBOM 의무화)의 요건이 되었다. 의존성의 지속적 모니터링, 취약 구성요소의 신속한 업데이트 정책, 라이선스 리스크 관리를 제도화해야 하며, 이는 공급망 공격(Log4Shell형)에 대한 조직의 회복력을 좌우한다.

  • 아키텍처 연계와 전망: 보안 테스트는 단독으로는 가치가 제한적이며 ASPM으로 결과를 통합하고, RASP·WAF 같은 런타임 보호, 위협 모델링·시큐어 코딩 같은 설계 단계 활동과 연결될 때 비로소 폐루프가 완성된다. 향후에는 AI 기반 자동 수정과 악용 가능성 분석으로 "탐지에서 자율 대응"으로 진화할 전망이므로, 조직은 보안 테스트를 개별 도구가 아닌 공통 보안 플랫폼 계층으로 포지셔닝하고 표준(OWASP·SARIF 등) 기반의 연계를 전제로 선정하는 것이 바람직하다.

참고자료

한 줄 요약: 애플리케이션 보안 테스트는 코드를 정적 분석하는 SAST, 구동 앱을 외부 공격하는 DAST, 런타임 계측으로 내부를 관찰하는 IAST, 오픈소스를 대조하는 SCA를 SDLC 단계별로 조합해 취약점을 겹겹이 걸러내는 다층 방어 체계로, DevSecOps 내재화와 ASPM·AI 기반 통합 관리로 진화하고 있다.