ESAA-Security: AI 생성 코드의 자동화된 보안 감사를 위한 이벤트 소싱 기반 아키텍처

보안 감사 (Security audits)를 자유 형식의 체크리스트가 아닌 결정론적 파이프라인 (deterministic pipelines)으로 취급하십시오.

ESAA-Security는 소프트웨어 저장소의 자동화된 보안 감사를 위해 ESAA 아키텍처를 **도메인 특화 전문화 (domain-specific specialization)**한 것으로, 특히 AI가 생성하거나 수정한 코드에 중점을 둡니다. 휴리스틱 에이전트 인지 (heuristic agent cognition)를 추가 전용 이벤트 (append-only events), 경계 계약 (boundary contracts), 제약된 구조화된 출력 (constrained structured outputs), 그리고 재생 기반 검증 (replay-based verification)을 통해 결정론적 상태 변이 (deterministic state mutation)와 분리하는 거버넌스 방법론은 ESAA 자체에서 유래되었습니다. ESAA-Security는 이 커널 (kernel)을 상속받아 보안 증거 (security evidence), 플레이북 기반의 도메인 커버리지 (playbook-driven domain coverage), 그리고 리스크 중심의 보고 (risk-oriented reporting)를 중심으로 아티팩트 공간 (artifact space)을 재정의합니다. 모든 발견 사항, 분류 및 수정 사항은 사실 (fact)로 기록되며, 최종 보고서는 감사 추적 (audit trail)의 결정론적 투영 (deterministic projection)입니다.

📄 ESAA 논문: ESAA: Event Sourcing for Autonomous Agents in LLM-Based Software Engineering — 거버넌스 커널: 이벤트 소싱 (event sourcing), 결정론적 오케스트레이션 (deterministic orchestration), 경계 계약 (boundary contracts), 재생 검증 (replay verification)
🔒 ESAA-Security 논문: ESAA-Security: An Event-Sourced, Verifiable Architecture for Agent-Assisted Security Audits of AI-Generated Code — 도메인 특화: 감사 단계 (audit phases), 보안 플레이북 (security playbooks), 리스크 중심 출력 (risk-oriented outputs)
🧩 PARCER 논문: PARCER as an Operational Contract to Reduce Variance, Cost, and Risk in LLM Systems — 운영 계약 (operational contract): 의사결정 위생 (decision hygiene), 적응형 예산 책정 (adaptive budgeting), 구조화된 검증 (structured validation)
🛡️ 소스 프레임워크: PARCER v1.6.0 Security Auditor

LLM 에이전트에 의해 수행되는 보안 감사는 자율 에이전트 (autonomous agents)가 가진 모든 구조적 문제에 도메인 특화 리스크를 더하여 상속받습니다:

문제점	ESAA-Security의 해결 방식
환각 취약점 (Hallucinated vulnerabilities) — 에이전트가 존재하지 않는 발견 사항을 지어냄	가드레일 (Guardrails)이 모든 발견 사항에 대해 기술적 증거를 요구하며, 플레이북 (playbooks)이 객관적인 합격/불합격 기준을 정의함
일관성 없는 커버리지 (Inconsistent coverage) — 에이전트가 임의로 도메인이나 점검 항목을 건너뜀	16개 도메인에 걸쳐 의존성 순서로 실행되는 95개의 실행 가능한 점검 항목 제공
감사 추적 불가 (No audit trail) — 실제로 무엇이 테스트되었는지 검증하는 것이 불가능함	모든 점검 결과는 추가 전용 로그 (append-only log)의 이벤트로 기록되며, 보고서는 검증 가능한 프로젝션 (projection)임
재현 불가능한 결과 (Non-reproducible results) — 동일한 시스템임에도 실행할 때마다 다른 결과가 나옴	결정론적 재생 (Deterministic replay) + SHA-256 검증; 동일한 이벤트는 항상 동일한 보고서를 생성함

임시방편적인 "LLM에게 내 코드를 검토해달라고 요청하기" 방식과 달리, ESAA-Security는 발견 사항부터 증거에 이르기까지 구조화된 플레이북 (structured playbooks), 스키마 검증 결과 (schema-validated results), 그리고 **포렌식 추적 가능성 (forensic traceability)**을 제공합니다.

ESAA-Security는 각각 별도의 논문과 기여를 가진 세 가지의 뚜렷한 계층 (layers)으로 구축되었습니다:

계층	기여 내용	논문
ESAA (거버넌스 커널)	방법론: 신뢰의 원천(source of truth)으로서의 추가 전용 이벤트 스토어 (append-only event store), 에이전트의 의도를 검증하고 영속화하는 결정론적 오케스트레이터 (deterministic orchestrator), 작업 유형별 경계 계약 (boundary contracts), SHA-256 재생 검증, "완료" 불변성 (immutability), 컨텍스트 주입을 위한 정제된 뷰 (purified views). 이질적인 멀티 에이전트 오케스트레이션 (Claude Sonnet 4.6, Codex GPT-5, Gemini 3 Pro, Claude Opus 4.6)을 통해 검증됨.	arXiv:2602.23193
PARCER (운영 계약)	에이전트 수준의 거버넌스: 의사결정 위생 (7가지 절차)을 강제하는 선언적 YAML 계약, 적응형 토큰 예산 책정 (adaptive token budgeting), 컨텍스트 폴백 (Map-Reduce/RAG), 하드 게이트 (hard gates)를 통한 구조화된 검증, 그리고 OpenTelemetry 관찰성 (observability). PARCER 프로필 (PARCER_PROFILE.agent-spec.yaml, agent-impl.yaml, agent-qa.yaml)은 각 에이전트 역할을 도구 예산, 검증 요구 사항 및 에스컬레이션 규칙 (escalation rules)에 결합함.

arXiv:2603.00856 |
ESAA-Security (도메인 전문화) |
보안 감사 파이프라인: 4단계 (정찰 (reconnaissance) → 도메인 감사 (domain audit) → 위험 분류 (risk classification) → 보고 (reporting)), 26개 작업 (tasks), 16개 보안 도메인 (security domains), 95개 실행 가능한 점검 항목 (executable checks), 심각도 분류 (severity classification)가 포함된 구조화된 결과물, 위험 매트릭스 (risk matrices), 조치 가이드 (remediation guidance), 그리고 경영진 보고 (executive reporting). 최종 보고서는 자유 형식의 서술이 아니라, 관리되는 감사 상태 (governed audit state)의 투영입니다. | arXiv:2603.06365 |

핵심 통찰은 보안 검토를 프롬프팅 문제 (prompting problem)가 아닌 **관리되는 실행 문제 (governed execution problem)**로 모델링해야 한다는 것입니다. ESAA는 메커니즘(상태가 어떻게 진화하는가)을 제공합니다. PARCER는 에이전트 규율(에이전트가 어떻게 행동하는가)을 제공합니다. ESAA-Security는 도메인 의미론 (domain semantics, 무엇을 감사하고 결과가 어떻게 구조화되는가)을 제공합니다.

┌─────────────┐ check_result ┌──────────────────┐ append event ┌─────────────┐
│ Audit Agent │ ───────────────► │ Orchestrator │ ─────────────► │ Event Store │
│ (finding) │ │ (deterministic) │ │ (.jsonl) │
...

핵심 원칙 (ESAA로부터 상속됨): 에이전트는 조사하고, 오케스트레이터 (Orchestrator)는 판결합니다.

**에이전트 (Agents)**는 플레이북 점검을 실행하고 구조화된 결과 (agent_result, issue.report)를 방출합니다. 에이전트는 보고서를 작성하거나, 상태를 변경하거나, 이벤트를 직접 추가할 수 없습니다. **오케스트레이터 (Orchestrator)**는 JSON 스키마 (JSON Schema) 및 경계 계약 (boundary contracts)에 따라 결과를 검증하고, 이벤트를 영속화하며, 읽기 모델 (read-model)을 투영합니다. 이벤트 스토어 (Event Store) (activity.jsonl)는 모든 점검 실행, 발견 사항 및 분류를 불변의 사실 (immutable fact)로 기록합니다. 읽기 모델 (Read-Model) (roadmap.json)은 어떤 점검이 통과되었고, 어떤 점검이 실패했으며, 어떤 도메인이 완료되었는지 감사 진행 상황을 추적합니다.

ESAA-Security는 PARCER 보안 감사관 (Security Auditor) 프레임워크에서 파생된 16개 보안 도메인을 다룹니다:

도메인 (Domain)	점검 항목 (Checks)	우선순위 (Priority)	플레이북 ID (Playbook IDs)
Secrets & Configuration	8	critical	SC-001 → SC-008
...
총계: 4단계 26개 작업에 걸친 95개의 실행 가능한 점검 항목.

.roadmap/
├── activity.jsonl # 이벤트 스토어 (Event store, 추가 전용, 신뢰할 수 있는 단일 원천)
├── roadmap.json # 읽기 모델 (Read-model): 감사 진행 상황 (파생됨, 검증 가능)
...

보안 점검이 실행되기 전, 에이전트는 지형을 매핑합니다:

작업	출력
SEC-001: 기술 스택 식별	언어, 프레임워크, 데이터베이스, 클라우드 서비스, 의존성 버전
...

이러한 출력값들은 depends_on을 통해 모든 Phase 2 작업에 전달됩니다.

.

핵심 감사: 보안 도메인당 하나씩, 총 16개의 작업으로 구성됩니다. 각 작업은 해당하는 플레이북 (playbook)을 실행합니다:

에이전트 수신: 플레이북 (점검 항목 + 에이전트 지침) + 정찰 (reconnaissance) 출력물
에이전트 실행: 점검 항목별 grep/find/curl 명령 실행, 통과/실패 (pass/fail) 기준 적용
에이전트 방출: 점검 항목별 구조화된 결과 (상태, 심각도, 증거, 해결 방안)

예시 — input_validation 플레이북의 IV-001 (SQL Injection) 점검:

{
"check_id": "IV-001",
"name": "SQL injection",
...

모든 Phase 2 발견 사항을 우선순위가 지정된 리스크 매트릭스 (risk matrix)로 통합합니다:

작업	출력
SEC-030: 취약점 통합	ID, 도메인 및 증거가 포함된 통합 인벤토리
...
작업	출력
---	---
SEC-040: 기술적 해결 방안	CRITICAL 및 HIGH 발견 사항에 대한 코드/설정 수정
...

playbooks.security.json에 있는 16개의 플레이북 각각은 다음 구조를 따릅니다:

{
"task_ref": "SEC-015",
"domain": "input_validation",
...

에이전트 전략 (Agent strategies):

전략	횟수	설명
static_analysis	77	소스 코드 및 설정 파일에서 Grep/find 패턴 탐색
hybrid	16	정적 분석 (Static analysis) + 라이브 엔드포인트 테스트 (endpoint_base_url 사용 가능 시)
tool_execution	2	보안 도구 실행 (npm audit, pip-audit 등)

모든 점검은 객관적인 통과/실패 (pass/fail) 기준을 제공합니다. 에이전트가 무엇을 취약점으로 간주할지 결정하는 것이 아니라, 플레이북이 이를 정의합니다.

감사 로드맵 (roadmap.json)은 ESAA v0.4.0 정형 스키마 (canonical schema)를 준수합니다:

{
"meta": {
"schema_version": "0.4.0",
...

모든 ESAA 불변성 (invariants)이 적용됩니다:

— 완료된 감사 작업은 수정할 수 없습니다. 수정하려면 핫픽스 (hotfix) 워크플로우가 필요합니다 immutable_done: true

— 모든 상태 변경 후 SHA-256 재생 검증 (replay verification)을 수행합니다 verify_status

— 모든 수준에서 엄격한 스키마 준수를 요구합니다 additionalProperties: false

인덱스 일관성 유지— by_status 및 by_kind 인덱스가 실제 작업 수와 일치합니다.

작업 라이프사이클 (lifecycle)은 ESAA 아키텍처에 의해 정의되며, 작업 전 점유 (claim-before-work), 완료 후 불변성 (done-immutability), 그리고 이전 상태 일관성 (prior-status consistency) 불변성을 강제합니다:

claim complete review(approve)
[todo] ─────────► [in_progress] ─────────► [review] ─────────► [done] ✗
▲ │ (immutable)
...

보안 감사 (security audit) 컨텍스트에 적용하면 다음과 같습니다:

— 에이전트가 보안 도메인 감사에 대한 소유권을 가져옵니다 (예: SEC-015: 입력 유효성 검사 (Input Validation)) claim

— 에이전트가 모든 플레이북 (playbook) 체크를 마치고 complete 상태와 함께 verification.checks가 포함된 구조화된 결과를 제출합니다

— QA 에이전트가 발견 사항이 증거에 기반했는지, 분류가 정당한지, 누락된 체크가 없는지 확인합니다 review(approve)

— QA 에이전트가 불완전한 커버리지 또는 정당화되지 않은 분류를 발견합니다 review(request_changes)

작업 종류(kind)별 경계:

종류 (Kind)	감사에서의 역할	읽기 (Read)	쓰기 (Write)
spec	정찰 (Reconnaissance) (Phase 1)	.roadmap/** , docs/**	reports/phase1/**
impl	감사 실행 (Audit execution) (Phase 2)	.roadmap/** , playbooks/** , reports/phase1/**	reports/phase2/**
qa	분류 + 보고 (Classification + report) (Phase 3–4)	.roadmap/** , reports/**	reports/phase3/** , reports/phase4/** , reports/final/**

매개변수 (Parameter)	값 (Value)	근거 (Rationale)
시도 TTL (Attempt TTL)	PT30M	일부 도메인(인프라, 데이터 보안)은 심층 분석이 필요함
...
심각도 (Severity)	조치 (Action)	감사 컨텍스트에서의 예시
---	---	---
low	로그 기록만 수행 (Log only)	Referrer-Policy 헤더 누락
medium	로그 기록 및 플래그 지정 (Log and flag)	인증 정보가 필요 없는 엔드포인트에 와일드카드를 사용한 CORS 설정
high	작업 차단 및 알림 (Block task + notify)	인증 컨트롤러(authentication controller)에서의 SQL 인젝션 (SQL injection)
critical	파이프라인 중단 및 알림 (Halt pipeline + notify)	저장소(repository)에 프라이빗 키(Private keys)가 커밋됨

보안 특화 가드레일 (guardrails)은 감사 품질을 강제합니다:

존재하지 않는 취약점을 절대 지어내지 말 것— 모든 발견 사항은 증거(파일, 라인, 명령 출력)를 필요로 합니다.
항상 기술적으로 위험을 정당화할 것— 심각도는 추측이 아닌 기술적 근거로 방어되어야 합니다.
실제 위험과 개선 사항을 구분할 것— 내부 도구에서 "WAF 누락"은 HIGH가 아닌 INFO입니다.
증거 없는 공포 조성을 피할 것— 오탐(false positives)은 감사에 대한 신뢰를 떨어뜨립니다.
심각도를 일관되게 분류할 것— 객관적인 기준에 따라 CRITICAL/HIGH/MEDIUM/LOW/INFO로 분류합니다.

ESAA-Security는 ESAA 검증 프로토콜 전체를 상속받습니다. 이벤트 스토어 (event store)는 신뢰할 수 있는 유일한 원천 (source of truth)이며, 읽기 모델 (read-model)은 재생 (replay)과 SHA-256 해싱을 통해 검증되는 결정론적 투영 (deterministic projection)입니다. 에이전트 또는 운영자는 이벤트 로그를 재생하고 계산된 해시를 저장된 투영 해시와 비교함으로써 언제든지 무결성을 검증할 수 있습니다:

def esaa_verify(events, roadmap_json):
projected = project_events(events) # 순수 함수 (pure function) — I/O 없음
hash_input = {
...

보안 감사에서 검증이 의미하는 바:

상태 (Status)	의미 (Meaning)	오케스트레이터 (Orchestrator) 응답
ok	감사 상태가 일관됨 — 모든 발견 사항이 이벤트로 추적 가능함	계속 진행 (Continue)
mismatch	감사 상태가 이벤트 로그와 일치하지 않음 — 발견 사항이 변조되었을 수 있음	reproject_or_halt
corrupted	이벤트 스토어가 손상됨 — 감사 무결성이 훼손됨	halt_and_snapshot

이는 최종 보고서가 감사 추적(audit trail)을 충실히 반영한 투영(projection)임을 보장합니다. 즉, 이벤트 스토어(event store)에 흔적을 남기지 않고서는 어떠한 결과(findings)도 추가, 삭제 또는 재분류될 수 없습니다.

오케스트레이션(orchestration) 사이클은 보안 감사 배포를 위해 특화된 ESAA 트랜잭션 파이프라인을 따릅니다:

1. parse_event_store → 현재 감사 상태 투영 (project current audit state)
2. select_next_eligible_task (depends_on 모든 작업 완료; status=todo)
└─ 적격 작업이 없고 모든 작업이 완료된 경우 → emit run.end(success) → 최종 보고서 컴파일
...

감사를 실행하려면 에이전트(agent)가 대상 시스템에 접근할 수 있어야 합니다. 글로벌 입력 계약(global input contract)은 다음과 같이 정의됩니다:

입력 (Input)	필수 여부 (Required)	설명 (Description)
repo_path	예 (yes)	감사 대상 리포지토리(repository)의 절대 경로
endpoint_base_url	아니요 (no)	하이브리드 점검(헤더, CORS, 속도 제한)을 위한 라이브 애플리케이션 URL
docs_path	아니요 (no)	기술 문서 또는 아키텍처 문서 경로
infra_config_path	아니요 (no)	인프라 설정 경로 (docker-compose, k8s, terraform)
ci_config_path	아니요 (no)	CI/CD 설정 경로 (.github/workflows, .gitlab-ci.yml)

각 플레이북(playbook)은 어떤 입력이 필요한지 선언합니다. 오케스트레이터(orchestrator)는 배포 전 가용성을 검증합니다.

최종 보고서에는 점검 결과로부터 도출된 보안 점수(0-100)가 포함됩니다:

범위 (Range)	분류 (Classification)
0–30	심각 (Critical) — 즉각적인 조치가 필요한 심각한 취약점
...

점수는 심각도(severity)에 따라 가중치를 둔 개별 점검 결과로부터 계산되며, 이를 통해 단 하나의 심각(CRITICAL)한 결과가 여러 개의 낮음(LOW) 결과보다 비례적으로 더 큰 영향을 미치도록 보장합니다.

ESAA-Security는 **L1/L2 성숙도의 내부 감사(internal audits)**에 맞춰 조정되었습니다: