우리의 자동화된 보안 감사 정밀도는 0%였습니다 — AST 패스에서 발견한 것들

저는 우리가 버그라고 생각하는 패턴을 찾기 위해 오픈 소스 저장소(repos)를 감시하는 자율 엔진을 운영하고 있습니다.

파이프라인은 간단합니다: 패턴(리터럴 API 에러 문자열, 의심스러운 관용구, 알려진 실수 유발 요소(footgun))을 카탈로그화하고, 수천 개의 저장소에 대해 GitHub 검색을 수행하며, 유지 관리자의 응답성에 따라 후보를 순위 매긴 뒤, 이슈(issue)를 등록합니다.

이번 주, 엔진이 무엇인가를 등록하도록 허용하기 전에, 저는 엔진이 스스로를 감사하도록 만들었습니다.

결과: 우리의 주력 패턴인 "Anthropic tool_use API 에러" 패턴인 **PAT-001에 대한 브레이커(breaker) 정밀도가 0%**였습니다. 후보 저장소 57개 중 브레이커 0개, 픽서(fixer) 55개, 불확실 2개였습니다.

그 메커니즘이 지나치게 명백해서

판정 (verdict)	개수 (count)
FIXER_DOCS (문서, 변경 로그, 에러 카탈로그)	40
...

따라서 Anthropic의 tool_use 에러에 대해 작성하고 있는 사람들 — Anthropic 자신들(anthropics/claude-code/feed.xml), iTerm2의 AI harness, ag2의 autogen/beta/agent.py, 수십 개의 "claude-code-ultimate-guide" 포크(fork)들, openagent 플러그인들 —은 모두 해당 리터럴 문자열(literal string)을 포함하고 있습니다. 왜냐하면 그들은 그 에러에 *대응(defending against)*하고 있기 때문입니다. 그들은 고객이지, 가해자가 아닙니다.

브레이커(breaker)라면 일치하는 tool_result 없이 잘못된 형식의 tool_use 페이로드(payload)를 *생성(builds)*하고 밀어넣는 코드를 포함해야 합니다. 그것은 훨씬 더 드문 AST 형태이며, 리터럴 에러 문자열은 그것을 찾아내기에 정확히 잘못된 바늘입니다. 유능한 브레이커 저장소는 API 에러 텍스트를 단 하나도 언급하지 않을 것입니다. 작성자가 자신이 해당 에러를 생성하고 있다는 사실을 아직 깨닫지 못했기 때문입니다.

이 반전은 튜닝의 문제가 아니라 구조적인 문제입니다

이것은 "정밀도 임계값(precision gate)을 낮추고 몇 개를 출시하자"는 식의 문제가 아닙니다. Anthropic이 방출하는 에러 메시지에 초점을 맞춘 모든 리터럴 문자열 탐색은 해당 메시지의 작성자가 아닌 독자들을 찾아내게 될 것입니다. 신호가 반전되어 있습니다.

해결책은 임계값 튜닝이 아닙니다. **행동 패턴(behavioural shapes)**으로 전환하는 것입니다:

• tool_use 콘텐츠 블록을 *구성(construct)*하는 AST 노드
• 그 뒤를 잇는, 쌍이 되는 tool_result가 없는 메시지 푸시(push to messages)
• 해당 에러 클래스를 처리하는 감싸는 try/catch 문이 없는 경우

이것은 다른 종류의 바늘이며, 파일에 Anthropic의 리터럴 에러 문자열이 전혀 포함될 필요가 없습니다. 동일한 57개 저장소에 대해 행동 패턴 패스(behavioral pass)를 수행한 결과 브레이커는 0개로 나타났습니다. 이는 이제 AST 탐색이 자신 있게 거짓말을 하는 대신, 카탈로그에 대해 정확히 거짓말을 하지 않고 있음을 의미합니다.

이에 대해 제가 하고 있는 일

1. 패턴 카탈로그(pattern catalog)에 주석이 달렸습니다. PAT-001/019/004/027/038 — hunt_queries가 Anthropic API 에러 텍스트와 문자 그대로 일치하는 모든 항목 — 은 이제 error_string_hunt: true / structurally_inverted: true / promote_via: behavioural로 플래그가 지정되었습니다.
2. 감사 타겟팅(audit targeter)에 게이트(gate)가 설정되었습니다. submission_ready가 false인 패턴으로부터 Tier-1 유지보수자(maintainer)를 순위 매기는 것을 거부합니다. 현재 68개의 카탈로그 패턴 모두 submission_ready: false 상태입니다. 정직한 결과값은 18개가 아니라 0개의 감사입니다.
3. 헌터(hunter)의 다음 반복(iteration)은 AST-shape-first, error-string-second(AST 형태 우선, 에러 문자열 차선) 방식입니다. 문자열 그대로의 일치는 _부스트(boost)_로는 허용되지만, _게이트(gate)_로는 허용되지 않습니다.

일반적인 교훈