피드로 돌아가기
Dev.toSecurity
원문 읽기
The LiteLLM Attack Exposed a Bigger Problem: Your Vibe-Coded App Probably Has the Same Vulnerabilities
AI 코드 생성 앱 5,600개 스캔 결과 2,000+ 취약점 발견, litellm 공급망 공격과 동일한 패턴이 대부분 앱에 존재
AI 요약
Context
AI 코딩 어시스턴트(Lovable, Bolt, Cursor 등)로 생성된 애플리케이션들이 transitive dependency 관리 부재, 보안 검토 결과 중심의 빌드, 환경변수에 저장된 자격증명 노출이라는 공통 취약점을 가지고 있다. litellm v1.82.8 백도어 공격(97만 건/월 다운로드)이 이 패턴을 악용해 SSH 키, 클라우드 자격증명, Kubernetes 설정, 암호화폐 지갑을 탈취했다.
Technical Solution
- 하드코딩된 API 키 제거: Firebase, Supabase, Stripe 비밀키를 클라이언트 코드에서 제거하고 환경변수(.env.local)로 이동
- 서버 사이드 프록시 라우트 구현: 민감한 자격증명을 사용하는 외부 서비스 요청을 서버 사이드 API 라우트로 중개
- Supabase Row Level Security(RLS) 정책 활성화: 모든 사용자 데이터 테이블에 RLS 정책 설정으로 사용자 간 데이터 접근 제어
- API 라우트 인증 검사 추가: POST, DELETE 메서드별 라우트 진입점에서 사용자 로그인 상태 확인 로직 구현
- 보안 헤더 설정: CSP, HSTS, X-Frame-Options 등 HTTP 보안 헤더를 배포된 애플리케이션에 추가
- .env 파일 Git 히스토리 정리: git log --all --full-history -- .env으로 커밋 이력 확인 후 BFG Repo-Cleaner 등으로 히스토리에서 제거
Impact
- Escape.tech 스캔 5,600개 AI 생성 앱: 2,000+ 취약점, 400개 노출된 비밀키 발견
- Tenzai 15개 앱 중 0개가 적절한 보안 헤더 보유
- Supabase 사용 앱: 10.3% RLS 설정 결함 가능성
- CodeRabbit 비교 결과: AI 생성 코드에서 XSS 취약점 2.74배 증가
- 무작위 Lovable 저장소 최저 스캔 점수: 28/100
Key Takeaway
AI 코딩 어시스턴트로 생성된 코드는 "동작 여부"를 최적화하지 "보안"을 고려하지 않으므로, 엔지니어는 5가지 항목(저장소 스캔, .env 이력 확인, RLS 정책, 보안 헤더, API 라우트 인증)을 15분 내에 자동으로 검증하고 수정해야 한다.
실천 포인트
AI 생성 애플리케이션 팀은 배포 전에 VibeCheck 같은 자동 스캔 도구로 저장소를 검사하고, securityheaders.com에서 배포된 URL의 보안 헤더를 B 등급 이상으로 설정하며, Supabase RLS 정책을 모든 사용자 데이터 테이블에 명시적으로 활성화하면 공급망 공격과 무관하게 애플리케이션 자체의 데이터 유출 위험을 대폭 감소시킬 수 있다.