개념
리포트 100건을 받은 다음 날
보안 스캔을 돌렸다. 리포트가 왔다.
Critical 3건
High 17건
Medium 42건
Low 61건
─────────────────
합계 123건여기서부터가 QA의 일이다. 스캔을 돌리는 것은 버튼 하나지만, 이 123건을 어떻게 다룰지는 판단의 영역이기 때문이다. 그리고 이 판단을 못 하면 두 가지 중 하나가 일어난다.
- 123건을 그대로 개발 백로그에 올린다 → 아무도 손대지 않는다
- 부담스러워서 리포트를 덮어둔다 → 스캔한 의미가 없어진다
모듈 16(레슨 6)에서 SAST·DAST·SCA를 배웠고, 이 모듈에서 SonarQube와 Fortify를 봤다. 이 레슨은 도구를 돌린 다음 을 다룬다.
AI 기반 스캐너라는 새 계열
최근 등장한 도구들은 기존 스캐너에 LLM을 얹어 몇 가지를 더 한다.
| 기존 스캐너 | AI를 얹은 스캐너가 추가로 하는 것 |
|---|---|
| 규칙·시그니처 매칭 | 코드 맥락을 읽고 악용 가능성 을 추정 |
| 취약점 위치 보고 | 왜 위험한지 설명 과 수정 제안 생성 |
| 알려진 패턴 탐지 | 배포된 JS를 분석해 노출된 키·내부 엔드포인트 추출 |
| CVE 목록 대조 | 우리 코드 맥락에서 실제로 도달 가능한지 판단 시도 |
| 항목 나열 | 심각도 재평가·우선순위 제안 |
세 번째 줄이 QA에게 특히 유용하다. 프런트엔드 번들에 API 키가 박혀 있거나, 문서에 없는 내부 엔드포인트가 노출되는 문제는 사람이 찾기 번거로운데 자동화하기는 좋다. 모듈 16(레슨 14)에서 다룬 토큰 노출 점검의 확장이다.
확인 메모: 이 레슨을 쓰면서 사용자가 언급한 특정 서비스 (securefirst.dev)를 확인해봤으나, 작성 시점에 사이트가 응답하지 않았다(배포 없음). 그래서 특정 제품이 아니라 계열의 특성 으로 정리한다. 이 영역의 도구는 등장과 소멸이 빠르므로, 개별 도구 사용법보다 리포트를 다루는 방법이 오래 간다.
스캔 전에 반드시 — 허가
기술 이야기보다 먼저 짚어야 한다. 동의 없는 스캔은 공격과 구분되지 않는다.
| 확인할 것 | 왜 |
|---|---|
| 스캔 대상이 우리 소유·우리 관리 인가 | 남의 서비스 스캔은 법적 문제다 |
| 서면 승인 이 있는가 | 구두 승인은 사고 시 근거가 안 된다 |
| 대상 범위(도메인·IP·경로)가 명시됐는가 | 서브도메인이 남의 것일 수 있다 |
| 운영 환경인가 테스트 환경인가 | 운영 스캔은 장애를 유발할 수 있다 |
| 시간대 합의가 있는가 | 트래픽 급증으로 알람이 울린다 |
| 인프라·보안 팀에 사전 공지 했는가 | 공격으로 오인돼 차단·신고될 수 있다 |
| 외부 SaaS 스캐너라면 데이터 처리 조건은 | 우리 코드·URL이 외부로 나간다 |
마지막 줄이 AI 스캐너에서 새로 생긴 항목이다. 소스코드나 배포 번들을 외부 서비스에 올려 분석하는 구조라면, 그건 모듈 18b(레슨 9)에서 다룬 데이터 유출 문제와 같다. 우리 코드가 학습에 쓰이는가 를 약관에서 확인해야 한다.
클라우드·호스팅 제공자에 따라 침투성 스캔에 별도 정책이나 사전 통보를 요구하는 경우가 있다. 대상이 우리 것이어도 인프라는 남의 것일 수 있다 는 점을 기억한다.
리포트를 받으면 — 4단계 트리아지
123건을 다루는 절차다. 모듈 6(레슨 1)의 결함 트리아지를 보안 리포트에 적용한 형태다.
① 중복·묶음 정리 같은 원인 여러 건을 하나로
↓ 123건 → 40건쯤
② 오탐 걸러내기 재현 가능한가
↓ 40건 → 15건쯤
③ 맥락으로 재평가 우리 환경에서 실제 위험한가
↓ 15건 → 우선순위가 매겨진 목록
④ 실행 가능한 형태로 담당·기한·수정 방향과 함께 전달①에서 가장 많이 줄어든다. 스캐너는 같은 취약점이 100개 페이지에 있으면 100건으로 보고한다. 원인이 공통 컴포넌트 하나라면 그건 1건이다.
오탐을 걸러내는 법
②단계가 QA의 핵심 기여다. 모듈 18c에서 배운 AI 산출물 교차검증 이 여기에 그대로 적용된다.
| 판정 | 기준 | 처리 |
|---|---|---|
| 확정 | 재현 절차로 실제 확인됨 | 즉시 티켓 |
| 후보 | 정황은 있으나 재현 미확인 | 추가 확인 큐 |
| 오탐 | 재현 불가 또는 오해 | 사유 기록 후 제외 |
| 해당 없음 | 우리 환경에 존재하지 않는 조건 | 사유 기록 후 제외 |
'사유 기록'이 중요하다. 같은 오탐이 다음 스캔에서 또 올라오기 때문이다. 기록해두면 다음번에는 5분이면 처리되고, 스캐너 설정에서 제외 규칙으로 만들 수도 있다. 모듈 18c(레슨 6)에서 보안 분석 하네스의 '기각' 등급을 기록으로 남기라고 한 이유와 같다.
AI 스캐너에서 특히 잦은 오탐 유형 이 있다.
| 유형 | 왜 오탐인가 |
|---|---|
| 도달 불가능한 코드 경로 | 조건상 실행되지 않는 분기 |
| 이미 방어된 입력 | 상위 계층에서 검증·이스케이프됨 |
| 테스트·목 코드 | 운영에 배포되지 않는 파일 |
| 의도된 공개 정보 | 공개용 API 키(예: 지도·분석 도구의 공개 키) |
| 버전만 보고 판정한 CVE | 취약 함수를 우리가 안 쓰는 경우 |
| 그럴듯한 설명이 붙은 없는 문제 | LLM이 생성한 설명이 설득력 있어 보인다 |
마지막 줄이 AI 스캐너의 새로운 위험이다. 기존 스캐너의 오탐은 "규칙에 걸렸다"는 건조한 형태라 의심하기 쉬웠다. AI가 생성한 설명은 왜 위험한지 논리적으로 서술 하기 때문에 오탐도 그럴듯하다. 모듈 18b(레슨 2)에서 배운 환각이 보안 리포트 형태로 나타나는 것이다.
판정 원칙: 설명이 얼마나 설득력 있는지가 아니라 재현되는지 로 판정한다. 재현 절차를 만들 수 없으면 '후보'에 두고, 확정하지 않는다.
심각도를 다시 매기는 법
③단계다. 스캐너가 준 심각도를 그대로 쓰면 안 된다. 스캐너는 우리 서비스의 맥락을 모르기 때문 이다.
CVSS 점수를 읽을 때 알아둘 것
| 구성 | 의미 |
|---|---|
| Base | 취약점 자체의 특성 — 스캐너가 주는 점수 |
| Temporal | 익스플로잇 존재 여부, 패치 가용성 |
| Environmental | 우리 환경에서의 실제 영향 — 여기를 우리가 채운다 |
Base 9.8이어도 우리 환경에서는 낮을 수 있고, Base 5.0이어도 우리에게는 치명적일 수 있다. 조정 기준은 모듈 4(레슨 2)의 리스크 평가와 같다.
| 올리는 요인 | 내리는 요인 |
|---|---|
| 인증 없이 접근 가능한 경로 | 내부망에서만 접근 가능 |
| 개인정보·결제가 걸림 | 테스트 데이터만 있음 |
| 실사용 트래픽이 많은 기능 | 사실상 안 쓰이는 기능 |
| 이미 공개된 익스플로잇 존재 | 악용에 높은 전문성 필요 |
| 규제 대상 데이터(모듈 25) | 별도 보상 통제가 있음 |
"인증 없이 접근 가능한가"가 첫 번째 질문 이다. 로그인해야만 닿는 취약점과 누구나 닿는 취약점은 위험이 다르다.
OWASP Top 10으로 묶어 보기
개별 항목 123건보다 분류별 집계 가 대화에 유용하다.
A01 접근 통제 실패 8건 ← 권한 설계 문제일 가능성
A02 암호화 실패 2건
A03 인젝션 5건 ← XSS 4 + SQL 1
A05 보안 설정 오류 14건 ← 헤더·기본 설정 문제
A06 취약·구버전 컴포넌트 9건 ← 의존성 업데이트로 대부분 해결
A07 인증 실패 3건이렇게 묶으면 대응 방향이 보인다. A05가 14건이면 개별 수정이 아니라 보안 헤더 설정을 한 번에 정리하는 것이 답이고, A06이 많으면 의존성 관리 프로세스(모듈 25의 SOUP·SBOM)를 손볼 문제다.
모듈 16(레슨 5)에서 배운 분류가 여기서 집계 축 으로 쓰인다.
개발팀에 넘기는 형태
④단계다. 스캐너 리포트를 그대로 전달하면 대개 방치된다. 다시 쓴다.
[보안] 주문 상세 API에 접근 통제 누락
분류 OWASP A01 접근 통제 실패
심각도 Critical (조정 근거: 인증만 되면 타인 주문 조회 가능,
개인정보 포함, 실사용 상위 API)
재현
1. 사용자 A로 로그인
2. GET /api/orders/{B의 주문ID} 호출
3. 200과 함께 B의 주문 상세가 반환됨 ← 403이어야 함
영향
로그인한 누구나 타인의 주문 내역(이름·주소·연락처) 조회 가능
수정 방향(참고)
조회 시 소유자 검증 추가. 유사 패턴이 있는 다른 엔드포인트도
함께 점검 필요 (아래 관련 항목 3건)
관련 항목 #1042, #1043, #1044 (같은 원인)
출처 AI 스캔 리포트 #78, 수동 재현 완료'출처'와 '수동 재현 완료'를 적는 것 이 요령이다. 스캐너가 찾았다는 사실과 사람이 확인했다는 사실을 함께 적으면, 받는 쪽이 신뢰하고 바로 작업에 들어간다.
공개 범위 제한 도 잊지 않는다. 미수정 취약점의 재현 절차가 전사에 공개돼 있으면 그 자체가 위험이다. 모듈 22(레슨 6)의 프로젝트 액세스 수준을 쓴다.
스캐너를 어디에 배치할 것인가
일회성 스캔으로 끝내면 다음 릴리즈에서 다시 쌓인다. 모듈 14(레슨 4)의 품질 게이트에 얹는 것이 정석이다.
| 배치 지점 | 무엇을 돌리나 | 통과 기준 |
|---|---|---|
| PR 단계 | SAST(변경분만), 의존성 스캔 | 신규 Critical/High 0건 |
| 야간 빌드 | 전체 SAST, DAST | 추세 관찰, 임계 초과 시 알림 |
| 릴리즈 전 | DAST + AI 스캔 | Critical 0건, High는 합의된 예외만 |
| 정기(분기) | 전문 진단·침투 테스트 | 별도 |
PR 단계는 '신규' 기준으로 거는 것이 핵심이다. 기존 이슈 전체를 기준으로 걸면 첫날부터 모든 PR이 막히고, 곧 게이트가 꺼진다. 모듈 18c(레슨 6)에서 "지킬 수 없는 게이트는 곧 무시된다"고 한 것과 같다.
AI 스캐너를 다룰 때의 원칙
정리하면 다섯 가지다.
- 허가가 먼저다. 대상·범위·시간·데이터 처리 조건을 문서로.
- 재현으로 판정한다. 설명이 설득력 있는 것과 문제가 있는 것은 다르다.
- 오탐 사유를 기록한다. 다음 스캔에서 같은 것을 다시 판정하지 않는다.
- 심각도는 우리가 다시 매긴다. 스캐너는 우리 맥락을 모른다.
- 게이트로 만들되 지킬 수 있는 기준으로. 신규 기준, 합의된 예외.
그리고 잊지 말아야 할 한 가지 — 스캐너가 통과시켰다는 것이 안전하다는 뜻은 아니다. 자동 스캔은 알려진 패턴을 찾는 것이고, 비즈니스 로직의 권한 결함(모듈 4 레슨 7의 L3)처럼 맥락을 알아야 보이는 문제 는 사람이 찾는다. 모듈 25(레슨 3)에서 인증에 대해 한 이야기와 같다 — 통과가 목표가 되면 최소선으로 수렴한다.
실무에서 왜 필요한가
보안 스캐너를 도입하는 조직은 늘고 있는데, 리포트를 다룰 사람이 없어서 방치되는 경우 가 그만큼 많다. 개발팀은 123건 앞에서 무엇부터 할지 모르고, 보안 담당은 인력이 부족하다. 이 간극을 메울 수 있는 직군이 QA다 — 재현하고 분류하고 우선순위를 매기는 일 이 원래 하던 일이기 때문이다.
AI 스캐너가 늘면서 이 역할의 중요성이 오히려 커졌다. 생성된 설명이 그럴듯해서 오탐을 걸러내기가 더 어려워졌기 때문이다. 모듈 18c에서 배운 교차검증 능력이 보안 영역에서 직접 쓰이는 지점이다.
채용 관점에서도 구별되는 경험이다. "보안 도구 사용 경험"은 흔하지만, "스캔 리포트 123건을 15건으로 정리해 개발팀이 실제로 수정하게 만든 경험" 은 드물고 구체적이다.