AI인사이트 로고AI인사이트
챕터 7

보안 코드 검증 — 취약점 탐지·OWASP 체크 프롬프트

AI를 활용해 OWASP Top 10 취약점을 자동 탐지하고, SQL Injection·XSS·CSRF 등 보안 위협을 코드 수준에서 차단하는 프롬프트 패턴을 다룹니다. Snyk 기반 의존성 취약점 관리, 시큐어 코딩 패턴 적용, 침투 테스트 시나리오 설계까지 보안 검증 전 영역을 포괄합니다.

보안은 선택이 아니라 기본입니다

보안 사고는 발생한 뒤에야 그 심각성이 드러납니다. 한 줄의 취약한 코드가 수만 명의 개인정보를 유출하고, 기업의 존립을 위협할 수 있습니다. 그럼에도 많은 개발 팀에서 보안 검증은 배포 직전에야 형식적으로 이루어지거나, 아예 생략되는 경우가 많습니다.

AI 코딩 도구는 보안 검증의 진입 장벽을 획기적으로 낮춥니다. OWASP Top 10을 외우지 않아도, 코드를 AI에게 전달하면 잠재적 취약점을 체계적으로 식별하고 수정 방안까지 제시합니다. Cursor나 Claude 같은 도구로 코드 리뷰 시 보안 관점의 프롬프트를 함께 실행하면, 개발과 보안을 동시에 달성할 수 있습니다.

이번 챕터에서는 코드 레벨의 보안 검증부터 인프라 보안, 의존성 관리까지 개발자가 직접 수행할 수 있는 보안 자동화 프롬프트를 체계적으로 정리합니다.

OWASP Top 10 체크 프롬프트 — 웹 보안의 기본기

OWASP(Open Worldwide Application Security Project) Top 10은 가장 흔하고 위험한 웹 보안 취약점 목록입니다. AI에게 코드를 전달할 때 OWASP 카테고리를 명시하면, 체계적이고 누락 없는 보안 검토가 가능합니다.

종합 OWASP 보안 검토 프롬프트

다음 코드를 OWASP Top 10 기준으로 보안 검토해 주세요.

코드: [코드 붙여넣기] 애플리케이션 타입: 웹 API (Node.js/Express) 인증 방식: JWT 데이터베이스: PostgreSQL

검토 항목 (OWASP Top 10):

  1. A01 - 접근 제어 취약점 (Broken Access Control)
  2. A02 - 암호화 실패 (Cryptographic Failures)
  3. A03 - 인젝션 (Injection)
  4. A04 - 안전하지 않은 설계 (Insecure Design)
  5. A05 - 보안 설정 오류 (Security Misconfiguration)
  6. A06 - 취약한 컴포넌트 (Vulnerable Components)
  7. A07 - 인증 실패 (Authentication Failures)
  8. A08 - 데이터 무결성 실패 (Data Integrity Failures)
  9. A09 - 로깅/모니터링 실패 (Logging Failures)
  10. A10 - SSRF (Server-Side Request Forgery)

각 항목에 대해 (1) 해당 여부, (2) 취약 코드 위치, (3) 위험도(심각/높음/중간/낮음), (4) 수정 코드를 제공해 주세요.

이 프롬프트 하나로 코드 전체의 보안 상태를 한눈에 파악할 수 있습니다. 특히 AI가 "해당 없음"이라고 판단한 항목도 확인하면, 놓친 부분이 없는지 이중으로 검증할 수 있습니다.

특정 OWASP 카테고리 심층 분석

다음 코드에서 A01(접근 제어) 취약점을 심층 분석해 주세요.

코드: [API 라우터/컨트롤러 코드] 분석 관점:

  1. 수평 권한 상승: 다른 사용자의 데이터에 접근 가능한가?
  2. 수직 권한 상승: 일반 사용자가 관리자 기능을 호출할 수 있는가?
  3. IDOR(Insecure Direct Object Reference): URL 파라미터 조작으로 타인 데이터 접근 가능한가?
  4. 메서드 우회: GET 요청으로 POST 전용 로직을 실행할 수 있는가?
  5. 경로 조작: 파일 다운로드 시 경로 traversal이 가능한가?

각 취약점에 대해 공격 시나리오와 방어 코드를 함께 제공해 주세요.

SQL Injection 탐지 및 방어

SQL Injection은 가장 오래되었지만 여전히 가장 파괴적인 공격 기법 중 하나입니다. AI를 활용하면 코드 전체에서 SQL Injection 취약점을 빠르게 식별하고, 안전한 패턴으로 변환할 수 있습니다.

SQL Injection 전수 검사 프롬프트

다음 코드에서 SQL Injection 취약점을 모두 찾아주세요.

코드: [데이터베이스 접근 코드] ORM/쿼리 빌더: [사용 중인 라이브러리]

검사 항목:

  1. 문자열 연결로 구성된 SQL 쿼리
  2. 사용자 입력이 직접 포함된 쿼리
  3. Prepared Statement/파라미터화 쿼리 미사용
  4. ORM raw query에서의 취약점
  5. Stored Procedure 내부 동적 SQL
  6. LIKE 절, ORDER BY, LIMIT 등에서의 인젝션 가능성

출력 형식: 각 취약점의 (1) 코드 위치, (2) 공격 페이로드 예시, (3) 안전한 코드로 수정

SQL Injection 방어 패턴 적용

다음 레거시 SQL 쿼리들을 안전한 패턴으로 변환해 주세요.

현재 코드: [취약한 쿼리 목록] 변환 기준:

  1. 파라미터화 쿼리 (Prepared Statement) 사용
  2. ORM 쿼리 빌더로 전환 (가능한 경우)
  3. 입력 검증 추가 (화이트리스트 기반)
  4. 에러 메시지에서 DB 정보 노출 제거
  5. 동적 테이블/컬럼명 처리 시 화이트리스트 적용

변환 전후 코드를 나란히 보여주세요.

XSS(Cross-Site Scripting) 탐지 및 방어

XSS 공격은 웹 애플리케이션에서 가장 빈번하게 발생하는 취약점입니다. 특히 프론트엔드와 백엔드 모두에서 방어해야 하는 다계층 보안이 필요합니다.

XSS 취약점 전체 스캔 프롬프트

다음 웹 애플리케이션 코드에서 XSS 취약점을 스캔해 주세요.

프론트엔드 코드: [React/Vue/Angular 컴포넌트] 백엔드 코드: [API 응답 처리]

검사 유형:

  1. Reflected XSS: URL 파라미터가 페이지에 그대로 출력되는 곳
  2. Stored XSS: DB에 저장된 사용자 입력이 이스케이프 없이 렌더링되는 곳
  3. DOM XSS: JavaScript에서 innerHTML, document.write, eval 등 사용
  4. React dangerouslySetInnerHTML: 사용 위치와 입력 검증 여부
  5. API 응답: Content-Type 헤더 올바른지, JSON 이스케이프 처리 여부

각 취약점에 (1) 공격 벡터, (2) 실제 공격 스크립트 예시, (3) 방어 코드를 포함해 주세요.

Content Security Policy 설정 프롬프트

다음 웹 애플리케이션에 맞는 Content Security Policy(CSP) 헤더를 설계해 주세요.

애플리케이션 특성:

  • React SPA (CDN에서 정적 자산 로드)
  • Google Analytics, Google Tag Manager 사용
  • YouTube 임베드 포함
  • API 서버: api.example.com
  • 이미지: CDN + 외부 이미지 (사용자 프로필)

요구사항:

  1. 가능한 엄격한 정책 (최소 허용 원칙)
  2. inline script/style 차단 (nonce 기반 허용)
  3. report-uri 설정으로 위반 모니터링
  4. 단계별 적용 전략 (Report-Only → Enforce)
  5. 각 디렉티브에 한국어 주석으로 설명

CSRF(Cross-Site Request Forgery) 방어

CSRF는 사용자의 인증된 세션을 악용하여 의도하지 않은 요청을 보내는 공격입니다. 특히 금융 거래나 데이터 변경 API에서 치명적입니다.

CSRF 방어 구현 프롬프트

다음 웹 애플리케이션에 CSRF 방어를 구현해 주세요.

현재 구조: [인증/세션 구조 설명] 프레임워크: Express.js + React

방어 전략:

  1. CSRF 토큰 생성 및 검증 미들웨어
  2. SameSite 쿠키 설정
  3. Origin/Referer 헤더 검증
  4. Custom 헤더 검증 (AJAX 요청용)
  5. Double Submit Cookie 패턴

각 방어 계층의 코드와 테스트 케이스를 함께 제공해 주세요.

인증/세션 보안 종합 검토

다음 인증 시스템의 보안을 종합 검토해 주세요.

코드: [인증 관련 코드] 검토 항목:

  1. 비밀번호 해싱 (bcrypt/argon2, salt, 반복 횟수)
  2. JWT 보안 (알고리즘, 만료 시간, 리프레시 토큰 전략)
  3. 세션 관리 (하이재킹, 고정 공격 방어)
  4. 브루트포스 방어 (Rate Limiting, 계정 잠금)
  5. OAuth 2.0 구현 (state 파라미터, PKCE)
  6. 비밀번호 재설정 (토큰 만료, 일회성)
  7. MFA 구현 (TOTP, 백업 코드)

각 항목의 현재 상태와 개선 권고사항을 표로 정리해 주세요.

의존성 취약점 관리 — Snyk 활용

현대 소프트웨어의 코드 대부분은 오픈소스 의존성에서 옵니다. 이 의존성에 포함된 보안 취약점(CVE)을 관리하지 않으면, 직접 작성한 코드가 아무리 안전해도 전체 시스템이 위험해집니다.

의존성 취약점 분석 프롬프트

다음 프로젝트의 의존성 보안 상태를 분석해 주세요.

package.json (또는 requirements.txt, go.mod): [파일 내용] Snyk/npm audit 결과: [결과가 있다면 첨부]

분석 요청:

  1. 알려진 취약점(CVE)이 있는 패키지 식별
  2. 각 취약점의 심각도와 공격 가능성 평가
  3. 안전한 버전으로의 업그레이드 경로 제안
  4. 업그레이드 불가 시 대안 패키지 추천
  5. 취약점이 실제 사용 코드 경로에 있는지 분석 (도달 가능성)
  6. 의존성 트리에서 간접 의존성 취약점도 포함

의존성 업데이트 전략 프롬프트

다음 프로젝트의 의존성 업데이트 전략을 수립해 주세요.

현재 의존성: [package.json] 마지막 업데이트: [날짜]

전략 수립 기준:

  1. 보안 패치: 즉시 적용 (자동화)
  2. 마이너 업데이트: 주간 배치 적용
  3. 메이저 업데이트: 분기별 계획 적용
  4. 각 업데이트의 호환성 위험도 평가
  5. Dependabot/Renovate 설정 파일 생성
  6. 업데이트 후 자동 테스트 파이프라인 설계

라이선스 컴플라이언스 검사 프롬프트

다음 프로젝트의 오픈소스 라이선스 컴플라이언스를 검사해 주세요.

package.json: [파일 내용] 프로젝트 유형: 상용 SaaS

검사 항목:

  1. GPL 계열 라이선스 의존성 (소스 공개 의무)
  2. AGPL 의존성 (네트워크 사용 시 공개 의무)
  3. 라이선스 미명시 패키지 식별
  4. 라이선스 충돌 (상충하는 라이선스 조합)
  5. 상용 사용 제한 라이선스
  6. 라이선스 고지 의무 이행 여부

시큐어 코딩 패턴 — 처음부터 안전하게

취약점을 사후에 발견하고 고치는 것보다, 처음부터 안전한 패턴으로 코드를 작성하는 것이 훨씬 효과적입니다. AI에게 시큐어 코딩 패턴을 요청하면, 보안이 내장된 코드를 생성합니다.

시큐어 코딩 패턴 적용 프롬프트

다음 기능을 시큐어 코딩 패턴으로 구현해 주세요.

기능: 파일 업로드 API 요구사항:

  1. 파일 타입 검증 (Magic Number 기반, 확장자만 체크 금지)
  2. 파일 크기 제한
  3. 파일명 정규화 (Path Traversal 방어)
  4. 바이러스 스캔 인터페이스
  5. 저장 경로 무작위화 (예측 불가능한 경로)
  6. 메타데이터 제거 (EXIF 등)
  7. 접근 제어 (업로드한 사용자만 다운로드)

각 보안 조치에 한국어 주석으로 "왜 필요한지" 설명을 포함해 주세요.

입력 검증 통합 프롬프트

다음 API 엔드포인트에 입력 검증 계층을 추가해 주세요.

API 코드: [코드] 검증 전략:

  1. 화이트리스트 검증: 허용된 값만 통과 (블랙리스트 금지)
  2. 타입 검증: 정수, 문자열, 이메일, URL 등 스키마 기반
  3. 길이 제한: 각 필드별 최소/최대 길이
  4. 특수문자 처리: 출력 컨텍스트별 이스케이프 (HTML, SQL, URL)
  5. 비즈니스 규칙 검증: 도메인 로직에 따른 유효성

Zod, Joi, class-validator 등 검증 라이브러리를 활용한 코드로 작성해 주세요.

에러 처리 보안 패턴

다음 애플리케이션의 에러 처리를 보안 관점에서 개선해 주세요.

현재 코드: [에러 처리 코드] 개선 방향:

  1. 내부 에러 정보(스택 트레이스, DB 스키마) 클라이언트 노출 차단
  2. 일관된 에러 응답 형식 (에러 코드 + 사용자 친화적 메시지)
  3. 보안 관련 이벤트 로깅 (로그인 실패, 권한 위반, 비정상 접근)
  4. 민감 데이터 로그 마스킹 (비밀번호, 카드번호, 주민번호)
  5. Rate Limiting과 연동한 자동 차단 로직

침투 테스트 시나리오 설계

보안 전문가가 아니더라도, AI의 도움으로 기본적인 침투 테스트 시나리오를 설계하고 실행할 수 있습니다. 물론 실제 프로덕션 환경에서는 전문 보안 팀의 검증이 필요하지만, 개발 단계에서 스스로 검증하는 것은 큰 의미가 있습니다.

침투 테스트 시나리오 생성 프롬프트

다음 웹 애플리케이션의 침투 테스트 시나리오를 설계해 주세요.

애플리케이션: [서비스 설명] 기술 스택: [스택] 인증 방식: [인증 구조]

테스트 시나리오 카테고리:

  1. 인증 우회: 로그인 없이 보호된 리소스 접근 시도
  2. 권한 상승: 일반 사용자 → 관리자 권한 획득 시도
  3. 데이터 유출: 타 사용자 개인정보 접근 시도
  4. 비즈니스 로직 악용: 결제 우회, 쿠폰 남용, 레이스 컨디션
  5. API 남용: Rate Limit 우회, 대량 데이터 스크래핑

각 시나리오에 (1) 공격 목표, (2) 공격 절차, (3) 예상 결과, (4) 성공 시 영향도, (5) 방어 확인 방법을 포함해 주세요.

주의: 이 테스트는 자체 개발 환경에서만 수행합니다.

보안 체크리스트 생성 프롬프트

다음 프로젝트의 릴리스 전 보안 체크리스트를 작성해 주세요.

프로젝트 유형: [웹 앱/API/모바일 앱] 체크리스트 범위:

  1. 코드 레벨 보안 (인젝션, XSS, CSRF, 인증)
  2. 인프라 보안 (HTTPS, 헤더, CORS, 쿠키)
  3. 데이터 보안 (암호화, 백업, 접근 제어)
  4. 의존성 보안 (CVE, 라이선스)
  5. 로깅/모니터링 (보안 이벤트, 감사 로그)
  6. 배포 보안 (시크릿 관리, 환경 분리)

각 항목에 확인 방법과 통과 기준을 명시해 주세요.

보안 검증 워크플로우 통합

보안 검증을 일회성 이벤트가 아닌, 개발 워크플로우에 자연스럽게 통합하는 방법을 정리합니다.

CI/CD 보안 파이프라인 프롬프트

다음 CI/CD 파이프라인에 보안 검증 단계를 추가해 주세요.

현재 파이프라인: [워크플로우 YAML] 추가할 보안 단계:

  1. SAST (Static Application Security Testing): 코드 정적 분석
  2. SCA (Software Composition Analysis): 의존성 취약점 스캔
  3. Secret Scanning: 코드 내 하드코딩된 시크릿 탐지
  4. Container Scanning: Docker 이미지 취약점 스캔
  5. DAST (Dynamic Application Security Testing): 배포 후 동적 테스트

Snyk, GitHub Advanced Security, Trivy 등 무료/오픈소스 도구를 우선 사용해 주세요. 심각도 'Critical'인 경우 파이프라인 차단, 'High'는 경고로 설정해 주세요.

보안 코드 검증의 핵심 원칙

보안 영역 AI 활용 포인트 반드시 사람이 판단할 부분
OWASP Top 10 코드 전체 자동 스캔 비즈니스 컨텍스트별 위험도 판단
인젝션 방어 취약 패턴 자동 감지 및 변환 새로운 공격 벡터 인식
인증/인가 패턴 검증 및 모범 사례 적용 접근 제어 정책 설계
의존성 관리 CVE 스캔 및 업그레이드 경로 업그레이드 영향도 및 우선순위
침투 테스트 시나리오 설계 및 자동 실행 결과 해석 및 위험 수용 결정

보안은 "한 번 하면 끝"이 아닙니다. 새로운 취약점은 매일 발견되고, 코드는 계속 변경됩니다. AI를 활용한 지속적 보안 검증을 개발 문화에 내재화하는 것이 가장 효과적인 방어 전략입니다. 다만, AI가 "안전하다"고 판단했다고 해서 맹신해서는 안 됩니다. AI는 알려진 패턴은 잘 잡지만, 비즈니스 로직에 특화된 새로운 공격 벡터는 놓칠 수 있습니다. 최종 보안 판단은 항상 보안 전문가와 개발자가 함께 내려야 합니다.


다음 챕터 미리보기: 8장 'AI 시대 개발자 생존 전략 — 대체되는 역할 vs 강화되는 역할'에서는 AI 시대에 개발자 직군별 대체 위험도를 데이터로 분석하고, 대체되는 업무와 오히려 강화되는 역할을 구분합니다. 개발자 커리어 로드맵, AI 시대 필수 스킬 5가지, 그리고 시리즈 전체 내용을 한눈에 정리하는 요약표를 제공합니다.