AI 해커는 침투 테스트보다 빠르다 — 지속적 오펜시브 시큐리티

URL: https://www.youtube.com/watch?v=f3o0-9Dlw3E 날짜: 2026-10-07 (실제 YouTube 업로드일) 채널: aiDotEngineer (AI Engineer) 처리일: 2026-10-08 발표자: Eli Cohen, Snyk Field CTO

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==코드가 배포되는 속도와 AI 해커가 공격하는 속도가 모두 인간 보안팀의 처리 속도를 넘어선다면, 침투 테스트를 연 1~3회 하는 방식으로는 애플리케이션을 지킬 수 없다. 지속적 오펜시브 시큐리티는 LLM 기반 침투 테스트·에이전트 레드팀·동적 테스트를 코드 변경마다 실행하고, 실제 악용 가능성이 입증된 문제만 실행 가능한 수정안과 함께 전달해야 한다.==

• AI 코딩 에이전트가 개발자 1인당 생성하는 코드량은 과거보다 218% 늘었고, 개발자의 85% 이상이 코딩 에이전트를 사용한다.
• LLM이 생성한 출력의 62%가 안전하지 않거나 깨져 있으며, 취약점이 생산 환경으로 유입되는 속도가 보안 백로그를 해결하는 속도를 앞선다.
• AI 공격의 평균 성공 시간은 자동자막상 24.34분으로 제시됐고, 가장 빠른 사례는 4분이었다.
• MCP 서버의 43%에 취약점이 있다는 수치까지 겹치면서, 공격자는 방어자가 쓰는 것과 같은 frontier model과 도구로 24시간 공격한다.

AI 시대의 보안은 정적 분석·동적 분석·인간 침투 테스트 중 하나를 고르는 문제가 아니라 각각 잘하는 취약점 영역을 결합하고, 애플리케이션 비즈니스 컨텍스트를 이해하는 공격형 에이전트를 지속적으로 돌리는 운영 문제다. 개발자는 더 많은 코드를 더 빠르게 배포하고, 공격자는 낮은 심각도의 문제를 연결해 치명적인 공격 경로로 만들며, 보안팀은 거짓 양성보다 실제로 악용되는 문제와 수정 방법에 집중해야 한다.

1. AI 코딩 에이전트가 바꾼 공격 속도

코드 생산량이 폭증한 동시에 안전하지 않은 코드와 자동화된 공격이 함께 늘어나 기존의 보안 백로그가 구조적으로 감당 불가능해졌다.

1.1. Eli Cohen의 배경과 청중

1. 제품·현장 보안 경험

   1. Eli Cohen은 런타임 보안 회사 Helios의 공동 창업자 겸 CEO였고, Helios는 Snyk에 인수됐다.
   2. 인수 뒤 2년 반 동안 Snyk에서 AI 제품의 제품 관리를 맡았고, 최근에는 Field CTO로서 개발자와 보안 담당자가 AI 보안 전략을 세우도록 돕고 있다.
   3. 핵심 관심사는 AI 에이전트를 안전하게 만드는 일과 생산 환경에서 에이전트를 운영하는 방법이다.

2. 서로 다른 역할을 한 방에 묶는 설명

   1. 손들기 질문으로 개발자, 보안 담당자, 영업·마케팅 담당자, 개발·보안 직군은 아니지만 생산 환경에서 에이전트를 운영하는 사람을 구분했다.
   2. AI engineering conference의 청중이므로 개발자와 보안팀 모두 이해할 수 있도록 기초 개념부터 설명하고, 특정 공급업체에 종속되지 않는 원칙으로 확장했다.
   3. 시작할 때 타이머를 설치해 달라고 요청하고 남은 시간을 확인하는 장면으로 발표의 시간 제약과 실무적 분위기를 만들었다.

1.2. 코드와 취약점의 동시 폭증

1. 개발자당 코드량 증가

   1. Snyk 데이터에 따르면 개발자 1인당 생성되는 코드 라인이 과거보다 218% 많아졌다.
   2. 개발자의 85% 이상이 코딩 에이전트를 사용한다.
   3. 각자가 Claude Code 세션을 다섯 개씩 동시에 돌리고 있을 것이라는 농담으로, 실제 AI engineering 행사에서는 사용률이 100%를 넘을 수도 있다고 과장했다.

2. AI 생성 코드의 낮은 보안성

   1. LLM이 생성한 출력의 62%가 안전하지 않거나 깨져 있다.
   2. 더 많은 코드가 생산 환경으로 들어오는데 그중 안전하지 않은 코드의 비율도 높아져, 보안 이슈 백로그가 길고 커지며 수정 난이도까지 올라간다.
   3. 팀은 해결·완화할 수 있는 속도보다 훨씬 빠른 속도로 새 취약점을 만들어 내고 있다.

3. 공격자도 같은 AI를 사용한다

   1. 공격자는 여러 낮은 심각도의 취약점을 연결해 하나의 치명적인 공격 경로를 만들 수 있다.
   2. 애플리케이션 컨텍스트를 파악하기 어려운 영역을 LLM이 특히 많이 노리는 방식으로 공격이 정교해진다.
   3. 방어자만 frontier model을 사용하는 것이 아니라 공격자도 같은 모델과 도구를 활용한다.

1.3. 공격 유효 시간이 짧아지는 현실

1. 분 단위로 줄어든 공격 시간

   1. AI 공격이 성공하기까지 걸리는 평균 시간은 자동자막상 “24.34분”으로 제시됐고, 가장 빠른 기록은 4분이었다.
   2. 발표자가 말하는 20분 남짓한 세션 중에도 생산 시스템 하나가 이미 AI 공격에 뚫릴 수 있다는 의미다.
   3. 4분은 약 5번의 발표 세션 시간보다도 짧다는 비유가 마지막에 다시 등장한다.

2. AI 모델과 인프라 취약점의 사례

   1. 발표에는 600개 이상의 취약점을 찾아 600개 방화벽을 뚫고 555개국 이상에서 작동했다는 운영 모델 사례가 언급된다.
   2. ‘555개국’이라는 자동자막 수치는 현실적으로 비정상적인 표현이므로, 원 발화가 국가가 아닌 조직·환경을 가리켰을 가능성이 있지만 공격 자동화 규모가 매우 크다는 메시지는 분명하다.
   3. MCP 서버의 43%에 취약점이 있다는 수치까지 합치면 에이전트 연결 계층 자체가 공격 표면이 된다.

3. 방어 운영에 남는 결론

   1. Claude Code나 Codex 세션을 여러 개 돌리며 24시간 코드를 밀어 넣는 개발팀을, 공격자가 훨씬 짧은 주기로 시험한다.
   2. 연 몇 차례 보안 점검으로는 나머지 기간에 쌓이는 공격 경로를 다룰 수 없다.
   3. 보안팀은 보안 백로그를 단순히 늘려 기록하는 체계가 아니라, 실제 악용 가능성과 우선순위를 증명하는 체계로 전환해야 한다.

2. 전통적인 보안 검사의 역할과 한계

정적 분석, 동적 분석, 인간 침투 테스트는 서로 다른 종류의 문제를 잘 찾으므로 하나의 검사로 통합해 대체할 수 없다.

2.1. SAST: 저렴하고 빠른 정적 코드 분석

1. 코드 변경에 붙는 기본 검사

   1. 개발자가 새 코드를 생산 환경으로 밀어 넣을 때 정적 분석기(SAST)가 코드를 훑는다.
   2. SQL injection과 cross-site scripting(XSS)처럼 코드의 패턴에서 확인할 수 있는 문제를 찾는다.
   3. 모든 코드 변경에 실행할 만큼 상대적으로 저렴하고 간단했다.

2. 런타임 문제를 놓치는 경계

   1. 권한 부여(authorization) 문제와 설정(configuration) 문제처럼 실행 환경에서 드러나는 이슈는 정적 분석만으로 잡기 어렵다.
   2. 코드가 정적으로 안전해 보여도 실제 사용자·객체·환경의 관계에서 권한이 새면 다른 검사가 필요하다.
   3. 따라서 SAST는 이후 검사를 대체하는 만능 도구가 아니라 코드 수준 취약점에 강한 한 축이다.

2.2. DAST: 실행 중인 애플리케이션을 두드리는 검사

1. 런타임 권한 문제의 대표 사례

   1. 동적 애플리케이션 보안 테스트(DAST)는 실행 중인 애플리케이션에 요청을 보내 결과를 관찰한다.
   2. BOLA(broken object level authorization)는 사용자 A가 사용자 B의 데이터에 접근하는 문제다.
   3. BOLA는 정적 분석으로는 사실상 찾을 수 없고, 런타임에서 애플리케이션을 실제로 찔러 봐야 드러난다.

2. 사전 정의 payload의 장점과 한계

   1. DAST 스캐너는 많은 사전 정의 payload를 준비해 여러 API endpoint로 전송한다.
   2. 애플리케이션의 응답 차이를 확인해 정적 코드에 없는 새로운 취약점을 찾아낸다.
   3. 그러나 정해진 payload와 탐색 방식만으로는 LLM이 만들어 낸 애플리케이션의 비즈니스 로직, 즉 ‘무엇을 할 수 있어야 하는가’와 ‘어떤 순서가 금지되는가’를 충분히 추론하지 못한다.

2.3. 인간 침투 테스트: 비즈니스 로직의 황금 기준

1. 컨텍스트를 이해하는 사람의 공격

   1. 인간 침투 테스터는 애플리케이션의 개념과 비즈니스 로직을 이해한 뒤 일부러 깨뜨리며 취약점을 찾는다.
   2. 자동화된 payload가 모르는 사용자 흐름, 업무 규칙, 여러 단계의 공격 경로를 추론하는 점이 강점이다.
   3. 그래서 인간 침투 테스트는 애플리케이션 보안 검사의 황금 기준으로 여겨져 왔다.

2. 비용 때문에 낮아지는 검사 빈도

   1. 실제로 공격을 수행하는 보안 연구자 한 명이 필요하므로 비용이 높다.
   2. 비싸고 느린 과정 때문에 기업은 보통 1년에 한 번, 많아야 두세 번 정도만 수행한다.
   3. AI 공격자가 계속해서 공격하는 상황에서 1년에 두 번 검사하는 것은 충분하지 않으며, 검사받지 않는 나머지 350여 일이 공격 창구가 된다.

3. 결과물이 개발자에게 도착하는 방식

   1. 침투 테스트가 끝나면 거창한 PDF 보고서가 나온다.
   2. 개발자는 보고서를 다시 읽어 무엇이 진짜 문제인지와 무엇이 아닌지를 판별하고, 수정한 뒤 재테스트를 요청해야 한다.
   3. 사람 사이에서 PDF를 전달하고 재검증을 기다리는 흐름은 1990년대 영화 같은 방식이며, 코드와 공격 속도가 분 단위인 지금의 배포 모델과 맞지 않는다.

3. 지속적 오펜시브 시큐리티의 새 운영 모델

생산 시스템을 ‘unknown unknowns’로부터 준비하려면 침투 테스트를 일회성 행사에서 코드 변경마다 실행하는 지속적 공격 검증으로 바꿔야 한다.

3.1. EVO가 묶는 세 가지 능력

1. AI 침투 테스트

   1. LLM이 애플리케이션의 비즈니스 컨텍스트를 이해하고, 인간 테스터가 맡던 맥락 기반 공격을 수행한다.
   2. 사람을 단순히 loop 안에 넣는 방식이 아니라, LLM을 사용해 침투 테스트 자체를 지속적이고 확장 가능하게 만든다.
   3. AI 침투 테스트는 Snyk의 EVO(Continuous Offensive Security)라는 제안의 중심이지만, 원칙 자체는 어떤 공급업체나 자체 구축에도 적용된다.

2. 에이전트 레드팀

   1. 단일 요청의 취약점이 아니라 여러 단계로 이어지는 공격을 시뮬레이션한다.
   2. prompt injection, data exfiltration, goal hijacking 같은 공격을 조합해 에이전트의 행동 경계를 확인한다.
   3. 에이전트가 한 번의 입력에 반응하는지만 보지 않고 공격자가 목표를 바꾸고 데이터를 빼내는 흐름까지 추적한다.

3. 동적 테스트와 통합

   1. DAST가 잘 찾는 authorization 문제를 함께 검사한다.
   2. AI 레드팀의 다단계 공격과 동적 권한 검사를 하나의 offensive security suite로 묶는다.
   3. 공격자가 방어자와 같은 도구를 사용해 24시간 공격하는 상황에 맞춰 방어 검증도 계속 실행한다.

3.2. 코드 변경마다 실행되는 침투 테스트

1. 연 1~3회에서 모든 PR로 전환

   1. 더 이상 1년에 두세 번만 침투 테스트를 예약하지 않는다.
   2. 모든 pull request와 모든 delta, 즉 직전 상태에서 달라진 코드마다 침투 테스트를 실행한다.
   3. 개발자는 변경된 코드가 무엇을 깨뜨렸는지와 무엇을 다르게 고쳐야 하는지 바로 전달받는다.

2. 애플리케이션 컨텍스트 활용

   1. 인간 침투 테스트의 강점이던 비즈니스 컨텍스트 이해를 LLM의 강점과 결합한다.
   2. 여러 머신과 여러 환경에서 얻은 컨텍스트를 합쳐 LLM이 애플리케이션의 구조와 공격 경로를 더 잘 이해하게 한다.
   3. 컨텍스트가 풍부할수록 취약점을 찾는 정확도가 높아지고, 무관한 경고를 줄이는 데도 도움이 된다.

3. 발견보다 악용 가능성 증명

   1. 취약점처럼 보인다는 이유만으로 버그를 생성하지 않는다.
   2. 실제로 exploit 가능한지 증명한 문제만 우선순위 높은 결과로 올린다.
   3. 거짓 양성을 줄여 개발자와 보안 담당자의 인지 부하를 낮추고, 실제로 고칠 가치가 있는 문제에 집중하게 만든다.

4. LLM 기반 AI 침투 테스트의 내부 에이전트 구조

정적 스캐너나 DAST 스캐너에 LLM을 덧붙이는 것이 아니라, 처음부터 LLM을 중심으로 서로 다른 역할의 에이전트가 협업하도록 구성한다.

4.1. 오케스트레이션과 정찰

1. LLM 오케스트레이터: 동적 계획의 두뇌

   1. 오케스트레이터는 시스템의 두뇌처럼 동작한다.
   2. 정해진 단일 절차를 반복하지 않고 dynamic plan을 따라가며 필요한 행동을 결정한다.
   3. 여러 하위 에이전트를 호출하고 순서를 조정해 공격 탐색의 전체 흐름을 관리한다.

2. Recon agent: 엘리트 정보 부대

   1. 네트워크 endpoint, API, fingerprint 같은 정보를 가능한 한 많이 수집한다.
   2. 흩어진 정보를 애플리케이션 아키텍처로 정리한다.
   3. 정식화한 구조를 다음 취약점 테스트 에이전트에게 넘겨, 어디를 어떤 순서로 검사할지 알려 준다.

4.2. 취약점 탐색과 악용 검증

1. 전문화된 취약점 테스트 에이전트

   1. 일부 에이전트는 잘 알려진 취약점 클래스를 겨냥한다.
   2. 다른 에이전트는 실제 환경에서 새로운 취약점을 사냥하며 애플리케이션을 깨뜨린다.
   3. 후자는 비즈니스 컨텍스트를 이해하고 공격자가 어디에서 어디까지 이동할 수 있는지 추론한다.

2. Judge agent: exploit validation

   1. 앞 단계에서 발견된 모든 후보 취약점은 Judge라는 검증 단계로 넘어간다.
   2. Judge는 문제가 진짜 취약점인지, 실제로 악용 가능한지를 판정한다.
   3. 존재 가능성만 있는 경고를 제거해 false positive와 개발자의 인지 부하를 줄인다.

4.3. 수정과 보고

1. Remediation agent: 발견을 행동으로 변환

   1. 취약점 이름만 보고하는 것으로 끝내지 않는다.
   2. 개발자가 무엇을 어떻게 바꿔야 하는지 이해할 수 있는 수정 지침을 만든다.
   3. 실행 가능한 결과가 되어야 보안 검사가 백로그를 늘리는 대신 백로그를 줄인다.

2. Reporting agent: 전달 가능한 결과

   1. 모든 탐색과 검증 결과는 보고되어야 한다.
   2. 검증된 취약점, 악용 근거, 수정 방법을 개발·보안팀이 사용할 수 있는 형식으로 남긴다.
   3. PDF를 읽고 진짜 문제인지 재판정하는 과거 흐름 대신, 코드 변경에 가까운 시점에 조치할 수 있는 결과를 만든다.

5. 컨텍스트가 성능과 비용을 결정한다

LLM은 공급업체의 이름보다 어떤 데이터를 어디에 넣어 주는지가 중요하며, 기존 보안 도구의 결과를 버리지 않고 AI 침투 테스트의 탐색 지도로 재활용해야 한다.

5.1. 기존 보안 신호를 AI에 공급하기

1. 정적·동적 스캐너 결과의 결합

   1. AI 침투 테스트를 독립 실행하는 대신 기존 static code scanner의 결과를 입력한다.
   2. dynamic code scanner와 여러 agent engine의 결과도 함께 묶는다.
   3. 과거 탐색 결과가 알려 주는 구조와 위험 지점을 바탕으로 LLM이 어디를 집중해서 봐야 할지 안내한다.

2. 모델이 위치를 알 때 좋아지는 결과

   1. LLM은 애플리케이션의 컨텍스트를 많이 받을수록 추론할 재료가 많아진다.
   2. 모델에게 어디를 찾아야 하는지 프레임을 제공하면 결과 품질이 크게 좋아진다.
   3. 더 풍부한 컨텍스트는 탐색 정확도를 높일 뿐 아니라 불필요한 LLM 호출을 줄여 운영 비용도 낮춘다.

5.2. 단일 도구가 해결하지 못하는 취약점 지형

1. DAST가 우수한 영역

   1. DAST는 매우 철저한 사전 정의 payload 집합을 애플리케이션에 전송할 수 있다.
   2. 정해진 패턴을 광범위하게 시험하는 cross-site scripting에는 DAST가 가장 좋은 선택이다.
   3. 같은 검사를 LLM만으로 다시 만들면 기존 도구의 장점을 잃을 수 있다.

2. AI 침투 테스트가 우수한 영역

   1. 비즈니스 로직 취약점은 애플리케이션의 목적과 업무 흐름을 이해해야 한다.
   2. 사용자가 어떤 상태에서 어떤 행동을 해야 하는지, 공격자가 여러 단계를 거쳐 무엇을 탈취할 수 있는지를 추론하는 일에는 침투 테스트가 더 적합하다.
   3. DAST와 AI 침투 테스트를 결합해야 정해진 payload와 맥락 기반 공격을 모두 커버한다.

3. 선택 기준에 대한 핵심 원칙

   1. 공급업체가 한 가지 도구로 모든 문제를 해결한다고 주장하는지 확인한다.
   2. 기존 검사 도구의 강점을 살리고 부족한 비즈니스 로직 영역을 AI 공격 에이전트로 보완한다.
   3. 랩 데이터와 실제 고객 데이터에서 얻은 신호를 결합할수록 어떤 조합이 효과적인지 더 정확히 판단할 수 있다.

6. 보안 솔루션을 고를 때 던질 네 가지 질문

코드와 공격이 24시간 흐르는 시대에는 새로운 솔루션을 데모가 아니라 운영 모델·컨텍스트·증명·비용의 관점에서 평가해야 한다.

6.1. 지속성·추론·데이터·증명의 네 축

1. 지속적으로 실행하는가

   1. 솔루션이 계속 실행되는가, 아니면 가끔 한 번 돌리는 point solution인가를 묻는다.
   2. 모든 PR과 코드 delta에 붙지 않는 도구는 빠른 AI 공격과 동일한 속도로 경쟁하기 어렵다.

2. 애플리케이션 컨텍스트를 실제로 추론하는가

   1. 새로운 취약점은 애플리케이션 컨텍스트에서 나오므로 단순한 패턴 매칭만으로는 부족하다.
   2. 업무 규칙·권한 관계·에이전트 목표·환경 차이를 이해하고 공격 경로를 구성하는지 확인한다.

3. 얼마나 많은 컨텍스트를 소화하는가

   1. 기존 정적·동적·에이전트 검사 결과와 여러 머신·환경의 데이터를 어떻게 enrich하는지 확인한다.
   2. 더 풍부한 데이터는 결과를 개선하고, 모델이 탐색 공간을 줄여 LLM 운영 비용도 낮춘다.

4. 버그와 악용 가능성을 증명하는가

   1. 문제를 단순히 버그라고 표시하는지, 실제 exploit 가능한지 입증하는지 구별한다.
   2. 발견 속도만이 아니라 정확도·비용·수정 가능성까지 함께 평가해야 개발자와 보안팀이 중요한 문제에 집중할 수 있다.

주요 발언 모음

“컨텍스트가 전부다. LLM은 공급받은 컨텍스트만큼만 좋아진다.”

“우리는 정적 스캐너나 DAST 스캐너를 LLM과 그냥 결합한 것이 아니라, 처음부터 LLM을 중심으로 만들었다.”

“4분이면 내가 방금 한 세션을 거의 다섯 번 진행하는 시간보다 짧다.”

“목표는 버그를 더 빨리 찾는 것뿐 아니라, 더 잘하고 더 싸게 하며 개발자와 보안 담당자가 가장 중요한 일에 집중하도록 돕는 것이다.”

핵심 데이터 & 수치

• 218%: Snyk 데이터 기준 개발자 1인당 생성 코드 라인 증가 폭.
• 85% 이상: 코딩 에이전트를 사용하는 개발자 비율.
• 62%: LLM 생성 출력 중 안전하지 않거나 깨진 것으로 제시된 비율.
• 평균 24.34분: AI 공격이 성공하기까지 걸리는 시간으로 제시된 수치이며, 자동자막에는 24~34분처럼 들리는 구간이 있다.
• 4분: 가장 빠른 AI 공격 성공 사례로 제시된 시간.
• 43%: 취약점이 있는 것으로 제시된 MCP 서버 비율.
• 600개 이상·600개·555개국: 자동자막에 남은 대규모 공격 모델 사례의 수치. 마지막 단위는 ‘국가’로 인식됐지만 실제 발화는 조직·환경을 뜻했을 가능성이 있다.
• 1~3회/년: 전통적인 인간 침투 테스트가 비용·속도 때문에 실행되는 빈도.
• 350여 일: 1년에 한두 번만 검사할 때 테스트되지 않은 기간을 강조한 표현.

결론 및 시사점

1. AI 코딩 에이전트는 개발자의 생산량을 늘리지만 안전하지 않은 코드와 보안 백로그도 함께 늘린다.
2. 공격자는 낮은 심각도의 취약점을 연결하고 frontier model을 활용해 방어팀보다 훨씬 빠르게 공격 경로를 만든다.
3. SAST는 SQL injection·XSS 같은 코드 패턴에, DAST는 런타임 권한과 사전 정의 payload에, 침투 테스트는 비즈니스 로직에 강하다.
4. 세 도구를 경쟁시키기보다 각 도구의 강점을 결합해야 실제 취약점 지형을 커버할 수 있다.
5. 지속적 오펜시브 시큐리티는 AI 침투 테스트, 다단계 에이전트 레드팀, 동적 테스트를 PR과 코드 delta마다 돌린다.
6. LLM 오케스트레이터·정찰·취약점 탐색·Judge·수정·보고 에이전트가 역할을 나눠 발견부터 조치까지 연결한다.
7. 가장 중요한 품질 기준은 취약점 후보를 많이 내는 것이 아니라 실제 exploit 가능성을 증명하고 거짓 양성을 줄이는 것이다.
8. 솔루션 선택 시 지속 실행, 애플리케이션 컨텍스트 추론, 입력 가능한 데이터의 폭, 악용 가능성 증명이라는 네 질문을 확인해야 한다.
9. 최종 목표는 더 빠른 발견만이 아니라 더 정확하고 저렴하며 개발자가 바로 조치할 수 있는 보안 운영이다.

핵심 요약 20줄

AI 코딩 에이전트의 확산은 개발자 1인당 코드 생산량을 218% 늘리면서 보안 검사의 부담도 함께 키운다. 코딩 에이전트를 사용하는 개발자가 85%를 넘고 여러 Claude Code 세션이 동시에 실행되는 환경이 표준이 되고 있다. LLM 생성 출력의 62%가 안전하지 않거나 깨져 있어 취약 코드가 생산 환경으로 유입되는 속도가 빨라진다. 공격자는 낮은 심각도의 취약점을 여러 개 연결해 하나의 치명적인 공격 경로로 만들 수 있다. AI 공격의 평균 성공 시간은 약 24.34분으로 제시됐고 가장 빠른 사례는 4분 만에 끝났다. MCP 서버의 43%가 취약하다는 수치는 에이전트 연결 계층도 중요한 공격 표면임을 보여 준다. SAST는 SQL injection과 XSS처럼 코드 패턴으로 확인할 수 있는 문제를 저렴하게 반복 검사한다. DAST는 실행 중인 API에 payload를 보내 BOLA 같은 런타임 권한 문제를 찾아낸다. 인간 침투 테스트는 비즈니스 로직을 이해하는 강점이 있지만 비용과 속도 때문에 연 1~3회에 머문다. 일 년에 한두 번만 검사하면 나머지 350여 일 동안 새 코드와 공격 경로가 검증되지 않는다. 지속적 오펜시브 시큐리티는 AI 침투 테스트와 에이전트 레드팀과 DAST를 하나의 운영 흐름으로 묶는다. AI 침투 테스트는 인간 테스터의 비즈니스 컨텍스트 이해를 LLM의 확장성과 지속성으로 전환한다. 모든 PR과 코드 delta에 침투 테스트를 붙이면 취약점과 수정 방법을 개발자에게 더 빨리 전달할 수 있다. 에이전트 레드팀은 prompt injection과 data exfiltration과 goal hijacking 같은 다단계 공격을 재현한다. LLM 오케스트레이터는 동적 계획을 세우고 정찰 에이전트는 endpoint와 API와 fingerprint를 아키텍처로 정리한다. 취약점 테스트 에이전트는 알려진 클래스와 실제 비즈니스 로직의 새로운 공격 경로를 함께 탐색한다. Judge 에이전트는 후보 취약점이 실제로 악용 가능한지 검증해 거짓 양성과 개발자의 인지 부하를 줄인다. Remediation 에이전트와 Reporting 에이전트는 발견 결과를 개발자가 실행할 수정안과 전달 가능한 보고서로 바꾼다. 기존 정적·동적·에이전트 검사 결과를 LLM에 제공하면 탐색 정확도가 올라가고 운영 비용도 낮아진다. 새 보안 도구는 지속 실행과 컨텍스트 추론과 데이터 확장과 exploit 증명이라는 네 질문으로 평가해야 한다.