요약
- 기존 보안 지식은 여전히 필수다. OWASP Top 10, SAST/DAST/SCA 같은 전통적 프레임워크는 사라지지 않는다.
- AI 도구는 "쓸 수 있다"가 아니라 "잘 설계해야 한다". 도구를 쓰는 것 자체보다 프롬프트 설계, context 관리, 결과 검증 파이프라인 설계 능력에 따라 다른 성능을 보여준다.
- AI는 새로운 공격 백터이다. 보안 위협으로 다룰 수 있어야 한다.
TL;DR — 보안에서 AI는 어떻게 쓰이는가?
두 가지 방식으로 나뉜다:
A. 기존 도구에 통합 (보조 레이어)
CI의 규칙 기반 스캔(SAST)은 그대로 돌리고, AI는 스캔 전후에 끼어든다.
- 스캔 후 트리아지: SAST가 뱉은 결과에서 false positive를 LLM이 걸러냄 (Semgrep Assistant — 60% 자동 트리아지, 사용자 동의율 96%)
- 스캔 후 자동 수정: true positive에 대해 LLM이 패치 생성 → 엔진으로 검증
- 로직 취약점 탐지: 규칙으로 못 잡는 IDOR 등을 LLM 에이전트가 엔진을 도구로 사용해 탐지 (정밀도 61%, LLM 단독 22% 대비 3배)
B. LLM을 독립적 분석기로 사용 (전체 코드 파악)
소스코드를 LLM에 직접 넣고 취약점을 찾게 하는 방식. 기존 도구 없이 LLM 자체가 분석기 역할.
- 대규모 탐지: 실제 high severity 버그 발견 가능하나, FPR 80%+, 비결정적 (Semgrep의 Claude Code/Codex 실험)
- 정밀 탐지: 프롬프트를 정교하게 설계하면 0-day도 발견 (o3 → Linux 커널 CVE-2025-37899). 단, 연구자가 코드를 사전 선별해 제공한 단일 사례.
핵심 차이: A는 기존 파이프라인의 노이즈를 줄이고, B는 새로운 버그를 찾는다. 둘 다 프롬프트 설계와 context 관리가 성능을 결정한다.
TODO
Isaac Evans, CEO Semgrep
Semgrep는 코드 취약점 탐지용 정적 분석(SAST) 도구다. 최근 AI를 보조 레이어로 추가한 하이브리드 방식을 도입했다.
슬라이드 없어서 스킵
- 소프트웨어 오류 → 사용자 신뢰 상실 + 막대한 비용
- LLM이 코드를 작성하는 시대 → 가드레일 필수
- 실제 사례: Replit AI가 고객 코드베이스 삭제, GitHub Copilot RCE 취약점 (CVE-2025-53773)
SQL Injection, XSS, Broken Authentication, Insecure Direct Object References, Security Misconfiguration, Sensitive Data Exposure
- SAST (Static Application Security Testing)
- 방식: White box — 소스코드/바이너리 정적 분석
- 시점: SDLC 초기 (비용 저렴)
- 기법: 패턴 매칭 코드 스캔
- 도구: Bandit, Semgrep, ESLint
- DAST (Dynamic Application Security Testing)
- 방식: Black box — 실제 해커 행동 모방
- 시점: SDLC 전반 (false positive 적음)
- 기법: Input fuzzing, 세션 토큰 조작, brute force
- SCA (Software Composition Analysis)
- 방식: OSS 패키지 분석
- 시점: 의존성 관리 시
- 기법: 메타데이터 분석, 취약점 DB 매칭
AI 에이전트 공격 백터 등장
- Prompt Injection - 숨겨진 지시로 AI 동작 변조
- 예: TutorBot에 악성 지시 삽입; AMP에서 시스템 프롬프트 전문 추출
- Tool Misuse - 기만적 프롬프트로 도구 악용
- 예: AMP가 settings.json 수정 → 악성 MCP 서버 추가 + 임의 코드 실행
- Code Attacks - 코드 실행으로 실행 환경 비인가 접근
- 예: Copilot
chat.tools.autoApprove자동 승인 위험
- 예: Copilot
- Intent Breaking - 에이전트 계획을 원래 의도에서 이탈시킴
- Identity Spoofing - 인증 탈취로 정당한 에이전트 사칭
- "Shift left" 보안이 더 접근 가능해짐
- Shift left: 보안 단계를 더 이른 단계(왼쪽)로 옮기는 것
- 기존 SAST/DAST 파이프라인에 LLM을 통합하여 트리아지·수정 자동화
- LLM을 독립 분석기로 사용하여 규칙 기반 도구가 놓치는 취약점 탐지
- 자동화된 침투 테스팅
- False Positive — LLM 자체 탐지: LLM을 독립적 취약점 탐지기로 사용할 경우 FPR 80%+ 보고 사례 존재 (예: Semgrep의 Claude Code / Codex 실험). LLM이 “취약점이다”라고 플래그한 것 중 상당수가 실제로는 취약점이 아님. 확률적 추론, 과잉 일반화, 문맥 오해가 주요 원인.
- 벤치마크 비현실적: LLM 평가가 어려움 (현실 코드베이스·환경 의존성 반영 부족)
- 비결정적 분석: 동일 프롬프트 → 다른 결과 → 완전한 커버리지 보장 불가
- Context Rot / Compaction: 컨텍스트 품질 편차 + 요약 과정에서 정보 손실 발생
이 글에서 전체적으로 다뤄지는 False Positive는 2가지 의미로 쓰인다.
- LLM 자체 탐지의 FP: 확률적 추론 기반이라 보수적으로 과잉 탐지하는 경향이 있으며, 실제 exploit 불가능한 코드까지 취약점으로 판단하는 경우가 많음.
- 기존 정적 분석 도구의 FP: - 패턴 매칭 중심 탐지로 인해 실제 취약점이 아님에도 경고가 발생하며, 데이터 흐름·런타임 맥락을 충분히 반영하지 못하는 한계가 있음.
- (LLM을 추가로 도입하여 유의미한 개선이 된다. 예: Semgrep Assistant의 AI Triage 기능, 기존 탐지 결과를 LLM이 재검토하여 노이즈를 줄이는 보조 계층이다.)
- False positive / hallucination 감소 방법?
- LLM 생성 패치의 안전성·regression 검증?
- LLM의 취약점 플래그/수정 제안에 대한 설명 가능성(explainability)?
- AppSec 성능의 올바른 벤치마크?
- CI/CD 통합 시 노이즈 최소화?
- AI 생성 패치가 취약점을 유발하면 책임은 누구에게?
- 기존 보안 테스팅(SAST/DAST/SCA)은 상호 보완적이며, AI 시대에도 기본 프레임워크로 유효하다.
- AI 에이전트의 공격 벡터는 프레임워크에 무관한 AI 에이전트의 구조적 문제이다.
- LLM 기반 취약점 탐지는 높은 수준(실제 0-day 찾음), 높은 false positive율·비결정적 분석·context rot 등의 핵심 한계를 가진다.
- SAST vs. DAST vs. RASP — Splunk
- 세 가지 보안 테스팅 기법 비교 해설.
- 핵심:
- SAST(white-box), DAST(black-box) 설명 - 위에 있으니까 스킵
- RASP: 앱 내부에 보안 모듈 삽입, 실시간 공격 탐지·차단. SAST/DAST가 놓치는 런타임 공격 대응.
- 세 기법은 경쟁이 아니라 보완 관계.
- OWASP Top Ten Web Application Security Risks
- 최신 버전은 OWASP Top 10 2025. 웹 앱에서 가장 치명적인 보안 위험 10가지에 대한 업계 표준 인식 문서.
- 개발자가 보안 코딩의 첫 단계로 채택해야 할 프레임워크.
- 이건 나중에 읽기, 뭐가 많네.
- GitHub Copilot: Remote Code Execution via Prompt Injection (CVE-2025-53773) — Embrace The Red
- Copilot Agent Mode에서 prompt injection → 설정 파일 변조(
autoApprove: true) → RCE 전체 공격 체인 분석. 봇넷·AI 바이러스로의 확장 가능성까지 시연.
- Copilot Agent Mode에서 prompt injection → 설정 파일 변조(
- AI Agents Are Here. So Are the Threats. — Palo Alto Unit 42
- CrewAI·AutoGen 두 프레임워크에서 동일 9가지 공격 재현. 핵심 결론: 취약점은 프레임워크가 아니라 에이전트 아키텍처의 구조적 문제(설정 오류, 도구 미보호, 자격 증명 유출)에서 발생. defense-in-depth(여러 계층의 방어) 필수.
- 코드 오픈소스: GitHub
- Finding vulnerabilities in modern web apps using Claude Code and OpenAI Codex — Semgrep
- Semgrep에서 진행한 Claude Code와 Codex로 실제 대규모 OSS 11개에서 취약점 탐지 실험.
- 결과: 실제 high severity 버그를 찾을 수 있으나, false positive가 80%+ 이상으로 노이즈가 심함. 동일 프롬프트·코드를 반복 실행해도 결과가 매번 달라지는 비결정성이 핵심 문제. 기존 벤치마크(WebGoat 등)는 LLM 학습 데이터에 오염되어 비현실적.
- 참고: 이 실험은 LLM을 독립적 탐지기로 사용한 것. Semgrep Assistant의 하이브리드 트리아지 방식(기존 엔진 + LLM 보조)과는 별개.
- o3 finds CVE-2025-37899 — system prompt (GitHub) / 블로그 원문
- o3 API만으로 Linux 커널의 원격 0-day use-after-free를 발견한 사례. 동시성 환경에서 객체 생명주기를 추론하여 인간 리뷰어가 놓친 버그를 잡음
- 의의: 프롬프트에 "false positive보다 미보고가 낫다" + 자기 검증 루프(코드 경로 기술 → 조건문 검증 → 모순 점검)를 명시한 것이 결과 품질에 결정적. 위 Semgrep 실험의 높은 FPR과 대비되며, 프롬프트 설계가 LLM 보안 분석의 핵심 변수임을 시사.
- 한계: 단일 사례이고, 연구자가 코드를 사전 선별 제공 → 자동화 대규모 탐지와는 다름.
- Context Rot: How Increasing Input Tokens Impacts LLM Performance — Chroma Research
- 18개 LLM(GPT-4.1, Claude 4, Gemini 2.5, Qwen3 등) 대상으로, 태스크 복잡도를 고정한 채 입력 길이만 변화시켜 성능을 측정한 기술 보고서.
- 결과:
- 입력이 길어질수록 성능이 비균일하게 열화: 10,000번째 토큰과 100번째 토큰을 동일하게 처리한다는 가정이 틀림.
- 표준 NIAH 벤치마크는 과대평가: NIAH는 단순 어휘 검색(lexical retrieval)이라 높은 점수가 나오지만, semantic 매칭·distractor 존재·haystack 내용 변화 조건에서는 성능 저하가 뚜렷.
- 길이 자체가 원인: 태스크 난이도가 동일해도 입력 토큰 수 증가만으로 성능 하락 발생.
- 실제 앱(에이전트, 요약, 코드 분석)은 벤치마크보다 훨씬 복잡하므로 영향이 더 클 것으로 예상.