지식
Security

OWASP ASVS: 애플리케이션 보안 검증 표준 활용 가이드

OWASP ASVS의 3개 검증 레벨과 챕터 구조, Top 10과의 차이를 정리하고, 검증 항목을 백로그 티켓·PR 체크리스트·자동화 테스트로 변환해 실무에 적용하는 방법을 다룹니다.

· 10 min read · PALDYN Team

지난 글에서 보안을 개발 생명주기 전체에 심는 Secure SDLC를 다뤘다. 그런데 곧바로 실무적인 질문이 따라온다. “보안 요구사항을 정의하라”는데, 도대체 어떤 항목을 얼마나 깊이 요구해야 하는가? 팀마다 매번 백지에서 보안 요구사항을 발명할 수는 없다. 이 질문에 대한 업계 표준 답안이 OWASP ASVS(Application Security Verification Standard)다.

ASVS는 무엇이고, Top 10과 어떻게 다른가

OWASP Top 10은 “가장 흔한 위험 10가지”를 알리는 인식 제고(awareness) 문서다. 반면 ASVS는 웹 애플리케이션이 갖춰야 할 보안 요구사항을 망라한 검증 가능한 체크리스트 다. Top 10이 “주의해야 할 병 목록”이라면 ASVS는 “건강검진 항목표”에 가깝다.

ASVS의 각 항목은 검증 가능한 문장으로 쓰여 있다. 예를 들면 이런 식이다.

“사용자가 설정한 비밀번호가 최소 12자 이상인지 검증한다.” (V2.1.1) “세션 토큰이 최소 64비트 엔트로피를 갖는지 검증한다.” (V3.2.2)

“보안을 잘 하자”가 아니라, 충족/미충족을 판정할 수 있는 단위로 쪼개져 있다는 점이 핵심이다. 그래서 ASVS는 다음 역할을 동시에 한다.

  • 개발팀에게는 보안 요구사항 카탈로그
  • 침투 테스터에게는 점검 범위 정의서
  • 발주사·구매팀에게는 벤더 보안 평가 기준
  • 보안팀에게는 성숙도 측정 지표

3개의 검증 레벨

ASVS의 가장 실용적인 설계는 모든 항목에 레벨을 매겨, 위험도에 따라 요구 수준을 고를 수 있게 한 것이다.

ASVS 3개 검증 레벨

  • Level 1: 모든 애플리케이션의 최소 기준선. 코드 접근 없이 외부 침투 테스트만으로도 검증 가능한 항목들로, OWASP Top 10 수준의 방어에 대응한다.
  • Level 2: 민감 데이터를 다루는 대부분의 비즈니스 애플리케이션에 권장되는 표준 수준. 문서와 코드 접근이 필요한 검증이 포함된다. 전자상거래, B2B SaaS, 개인정보 처리 서비스가 여기에 해당한다.
  • Level 3: 침해 시 인명·금융 시스템·사회 인프라에 중대한 영향을 주는 시스템을 위한 고보증 수준. 아키텍처 분석까지 포함하는 심층 검증을 요구한다.

실무 감각으로는 이렇게 정리할 수 있다. 외부 공개 서비스라면 L1은 자격 요건이고, 사용자 데이터를 다룬다면 L2가 목표선이다. L3는 정말 필요한 시스템에만 적용한다.

챕터 구조 훑어보기

ASVS는 보안 도메인별 챕터(V1~V14, 버전에 따라 구성이 조금씩 다름)로 구성된다. 웹 보안에서 다뤄온 주제들이 그대로 챕터로 매핑된다는 걸 알 수 있다.

V1  아키텍처·설계          → 위협 모델링, 신뢰 경계
V2  인증                  → 비밀번호 해싱, MFA, 크리덴셜 스터핑 방어
V3  세션 관리              → 세션 고정, 토큰 엔트로피, 만료
V4  접근 제어              → IDOR, 권한 상승, deny-by-default
V5  검증·새니타이즈·인코딩   → 인젝션, XSS, 입력 검증
V6  암호화 (저장)          → 키 관리, CSPRNG
V7  에러 처리·로깅          → 민감정보 로그 금지, 감사 로그
V8  데이터 보호             → 민감 데이터 분류, 캐시 통제
V9  통신                  → TLS 설정, 인증서 검증
V10 악성 코드              → 의존성·빌드 무결성 (공급망)
V11 비즈니스 로직           → 흐름 강제, 레이스 컨디션
V12 파일·리소스            → 파일 업로드 보안
V13 API·웹서비스           → REST/GraphQL, BOLA
V14 설정                  → 보안 헤더, 디버그 모드, 기본 계정

새 기능을 설계할 때 해당 챕터만 펼쳐서 관련 항목을 추리면, 그 기능의 보안 요구사항 초안이 바로 나온다.

실무 적용: 체크리스트를 살아있는 프로세스로

ASVS를 PDF로 출력해 책상에 두는 것과 프로세스에 심는 것은 완전히 다른 일이다. 권장하는 활용 흐름은 다음과 같다.

ASVS 실무 활용 흐름

1) 레벨을 선정하고 범위를 선별한다. 서비스 위험도에 맞는 레벨을 고른 뒤, 해당 없는 챕터(예: WebSocket을 쓰지 않으면 관련 항목)는 “N/A”로 명시적으로 제외한다. 제외 사유를 기록해 두는 것이 나중에 감사 대응에서 큰 차이를 만든다.

2) 항목을 작업 단위로 변환한다. ASVS 항목을 그대로 백로그 티켓이나 PR 템플릿 체크리스트로 옮긴다. 예를 들어 인증 기능 PR 템플릿에는 V2 챕터에서 뽑은 항목이 들어가는 식이다.

<!-- PR 템플릿: 인증 관련 변경 시 -->
## 보안 체크 (ASVS V2/V3)
- [ ] 비밀번호는 Argon2id/bcrypt로 해싱 (V2.4)
- [ ] 로그인 실패 응답이 계정 존재 여부를 노출하지 않음 (V2.2)
- [ ] 인증 성공 시 세션 ID 재발급 (V3.2)
- [ ] 로그아웃 시 서버 측 세션 무효화 (V3.3)

3) 검증을 자동화에 매핑한다. 항목마다 “무엇으로 검증되는가”를 연결한다. 어떤 항목은 SAST 룰로(예: 하드코딩 시크릿), 어떤 항목은 단위 테스트로(예: 비밀번호 정책), 어떤 항목은 DAST 스캔으로(예: 보안 헤더), 어떤 항목은 수동 리뷰로만 검증된다. 이 매핑이 곧 다음 글에서 다룰 보안 테스트 도구 선택의 근거가 된다.

4) 갭을 측정하고 추적한다. “충족 / 미충족 / 해당없음”으로 분류한 커버리지를 분기마다 갱신하면, 보안 수준을 “느낌”이 아니라 숫자로 말할 수 있게 된다. 미충족 항목은 위험도 기준으로 우선순위를 매겨 로드맵에 올린다.

흔한 함정

  • 100% 충족을 목표로 삼는 것: ASVS는 통과/탈락 시험이 아니다. 어떤 항목을 충족하지 못했고 그 위험을 어떻게 관리하는지 아는 것이 목적이다.
  • 레벨 과욕: 사내 도구에 L3를 들이대면 비용만 늘고 아무도 따르지 않는다. 위험도에 맞는 레벨이 정답이다.
  • 일회성 평가로 끝내기: 한 번 갭 분석하고 방치하면 6개월 뒤 문서는 현실과 무관해진다. 릴리스 주기에 맞춘 갱신 루프가 필요하다.
  • 항목 번호에 집착: ASVS는 버전이 올라가면 번호 체계가 바뀐다. 내부 문서에는 항목 번호와 함께 요구사항 문장 자체를 기록해 두자.

ASVS로 “무엇을 검증할지”가 정해졌다면, 다음 질문은 “무엇으로 검증할 것인가”다. 다음 글에서는 자동화 보안 테스트의 세 축인 SAST, DAST, IAST를 비교하고 선택 기준을 정리한다.

지난 글: Secure SDLC: 개발 생명주기에 보안을 내재화하는 법

다음 글: SAST·DAST·IAST: 자동화 보안 테스트 도구 비교와 선택


읽어주셔서 감사합니다. 😊