turva.dev의 회사 페이지는 구매자에게 저를 고용하기 전에 모든 코드를 한 줄씩 읽어볼 수 있다고 말합니다. 감사(Audit) 비즈니스는 스스로의 약속을 지켜낼 수 있어야 하기에, 저는 제 사이트를 대상으로 감사를 진행했습니다. 모두 Claude Fable 5를 실행하는 4개의 AI 에이전트가 공개된 표면을 한 줄씩 읽었습니다: turva.dev를 렌더링하는 Worker 소스 코드 약 5,400줄, mcp.turva.dev 뒤에 있는 MCP 서버, 그리고 공개 리포지토리(public repos)의 README 파일들입니다. 그 결과 91개의 발견 사항(findings)이 도출되었습니다.

91개의 발견 사항이란 어떤 모습인가

대부분은 살아있는 모든 코드베이스가 축적하는 드리프트(drift)였습니다. 한 표면에서는 검증을 위해 RS256 및 ES256을 광고했지만, 사이트의 실제 키는 Ed25519였습니다. x-markdown-tokens라는 이름의 응답 헤더(response header)는 단어 수를 포함하고 있었습니다. 한 가이드에서는 MPP를 잘못된 프로토콜 이름으로 확장하여 설명했습니다. 한 가이드의 표(table)는 렌더러가 표를 지원하지 않아 한 번도 표로 렌더링된 적이 없었습니다. 법적 페이지에서는 등록된 비즈니스(registered business)를 등록된 회사(registered company)라고 불렀습니다. 이 중 그 어떤 것도 스캐너(scanner)를 움직이지는 못합니다.

약 60개의 수정 사항이 배포되었고, 배포 후 두 스캐너를 모두 다시 실행했습니다: startuphub.ai는 6개 카테고리 모두 100점을 기록하며 100/100, A+ 등급으로 읽어냈고, isitagentready.com은 레벨 5(Level 5)로 읽어냈습니다. 이러한 수정 사항이 대부분 적용되기 전에도 점수는 동일했으며, 바로 그것이 핵심입니다. 스캐너는 당신이 광고하는 키 알고리즘이 실제로 사용하는 것인지 확인할 수 없습니다. 한 줄씩 읽는 것(Line-by-line reading)이 점수 아래에 있는 계층입니다.

4개의 HIGH 경고, 그리고 그것들이 사라진 방식

에이전트들은 4개의 발견 사항을 HIGH로 표시했습니다. 검증 결과 4개 모두 사라졌으며, 이는 두 가지 근본 원인으로 추적되었습니다.

첫 번째: 사이트는 두 개의 독립적인 스캐너에 의해 100/100으로 검증되었다고 주장하며, 에이전트들은 그 스캐너 중 하나인 isitagentready.com이 사이트를 0에서 5까지의 레벨로 등급을 매긴다는 사실을 알고 있었습니다. 레벨 기반 스캐너의 수치를 퍼센트로 표현하는 것은 지어낸 숫자처럼 보이기 때문에, 해당 주장은 감사 대상 자체에 대한 허위 광고로 플래그(flagged)되었습니다. 스캐너 자체의 스코어카드(scorecard)가 이를 해결합니다. 스캔을 실행하면 보고서에 이 사이트에 대해 Level 5 옆에 100/100이 표시됩니다. 주장은 작성된 대로 유지됩니다.

두 번째 사례: 한 에이전트가 라이브 MCP 서버 카드를 가져와 버전 1.1.0을 읽었으나, 소스에는 1.2.0이라고 명시되어 있었습니다. 리포지토리(repo)를 따라가지 못하는 배포된 코드는 어디에서나 실제적인 문제이므로, 해당 주장에 대해 HIGH(높음) 등급의 심각도를 부여한 것은 적절했습니다. 하지만 이는 여전히 틀린 결과였습니다. 데이터 가져오기(fetch)가 캐시(cache)를 통해 이루어졌던 것이며, Cloudflare API에서 배포된 워커(Worker)를 직접 가져오자 소스와 동일한 1.2.0이 나타났습니다. 발견 사항은 측정 도구의 오류를 기술한 것이었으며, 배포 상태는 결코 동기화가 어긋나 있지 않았습니다.

유효했던 발견 사항

하나의 HIGH 등급이 살아남았습니다. MCP 서버의 README는 서비스가 로깅(logging)을 수행하지 않는다고 약속했으나, 워커(Worker) 설정에는 플랫폼 관측성(platform observability)이 켜져 있어 모든 호출에 대해 로그 라인을 저장하고 있었습니다. 약속과 코드가 일치하지 않았으며, 이는 바로 감사가 잡아내고자 하는 전형적인 격차의 유형입니다. 수정은 정직한 방식으로 이루어졌습니다. 말이 현실에 맞게 변경되었습니다. 즉, 관측성(observability)을 끄고, README에도 이제 플랫폼 로그가 비활성화되어 있다고 명시적으로 기재했습니다. README를 '최소한의 로깅'을 수행한다고 다시 쓰는 것이 배포하기에는 더 빨랐겠지만, 이를 읽는 누구에게도 가치가 낮았을 것입니다.

어려운 부분은 오탐(false positives)입니다

발견 사항은 하나의 주장이며, 주장은 마케팅 문구와 동일한 취급을 받습니다. 1차 소스(primary source)를 통해 검증하거나, 그렇지 않으면 버리십시오. 여기서 죽은 경고(dead alerts)에 따라 조치를 취했다면 사이트를 더 악화시켰을 것입니다. 왜냐하면 올바른 주장을 수정하는 것은 오경보가 있던 자리에 실제 오류를 심는 격이기 때문입니다. 스캐너의 척도를 당연하게 가정하는 대신 스캐너 자체의 스코어카드(scorecard)를 읽으십시오. 그리고 캐시된 가져오기(fetch)를 신뢰하는 대신 플랫폼에서 배포된 아티팩트(artifact)를 직접 가져오십시오. 몇 분간의 확인 작업이 네 개의 HIGH 등급을 제거했습니다.

동일한 원칙이 감사를 구매할 때도 적용됩니다. 여러분에게 전달되는 보고서는 살아남은 것들이어야 하며, 모든 감사인에게 유용한 질문은 원시 스캔(raw scan)과 작성된 보고서 사이에 얼마나 많은 발견 사항이 제외되었는가 하는 점입니다. 답변이 '0'인 보고서는 대개 아무도 확인하지 않았음을 의미합니다.

발견 사항이 여러분이 읽기 전에 검증되는 에이전트 준비성 감사(agent-readiness audit)가 필요하다면, info@turva.dev로 문의하십시오.

원문은 https://turva.dev/blog/auditing-the-auditor에서 처음 게시되었습니다.