보안 감사 (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)가 가진 모든 구조적 문제에 도메인 특화 리스크를 더하여 상속받습니다:

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

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

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개 보안 도메인을 다룹니다:

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

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

이러한 출력값들은 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)로 통합합니다:

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

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

에이전트 전략 (Agent strategies):

모든 점검은 객관적인 통과/실패 (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)별 경계:

보안 특화 가드레일 (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 = {
...

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

이는 최종 보고서가 감사 추적(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)은 다음과 같이 정의됩니다:

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

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

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

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