메인 콘텐츠로 건너뛰기
아래에 설명된 5단계 Vulnresearch 파이프라인은 오늘 출시된 상태이며, Vulnresearch 조율자와 그 5개의 서브 에이전트가 구동합니다. 루프를 닫는 방어 측 절반 (“Defender” 에이전트, 자동 완화 백엔드, 재공격 검증)은 현재 코드베이스에 활성 구현되지 않은 계획된 제품 방향입니다. 이전 Defender 그래프와 Docker 방어 백엔드는 제거되었고, 향후 구현은 OPPLAN 미들웨어 위에 재구축될 예정입니다. 자세한 내용은 repo의 docs/offensive-vaccine.md 참조.
오펜시브 백신은 Decepticon에 이름과 목적을 부여하는 루프입니다: 모든 오펜시브 행동이 방어적 산출물이 됩니다. 이 페이지는 오늘 출시된 5단계 Vulnresearch 파이프라인과, 향후 루프를 종료할 계획된 방어 측 컴포넌트를 문서화합니다.

​
루프

공격 → 탐지 규칙 → 검증 → 익스플로잇 PoC → 패치
   ↑                                                      │
   └───────────────────────────────────────────────────────┘
                    회귀 테스트 커버리지
각 단계는 전문가 에이전트가 소유합니다. 함께 보안 산업이 “퍼플 팀 활동”이라고 부르는 것을 완전히 자동화합니다.

​
5단계

1

Scanner — 표면 찾기

타겟 전체의 자동 취약점 스캔. 출력: 후보 발견 (CVE 매치, 설정 문제, 노출된 표면).
2

Detector — 규칙 작성

후보 취약점의 탐지 신호 생성 — Sigma 규칙, YARA 규칙, IDS 서명 또는 텔레메트리 기반 휴리스틱. 방어자들은 탐지하기 전에 무엇을 찾아야 할지 알아야 합니다.
3

Verifier — 실제 증명

2-메서드 게이트: 최소 2가지의 독립적인 검증 기법을 통해 취약점 확인. 익스플로잇 작업을 시작하기 전에 거짓 양성을 제거합니다.
4

Patcher — 수정 제안 및 검증

취약점을 애플리케이션을 깨지 않고 닫는 최소 패치 — 코드 변경, 설정 변경, 보상 통제 — 를 생성하고, patch_verify로 패치가 버그를 닫았음을 증명합니다. PoC 이전 패치는 offensive-vaccine 역전 — 방어자의 diff가 테스트 대상이 됩니다.
5

Exploiter — 패치 깨기 시도

패치된 후보를 대상으로 재현 가능한 PoC를 작성합니다. PoC가 패치된 코드에 대해 성공하면 패치가 불완전하므로 루프가 반복되고, PoC가 실패하면 패치가 견고했음을 입증합니다.

​
Vulnresearch 오케스트레이터

5개의 에이전트는 고정 파이프라인으로 실행되지 않습니다 — 발견 사항을 기반으로 순서를 결정하는 6번째 에이전트 Vulnresearch에 의해 오케스트레이션됩니다. Scanner가 높은 신뢰도의 후보를 생성하면, Vulnresearch는 Verifier로 직접 스킵할 수 있습니다. Verifier가 후보를 거부하면, Patcher나 Exploiter 리소스를 낭비하지 않고 루프는 종료됩니다.
에이전트입력출력
Scanner타겟 범위후보 발견 목록
Detector후보 발견탐지 규칙 (Sigma / YARA / 휴리스틱)
Verifier후보 + 탐지 규칙검증됨-예 또는 검증됨-아니요, 2가지 증거 방법 포함
Patcher검증된 후보패치 (코드 또는 설정) + 패치가 버그를 닫았음을 증명하는 patch_verify
Exploiter패치된 후보패치에 대한 재현 가능한 PoC — 패치가 견고하면 실패, 패치가 불완전하면 성공 (루프 반복)

​
계획된 방어 컴포넌트

이 컴포넌트는 현재 코드베이스에 구현되어 있지 않습니다 — 이전 Defender 그래프와 Docker 방어 백엔드는 제거되었고, 향후 대체는 OPPLAN 미들웨어와 전용 백신 개념 위에 재구축될 예정입니다. 오늘은 Vulnresearch 파이프라인의 산출물(탐지 규칙, PoC, 패치)이 워크스페이스와 지식 그래프에 영속화되며, 사람 운영자가 이를 블루팀에 전달합니다.
계획된 방어 종결 컴포넌트는 5단계 파이프라인의 일부가 아닙니다 — 산출물을 소비하는 병렬 에이전트로 의도되어 있으며 방어 브리프를 생성하도록 설계되어 있습니다: 작전 최종 보고에서 블루팀에 전달되는 문서. 계획된 방어 브리프에는:
  • 사용된 기법 (MITRE ATT&CK ID)
  • Detector가 생성한 탐지 규칙
  • Exploiter가 생성한 PoC
  • Patcher의 권장 패치
  • 검증 상태 (패치가 PoC를 깨뜨렸나요?)
  • 블루팀의 기존 탐지 커버리지로의 매핑 (갭)
이것은 결국 오펜시브 작전을 방어적 개선으로 변환할 산출물입니다. 이 컴포넌트가 도착할 때까지는 운영자가 워크스페이스 출력에서 브리프를 수동으로 조립합니다.

​
2-메서드 검증이 중요한 이유

단일 검증 방법은 속일 수 있습니다 — 네트워크 스캔은 취약한 코드가 도달 가능하지 않아도 배너와 일치할 수 있습니다; PoC는 허니팟에 대해 성공할 수 있습니다. Verifier는 2가지 독립적인 메서드를 요구합니다. 예:
  • 정적 증거 (버전 배너) + 동적 증거 (PoC 페이로드 응답)
  • 네트워크측 탐지 (IDS 발화) + 호스트측 탐지 (프로세스 아티팩트)
  • 소스 코드 분석 + 런타임 계측
Decepticon은 2-메서드 게이트 없이 발견을 Patcher / Exploiter 단계로 escalate하지 않습니다. 이는 작전 기록의 낭비된 계산과 거짓 경보를 대폭 감소시킵니다.

​
지식 그래프 통합

파이프라인이 생성한 모든 산출물은 Neo4j 공격 그래프에 도착합니다:
  • 발견은 Vulnerability 노드가 됩니다
  • 탐지 규칙은 DETECTS 에지를 가진 DefenseAction 노드가 됩니다
  • 패치는 MITIGATES 에지를 가진 DefenseAction 노드가 됩니다
  • 검증은 프로비넌스 에지가 됩니다
그래프는 작전 중에 쿼리 가능하고 작전 산출물로 내보낼 수 있습니다.

지식 그래프

발견, 탐지 및 패치가 Neo4j 공격 그래프에 어떻게 도착하는지.

스킬 시스템

각 파이프라인 단계는 skills/scanner/, skills/detector/ 등의 전용 스킬 세트를 가집니다.