[프롬프트] 보안 취약점 탐지 프롬프트 - 최적 프롬프트 레시피
💡 한 줄 요약: "이 코드 보안 취약점 찾아줘"라는 단순 질의 시 발생하는 피상적인 "입력값을 검증하세요" 수준의 원론적 조언을 탈피하고, Principal AppSec Architect 및 수석 보안 감사관 관점에서 OWASP Top 10, CWE 매핑, 실증 가능한 익스플로잇 PoC, 심층 방어(Defense-in-Depth) 패치 코드, API BOLA/IDOR 및 테넌트 격리 결함까지 완벽히 적발하는 실전 보안 감사 프롬프트 레시피입니다.
1. 페인포인트 & 작업 목표
• 실무 상황: 대규모 엔드포인트나 외부 입력을 처리하는 파일 업로드/멀티테넌트 API를 릴리스하기 전 보안 감사를 수행해야 하나, 보안 전문 인력 부족으로 AI에 의존하는 과정에서 피상적이거나 실현 불가능한 이론적 조언만 반복되어 실질적인 공격 벡터를 놓치는 상황.
• 단순 프롬프트 요청 시 발생하는 4대 전형적 문제:
1. 추상적이고 교과서적인 권고(No Fluff 위반): 취약점의 정확한 실행 조건이나 코드 레벨 원인 없이 "입력값을 엄격히 검증하고 방화벽을 설정하세요" 같은 뻔한 잔소리만 나열함.
2. 위협 모델링 및 공격 시나리오 결여: 취약점이 실제 비즈니스 환경에서 어떻게 연쇄 익스플로잇(Exploit Chaining)으로 이어지는지 공격 페이로드(PoC)를 제시하지 못함.
3. 비즈니스 로직 및 인가 결함(BOLA/IDOR) 탐지 실패: SQL Injection 같은 단순 문법적 오류는 감지하지만, 멀티테넌트 환경의 객체 수준 권한 검증 누락이나 JWT 클레임 검증 부재 같은 구조적 결함을 식별하지 못함.
4. 운영 불가능한 수정안 제시: 기존 비즈니스 플로우를 파괴하거나 성능을 심각하게 저하시키는 비현실적 패치 코드를 제시하여 개발자가 실제 프로덕션에 적용할 수 없음.
• 해결 목표:
• Principal AppSec Architect 페르소나 주입: OWASP ASVS 및 CWE 체계를 기반으로 취약점 심각도(CVSSv3), 공격 벡터, 영향도를 명확히 정량화.
• 공격 PoC와 방어 패치의 동시 산출: 공격자가 전송할 구체적 페이로드 시나리오와 이를 무력화하는 프로덕션급 방어 코드(Defense-in-Depth)를 1:1로 대조 제시.
• 감사 목적별 듀얼 레시피 체계화: 시스템 I/O 및 파일 처리/SSRF 공격 벡터를 파헤치는 종합 AppSec 감사(레시피 B)와 마이크로서비스 API 권한/테넌트 격리(BOLA/IDOR) 전용 감사(레시피 C)의 이원화.
2. 프롬프트 레시피 비교
❌ 레시피 A: 기본형 (단순 질의 초안)
역할 정의, 공격 벡터 분석 기준, 패치 요구사항 없이 단순 취약점 탐지만 요청하는 초안입니다.
[영문 프롬프트 (복사용)]
Find security vulnerabilities in this code:
[PASTE_SOURCE_CODE_HERE][한글 프롬프트 (1:1 매칭 복사용)]
이 코드에서 보안 취약점을 찾아줘:
[여기에_소스_코드_붙여넣기]💡 [프롬프트 구조 및 핵심 파라미터 해설란]
• 구조적 결함: 위협 모델, 보안 표준(OWASP/CWE), 공격자 시나리오, 수정 코드 제시 규격이 전무합니다.
• 부작용: AI는 "보안을 위해 입력을 검증하십시오", "HTTPS를 사용하세요" 같은 교과서적이고 모호한 답변만 반환하며 실질적인 위험 소스코드를 짚어내지 못합니다.
⚡ 레시피 B: Principal AppSec Architect 실무 종결형 보안 취약점 감사 프롬프트
파일 업로드, 외부 URL 처리, 시스템 명령어, 역직렬화 등 고위험 I/O 로직에서 Path Traversal, SSRF, 원격 코드 실행(RCE), XSS 취약점을 전방위로 적발하고 심층 방어 코드를 도출하는 종합 레시피입니다.
[영문 프롬프트 (복사용)]
You are a Principal Application Security (AppSec) Architect and Offensive Security Certified Professional (OSCP) conducting a white-box penetration audit.
Perform a rigorous vulnerability assessment on the target source code according to OWASP Top 10 and CWE standards.
### Target Environment & Technology Stack:
- Runtime & Language: [e.g., Node.js 20 LTS / TypeScript 5.4 / Python 3.12 / Go 1.22]
- Framework & Web Server: [e.g., Express.js, FastAPI, Spring Boot, Nginx reverse proxy]
- Source Code to Audit:
[PASTE_SOURCE_CODE_HERE]
### Security Audit Directives:
1. VULNERABILITY TAXONOMY: Identify all flaws with accurate CWE-ID, OWASP Category, and estimated CVSSv3 base score.
2. ATTACK VECTOR & PROOF OF CONCEPT (PoC):
- Provide the exact HTTP request, malicious payload, or sequence of actions needed to exploit each flaw.
- Detail the exploit chain impact (e.g., Local File Inclusion -> Remote Code Execution).
3. ROOT CAUSE ANALYSIS: Pinpoint the exact line numbers and architectural mistakes enabling the bypass.
4. DEFENSE-IN-DEPTH REMEDIATION:
- Provide production-ready, idiomatic patch code replacing vulnerable calls.
- Enforce multi-layered defense: strict schema validation, canonicalization, principle of least privilege, and safe standard APIs.
5. SECURITY UNIT TEST: Write a test asserting that the malicious PoC payload is rejected with appropriate HTTP status/exception.[한글 프롬프트 (1:1 매칭 복사용)]
당신은 화이트박스 모의해킹 감사를 수행하는 수석 애플리케이션 보안 아키텍트(Principal AppSec Architect)이자 OSCP 공인 침투 시험관입니다.
OWASP Top 10 및 CWE 표준에 의거하여 제공된 대상 소스 코드에 대해 철저한 보안 취약점 감사를 수행하십시오.
### 대상 환경 및 기술 스택:
- 런타임 및 언어: [예: Node.js 20 LTS / TypeScript 5.4 / Python 3.12 / Go 1.22]
- 프레임워크 및 웹 서버: [예: Express.js, FastAPI, Spring Boot, Nginx 역방향 프록시]
- 감사 대상 소스 코드:
[여기에_감사_대상_소스_코드_붙여넣기]
### 보안 감사 필수 지침:
1. 취약점 분류 체계화: 정확한 CWE-ID, OWASP 분류, 추정 CVSSv3 기본 점수를 명시하여 결함을 식별하십시오.
2. 공격 벡터 및 실증 PoC(Proof of Concept):
- 각 결함을 공격하기 위해 필요한 구체적 HTTP 요청, 악성 페이로드 또는 작업 시퀀스를 작성하십시오.
- 공격 체이닝 영향도(예: 로컬 파일 인클루전 -> 원격 코드 실행)를 상세히 서술하십시오.
3. 근본 원인 분석: 보안 우회를 허용한 정확한 코드 라인과 아키텍처적 결함을 적시하십시오.
4. 심층 방어(Defense-in-Depth) 조치 코드:
- 취약한 호출부를 완전히 대체하는 실무 프로덕션급 관용적 패치 코드를 제시하십시오.
- 다층 방어 강제: 엄격한 스키마 검증, 경로 정규화(Canonicalization), 최소 권한 원칙, 안전한 표준 API 적용.
5. 보안 회귀 테스트 코드: 악성 PoC 페이로드가 적절한 HTTP 상태 코드 및 예외로 차단되는지 검증하는 테스트 코드를 작성하십시오.💡 [프롬프트 구조 및 핵심 파라미터 해설란]
• CWE 및 CVSSv3 정량화: 취약점의 위험도를 조직 내 우선순위화할 수 있도록 객관적 지표를 강제합니다.
• 공격 PoC 페이로드 요구: 취약점이 단순 이론이 아니라 실제 악용 가능한 조건임을 입증하여 오탐(False Positive)을 획기적으로 줄입니다.
• 심층 방어(Defense-in-Depth) 패치: 정규식 필터링 같은 단편적 우회 방지가 아니라, 경로 정규화, 스토리지 격리, 화이트리스트 검증을 결합한 프로덕션 완성형 코드를 산출합니다.
🚀 레시피 C: API BOLA/IDOR 및 인증/인가 결함 특화 (Auth & Tenant Isolation Auditor)
REST/GraphQL API 환경에서 가장 치명적인 수평적 권한 상승(IDOR/BOLA), 테넌트 간 데이터 침범, JWT 클레임 검증 부재, 대량 할당(Mass Assignment) 결함을 정밀 타격하는 레시피입니다.
[영문 프롬프트 (복사용)]
You are a Principal Security Engineer specializing in Cloud API Security, Zero-Trust Architecture, and OAuth2/OIDC authorization models.
Audit the provided multi-tenant API handler specifically for Broken Object-Level Authorization (BOLA/IDOR), tenant data leakage, and authentication bypasses.
### Target Specifications:
- Framework & ORM/Database: [e.g., NestJS / Express with Prisma / Django with PostgreSQL RLS]
- Identity & Session Model: [e.g., JWT Bearer Token with tenant_id, role, sub claims]
- Target API Endpoint Code:
[PASTE_API_HANDLER_CODE_HERE]
### Specialized Audit Directives:
1. OBJECT-LEVEL AUTHORIZATION AUDIT:
- Trace whether database lookups verify the resource's owner against the authenticated session context (tenant_id, user_id).
- Identify horizontal privilege escalation vectors where User A manipulates resource identifiers to access User B's data.
2. MASS ASSIGNMENT & SCOPE CHECK:
- Inspect request DTOs/body bindings to ensure sensitive fields (e.g., is_admin, role, tenant_id) cannot be overwritten.
3. TENANT ISOLATION HARDENING:
- Implement repository-level or database-level (Row-Level Security) isolation guards instead of relying solely on controller-level checks.
4. EXPLICIT PATCH CODE:
- Provide the complete, hardened handler code with strict authorization policies and domain-level guard clauses.[한글 프롬프트 (1:1 매칭 복사용)]
당신은 클라우드 API 보안, 제로 트러스트 아키텍처, OAuth2/OIDC 인가 모델을 전문으로 하는 수석 보안 엔지니어(Principal Security Engineer)입니다.
제공된 멀티테넌트 API 핸들러에 대해 객체 수준 권한 결함(BOLA/IDOR), 테넌트 간 데이터 누출, 인증 우회 취약점을 정밀 감사하십시오.
### 대상 사양:
- 프레임워크 및 ORM/DB: [예: NestJS / Express + Prisma / Django + PostgreSQL RLS]
- 인증 및 세션 모델: [예: tenant_id, role, sub 클레임을 포함하는 JWT Bearer 토큰]
- 감사 대상 API 엔드포인트 코드:
[여기에_API_핸들러_코드_붙여넣기]
### 특화 감사 필수 지침:
1. 객체 수준 인가(BOLA/IDOR) 감사:
- 데이터베이스 조회 시 인증된 세션 컨텍스트(tenant_id, user_id)와 리소스 소유권을 철저히 교차 검증하는지 추적하십시오.
- 사용자 A가 식별자(ID) 변조를 통해 사용자 B의 리소스에 무단 접근하는 수평적 권한 상승 벡터를 찾아내십시오.
2. 대량 할당(Mass Assignment) 및 스코프 검증:
- 요청 바디 바인딩 시 민감 필드(is_admin, role, balance, tenant_id 등)가 클라이언트 임의로 덮어써질 위험을 검증하십시오.
3. 테넌트 격리 아키텍처 강화:
- 컨트롤러 계층의 단일 IF문에 의존하지 않고, 레포지토리 또는 DB 레벨(Row-Level Security) 격리 가드를 적용하십시오.
4. 완전한 패치 코드 제시:
- 엄격한 인가 정책과 도메인 가드 절이 적용된 프로덕션급 방어 코드를 작성하십시오.💡 [프롬프트 구조 및 핵심 파라미터 해설란]
• 인증 토큰 컨텍스트와 DB 쿼리 추적: URL 파라미터로 넘어오는
orderId나 fileId를 세션 사용자 ID/테넌트 ID와 대조하지 않는 흔한 BOLA 취약점을 직격합니다.• DB 계층 격리(RLS) 유도: 애플리케이션 로직 실수로
where: { id }만 실행되더라도 DB 계층에서 다른 테넌트의 행 조회를 원천 차단하는 엔터프라이즈급 방어 설계를 강제합니다.3. 실행 결과 비교: 레시피 A vs B vs C 실전 대조
❌ 레시피 A 실행 결과: [단순 질의의 한계] 원론적이고 피상적인 답변
사용자 프로필 이미지 다운로드 및 처리 엔드포인트를 레시피 A에 입력했을 때의 결과입니다.
이 코드에는 몇 가지 보안 문제가 있을 수 있습니다:
1. 사용자가 업로드하는 파일 이름을 믿으면 안 됩니다. 파일 이름에 특수문자가 들어갈 수 있으니 검증하세요.
2. 사용자가 다른 사람의 이미지를 요청할 수 있으니 올바른 인증을 적용하세요.
3. 이미지 처리 시 서버 부하가 발생할 수 있으니 적절한 크기 제한을 두세요.비판:
• 구체적으로 어떤 경로 조작(Path Traversal) 공격 페이로드가 가능한지, 어떤 함수가 안전하지 않은지 전혀 언급하지 않습니다.
• 실제 실행 가능한 공격 PoC나 즉시 적용 가능한 안전한 코드 조각을 단 한 줄도 제공하지 않아 보안 감사로서 무가치합니다.
⚡ 레시피 B 실행 결과: [실전 사례 1] 파일 업로드 및 이미지 처리 API 취약점 전면 감사
외부 URL을 받아 이미지를 다운로드하고 서버 로컬 디렉터리에 저장한 뒤 썸네일을 생성하는 Express 엔드포인트를 레시피 B로 감사한 결과입니다.
AI 생성 출력 결과 (핵심 발췌)
[취약점 평가 요약]
- 취약점 1: CWE-918 서버 측 요청 위조 (SSRF) | CVSSv3: 9.1 (Critical) | OWASP A10:2021
- 취약점 2: CWE-22 경로 조작 (Path Traversal) | CVSSv3: 8.6 (High) | OWASP A01:2021
- 취약점 3: CWE-79 악성 SVG를 통한 저장형 XSS | CVSSv3: 7.2 (High) | OWASP A03:2021
[공격 시나리오 및 PoC]
1. SSRF: imageUrl에 "http://169.254.169.254/latest/meta-data/iam/security-credentials/" 전달 시 AWS 클라우드 메타데이터 토큰 탈취 가능.
2. Path Traversal: filename 파라미터에 "../../../etc/passwd" 주입 시 임의 파일 덮어쓰기 또는 민감 시스템 파일 유출.심층 방어(Defense-in-Depth) 패치 코드 (TypeScript / Express)
import path from 'path';
import crypto from 'crypto';
import { Request, Response } from 'express';
import { z } from 'zod';
import ipaddr from 'ipaddr.js';
import sharp from 'sharp';
// 1. 입력 스키마 및 URL 화이트리스트 검증 (Zod)
const DownloadSchema = z.object({
imageUrl: z.string().url(),
category: z.enum(['avatar', 'cover', 'attachment']),
});
const STORAGE_ROOT = path.resolve('/var/app/secure_storage');
// SSRF 방어: 사설 IP 대역(RFC 1918, Link-local, Loopback) 원천 차단 함수
function validatePublicIp(targetIp: string): boolean {
const addr = ipaddr.parse(targetIp);
const range = addr.range();
const forbiddenRanges = ['loopback', 'private', 'linkLocal', 'carrierNat', 'reserved'];
return !forbiddenRanges.includes(range);
}
export async function secureImageProcessor(req: Request, res: Response) {
const parsed = DownloadSchema.safeParse(req.body);
if (!parsed.success) {
return res.status(400).json({ error: 'INVALID_REQUEST_PAYLOAD', details: parsed.error.issues });
}
const { imageUrl, category } = parsed.data;
const parsedUrl = new URL(imageUrl);
// 프로토콜 제한 (HTTP/HTTPS만 허용, gopher://, file:// 차단)
if (!['http:', 'https:'].includes(parsedUrl.protocol)) {
return res.status(400).json({ error: 'UNSUPPORTED_PROTOCOL' });
}
// 2. Path Traversal 원천 방지: 사용자 입력 파일명 폐기 -> UUID 기반 안전한 파일명 강제
const safeFilename = `${crypto.randomUUID()}.webp`;
const targetDir = path.join(STORAGE_ROOT, category);
const finalPath = path.resolve(targetDir, safeFilename);
// 정규화된 경로가 STORAGE_ROOT 하위인지 검증 (Canonicalization Guard)
if (!finalPath.startsWith(STORAGE_ROOT)) {
return res.status(403).json({ error: 'PATH_TRAVERSAL_DETECTED' });
}
// 3. 이미지 리사이징 및 버퍼 재인코딩을 통한 악성 SVG/WebShell 무력화
const response = await fetch(imageUrl, { signal: AbortSignal.timeout(5000) });
const rawBuffer = Buffer.from(await response.arrayBuffer());
await sharp(rawBuffer)
.resize(500, 500, { fit: 'inside' })
.webp({ quality: 80 })
.toFile(finalPath);
return res.status(201).json({ message: 'PROCESSED_SUCCESSFULLY', resourceId: safeFilename });
}후속 체이닝: S3 프리사인드(Presigned) 업로드 및 Snyk 취약점 감사 연동
체이닝 1: "로컬 디스크 저장 대신 AWS S3 Presigned URL 발급 방식으로 구조를 전환하고, S3 버킷 정책에서 퍼블릭 읽기를 차단하는 테라폼(Terraform) 인프라 코드와 발급 엔드포인트를 작성해줘."
체이닝 2: "위 코드의 Sharp 및 의존성 라이브러리에 알려진 메모리 오버플로 CVE가 존재하는지 검증하기 위한 Snyk/npm audit 자동화 CI 스크립트를 작성해줘."
4단계 워크플로우
1. 취약점 식별 및 CVSS 점수화: 영향도와 악용 난이도를 정량 평가.
2. 익스플로잇 PoC 구성: 공격 페이로드 전송 시나리오 구체화.
3. 심층 방어 패치 적용: Zod 유효성 검사 + IP 대역 검증 + UUID 파일명 + Sharp 변환의 4중 방어벽 구축.
4. 보안 단위 테스트 작성:
../../ 주입 및 메타데이터 IP 요청 시 400/403 차단 단언.🚀 레시피 C 실행 결과: [실전 사례 2] 멀티테넌트 SaaS 주문 조회 API의 IDOR/BOLA 수평 권한 탈취 격리
테넌트 간 데이터가 섞일 위험이 있는 SaaS 주문 단건 조회 API 핸들러를 레시피 C로 감사한 결과입니다.
AI 생성 출력 결과 (핵심 발췌)
[BOLA/IDOR 아키텍처 결함 발견]
- 취약점: CWE-639 사용자 제어 키를 통한 인가 우회 (BOLA / IDOR) | CVSSv3: 8.5 (High)
- 문제 라인: prisma.order.findUnique({ where: { id: req.params.orderId } })
- 결함 원인: 주문 PK(orderId)만으로 단건 조회를 수행하며, 세션 토큰의 tenantId 및 userId와의 소유권 일치 여부를 대조하지 않음.
- 공격 시나리오: 테넌트 A의 사용자가 테넌트 B의 orderId(UUIDv4 브루트포스 또는 유출된 ID)를 파라미터로 넘기면 테넌트 B의 결제 내역과 개인정보가 평문 반환됨.소유권 검증 및 RLS 격리 패치 코드 (TypeScript + Prisma)
import { Request, Response } from 'express';
import { prisma } from '../lib/prisma';
import { ForbiddenError, NotFoundError } from '../errors';
// 세션 토큰에서 추출된 인증 컨텍스트 인터페이스
interface AuthenticatedUser {
userId: string;
tenantId: string;
role: 'ADMIN' | 'MEMBER';
}
export async function getOrderSecurely(req: Request, res: Response) {
const user = req.user as AuthenticatedUser;
const { orderId } = req.params;
// 1. BOLA 원천 차단: ID 단독 조회가 아닌 [tenantId + orderId] 복합 조건 강제
const order = await prisma.order.findFirst({
where: {
id: orderId,
tenantId: user.tenantId, // 테넌트 격리 보장
// 일반 사용자는 본인이 생성한 주문만 열람 가능 (권한 세분화)
...(user.role !== 'ADMIN' ? { customerId: user.userId } : {})
},
select: {
id: true,
orderNumber: true,
totalAmount: true,
status: true,
createdAt: true,
// 민감한 결제 카드 토큰 등은 명시적으로 제외(Mass Exposure 방어)
}
});
if (!order) {
// 테넌트가 다르거나 존재하지 않는 리소스에 대해 동일한 404를 반환하여 ID 존재 유무 탐색(Enum Attack) 차단
return res.status(404).json({ error: 'RESOURCE_NOT_FOUND' });
}
return res.status(200).json({ data: order });
}후속 체이닝: PostgreSQL Row-Level Security (RLS) 정책 자동 생성
추가 프롬프트: "애플리케이션 개발자가
where: { tenantId } 절을 실수로 누락하더라도 DB 레벨에서 트랜잭션별 app.current_tenant_id 세션 변수와 매칭되지 않는 행은 원천적으로 조회되지 않도록 차단하는 PostgreSQL Row-Level Security(RLS) DDL 쿼리를 생성해줘."3단계 워크플로우
1. 인가 모델 교차 분석: URL 파라미터와 JWT 세션 클레임 간의 소유권 연결 고리 추적.
2. 복합 조건부 조회 패치: 테넌트 ID 및 사용자 역할을 쿼리 조건에 강제 주입.
3. DB 레벨 심층 격리: RLS 설계를 통해 컨트롤러 실수에 대비한 2차 안전망 확보.
4. 보안 취약점 탐지를 위한 4대 엔지니어링 원칙
1. 실증 가능한 공격 PoC(Proof of Concept) 요구:
• 추상적 취약점 지적을 배제하고 구체적인 공격 HTTP 페이로드를 생성하게 함으로써 오탐을 걸러내고 패치의 시급성을 즉각 증명합니다.
2. 심층 방어(Defense-in-Depth) 패치 강제:
• 취약 함수 1개를 바꾸는 미봉책을 넘어 입력 유효성 검사(Zod), 런타임 제약(UUID 대체), DB 레벨 제약(RLS)까지 3단계 방어벽을 동시에 수립합니다.
3. 열거 공격(Enumeration Attack) 방지 및 안전한 에러 응답:
• 인가 실패 시 403 Forbidden 대신 404 Not Found를 통일하여 공격자가 무차별 대입을 통해 리소스 존재 유무를 확인하지 못하도록 설계합니다.
4. 보안 회귀 단위 테스트 동시 도출:
• 보안 패치가 작성된 즉시 공격 페이로드를 전달하여 400번대 에러가 발생하는지 단언(Assert)하는 회귀 테스트를 파이프라인에 편입합니다.
5. 실전 투입용 플레이스홀더 템플릿
[역할 정의]
당신은 엄격한 화이트박스 코드 감사와 침투 테스트를 전문으로 하는 Principal AppSec Architect입니다.
[대상 환경 및 아키텍처 사양]
- 언어 및 런타임: [예: Node.js 20 / Python 3.12 / Java 21 / Go 1.22]
- 프레임워크 및 DB: [예: Express + Prisma / FastAPI + SQLAlchemy / Spring Boot + JPA]
- 배포 인프라: [예: AWS ECS / Kubernetes / Lambda / Cloudflare Workers]
[감사 대상 소스 코드][여기에 보안 검토를 진행할 코드를 붙여넣으십시오]
[보안 감사 요구사항]
1. OWASP Top 10 및 CWE 기준으로 식별된 취약점을 분류하고 CVSSv3 점수를 추정할 것.
2. 해당 결함을 실제 악용할 수 있는 공격 페이로드(HTTP 요청 / 입력값 PoC)를 제시할 것.
3. 취약 코드를 안전한 표준 API 및 심층 방어 원칙으로 전면 수정한 프로덕션 패치 코드를 작성할 것.
4. 악성 입력을 주입했을 때 안전하게 차단되는지 검증하는 보안 단위 테스트를 작성할 것.6. 프롬프트 활용 팁 & 주의사항
1. AI의 정규식 필터링 편향 경계:
• AI는 종종 취약점을 막기 위해 복잡한 정규식(Regex)을 제시하지만, 이는 ReDoS(정규식 DoS)를 유발하거나 기형 유니코드/URL 인코딩 우회에 무너집니다. 정규식 차단 대신 화이트리스트 파싱이나 안전한 표준 라이브러리를 쓰도록 지시하십시오.
2. 가상 공격 페이로드의 안전성 보장:
• AI가 생성한 PoC 페이로드는 오직 격리된 로컬 테스트 환경이나 스테이징 서버에서만 검증하고, 프로덕션 환경에 직접 전송하지 마십시오.
3. 외부 의존성(SCA)과 로직 취약점 분리:
• 패키지 버전 문제는
npm audit이나 Trivy 같은 전용 SCA 도구에 맡기고, AI 프롬프트로는 비즈니스 인가 결함(BOLA)과 커스텀 데이터 파이프라인의 설계상 결함을 발굴하는 데 집중하십시오.4. 최소 권한의 원칙(PoLP) 실천:
• 아무리 코드를 안전하게 패치하더라도 실행 컨테이너가 루트(root) 권한이거나 클라우드 IAM 역할이 과도하면 무력화됩니다. 코드 패치와 함께 인프라 최소 권한 설정을 병행하십시오.
