50,000 스타 오픈소스에서 32개 버그, 오탐 0개
50,000개 이상의 GitHub 스타를 보유한 오픈소스 프로젝트 매니지먼트 툴 Plane이 AI 코드 스캐너에 걸렸다. 개발자 Rohit Sriram이 직접 만든 Faultmark라는 도구로 스캔한 결과, 32개의 버그가 발견됐다. 그리고 오탐(false positive)은 단 하나도 없었다. 스캔 소요 시간은 10분.
이 숫자가 중요한 이유는 두 가지다. 첫째, 발견된 버그 중 상당수가 단순한 코드 스타일 문제가 아니라 실제 운영에서 폭발하는 수준이다. GitHub·GitLab OAuth가 TypeError: 'str' object is not callable로 완전히 동작 불능 상태였고, 신규 가입자와 기존 사용자를 반대로 처리하는 인증 로직 역전, 프로젝트 초대 기능의 AttributeError 크래시, 워크스페이스 멤버 간 권한 없는 설정 수정, 그리고 LLM 응답이 HTML 이스케이핑 없이 프론트엔드에 그대로 전달되는 저장형 XSS까지 포함돼 있다. 둘째, 이 버그들이 활발히 유지보수되는 프로덕션급 오픈소스에서 나왔다는 사실이다. '우리 팀 코드는 괜찮겠지'라는 가정은 이 결과 앞에서 꽤 불편해진다.
Faultmark가 오탐을 줄일 수 있는 건 다중 모델 토론(multi-model debate) 방식 덕분이다. 후보 버그를 여러 모델이 교차 검증하고 이의를 제기하는 과정을 거쳐야 최종 목록에 오른다. 단일 모델이 판단하면 맥락 이해 부족으로 오탐이 쌓이고, 결국 팀은 알람을 무시하게 된다. 보안 스캐너의 가장 큰 적은 '알람 피로'다. 오탐을 줄이는 설계 자체가 도구의 신뢰도를 결정한다.
에이전트가 하드코딩한 AWS 키를 사람이 잡을 수 없는 이유
두 번째 관점은 코딩 에이전트가 직접 만들어내는 시크릿 노출 문제다. dev.to에 공개된 leakferret 프로젝트는 이 문제를 정면으로 다룬다. PR 화면은 깔끔했고, 테스트는 통과했고, diff는 작았다. 그런데 config 헬퍼 파일 세 줄 아래에 실제 AWS 액세스 키가 박혀 있었다. 에이전트가 예제를 동작시키려고 붙여넣은 것이다.
사람이 코드를 작성할 때는 커밋 전에 최소 한 번 눈을 거친다. 에이전트가 작성한 코드는 다르다. 리뷰어는 600줄짜리 diff를 훑는 사람이거나, 심지어 그 코드를 작성한 것과 동일한 에이전트다. 정규식 스캐너는 키의 '형태'를 잡을 수 있지만, 그 키가 살아있는지는 모른다. 그리고 탐지에서 멈추면 수정은 여전히 사람의 몫이다. 시크릿을 빼내고, 환경변수로 교체하고, .env.example을 업데이트하고, 시크릿 매니저에 등록하는 일련의 과정이 수동으로 남는다.
leakferret은 이 갭을 닫으려는 도구다. 5단계 파이프라인으로 작동한다. 스캔 → 카탈로그 대조(공개 예제 키 필터링) → 분류(REAL/FIXTURE/UNKNOWN) → 실제 제공자 API로 활성 여부 검증 → 자동 재작성. 특히 카탈로그 단계에서 AKIAIOSFODNN7EXAMPLE 같은 AWS 공식 문서 예제 키를 사전 등록된 서명 DB와 대조해 FIXTURE로 처리한다. 이 단계 없이는 README 하나에 있는 예제 키가 알람을 울려서 팀이 스캐너를 꺼버리게 된다.
검증 단계는 이 도구가 기존 정규식 스캐너와 구별되는 핵심이다. AWS라면 STS GetCallerIdentity를, GitHub는 인증된 사용자 읽기 API를 호출해 키가 실제로 살아있는지 확인한다. 읽기 전용 호출만 사용하고, 요청은 leakferret 서버 없이 사용자 머신에서 제공자에게 직접 전달된다. 전체 시크릿 값은 로컬 디스크 밖으로 나가지 않고, 리포트와 프롬프트에는 앞뒤 4자리만 노출되는 redacted 형태로만 표시된다.
AI-First 팀의 파이프라인에 지금 당장 꽂아야 할 두 레이어
두 도구를 함께 보면 AI-First 팀의 보안 파이프라인이 채워야 할 두 레이어가 보인다.
레이어 1 — 코드 로직 취약점 스캔: Faultmark 같은 다중 모델 검증 방식의 정적 분석. 단일 모델 판단이 아니라 교차 검증을 통해 오탐을 줄이고 팀의 알람 신뢰도를 유지한다. OAuth 로직 역전, AttributeError 크래시, 권한 우회, XSS처럼 에이전트가 생성한 코드에서 발생하기 쉬운 패턴이 이 레이어에서 걸린다.
레이어 2 — 시크릿 노출 탐지 + 자동 수정: leakferret 같은 도구를 CI/CD 파이프라인과 에이전트 루프 양쪽에 배치한다. CI 게이트에서 PR 머지 전 스캔하고, MCP 서버로 에이전트가 커밋 전 자기 작업을 자가 검증하도록 구성한다. 탐지에서 멈추지 않고 환경변수 교체까지 자동화하는 것이 핵심이다.
두 레이어가 없으면 어떻게 되는지는 이미 알고 있다. 에이전트가 빠르게 생성한 코드가 리뷰를 통과하고, 시크릿이 히스토리에 묻히고, 제공자 알림 이메일로 사후에 알게 된다. 속도는 에이전트가 내고, 방향은 파이프라인이 잡아야 한다.
냉정하게 짚어야 할 부분
도입 장벽도 솔직히 말해두자. Faultmark의 다중 모델 토론 방식은 10분 스캔에 실제 API 비용이 발생한다. 대규모 모노레포에 매 PR마다 돌리면 비용 구조를 먼저 설계해야 한다. leakferret의 실시간 제공자 API 검증은 현재 약 15개 제공자를 지원하고 나머지는 trufflehog 폴백이다. 팀이 쓰는 내부 시스템 시크릿은 검증 범위 밖이다.
그럼에도 방향은 맞다. AI가 코드를 더 빠르게 생성할수록, 그 코드를 검증하는 파이프라인도 AI 속도에 맞게 자동화돼야 한다. 사람이 600줄 diff를 줄 단위로 읽는 건 더 이상 현실적인 보안 전략이 아니다. 오탐 없는 버그 탐지와 시크릿 자동 수정이 CI/CD에 기본으로 탑재되는 것, 그게 AI-First 팀의 보안 베이스라인이다.