애플리케이션 보안이란? 완벽 가이드

애플리케이션 보안이란?

취약한 API 엔드포인트 하나, 패치되지 않은 오픈소스 라이브러리 하나, 프로덕션 환경에서 실행 중인 잘못 구성된 컨테이너 하나. 이 중 어느 하나라도 공격자에게 환경에 대한 접근 권한을 넘겨줄 수 있습니다. Verizon DBIR는 취약점 악용이 침해 사고의 초기 접근 벡터로 점점 더 흔해지고 있음을 확인합니다.

애플리케이션 보안(AppSec)은 소프트웨어 개발 생명주기(SDLC) 전반에 걸쳐 애플리케이션의 취약점을 탐지, 수정, 보호하기 위해 사용하는 프로세스, 관행, 도구를 포괄합니다. 범위는 애플리케이션 코드뿐만 아니라 시스템 설정, API, 데이터베이스, 서드파티 라이브러리, 그리고 애플리케이션이 실행되는 인프라까지 확장됩니다.

애플리케이션 보안 테스트(AST)는 수동 기법과 특화된 도구를 모두 활용하여 소프트웨어의 보안 취약점, 컴플라이언스 문제, 악용 가능한 결함을 식별하는 분석 분야입니다. AST는 SDLC 전반, 즉 코드 작성 초기부터 프로덕션 런타임까지 적용되며, 목표는 공격자가 악용하기 전에 취약점을 찾아내고 수정하는 것입니다.

AppSec는 독립적으로 운영되지 않습니다. 조직의 전체 보안 프로그램 내에서 AppSec의 위치를 이해하는 것이 커버리지의 공백을 방지하는 데 필수적입니다.

애플리케이션 보안이 중요한 이유

AppSec는 조직의 광범위한 사이버보안 전략 내에서 특정 계층을 차지합니다. 네트워크 보안이 데이터 전송, 경계, 인프라 세그먼트를 보호하는 반면, 애플리케이션 보안은 해당 인프라 위에서 실행되는 소프트웨어 논리, 인터페이스, 데이터 처리를 보호합니다.

이 두 분야는 상호 보완적이며, 대체할 수 없습니다. 방화벽은 경계에서 악성 트래픽을 차단합니다. 애플리케이션 보안은 코드의 결함을 악용하는 SQL 인젝션 공격을 차단합니다. 두 가지를 혼동하는 전략은 애플리케이션 계층에서 미해결 노출을 남기며, 이는 공격자들이 점점 더 집중하는 영역입니다.

이러한 융합은 계속 심화되고 있습니다. OWASP Top 10 문서는 여러 주요 위험이 프로덕션에서만 나타난다고 명시하며, 애플리케이션 보안이 빌드 단계에서 멈출 수 없음을 확인합니다. 엔드포인트 보호, 클라우드 워크로드 보안, AppSec 도구가 런타임 가시성에서 통합 방어로 결합되어야 합니다.

도구를 선택하기 전에, 해당 도구가 해결하도록 설계된 위협을 이해해야 합니다.

일반적인 애플리케이션 보안 위협

OWASP Top 10:2025는 웹 애플리케이션에 가장 널리 퍼진 위험을 정의합니다. 이 카테고리는 AppSec 팀이 테스트 및 런타임 방어의 우선순위를 정하는 데 영향을 줍니다.

가장 영향력 있는 카테고리는 다음과 같습니다:

권한 제어 실패는 여전히 최상위 위험입니다. 인가 논리의 결함으로 인해 공격자가 의도된 권한을 벗어난 데이터나 기능에 접근할 수 있습니다.
인젝션 결함은 SQL 인젝션 및 크로스사이트 스크립팅(XSS)과 같이, 공격자가 정제되지 않은 입력 필드를 통해 악성 코드를 삽입하여 데이터베이스와 사용자 세션을 위협합니다.
소프트웨어 공급망 실패는 취약한 오픈소스 구성요소, 손상된 종속성, 서드파티 코드의 불충분한 검증에서 비롯된 위험을 포함합니다. CISA는 npm 생태계에 영향을 미치는 공급망 침해에 대한 공식 경고를 발령했습니다.
보안 설정 오류는 기본 자격 증명, 불필요한 서비스, 과도하게 허용된 클라우드 설정 등 애플리케이션을 악용에 노출시키는 요소를 포함합니다.
암호화 실패는 약한 암호화, 노출된 키, 전송 계층 보안 미비 등으로 인해 민감한 데이터가 전송 중 또는 저장 중에 평문으로 노출될 수 있습니다.
서버 측 요청 위조(SSRF)는 공격자가 애플리케이션을 이용해 내부 리소스에 요청을 보내도록 하여, 종종 방화벽과 접근 제어를 우회할 수 있게 합니다.

각 카테고리는 애플리케이션 스택의 서로 다른 부분을 겨냥합니다. 다음 섹션에서 다루는 도구와 관행은 이러한 위험에 직접적으로 대응합니다.

애플리케이션 보안의 핵심 구성요소

AppSec 프로그램은 SDLC의 각 단계별로 여섯 가지 주요 도구에 의존합니다.

SAST(정적 애플리케이션 보안 테스트)는 애플리케이션을 실행하지 않고 소스 코드, 바이트코드, 바이너리 코드를 분석하여 보안 결함을 찾습니다. 이 화이트박스 방식은 SQL 인젝션, XSS, 버퍼 오버플로우 등 취약점을 코드에서 직접 찾아내며, 수정이 필요한 정확한 라인을 안내합니다. 개발 단계에서 작동하여 파이프라인 내에서 가장 이른 보안 통제입니다.
DAST(동적 애플리케이션 보안 테스트)는 반대 접근법을 취합니다. 실행 중인 애플리케이션을 외부에서 테스트하여 런타임에만 나타나는 취약점에 대한 실제 공격을 시뮬레이션합니다. 이 블랙박스 방식은 소스 코드 접근이 필요 없으며, QA, 스테이징, 프로덕션 단계에서 인증 실패, 서버 설정 오류, API 취약점을 탐지합니다.
SCA(소프트웨어 구성 분석)는 애플리케이션 내 오픈소스 구성요소와 서드파티 라이브러리를 스캔하여 알려진 CVE 및 라이선스 컴플라이언스 위험을 식별합니다. OWASP Top 10이 소프트웨어 공급망 실패를 주요 위험으로 분류함에 따라, SCA는 기본 통제로 자리잡았습니다. 초기 개발부터 프로덕션까지 지속적으로 실행됩니다.
IAST(인터랙티브 애플리케이션 보안 테스트)는 기능 테스트 중 에이전트를 통해 애플리케이션 내부에서 작동하며, SAST와 DAST의 요소를 결합해 런타임 코드 취약점을 실시간으로 분석하고 오탐률이 낮습니다. NIST 800-53 SA-11(9)는 결함 식별 및 결과 문서화를 위해 IAST 도구 사용을 명시적으로 요구합니다.
RASP(런타임 애플리케이션 자체 보호)는 보안 기능을 애플리케이션에 직접 통합하여 배포 후 보호합니다. RASP는 사전 배포 테스트를 보완하며, 프로덕션 환경 내에서 실시간으로 익스플로잇을 차단합니다. NIST 800-53 SI-7(17)은 런타임 자체 보호 통제를 요구합니다.
WAF(웹 애플리케이션 방화벽)은 웹 애플리케이션과 인터넷 간의 HTTP 트래픽을 필터링 및 모니터링합니다. 네트워크 경계에서 작동하며, OWASP 룰셋과 같은 규칙을 사용해 SQL 인젝션, XSS, 로컬 파일 포함 등 일반적인 웹 공격을 방어합니다.

다음 표는 이러한 도구가 SDLC 전반에서 어떻게 다른지 요약합니다:

도구	SDLC 단계	접근 방식	주요 커버리지
SAST	개발	화이트박스(소스 코드)	코드 수준 결함: 인젝션, XSS, 버퍼 오버플로우
DAST	QA / 스테이징	블랙박스(실행 중 앱)	인증, 설정 오류, API 결함
SCA	개발 → 프로덕션	종속성 스캔	오픈소스 CVE, 라이선스 컴플라이언스
IAST	기능 테스트	에이전트 기반(앱 내부)	오탐률이 낮은 런타임 코드 결함
RASP	프로덕션	인사이드-아웃(내장형)	실시간 익스플로잇 차단
WAF	프로덕션	아웃사이드-인(네트워크 경계)	HTTP 계층 공격: SQLi, XSS, 파일 포함

SAST와 DAST는 서로 다른 인사이트를 제공하며, 어느 하나가 다른 것을 대체하지 않습니다. 런타임에서는 WAF가 네트워크 계층에서 아웃사이드-인 방식으로, RASP는 애플리케이션 내부에서 인사이드-아웃 방식으로 작동합니다.

각 도구의 역할을 이해하는 것만으로는 충분하지 않습니다. 실제로는 개발 및 배포 파이프라인 전반에서 이들이 어떻게 연계되는지가 핵심입니다.

애플리케이션 보안의 작동 방식

AppSec는 SDLC의 모든 단계에 보안 통제를 내장하여, 가능한 한 이른 시점에 문제를 발견해 수정 비용을 최소화하는 시프트 레프트 원칙을 따릅니다.

OWASP DevSecOps 가이드라인은 다음과 같은 순차적 파이프라인을 명시합니다:

Git 저장소에서 자격 증명 유출 스캔
SAST(소스 코드 정적 분석)
SCA(오픈소스 종속성 스캔)
IAST(QA 중 에이전트 기반 테스트)
DAST(실행 중 애플리케이션 블랙박스 테스트)
설정 오류 탐지를 위한 인프라스트럭처-애즈-코드 스캔
인프라 스캔
컴플라이언스 점검

실제 환경에서는 CI/CD 파이프라인이 매 빌드마다 SAST와 SCA를 실행합니다. 개발자가 코드를 커밋하면, 툴체인은 빌드 완료 전에 취약한 서드파티 라이브러리와 코드 결함을 플래그합니다. IAST 에이전트는 기능 테스트 중 활성화되어 런타임 컨텍스트에서 취약점을 포착합니다. DAST 스캐너는 릴리스 전 스테이징 환경을 점검합니다.

배포 후에는 RASP와 WAF가 런타임 방어를 제공합니다. 엔드포인트 및 클라우드 워크로드 보호 계층은 AppSec 테스트 도구가 제공하지 못하는 행위 기반 모니터링을 추가하여, 제로데이, 설정 오류, 프로덕션에서만 나타나는 위협을 커버합니다.

문제는 이 파이프라인이 대량의 취약점 데이터를 생성한다는 점입니다. SAST, DAST, SCA 결과에는 오탐과 중복이 포함됩니다. 기존 AppSec 도구는 개별 취약점은 찾지만, 소프트웨어 아키텍처를 이해하거나 비즈니스 위험 기반으로 우선순위를 정하지 못합니다. Cloud Security Alliance가 문서화한 바와 같이, 이 격차로 인해 애플리케이션 보안 태세 관리(ASPM) 도입이 증가하고 있습니다.

이 파이프라인이 효과적으로 작동하면, 툴체인은 알려진 취약점 유형을 대규모로 처리할 수 있습니다. 그러나 스캐닝만으로는 성숙한 테스트 프로그램의 한 축에 불과합니다.

애플리케이션 보안 테스트 방법

완전한 테스트 프로그램은 스캐닝 도구를 넘어, 애플리케이션 논리, 비즈니스 워크플로우, 사전 정의된 점검으로는 놓칠 수 있는 공격 경로까지 평가합니다.

가장 효과적인 방법은 다음과 같습니다:

침투 테스트는 숙련된 테스터가 실제 공격을 시뮬레이션하여 취약점 연결, 비즈니스 논리 테스트, 애플리케이션 경계 간 권한 상승 시도를 수행합니다. OWASP 테스트 가이드는 신원 관리, 인증, 인가, 세션 관리, 입력 검증, 비즈니스 논리 테스트를 포괄하는 구조화된 방법론을 제공합니다. 조직은 일반적으로 분기별 또는 주요 릴리스 후 침투 테스트를 실시합니다.
위협 모델링은 코드 작성 전 설계 단계에서 보안 위험을 식별합니다. STRIDE 및 PASTA와 같은 프레임워크는 개발팀이 데이터 흐름을 매핑하고, 신뢰 경계를 식별하며, 아키텍처 위험의 우선순위를 정하는 데 도움을 줍니다. NIST SP 800-218(SSDF)은 "보안이 잘 된 소프트웨어 생산" 그룹의 핵심 관행으로 위협 모델링을 포함합니다.
퍼즈 테스트는 애플리케이션 입력에 비정상적이거나 무작위 데이터를 전송하여 크래시, 메모리 누수, 처리되지 않은 예외를 유발합니다. 퍼저는 프로토콜, 파일 포맷, API 수준에서 작동하며, 구조화된 테스트 케이스로는 발견하기 어려운 엣지 케이스 취약점을 노출합니다.
API 보안 테스트는 애플리케이션 구성요소, 마이크로서비스, 서드파티 통합을 연결하는 인터페이스를 대상으로 합니다. OWASP API Security Top 10은 API 위험 중 가장 중요한 항목(객체 수준 인가 실패, 인증 실패, 무제한 리소스 소비 등)을 정의합니다.
수동 코드 리뷰는 SAST를 보완하여, 스캐너가 오탐을 내는 복잡한 논리, 암호화 구현, 인가 모델에 대해 인간의 판단을 적용합니다. 이 방법은 위협 모델링을 통해 식별된 고위험 코드 경로에 집중할 때 가장 효과적입니다.

이전 섹션에서 설명한 스캐닝 도구와 결합하면, 이러한 방법은 프로그램의 실질적 효과를 이끄는 커버리지 깊이를 제공합니다.

애플리케이션 보안의 주요 이점

성숙한 AppSec 프로그램은 보안 태세, 컴플라이언스 준비, 위험 감소 등에서 측정 가능한 효과를 제공합니다.

SDLC 전체에 걸친 측정 가능한 보안 태세. SAMM 프레임워크는 조직이 거버넌스, 설계, 구현, 검증, 운영 등 5개 비즈니스 기능 전반에서 소프트웨어 보안 태세를 분석하고 개선할 수 있는 효과적이고 측정 가능한 방법을 제공합니다. Dell은 OWASP SAMM을 활용해 자원을 집중하고, 보안 개발 프로그램의 우선순위를 결정합니다.

구조화된 경영진 커뮤니케이션. SAMM은 경영진 수준에서 보안 메시지를 효과적으로 전달하고 시프트 레프트 도입을 촉진합니다. 예산을 정당화하는 CISO에게는 BSIMM과 같은 프레임워크가 동종 업계 벤치마킹을 제공하여 내부 이해관계자, 고객, 규제기관의 신뢰를 높입니다.

규제 컴플라이언스 준비. OWASP SAMM은 EU 사이버 복원력법(CRA) 등 규제 요구사항과 직접적으로 매핑됩니다. SAMM 활동은 CRA 부속서 I의 필수 보안 요구사항(위험 평가, 위협 모델링, SBOM 관리, 사고 대응 등)과 일치합니다.

표준화된 관행을 통한 취약점 부채 감소. NIST 보안 소프트웨어 개발 프레임워크(SSDF)는 네 가지 관행 그룹을 정의합니다:

조직 준비
소프트웨어 보호
보안이 잘 된 소프트웨어 생산
취약점 대응

이러한 관행을 체계적으로 따르면, 조직이 프로덕션에서 떠안는 보안 부채의 누적을 줄일 수 있습니다.

이사회 보고를 위한 정량적 위험 감소. 데이터 유출은 조직에 평균 수백만 달러의 비용을 초래하며, 취약점 악용은 초기 접근 벡터로 계속 증가하고 있습니다. 성숙한 AppSec 프로그램은 이 증가하는 침해 범주에 대한 노출을 직접적으로 줄여줍니다.

이러한 이점은 실질적이지만, 이를 실현하려면 상당한 운영 및 조직적 장벽을 극복해야 합니다.

애플리케이션 보안의 과제

효과적인 AppSec 프로그램 구축은 어느 단계에서든 진행을 저해할 수 있는 조직적, 기술적, 자원적 장벽을 해결해야 합니다.

DevSecOps 문화적 마찰. 다양한 소프트웨어 아키텍처, 여러 언어, 다양한 개발 생명주기 전반에 AppSec를 확장하는 것이 핵심 운영 과제입니다. 보안을 통합된 전달 기능이 아닌 게이트로 보는 팀은 도입 저항에 직면합니다.
도구 난립과 단편화된 가시성. 여러 스캐닝 도구가 별도의 대시보드와 상이한 취약점 분류 체계를 제공하면, 팀은 결과를 수동으로 집계하고 중복 제거해야 합니다. 기존 SAST, DAST, SCA 도구는 개별 결함은 찾지만, 비즈니스 위험이나 아키텍처 맥락에 따라 우선순위를 정하지 못합니다.
사전 배포/런타임 간극. 시프트 레프트 테스트는 배포 전 코드 수준 취약점을 포착합니다. 그러나 프로덕션 환경은 런타임 위협, 제로데이, 설정 오류, 공급망 침해에 여전히 노출됩니다. Verizon 2025 DBIR는 많은 엣지 디바이스 취약점이 관찰 기간 내내 패치되지 않았음을 보여줍니다. 사전 배포 스캐닝에만 의존하는 프로그램은 프로덕션에서 맹점이 생깁니다. NIST 800-53은 IAST(SA-11(9))와 RASP(SI-7(17)) 통제를 모두 요구하는데, 이는 테스트와 런타임 보호가 서로 다른 기능을 수행하기 때문입니다.
인력 부족이라는 제약. SANS Institute는 숙련된 인력이 효과적인 보안 운영의 핵심 전제임을 지적합니다. 기술은 인적 역량의 배가이지, 대체가 아닙니다. 경험 있는 보안 인력이 없으면, 조직은 AppSec 도구를 운영화하고 결과에 신속히 대응하는 데 어려움을 겪습니다.

이러한 과제는 거버넌스, 자동화, 런타임 커버리지에 기반한 체계적 실천이 필요합니다.

애플리케이션 보안 모범 사례

다음 실천 방안은 조직 정렬부터 프로덕션 수준 방어까지 이러한 장벽을 직접적으로 해결합니다.

프로그램을 거버넌스에 기반하여 시작하십시오. SAMM의 거버넌스 비즈니스 기능(전략 및 지표, 정책 및 컴플라이언스, 교육 및 가이드)은 구조적 기반입니다. 이는 보안 태세, 기존 위협, 리더십의 위험 허용도를 조직 전체에 공유합니다. OWASP SAMM 실무 자료는 AppSec가 개발팀뿐 아니라 거버넌스, 설계, 운영 등 다양한 이해관계자가 필요함을 강조합니다. 프레임워크를 선택하기 전에 다음 정렬 질문을 해결해야 합니다:

조직이 접근 방식에 동의하는가?
프레임워크가 환경에 맞게 맞춤화가 필요한가?
예산이 확보되고 계획되어 있는가?

이 단계를 건너뛰면 도입률 저하와 투자 낭비로 이어집니다.

보안 챔피언을 배치하고 역할을 정의하십시오. 보안 챔피언 모델은 개발팀이 보안 책임을 주도하도록 하여, 기존 보안 모델이 빠른 환경에서 병목을 유발하는 문제를 해결합니다. OWASP Cincinnati가 문서화한 바와 같이, NIST SSDF는 조직이 프레임워크 전반에 걸쳐 새로운 역할을 만들고 기존 책임을 변경할 것을 요구합니다. 명확한 역할 정의 없이는 보안이 후반부에 추가되는 부가 기능이 됩니다.

서드파티 취약점 스캔을 자동화하십시오. NIST SP 800-218은 소프트웨어 구성요소에 대한 자율적 취약점 스캔을 툴체인에 내장하고, 상용 및 오픈소스 구성요소가 라이프사이클 전반에 걸쳐 요구사항을 준수하는지 검증할 것을 명시합니다. 오픈소스 종속성의 수동 검토는 지속 불가능하므로, 서드파티 검토는 핵심 프로그램 책임입니다.

OWASP ASVS로 검증을 표준화하십시오. OWASP ASVS는 웹 애플리케이션 기술 보안 통제 테스트의 기준을 제공하여, SDLC 모든 단계에서 공통 기준을 만듭니다.

위험 기반 우선순위 적용. NIST SSDF는 비용, 실행 가능성, 적용성을 고려해 어떤 관행을 도입하고, 얼마만큼의 시간과 자원을 투입할지 결정할 것을 명시합니다. SAMM + CRA 가이드는 실용적 공식(우선순위 = CRA 위험 중요도 × SAMM 성숙도 격차)으로 이를 보완합니다. 이 필터 없이 프로그램은 결과를 내기 전에 정체됩니다. 모든 관행이 모든 조직에 동일하게 적용되는 것은 아닙니다.

보호를 런타임까지 확장하십시오. 런타임 방어 없이는 AppSec 프로그램이 완전하지 않습니다. 시프트 레프트 테스트와 RASP, 클라우드 워크로드 보호, 엔드포인트 행위 모니터링을 결합해, 사전 배포 스캐닝으로는 도달할 수 없는 프로덕션 위협을 커버하십시오.

이러한 실천은 2026년까지 애플리케이션 보안을 재편하는 트렌드에 대응할 수 있도록 프로그램을 준비시킵니다.

애플리케이션 보안 트렌드: 2025년과 2026년

AI 기반 공격부터 플랫폼 통합까지, 여러 변화가 조직의 애플리케이션 보안 접근 방식을 재편하고 있습니다.

AI가 공격 표면을 확장하고 있습니다. 위협 행위자는 엔터프라이즈 애플리케이션 내 AI 통합을 통해 도입된 취약점을 노리고 있습니다. OWASP는 2025년 Securing Agentic Applications Guide v1.0을 발표하여 AI 에이전트 개발자를 위한 보안 권고를 제공합니다. 영국 국가사이버보안센터는 생성형 AI 애플리케이션에 대한 프롬프트 인젝션 공격이 완전히 차단되지 않을 수 있음을 경고하며, 조직이 위험 감소와 영향 제한에 집중할 것을 권고합니다.
플랫폼 통합이 가속화되고 있습니다. KuppingerCole의 Research Compass Cybersecurity 2026은 XDR과 CNAPP가 EDR 및 SIEM 도구를 대체하며, 자율적 대응을 위한 통합 데이터 소스를 제공할 것으로 전망합니다. 런타임 보호는 CNAPP의 주요 차별화 요소로 부상하고 있으며, 조직은 태세 스캔과 함께 행위 모니터링을 요구하고 있습니다.
AppSec/런타임 경계가 좁아지고 있습니다. 개발 시점 보안 테스트와 프로덕션 시점 보호 간의 전통적 분리가 해소되고 있습니다. 조직은 AppSec 결과, 런타임 텔레메트리, SOC 대응을 통합 워크플로우로 연결하여 기술적 노출과 비즈니스 영향 간의 연계를 강화하고 있습니다.

이러한 융합이야말로 플랫폼 접근 방식이 가장 큰 가치를 제공하는 지점입니다.

AI 기반 사이버 보안

실시간 감지, 머신 속도 대응, 전체 디지털 환경에 대한 종합적인 가시성을 통해 보안 태세를 강화하세요.

데모 신청하기

핵심 요약

애플리케이션 보안은 SAST, DAST, SCA, IAST, RASP, WAF를 SDLC 각 단계에 적용하여 소프트웨어를 코드부터 프로덕션까지 보호합니다. 취약점 악용과 공급망 침해가 증가함에 따라, 사전 배포 테스트만으로는 충분하지 않습니다.

런타임 보호는 파이프라인 스캐닝과 프로덕션 방어 간의 중요한 간극을 해소합니다. OWASP SAMM과 NIST SSDF를 기반으로 프로그램을 구축하고, 서드파티 취약점 스캔을 자동화하며, 행위 모니터링을 프로덕션 워크로드까지 확장하십시오.

자주 묻는 질문

애플리케이션 보안(AppSec)은 개발 생명주기 전반에 걸쳐 소프트웨어의 취약점을 발견, 수정, 예방하는 실천입니다. 소스 코드, API, 서드파티 라이브러리, 시스템 구성, 애플리케이션이 실행되는 인프라를 모두 포함합니다.

AppSec 프로그램은 테스트 도구(SAST, DAST, SCA, IAST)와 런타임 방어(RASP, WAF)를 결합하여 코드부터 운영 환경까지 애플리케이션을 보호합니다.

SAST는 애플리케이션을 실행하지 않고 소스 코드를 분석하는 방식(화이트박스 테스트)으로, 개발 단계에서 SQL 인젝션, XSS와 같은 결함을 찾아냅니다. DAST는 실행 중인 애플리케이션을 외부에서 테스트하는 방식(블랙박스 테스트)으로, 인증 실패나 서버 오구성 등 런타임 문제를 발견합니다.

SAST는 정확한 코드 라인을 안내합니다. DAST는 공격자가 볼 수 있는 결과를 보여줍니다. 두 방식은 서로 대체할 수 없으며, 모두 사용해야 완전한 커버리지가 가능합니다.

애플리케이션 보안은 소프트웨어 계층을 보호합니다: 코드 로직, API, 데이터 처리, 서드파티 구성 요소 등입니다. 네트워크 보안은 인프라 계층을 보호합니다: 전송 중인 데이터, 경계, 네트워크 세그먼트를 방화벽, VPN, IDS/IPS를 통해 보호합니다.

WAF는 네트워크 경계에서 HTTP 트래픽을 필터링하여 웹 애플리케이션을 보호함으로써 두 영역을 모두 연결합니다. 대부분의 조직은 두 가지가 함께 작동해야 하며, 방화벽만으로는 코드 내 SQL 인젝션 취약점을 차단할 수 없습니다.

OWASP Top 10:2025에서는 소프트웨어 공급망 실패를 주요 위험 요소 중 하나로 선정했습니다. CISA는 2025년 9월, 최초의 성공적인 자기 전파형 공급망 공격인 Shai-Hulud npm 웜에 대해 공식 경고를 발령했습니다.

대부분의 최신 애플리케이션이 오픈소스 구성요소에 크게 의존하고 있기 때문에, SCA는 종속성 트리 전반에 걸쳐 알려진 CVE 및 라이선스 준수 위험에 대한 지속적인 가시성을 제공합니다.

런타임 보호(RASP, CWPP, 엔드포인트 모니터링)는 SAST, DAST, SCA와 같은 배포 전 도구들이 가시성을 제공하지 못하는 배포 후 애플리케이션을 방어합니다. NIST 800-53 SI-7(17)은 런타임 애플리케이션 자체 보호 통제를 요구하는데, 이는 운영 환경에서 제로데이, 잘못된 구성, 공급망 침해와 같은 테스트만으로는 방지할 수 없는 위협에 직면하기 때문입니다.

런타임 방어는 애플리케이션이 실제로 운영될 때에만 나타나는 위협을 포괄함으로써 시프트 레프트 테스트를 보완합니다.

OWASP SAMM은 거버넌스, 설계, 구현, 검증, 운영의 5가지 비즈니스 기능 전반에 걸친 구조화된 평가를 제공합니다. BSIMM은 다른 조직과의 동료 벤치마킹을 제공합니다.

가장 효과적인 접근 방식은 SAMM의 처방적 로드맵과 BSIMM의 기술적 벤치마크를 결합하고, OWASP ASVS를 표준화된 검증 기준으로 사용하는 것입니다. 이 프레임워크들은 시간 경과에 따른 진행 상황을 반복적으로 추적하고, 격차를 식별할 수 있는 방법을 제공합니다.

주요 도구에는 SAST(소스 코드의 정적 분석), DAST(실행 중인 애플리케이션의 블랙박스 테스트), SCA(오픈 소스 종속성 스캐닝), IAST(QA 중 에이전트 기반 테스트), RASP(런타임 익스플로잇 차단), WAF(네트워크 경계에서의 HTTP 트래픽 필터링)이 포함됩니다.

스캐닝 도구 외에도, 팀은 침투 테스트, 위협 모델링, 퍼즈 테스트, 수동 코드 리뷰를 적용하여 스캐너가 놓치는 비즈니스 로직 결함과 엣지 케이스를 보완합니다. 대부분의 성숙한 프로그램은 커밋 시점의 정적 분석부터 운영 환경의 런타임 방어까지 SDLC 전반에 걸쳐 이러한 도구를 계층적으로 적용합니다.