왜 이걸 신뢰할 수 있나 (의사결정자용)¶
한 줄: 검증가능-as-code 82.5% (33/40) — 주장하는 모든 통제가
verify.sh/authz.py의 재실행 가능한 한 줄에 연결된다. 나머지 17.5%는 숨긴 게 아니라 행 단위로 공개되어 있다(docs/mls-coverage.csv).
대부분의 보안 산출물은 "안전하다"고 말한다. 이 프로젝트는 "무엇을 증명했고 무엇을 아직 못 했는지"를 말한다. 그게 감사·도입 관점에서 더 신뢰할 수 있는 형태다.
직접 재확인할 수 있는 3가지¶
- 재현되는 증거 (감사자가 직접 돌린다). 통제별 거부/허용이 부작용 없는 server dry-run으로 재현된다 — 누가 보여주는 게 아니라 감사자가 스스로 실행해 확인한다. → 감사증거 패키지
- 명시된 갭 (17.5%가 구체적이다). 미검증 항목을 범주로 공개: CONFIGURED 3 · GOVERNANCE 2 · NOT_COVERED 4.
"대충 다 됐다"가 아니라 어느 통제가 왜 아직 미검증인지가 행 단위로 적혀 있다. →
mls-coverage.csv - 정직성의 증명 (증명되면 올리고, 안 되면 내린다). 요청자 JWT 행(ID8)을 처음엔 CONFIGURED로 추가해
헤드라인을 낮췄다 — 검증기 로직은 단위테스트됐어도 라이브 강제 전엔 VERIFIED라 주장하지 않았다. 이후
enforce 모드(
AUTH_REQUIRE_JWT)를 라이브로 증명(verify-jwt-enforce: unauth→401·Bearer→200)해 VERIFIED로 끌어올렸다. 편한 숫자가 아니라 증명에 따라 움직이는 참값. → 평가·커버리지
적대적 자기검증¶
LLM 멀티에이전트 재검토를 반복해 우리 자신의 정책에서 실제 결함(예: SA-use 우회 CRITICAL 1)을 찾아 수정하고 라이브로 재검증했다. 발견·잔여위험은 과장 없이 위협 모델에 명시한다 — "막지 못하는 것"까지 적는다.
감사 비용 관점¶
증명할 수 없는 통제는 감사에서 보상통제로 주장할 수 없다. 증명되는 통제는 감사 증거 부담을 줄인다 — "막는다 + 매번 재현된다"를 감사자가 dry-run으로 스스로 확인하기 때문.
정직 단서 (이 페이지도 과장하지 않도록)¶
- 21/21 라이브 검증은 기능 회귀 스위트이지 연구 측정값이 아니다(분모 없음). 82.5%의 분모는 워크로드-적용가능 40이다.
- ISMS-P·전자금융감독규정 항목 매핑은 구조적 매핑이며 인증·공식 컴플라이언스가 아니다(매핑).
- 교육·포트폴리오 목적의 레퍼런스다 — 법률/금융 자문이 아니다. 규제 세부는 1차 출처 대조가 필요하다.