애플리케이션 보안
더 많은 작업
애플리케이션 보안(Application Security, AppSec)은 소프트웨어 애플리케이션의 설계·개발·테스트·배포·운영·폐기 전 과정에서 보안 취약점과 위험을 식별하고 통제하여 애플리케이션과 관련 데이터 및 서비스의 기밀성·무결성·가용성을 보호하는 정보보안 분야이다.
애플리케이션 보안은 소프트웨어 자체의 보안 결함을 예방하고, 공격자가 취약점을 악용하는 것을 방지하며, 취약점이 발견되었을 때 신속하게 대응하기 위한 활동이다.
보호 대상에는 웹 애플리케이션, 모바일 앱, 데스크톱 프로그램, 서버 애플리케이션, API, 마이크로서비스, 클라우드 네이티브 애플리케이션 등이 포함된다.
애플리케이션 보안은 단순히 완성된 프로그램의 취약점을 점검하는 활동에 한정되지 않는다. 초기 설계에서 보안 요구사항을 정의하고, 개발 과정에서 안전한 코드를 작성하며, 배포 이후에도 취약점과 공격을 지속적으로 관리하는 활동을 포괄한다.
미국 국립표준기술연구소(NIST)는 안전한 소프트웨어 개발 프레임워크(SSDF)를 통해 소프트웨어 개발 생명주기에 보안 활동을 통합하여 취약점 발생을 줄이고, 발견되지 않은 취약점의 영향을 완화하며, 취약점의 근본 원인을 개선할 것을 권고한다.[1]
애플리케이션 보안은 보호 대상과 보안통제의 성격에 따라 여러 영역으로 구분된다.
| 영역 | 주요 내용 |
|---|---|
| 설계 보안 | 보안 요구사항 정의, 위협 모델링, 신뢰 경계 식별, 안전한 아키텍처 설계 |
| 시큐어 코딩 | 입력값 검증, 안전한 메모리 처리, 오류 처리 등 구현 단계의 보안 결함 예방 |
| 인증 및 인가 | 사용자 신원 확인, 세션 관리, 접근권한 검증, 권한 상승 방지 |
| 데이터 보호 | 중요정보 암호화, 비밀정보 관리, 개인정보 및 인증정보 보호 |
| 애플리케이션 보안 테스트 | 소스코드, 실행 환경, 애플리케이션 동작 및 구성요소의 취약점 분석 |
| 소프트웨어 공급망 보안 | 외부 라이브러리, 패키지, 개발·빌드·배포 과정의 무결성 및 위험 관리 |
| 배포 및 운영 보안 | 안전한 설정, 취약점 패치, 런타임 보호, 로그 및 침해 탐지 |
| 취약점 관리 | 취약점 접수, 영향도 평가, 우선순위 결정, 수정 및 재검증 |
각 영역은 상호 보완적이다. 예를 들어 애플리케이션 코드에 취약점이 없더라도 외부 라이브러리에 알려진 취약점이 있거나 배포 환경에 잘못된 접근권한이 설정되어 있다면 전체 서비스가 침해될 수 있다.
애플리케이션 보안은 소프트웨어 개발 생명주기(Software Development Life Cycle, SDLC)의 모든 단계에 반영되어야 한다.
| 단계 | 주요 보안 활동 | 산출물 및 점검 항목 |
|---|---|---|
| 기획·요구사항 | 보호 대상 식별, 데이터 중요도 분류, 보안 요구사항 정의 | 보안 요구사항 명세, 위험평가 |
| 설계 | 위협 모델링, 인증·인가 구조 설계, 신뢰 경계 검토 | 위협 모델, 보안 아키텍처 |
| 개발 | 시큐어 코딩, 보안 코드 리뷰, 정적 분석, 외부 의존성 분석 | 소스코드 분석 결과, 취약점 목록 |
| 빌드 | 빌드 환경 보호, 구성요소 분석, 산출물 무결성 검증 | SBOM, 빌드 출처 정보, 서명된 산출물 |
| 테스트 | 동적 분석, 모의해킹, API 테스트, 퍼징 | 보안 테스트 보고서, 취약점 재현 결과 |
| 배포 | 보안 설정 검증, 비밀정보 관리, 배포 승인 및 무결성 확인 | 설정 점검 결과, 배포 승인 기록 |
| 운영 | 보안 로그 분석, 침해 탐지, 취약점 모니터링, 보안 패치 | 보안 이벤트, 취약점 조치 이력 |
| 폐기 | 데이터 삭제, 인증정보 폐기, 연동 해제 | 삭제·폐기 확인 기록 |
과거에는 개발이 완료된 이후 별도로 보안 점검을 수행하는 방식이 일반적이었다. 그러나 이러한 방식은 설계상 결함을 뒤늦게 발견하거나 배포 일정과 보안 점검이 충돌하는 문제가 있다.
이를 개선하기 위해 보안 검토를 개발 초기 단계로 앞당기는 시프트 레프트(Shift Left) 접근법이 활용된다.
다만 개발 초기의 보안 점검만으로 충분한 것은 아니다. 배포 이후에도 새로운 취약점이 공개되거나 운영 환경이 변경될 수 있으므로 지속적인 모니터링과 대응이 필요하다.
애플리케이션 취약점은 소프트웨어 설계 오류, 구현 결함, 인증·인가 체계의 문제, 부적절한 설정 및 외부 구성요소의 취약점 등으로 발생한다.
| 취약점 | 주요 내용 | 대응 방안 |
|---|---|---|
| SQL 인젝션 | 외부 입력을 통해 데이터베이스 질의를 변조 | 매개변수화 질의, 최소 권한 |
| 크로스 사이트 스크립팅(XSS) | 악성 스크립트가 다른 사용자의 브라우저에서 실행 | 문맥별 출력 인코딩, 안전한 DOM API |
| 명령어 인젝션 | 입력값을 이용해 의도하지 않은 운영체제 명령 실행 | 명령 실행 최소화, 안전한 API 사용 |
| 버퍼 오버플로 | 메모리 경계를 넘어 데이터를 기록하여 메모리를 손상 | 메모리 안전성 확보, 경계 검사 |
| Use After Free | 해제된 메모리를 다시 참조하여 비정상 동작 유발 | 안전한 메모리 관리, 정적·동적 분석 |
| 접근통제 실패 | 다른 사용자나 관리자에게만 허용된 정보·기능에 접근 | 서버 측 인가 검증, 최소 권한 |
| 인증 취약점 | 취약한 인증 구현으로 계정 또는 세션 탈취 | 다중요소 인증, 안전한 세션 관리 |
| SSRF | 서버가 공격자가 지정한 자원에 요청하도록 유도 | 목적지 검증, 네트워크 접근 제한 |
| 안전하지 않은 역직렬화 | 신뢰할 수 없는 직렬화 데이터를 처리하는 과정에서 비정상 동작 발생 | 입력 형식 제한, 안전한 역직렬화 |
| 암호화 오류 | 취약한 암호 알고리즘이나 부적절한 키 관리로 정보 노출 | 검증된 암호 알고리즘, 안전한 키 관리 |
| 공급망 취약점 | 취약하거나 악성인 외부 구성요소가 애플리케이션에 포함 | 구성요소 검증, SCA, SBOM |
이러한 위험은 OWASP Top 10, CWE, CVE 등의 자료를 활용하여 분류하고 관리할 수 있다.
애플리케이션 보안 테스트(Application Security Testing, AST)는 애플리케이션의 보안 결함과 취약점을 발견하고 검증하는 활동이다.
분석 대상과 수행 방식에 따라 여러 기법으로 구분된다.
| 기법 | 영문명 | 분석 방식 | 주요 특징 |
|---|---|---|---|
| 정적 애플리케이션 보안 테스트 | SAST | 소스코드 또는 바이너리를 실행하지 않고 분석 | 개발 초기 적용 가능, 코드 수준 결함 식별 |
| 동적 애플리케이션 보안 테스트 | DAST | 실행 중인 애플리케이션에 요청을 보내 동작 분석 | 실제 실행 환경의 취약점 탐지 |
| 인터랙티브 애플리케이션 보안 테스트 | IAST | 애플리케이션 내부에 계측 기능을 적용하여 실행 중 분석 | 실행 흐름과 내부 정보를 결합하여 취약점 탐지 |
| 소프트웨어 구성 분석 | SCA | 오픈소스 및 외부 라이브러리 분석 | 알려진 취약점, 라이선스, 의존성 위험 식별 |
| 퍼징 | Fuzzing | 비정상적이거나 다양한 입력값을 자동으로 전달 | 충돌, 메모리 오류, 예외 처리 결함 탐지 |
| 모의해킹 | Penetration Testing | 공격자의 관점에서 취약점의 실제 악용 가능성 검증 | 취약점 간 연계 및 실제 영향 분석 |
| 보안 코드 리뷰 | Secure Code Review | 개발자가 작성한 코드의 보안 로직과 구현 검토 | 설계·업무 로직상의 결함 분석 |
각 기법은 서로 다른 유형의 취약점 탐지에 강점과 한계를 가진다.
예를 들어 SAST는 소스코드의 잠재적인 결함을 식별하는 데 유용하지만 실제 공격 가능성을 완전하게 판단하지는 못한다. DAST는 실행 중인 서비스의 동작을 분석하지만 모든 코드 경로를 확인할 수 있는 것은 아니다.
또한 SCA는 외부 구성요소의 알려진 취약점을 식별하는 데 유용하지만 자체 개발한 비즈니스 로직의 취약점을 분석하는 데에는 한계가 있다.
따라서 중요 애플리케이션은 여러 보안 테스트 기법을 조합하여 검증하는 것이 바람직하다.
NIST SSDF(Secure Software Development Framework)는 소프트웨어 개발 과정에 보안 활동을 통합하기 위한 프레임워크이다.
NIST SP 800-218의 SSDF 1.1은 다음 네 가지 실무 그룹으로 구성된다.[1]
| 그룹 | 영문명 | 주요 내용 |
|---|---|---|
| PO | Prepare the Organization | 보안 개발을 위한 조직, 인력, 정책, 도구 및 프로세스 준비 |
| PS | Protect the Software | 소스코드와 소프트웨어 구성요소를 무단 접근 및 변조로부터 보호 |
| PW | Produce Well-Secured Software | 안전한 설계·개발·검증을 통해 소프트웨어 취약점 최소화 |
| RV | Respond to Vulnerabilities | 취약점을 식별·조치하고 근본 원인을 분석하여 재발 방지 |
2025년 12월에는 SSDF 1.2의 초기 공개 초안(NIST SP 800-218 Rev. 1)이 발표되었다. 2026년 11월 14일 기준 NIST 공식 발행 목록에서는 SSDF 1.1을 최종본으로, 1.2를 초안으로 구분하고 있다.[2]
OWASP ASVS(Application Security Verification Standard)는 웹 애플리케이션과 웹 서비스의 보안 요구사항을 정의하고 이를 검증하기 위한 표준이다.
애플리케이션의 인증·인가, 입력값 검증, 암호화, 세션 관리, API 보안 등 다양한 영역에서 구체적인 보안 요구사항을 제시한다.
2026년 11월 기준 최신 안정판은 2025년 5월 30일 발표된 ASVS 5.0.0이다.[3]
ASVS는 보안 검증 수준을 세 가지로 구분한다.
- Level 1: 일반적인 애플리케이션에 적용할 수 있는 기본적인 보안 검증 수준
- Level 2: 대부분의 애플리케이션에 권장되는 강화된 보안 검증 수준
- Level 3: 높은 수준의 보안 보증이 필요한 중요 애플리케이션을 위한 검증 수준
다만 ASVS는 주로 웹 애플리케이션과 웹 서비스를 대상으로 하므로 모든 유형의 소프트웨어에 동일하게 적용할 수 있는 범용 표준은 아니다.
OWASP SAMM(Software Assurance Maturity Model)은 조직의 소프트웨어 보안 활동을 평가하고 개선하기 위한 성숙도 모델이다.
소프트웨어 개발 생명주기 전반에 적용할 수 있도록 설계되었으며, 조직의 현재 보안 수준을 파악하고 개선계획을 수립하는 데 활용된다.
SAMM은 다음 다섯 가지 업무 기능으로 구성된다.[4]
| 기능 | 영문명 | 주요 내용 |
|---|---|---|
| 거버넌스 | Governance | 보안 전략, 정책, 교육, 규정 준수 |
| 설계 | Design | 위협평가, 보안 요구사항, 아키텍처 분석 |
| 구현 | Implementation | 안전한 빌드, 안전한 배포, 결함 관리 |
| 검증 | Verification | 아키텍처 평가, 요구사항 기반 테스트, 보안 테스트 |
| 운영 | Operations | 사고 관리, 환경 관리, 운영 관리 |
SAMM은 개별 취약점의 존재 여부보다 조직이 보안 활동을 얼마나 체계적이고 지속적으로 수행하는지 평가하는 데 중점을 둔다.
현대의 애플리케이션은 개발자가 직접 작성한 코드 외에도 외부 라이브러리, 프레임워크, 패키지, 컨테이너 이미지 등 다양한 구성요소를 사용한다.
따라서 애플리케이션 자체의 코드가 안전하더라도 외부 구성요소에 취약점이나 악성 기능이 존재하면 전체 서비스가 침해될 수 있다.
주요 관리 대상은 다음과 같다.
- 오픈소스 의존성: 외부 라이브러리의 취약점, 유지관리 상태, 라이선스 검토
- 패키지 저장소: 악성 패키지, 타이포스쿼팅, 의존성 혼동 등의 공격 대응
- SBOM: 소프트웨어에 포함된 구성요소와 의존관계의 가시성 확보
- 빌드 무결성: 빌드 서버, 도구, 스크립트 및 산출물의 변조 방지
- 배포 경로 보호: 코드 저장소, CI/CD 파이프라인, 배포 권한 및 비밀정보 관리
- 취약점 추적: 새로운 취약점 공개 시 영향을 받는 제품과 구성요소 식별
미국 NIST는 SSDF에서 개발·배포되는 소프트웨어의 구성요소와 출처에 관한 정보를 확보하고, 코드와 산출물을 무단 접근 및 변조로부터 보호하도록 권고한다.[1]
공급망 보안의 세부적인 구성요소 분석은 소프트웨어 구성 분석에서, 개발도구와 코드 저장소 및 빌드 환경의 보호는 개발 환경 보안에서 다룬다.
데브섹옵스(DevSecOps)는 개발(Development), 보안(Security), 운영(Operations)을 통합하여 소프트웨어의 개발·배포·운영 과정에 보안 활동을 지속적으로 적용하는 접근법이다.
기존의 개발 방식에서는 개발 완료 이후 보안팀이 별도로 취약점을 점검하고 수정사항을 요청하는 경우가 많았다.
반면 데브섹옵스는 소스코드 변경, 빌드, 테스트, 배포 등 각 단계에 보안 점검을 자동화하고 개발자가 빠르게 결과를 확인할 수 있도록 한다.
대표적인 자동화 활동은 다음과 같다.
- 소스코드 저장소에 변경사항이 등록되면 SAST와 비밀정보 노출 검사를 수행
- 빌드 과정에서 SCA를 실행하여 취약한 의존성을 식별
- 배포 전 DAST와 API 보안 테스트를 수행
- 컨테이너 이미지와 인프라 설정의 보안 위험을 검사
- 정해진 위험 기준을 초과하는 취약점이 발견되면 배포를 제한
- 운영 중 새로운 취약점이 공개되면 영향을 받는 애플리케이션을 재평가
데브섹옵스는 특정 보안 도구나 제품을 도입하는 것만으로 구현되지 않는다. 개발자, 보안 담당자, 운영 담당자의 역할과 책임, 취약점 처리 기준, 자동화 프로세스가 함께 정립되어야 한다.
애플리케이션은 배포된 이후에도 지속적으로 보안 위험에 노출된다.
새로운 취약점이 공개되거나 운영 환경이 변경될 수 있으며, 공격자가 정상적인 기능을 악용하여 시스템을 침해하는 경우도 있다.
주요 운영 보안통제는 다음과 같다.
| 보안통제 | 주요 내용 |
|---|---|
| 웹 애플리케이션 방화벽(WAF) | 악성 HTTP 요청 및 알려진 웹 공격 패턴 탐지·차단 |
| RASP | 실행 중인 애플리케이션의 내부 동작을 기반으로 공격 탐지 및 차단 |
| 접근통제 및 인증 | 사용자와 서비스 계정의 권한 관리, 인증 강화 |
| 비밀정보 관리 | API 키, 인증 토큰, 데이터베이스 비밀번호 등의 안전한 저장·교체 |
| 취약점 관리 | 운영 중인 애플리케이션과 구성요소의 취약점 식별 및 패치 |
| 보안 로깅 | 인증 실패, 권한 위반, 비정상 요청 등 보안 이벤트 기록 |
| 침해 탐지 및 대응 | 애플리케이션의 이상행위 분석, 사고 조사, 차단 및 복구 |
운영 보안통제는 소프트웨어 자체의 취약점을 수정하는 활동을 대체할 수 없다. 예를 들어 WAF가 특정 공격 패턴을 차단하더라도 애플리케이션에 존재하는 접근통제 오류나 비즈니스 로직 결함이 해결되는 것은 아니다.
보안 내재화(Secure by Design)는 애플리케이션의 설계·개발 초기부터 보안 요구사항을 반영하여 근본적인 보안 결함의 발생을 줄이는 접근법이다.
미국 사이버보안 및 인프라보안국(CISA)은 소프트웨어 제조사가 제품의 보안 결과에 대한 책임을 강화하고, 안전한 기본 설정을 제공하며, 보안 취약점과 개선 활동에 대해 투명성을 확보할 것을 권고하고 있다.[5]
이는 보안 책임을 최종 사용자나 운영 조직에만 부담시키지 않고 소프트웨어를 개발·공급하는 조직이 초기 단계부터 적극적으로承担하도록 하는 방향이다.
생성형 인공지능을 활용한 코드 생성과 개발 자동화가 확대되면서 애플리케이션 보안에서도 새로운 관리 요소가 등장하고 있다.
- AI가 생성한 코드의 보안 취약점 검증
- 존재하지 않거나 악성인 외부 패키지를 추천하는 문제 대응
- AI 코딩 도구에 전달되는 소스코드와 비밀정보 보호
- AI 개발 도구의 권한과 외부 시스템 접근 범위 제한
- AI 모델 및 에이전트가 포함된 애플리케이션의 보안 요구사항 정의
- 자동화된 취약점 분석과 코드 수정 제안에 AI 활용
NIST는 2024년 SP 800-218A를 발표하여 생성형 AI 및 이중용도 기반모델의 개발 과정에 적용할 수 있는 추가적인 보안 개발 실무를 제시했다.[6]
AI가 생성한 코드 역시 일반적인 애플리케이션과 동일하게 보안 요구사항 검토, 소스코드 분석, 의존성 분석 및 취약점 검증이 필요하다.
웹 보안은 웹 브라우저, 웹 서버, HTTP 기반 서비스와 관련된 보안에 초점을 맞추는 반면, 애플리케이션 보안은 웹을 포함한 모든 유형의 소프트웨어 애플리케이션을 대상으로 한다.
| 구분 | 애플리케이션 보안 | 웹 보안 |
|---|---|---|
| 주요 대상 | 웹, 모바일, 데스크톱, 서버, 임베디드 애플리케이션 등 | 웹사이트, 웹 애플리케이션, 웹 서버, 웹 API 등 |
| 주요 취약점 | 메모리 오류, 인증·인가 실패, 인젝션, 공급망 취약점 등 | SQL 인젝션, XSS, CSRF, SSRF, 세션 취약점 등 |
| 주요 보안 기술 | SAST, DAST, SCA, 퍼징, 코드 리뷰, 런타임 보호 등 | WAF, CSP, HTTPS, 브라우저 보안 정책, 웹 취약점 점검 등 |
| 적용 단계 | 설계·개발·배포·운영 전 과정 | 웹 서비스 설계·구현·운영 및 통신 환경 |
웹 보안은 애플리케이션 보안과 상당 부분 중첩되지만, 웹 서버와 브라우저의 통신 보안 등 애플리케이션 외부의 구성요소도 다룬다는 점에서 범위가 완전히 일치하지는 않는다.
- ↑ 1.0 1.1 1.2 NIST, Secure Software Development Framework (SSDF) Version 1.1: Recommendations for Mitigating the Risk of Software Vulnerabilities, 2022-02-03.
- ↑ NIST, Secure Software Development Framework (SSDF) Version 1.2: Initial Public Draft, 2025-12-17.
- ↑ OWASP, OWASP Application Security Verification Standard 5.0.0, 2025-05-30.
- ↑ OWASP, OWASP Software Assurance Maturity Model, 확인: 2026-11-14.
- ↑ CISA 외, Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software, 2023-10-16.
- ↑ NIST, Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile, 2024-07-26.