이 레포가 무엇을 하는 물건인가.
보통 보안 도구는 pip install 한 뒤 저장소를 가리키면 끝이다. Foundry는 그런 물건이 아니다. 이건 "프런티어 LLM을 어떻게 한 무리의 협업 에이전트로 조직해야, 사람이 믿고 쓸 수 있는 취약점 보고서가 나오는가"에 대한 청사진이다.
Cisco의 Advanced Security Initiatives Group이 내부에서 같은 시스템을 여러 번 다시 만들며 얻은 교훈 — "이건 중요했다"는 설계와 "이건 안 중요했다"는 설계의 긴 목록 — 을 조직 중립적인 한 편의 명세로 증류했다.
Foundry Security Spec은 에이전트 기반 보안 평가(agentic security evaluation) 시스템의 '씨앗(seed) 명세'다. 저장소의 핵심 산출물은 딱 세 문서다. spec.md(8개 핵심 역할·5개 확장 역할·발견 생명주기·약 130개 기능 요구사항을 담은 본체), constitution.md(어떤 구현이든 반드시 지켜야 할 11개 불가침 원칙), GLOSSARY.md(용어집). README의 표현을 그대로 옮기면 — "이 저장소엔 코드가 없으며, 그것은 의도된 것이다. 명세 자체가 결과물이다."
사용법조차 코드 실행이 아니다. 이 명세는 GitHub의 spec-kit(스펙 주도 개발 도구)에 넣고 돌리도록 설계됐다. 명세 곳곳에 박힌 약 43개의 [NEEDS CLARIFICATION: ...] 표식(README는 「서른 남짓」이라 부름)을 당신 조직의 환경에 맞춰 하나씩 답하고 나면, 그 끝에서 '당신만의 명세'가 나온다. 그걸로 당신 인프라 위에 당신의 구현을 짓는다.
[NEEDS CLARIFICATION]으로 비워 두고, 보편적으로 옳은 구조·불변식만 못 박아 둔다. 그래서 직접 구현하면 안 되고, 먼저 빈칸을 채워 '내 명세'로 굳혀야 한다.트렌딩 이유 · 경쟁 대비 장점.
2026년은 "LLM에게 보안 점검을 시키면 그럴듯한 거짓말을 너무 많이 한다"는 현실과, 그럼에도 "사람보다 빠르고 넓게 훑는다"는 매력이 부딪히는 해다. Foundry가 주목받는 이유는 세 가지다. 첫째, "도구가 아니라 명세를 푼다"는 역발상 — Cisco는 자기 인프라에 묶인 코드 대신, 환경에 독립적인 '설계의 정수'만 공개했다. 둘째, 각 원칙이 추상론이 아니라 실제로 운영하다 터뜨린 사고에서 뽑은 교훈이라는 점. 셋째, 탐지(detection)가 곧장 예방(prevention)으로 이어지는 '플라이휠' 설계가 신선하다.
| 비교 항목 | 턴키 스캐너 (Semgrep·CodeQL 류) | Foundry 명세 |
|---|---|---|
| 형태 | 설치하면 도는 도구 | 코드 없는 설계도(마크다운) |
| 탐지 방식 | 정적 규칙 매칭 위주 | 규칙 일소 + 탐험형 에이전트 사냥 병행 |
| 거짓 양성 | 사람이 일일이 걸러야 함 | 증거 게이트로 기계 검증된 것만 노출 |
| 환경 종속 | 도구 환경에 고정 | 내 LLM·트래커·인프라에 맞춰 재단 |
| 학습 가치 | "어떻게 쓰나" | "어떻게 설계하나" + 분산시스템 교훈 |
| 발전 방식 | 벤더가 규칙 업데이트 | 운영하며 규칙 자가 증식(플라이휠) |
이런 시스템을 처음부터 직접 설계하면, 어떤 역할이 필요한지·무엇을 보장해야 하는지 모른 채 6개월 뒤에야 "아 이게 함정이었구나"를 깨닫는다(빈 페이지의 저주). 반대로 Cisco가 자기 내부 코드를 그대로 공개했다면? 그건 Cisco의 클라우드·트래커·LLM 게이트웨이에 단단히 묶여 딱 한 환경에서만 도는 물건이 됐을 것이다.
어떤 역할이 왜 필요한지, 각자 무엇을 보장해야 하는지, 발견이 탐지→발행까지 어떻게 흐르는지, 평가의 "끝"이 무엇인지, 품질 관문을 어디에 둘지, 6개월 뒤 발목 잡을 지름길은 무엇인지 — 이 설계는 인프라에 독립적이다. 그래서 Foundry는 "검증된 형태(proven shape)"를 주고, 구현은 당신 스택 위에서 직접 하게 한다.
코드가 없는 저장소의 '스택'이란 무엇인가.
이 저장소엔 package.json도 requirements.txt도 없다. 그러니 여기서 '스택'은 ① 명세를 어떤 형식·도구로 소비하는가와 ② 명세가 당신에게 어떤 외부 시스템을 연결하라고 요구하는가 두 갈래로 봐야 한다.
| 요소 | 내용 |
|---|---|
| 저장소 형식 | 100% Markdown. 실행 코드·스키마 파일·테스트 케이스 없음. |
| 소비 도구 | spec-kit (github/spec-kit) — /speckit.clarify·/speckit.specify·/speckit.plan 같은 스펙 주도 워크플로 |
| 호환 에이전트 | spec-kit을 지원하는 코딩 에이전트(Claude Code 또는 호환) |
| 규칙 형식 | CodeGuard — Cisco가 먼저 오픈소스화해 CoSAI(OASIS)에 기부한 보안 규칙 포맷. Foundry의 Detector가 이걸 '소비'한다. |
| 라이선스 | Creative Commons Attribution 4.0 (CC BY 4.0) — 코드가 아니라 '문서' 라이선스 |
| CI | 유일한 비문서 파일 .github/workflows/stale.yml (오래된 이슈/PR 자동 종료) |
clarify(빈칸 묻기)→specify(굳히기)→plan→tasks→implement 순. Foundry는 이 도구에 넣어 쓰라고 만들어졌다.Foundry는 구체 제품을 강요하지 않는다. 대신 각 자리에 대해 "이 인터페이스 계약만 만족하면 무엇이든 좋다"고 한다. 아래는 당신이 골라 끼워야 할 12개 통합 표면의 핵심이다.
| 통합 표면 | 무엇을 끼우나 (예시 — 강요 아님) |
|---|---|
| LLM 공급자 | 프런티어 모델 게이트웨이 (예: Anthropic Claude) |
| VCS · 이슈 트래커 | GitHub / GitLab 등 |
| 데이터스토어 | 발견 저장소용 DB (예: PostgreSQL 16) |
| 벡터 검색 | 임베딩 검색 (예: pgvector) |
| 격리 런타임 | 샌드박스 (예: gVisor, 컨테이너) |
| 배포 타깃 | 실행 환경 (예: Kubernetes, 단일 VM) |
| 에이전트 하니스 | 에이전트 실행 틀 (예: Claude Code) |
| 심각도 체계 | severity 분류 (예: CVSS v4.0 — 강요 아님) |
Foundry는 건축 설계도와 같다. "여기에 현관문, 저기에 창문, 이 벽은 내력벽"이라고 못 박지만, 문을 어느 회사 제품으로 달지·창틀을 알루미늄으로 할지 목재로 할지는 시공자(=당신)가 고른다. 명세는 '문이 만족해야 할 규격(잠금·방화 등급)'만 규정한다. 워크드 예제에 등장하는 Claude·PostgreSQL·K8s는 "이렇게도 지을 수 있다"는 한 채의 견본일 뿐, 자재 목록이 아니다.
8개 역할 군단 · 발견 생명주기 · 탐지→예방 플라이휠.
운영자(사람) 한 명이 위에 있고, 그 아래 오케스트레이터가 전체 수명주기와 대화를 맡는다. 그 밑으로 공유 기반(substrate) — 작업 큐·발견 저장소·샌드박스·예산·대시보드 — 이 깔리고, 그 위에서 8개 핵심 역할이 돈다. 핵심 통찰은 "각 역할이 바로 앞 역할의 실패 양식을 잡아낸다"는 점이다.
| 역할 (절) | 책임 · 무엇을 잡는가 |
|---|---|
| 오케스트레이터 §5.1 | 운영자의 유일한 창구. 수명주기 관리 + 대화 응대. |
| 인덱서 §5.2 | 코드 색인: 심볼·호출 그래프·교차참조·임베딩. |
| 카토그래퍼 §5.3 | 보안 지도: 아키텍처·공격 표면·신뢰 경계·데이터 흐름·위협 모델. |
| 디텍터 §5.4 | 규칙 일소 + 탐험형 사냥으로 후보 발견 생성. 넓게 훑기. |
| 트리아저 §5.5 | 판정(verdict) 부여 — 구조적 증거가 있어야만. 잡음 필터. |
| 밸리데이터 §5.6 | 테스트베드에서 독립 청정실 재현. 증명 필터. |
| 커버리지 가이드 §5.7 | 목표→체크리스트. "다 했다"의 절반 신호를 선언. |
| 리포터 §5.8 | 발견별 보고서 작성 + 심각도·분류 + 종합 집계. |
LLM은 자신만만하게 틀린 취약점을 줄줄 써낸다. Foundry의 심장부는 이걸 거르는 다단 깔때기다. 후보(candidate)가 들어오면 트리아저가 5가지 판정 중 하나를 매긴다.
판정 5종(원문 그대로): true-positive, false-positive, needs-review, not-applicable, code-quality. 이 중 true-positive가 되려면 증거 게이트(evidence gate)의 세 다리 — ① 도달성(reachable), ② 신뢰 경계를 넘는가, ③ 실제 영향 — 가 각각 진짜 코드 위치로 기계적으로 해소(resolve)돼야 한다. 인용한 줄이 엉뚱한 함수를 가리키면 자동으로 needs-review로 강등된다(FR-088).
Finding A (CWE-89 SQL 인젝션): handle_export()에서 세 다리가 모두 실제 코드로 해소 → true-positive 통과.
Finding B (CWE-639 IDOR): 도달성 인용 __init__.py:31이 엉뚱한 함수를 가리킴 → needs-review로 강등.
Finding C (CWE-22 경로 순회): safe_join()의 commonpath 검사가 순회를 제대로 막음 → false-positive 기각.
정적 규칙은 "이미 아는 것"만 잡는다. 탐험형 에이전트는 "아직 규칙 없는 것"을 잡는다. Foundry는 이 둘을 자기 강화 루프로 묶는다.
게다가 CodeGuard 규칙은 이식 가능하다. 평가에서 배운 그 규칙 뭉치를 그대로 IDE 코딩 어시스턴트에 넣으면, 방금 '탐지'를 배운 버그 클래스가 이제 개발자 에디터에서 키 입력 단계부터 '예방'된다. 루프가 한 바퀴 돌 때마다 "여기선 탐지가, 모든 곳에선 예방이" 좋아진다.
전부 마크다운 (LICENSE·.gitignore·CI 제외) — 루트 12개 + docs/ 24개 + CI 1개, 총 37개 파일.
① README.md로 큰 그림 → ② constitution.md 11개 원칙(짧다, 끝까지) → ③ spec.md §4~5(역할)·§7(생명주기) → ④ docs/worked-examples/로 "실제론 이렇게 쓴다" 체감. 코드가 없으니 IDE가 아니라 그냥 읽기 도구로 정독하면 된다.
이 레포에서 무엇을 배우고, 무엇을 실습할까.
이 원칙들은 보안만의 이야기가 아니다. "신뢰할 수 없는 작업자(LLM)를 다수 병렬로 굴릴 때 무엇이 깨지는가"에 대한 농축된 분산 시스템 교훈이다. 각 원칙엔 "이것이 불가침인 이유"로 실제 터뜨린 사고가 적혀 있다.
| 원칙 (원문 제목) | 요구사항 · 박제된 실패 |
|---|---|
| I. Evidence Over Assertion | 모델 확신이 아니라 기계 검증된 구조적 증거로만 진짜 판정. "고확신은 게이트 면제" 같은 완화가 조작을 통과시켰다. |
| II. Surface Only What Survives | 관문 통과분만 사람에게 노출. 탐지마다 이슈를 만들었더니 타깃당 수만 건 → "맞지만 쓸모없음". |
| III. Liveness By Heartbeat, Never By Clock | 벽시계 타임아웃이 아니라 하트비트로 생존 판정. 타임아웃은 '멈춤'과 '레이트리밋 대기'를 구분 못 해 멀쩡한 일을 재시작했다. |
| IV. Claims Are Atomic And Mortal | claim은 원자적(승자 1명)이고 죽으면 자동 해제. 안 그러면 병렬 에이전트가 서로 덮어쓰고, 죽은 에이전트가 자원을 며칠 붙들었다. |
| V. The Provider Is The Rate Arbiter | 내부에서 미리 조이지 말고 공급자 신호에 맞춰 적응 백오프. 모든 정적 상한은 며칠 만에 틀렸다. |
| VI. Coverage Before Yield | 수율 하락 자동정지는 커버리지 완료 깃발이 선 뒤에만. 초반 수율은 잡음이라 첫 가뭄에 멈췄다. |
| VII. Exploited Means Demonstrated | 'exploited'는 독립 청정실 재현으로만. "페이로드 먹혔다"·"디버거로 도달"은 불가. 자기 익스플로잇 자가채점이 신뢰를 무너뜨렸다. |
| VIII. Fingerprints Are Stable Under Edit | 발견 정체성 = 구조적 위치(경로+심볼+클래스), 줄 번호 제외. 줄 기반 지문은 근처만 고쳐도 전부 '신규'로 재등록됐다. |
| IX. Sandbox By Infrastructure, Not By Prompt | 망 egress·파일 쓰기 경계는 런타임이 강제. 프롬프트 규칙은 보조일 뿐. 프롬프트만 믿으면 에이전트는 언젠가 나쁜 지시에 복종한다. |
| X. The Operator Outranks Every Agent | 운영자 지시가 권위, 동료 에이전트 말은 힌트일 뿐. 안 그러면 에이전트끼리 "여긴 다 했다"며 서로 설득해 평가를 멋대로 종료했다. |
| XI. Persist Atomically | 새 상태를 완전히 쓴 뒤 원자적 교체. delete-then-write는 중간에 죽으면 모두가 빈손이 됐다(멀티시간 색인 반복 손실). |
"LLM이 말한 걸 어떻게 믿나?"의 정석 답안. 핵심은 주장(assertion)과 증거(evidence)의 분리, 그리고 인용이 실재 코드로 해소되는지를 기계가 확인하는 것. RAG·에이전트 어디에나 옮길 수 있는 패턴이다.
"한 거대 프롬프트"가 아니라 책임을 쪼개 각자 앞 단계의 실패를 잡게 하는 설계. 디텍터(넓게)→트리아저(거르기)→밸리데이터(증명)로 갈수록 통과 기준이 빡세진다.
워크드 예제의 규칙 하나(id: codeguard-py-shell-injection-from-flask, weakness_class: CWE-78)를 읽고, 필드 구조(trigger_when·example_positive·example_negative)를 익혀라.
'읽기'엔 아무것도, '구현'엔 꽤 많이 필요하다.
| 목적 | 필요한 것 |
|---|---|
| 명세 읽기·학습 | 마크다운 뷰어/브라우저 하나면 끝. 설치·실행 없음. |
| spec-kit으로 '내 명세' 만들기 | spec-kit 지원 코딩 에이전트(Claude Code 등) + 프로젝트 저장소 |
| 실제 Foundry 구현 운영 | 프런티어 LLM 접근 · 소스가 있는 평가 대상 · (가능하면) 실행 테스트베드 |
| 인프라 선택지(미리 정할 필요 없음) | LLM 공급자 · 이슈 트래커 · 데이터스토어 · 격리 런타임 · 배포 위치 |
| 안전 전제(A-가정) | "소스 접근 권한 있는 인가된 평가"가 성립해야 함 — 남의 시스템을 몰래 터는 도구가 아니다. |
README가 못 박는다 — "오늘 pip install 해서 저장소에 들이댈 물건을 원한다면, 이건 그게 아니다." Foundry는 "3년 뒤에도 당신 조직이 굴리고 있을 시스템"의 청사진이다. 빠른 결과가 아니라 오래 가는 토대를 위한 것.
난이도별 5단계 — 읽기부터 미니 구현까지.
constitution.md 11개 원칙을 끝까지 읽고, 각 원칙의 "이것이 불가침인 이유" 문단에서 박제된 실제 사고를 한 줄로 요약해 표를 만든다. 이미 당신이 운영하는 시스템(크론·큐·CI)에 똑같은 함정이 있는지 옆 칸에 ✓/✗로 표시.
빈 저장소에 spec-kit을 설치하고, constitution.md를 .specify/memory/로, spec.md를 specs/001-foundry/로 복사한 뒤 /speckit.clarify를 실행한다. 에이전트가 묻는 [NEEDS CLARIFICATION] 질문 중 '정체성·범위' 그룹만이라도 답해 본다. (확장 역할 5개는 모두 'no' 권장.)
작은 파이썬 저장소에서, LLM에게 "취약점 + 도달성/경계/영향을 각각 파일:줄로 인용"하게 시킨다. 그 인용 3개가 실재 코드로 해소되는지 검사해, 하나라도 어긋나면 needs-review로 강등하는 스크립트를 짠다. 워크드 예제 Finding A~C로 검증.
CWE-78(셸 인젝션) 규칙 하나를 CodeGuard 양식으로 쓰고, 디텍터(규칙 적용)→트리아저(증거 게이트)→리포터(보고서)를 순차 호출하는 미니 파이프라인을 만든다. 발견은 지문(경로+심볼+클래스)으로 dedup 할 것 — 줄 번호는 빼라(원칙 VIII).
원칙 III·IV·XI를 코드로 구현한다. 여러 워커가 작업을 원자적으로 claim하고(승자 1명), 하트비트로 생존을 알리며, 하트비트가 끊긴 작업만 재할당하고, 상태는 write-then-rename으로 원자적으로 저장. 워커를 일부러 죽여 봐도 데이터가 안 깨지는지 확인.
6주 코스 — 명세 독해에서 멀티에이전트 구현까지.
| 주차 | 주제 | 실습 · 참고 |
|---|---|---|
| 1주차 | 명세 전체 독해 + 스펙 주도 개발(spec-kit) 개념 | README Step 0~7 · spec.md §1~4 |
| 2주차 | 11개 헌법 원칙 ↔ 분산시스템 실패 양식 매핑 | constitution.md · docs/principles/anti-patterns.md |
| 3주차 | 발견 생명주기·증거 게이트·지문(fingerprint) 설계 | spec.md §7 · worked-examples/example-evidence-gate |
| 4주차 | 멀티에이전트 오케스트레이션·역할 분업·claim/하트비트 | spec.md §5·§8 · 미니 파이프라인 구현 |
| 5주차 | CodeGuard 규칙 작성 + 탐지→예방 플라이휠 | project-codeguard.org · example-detection-rule |
| 6주차 | 심각도·수율(yield)·자동정지·샌드박스 거버넌스 | spec.md §9 (FR-115~117) · operations/budget-and-stop-conditions |
본문·명세에 나온 용어 빠른 참조 (GLOSSARY.md 기반).
| 용어 | 의미 |
|---|---|
| Target (평가 대상) | 평가하는 소프트웨어. 소스코드와, 선택적으로 실행 중인 배포(테스트베드). |
| Testbed (테스트베드) | 에이전트가 찔러 보고 익스플로잇할 수 있는 대상의 실행 인스턴스. 없을 수도 있음. |
| Substrate (공유 기반) | 모든 역할이 의존하는 비에이전트 기계장치: 작업 큐·발견 저장소·샌드박스·예산·대시보드. |
| Role / Fleet (역할 / 군단) | 역할=에이전트 특화(디텍터 등). 군단=한 평가에서 도는 모든 에이전트 인스턴스. |
| Finding (발견) | '후보'부터 '확정·보고'까지 어느 단계에 있든, 주장된 취약점. |
| Verdict (판정) | 트리아저의 분류: true-positive·false-positive·needs-review·not-applicable·code-quality. |
| Evidence gate (증거 게이트) | true-positive로 분류되기 전 만족해야 할 구조적 증거 요건(도달성·경계·영향). |
| Exploited (증명됨) | headline 영향을 테스트베드에서 청정실로 독립 재현한 true-positive 발견. |
| Fingerprint (지문) | 실행 간 중복 제거에 쓰는 안정적 식별자. 경로+심볼+취약점 클래스, 줄 번호 제외. |
| Detection rule (탐지 규칙) | 한 취약점 클래스를 점검하는 재사용·버전 관리 규칙. 에이전트 코드와 독립된 뭉치(CodeGuard). |
| Rule-gap (규칙 공백) | 탐험형 발견이 true-positive인데 어떤 규칙도 못 잡았다는 기록. 규칙 증식의 입력. |
| Coverage / Yield (커버리지/수율) | 커버리지=목표를 얼마나 시도했나. 수율=심각도 가중 확정 발견 ÷ 비용(이동 창). |
| Claim (점유) | 한 작업 단위에 대한 에이전트의 배타적·크래시 안전 점유. |
| Seed / spec-kit (씨앗/스펙킷) | 씨앗=빈칸 남은 반제품 명세. spec-kit=빈칸을 채워 굳히는 스펙 주도 워크플로. |