AI가 구축한 393개 리포지토리를 AI를 사용하지 않고 재검사했습니다. 8개 중 1개가 치명적인 결함을 포함하고 있었습니다.

지난 9월에 저는 언어 모델이 분석한 400개의 AI 구축 리포지토리에서 발견된 내용을 발표했습니다. 가장 유용한 비판은 동시에 가장 명백한 것이었습니다. 즉, 모델의 판단은 재현할 수 없으며 감사(audit)할 수 없다는 것입니다. 다시 실행하면 다른 답변을 얻을 수도 있습니다. "정확히 어떻게 계산했나요?"라고 물으면 솔직한 대답은 "모델이 결정했습니다."입니다.

그래서 저는 이 전체 과정을 결정론적 규칙(deterministic rules)으로 다시 실행했습니다. 동일한 고정 코퍼스(frozen corpus), 모델 없이, 26개의 규칙을 사용했으며, 모든 발견 사항은 특정 규칙 ID와 라인 번호로 추적 가능합니다.

헤드라인 수치가 감소했습니다. 이것이 이번 실험에서 가장 흥미로운 부분이었습니다.

코퍼스

Lovable, Bolt 및 v0으로 구축된 400개의 공개 리포지토리가 사용되었습니다. 이 리포지토리는 README 텍스트에 "Lovable로 구축됨"과 같은 문구가 쓰여 있어서가 아니라, .lovable, lovable-tagger 또는 .bolt를 포함하고 있기 때문에 자격이 주어졌습니다. 소유자당 하나의 리포지토리이며, 포크(forks)는 제외했고, 각 최대 3개의 파일을 포함하며, 샘플이 결과에 따라 변동하지 않도록 2026년 9월 5일자로 고정되었습니다.

총 1,185개 파일 중 1,163개가 393개 리포지토리에서 읽을 수 있었습니다. 누락된 22개는 동결 이후 GitHub에서 삭제되었습니다. 전체 실행은 약 90초가 소요되며 비용이 들지 않아 중요합니다. 첫 번째 시도는 진행 도중에 API 잔액을 모두 소진했기 때문입니다.

규칙들이 발견한 것들

1,163개 파일 중 27%인 309개의 파일에서 적어도 하나의 발견 사항이 있었습니다. 58개의 파일에는 치명적인 무언가가 있었고, 이는 49개 리포지토리에 걸쳐 분포되어 있습니다. 즉, 규칙만으로도 리포지토리의 8개 중 1개가 최소한 하나의 치명적인 결함을 가지고 있었다는 의미입니다.

Cookie set without Secure or SameSite       111
Access-Control-Allow-Origin: *               74
dangerouslySetInnerHTML from a variable      60
...

예상치 못한 발견

39개의 파일에서 using (true)로 작성된 행 수준 보안 정책(row-level security policy)이 포함되어 있었습니다.

단순히 RLS(행 레벨 보안) 활성화를 잊은 것보다 더 심각한 문제입니다. 왜냐하면 이는 누군가 '시도했다'는 증거이기 때문입니다. 그들은 스업베이스(Supabase) 테이블에 행 레벨 보안이 필요하다는 것을 읽었습니다. 그리고 그것을 활성화했습니다. 그런 다음 모든 행에 대해 true를 반환하는 정책을 작성했는데, 이 정책은 모든 검사를 통과하고, 모든 사용자에게, 매번 작동합니다.

-- 활성화되었지만 완전히 무효함
alter table orders enable row level security;
create policy "read orders" on orders for select using (true);
...

대시보드는 RLS가 활성화된 것을 보여줍니다. 체크박스는 선택되어 있습니다. 테이블은 이전과 마찬가지로 열려 있습니다.

AI 코딩 도구는 'RLS를 추가해 달라'고 요청받으면 기꺼이 첫 번째 버전을 생성합니다. 왜냐하면 그것은 질문에 대한 문자 그대로의 답변이기 때문입니다. 앱에서 아무것도 깨지지 않고, 경고하는 것도 없으며, 테이블을 읽기 가능하게 만드는 익명 키(anon key)가 설계상 프론트엔드 번들로 포함됩니다.

하락한 수치

첫 번째 연구에서는 스캔된 레포지토리 중 59%가 심각한 문제점을 가지고 있다고 보고했습니다. 이번 테스트는 12%입니다. 둘 다 사실이며, 그 격차가 핵심입니다.

두 테스트 모두에서 읽은 파일 수는 115개였습니다:

• 모델이 113개에서 무언가를 플래그 지정함
• 규칙이 32개에서 무언가를 플래그 지정함
• 둘은 판정에서 **30%**의 일치율을 보임

규칙(Rules)은 구문 패턴—플래그가 없는 쿠키, 와일드카드 CORS 헤더, 템플릿 리터럴로 붙여진 SQL 등—을 포착합니다. 이들은 읽기 위해 의도(intent)가 필요한 모든 것에는 눈이 멀어 있습니다: 누가 요청하는지 확인하지 않는 엔드포인트, 사용자 입력이 세 함수 후에 싱크에 도달하는 경우, 브라우저로 스택 트레이스를 반환하는 에러 핸들러 등입니다.

따라서 12%는 **추정치가 아니라 하한선(floor)**입니다. 이는 코드에 대한 이해 없이 패턴 매칭만으로 무언가 잘못되었다고 '증명'할 수 있는 레포지토리의 비율입니다. 실제 수치는 더 높습니다. 저는 이 하한선을 발표합니다. 왜냐하면 이것은 제가 줄 단위로 방어할 수 있는 숫자이기 때문입니다.

LLM이 생성한 보안 통계를 발표할 때 아무도 언급하지 않는 상충 관계가 있습니다. 즉, 재현할 수 없는 광범위함(breadth)을 얻거나, 체계적으로 과소 계산하는 엄밀성(rigour) 중 하나를 선택해야 한다는 것입니다. 둘 다 가질 수는 없으며, 어떤 것을 원하는지는 누군가가 그 숫자에 대해 논쟁할 것인지 여부에 전적으로 달려 있습니다.

주목할 만한 또 다른 점

1,163개 파일에 걸쳐 단 3개의 비밀(secrets)만 발견되었습니다.

이것은 좋은 소식처럼 들리지만 그렇지 않습니다. 두 검사 모두 .env 파일을 열어보지 않는데, 이전 연구에서는 이 저장소의 18.5%가 해당 파일을 커밋한 것으로 나타났습니다. 이러한 프로젝트의 비밀들은 컴포넌트에 붙여넣기 되는 것이 아닙니다. 그들은 첫 푸시(push)에 포함된 환경 파일(environment file) 안에 존재하며, 이는 또한 코드를 대충 살펴보는 사람도 절대 찾을 수 없는 유일한 장소입니다.

이렇게 구축한다면, 세 가지 검사

1. SQL에서 using (true)를 검색하세요. 만약 이 구문이 고객 데이터를 담고 있는 테이블에 있다면, 이 게시물 전체가 여러분의 저장소 안에 있다는 의미입니다.
2. git log --all -- .env를 실행하세요. 어떤 출력이라도 나온다면 파일이 히스토리(history)에 존재한다는 뜻입니다. 키를 순환(rotating)시키는 것이 유일한 해결책이며, 파일을 삭제하는 것은 아닙니다. 왜냐하면 히스토리가 이전 블롭(blob)을 계속 보존하기 때문입니다.
3. 신규 로그인 요청이 무엇을 읽을 수 있는지 확인하세요. RLS가 '켜져 있다'는 것이 어떤 작업을 수행하고 있다는 것을 의미한다고 신뢰하는 대신에 말입니다. 외부에서 볼 때, 빈 테이블과 보호된 테이블은 동일하게 보이기 때문에, 유일한 실제 증거는 두 개의 계정입니다. 두 번째 계정으로 로그인하여 첫 번째 계정의 행을 읽으려고 시도해 보세요.

방법론, 규칙별 카운트 및 주의사항은 여기서 자세히 설명했습니다: https://www.vibesafe.info/blog/393-ai-built-repos-rules-scan

혹시 작동 방식을 확인하고 싶은 분이 있다면, 파일별 및 발견 항목별 CSV를 공유해 드릴 수 있습니다. 모든 행에는 저장소, 파일, 규칙 ID, 그리고 줄 번호가 포함되어 있습니다. 저는 저장소 이름은 공개하지 않습니다. 이들은 실제 사람들의 실제 프로젝트이며, 그들 대부분은 상황을 모릅니다. 취약한 앱 목록은 단지 목표 목록일 뿐입니다.