AI 코딩 도구가 보안 허점을 남기는 이유

AI- 생성된 코드의 보안이 다른 이유

AI 코딩 도구에는 보안 격차가 발생하는 구조적인 이유가 있습니다. 그것은 무작위 감독이 아닙니다. 이는 훈련과 최적화의 예측 가능한 결과물입니다.

• Training data skews toward "make it work." 오픈 소스 저장소와 튜토리얼이 LLM 교육의 대부분을 차지합니다. 중앙값 OSS 저장소는 보안 강화의 모범이 아니라 문제를 해결하기 위해 작성되었습니다. LLM은 보안 코드 배포가 아닌 실제 코드 배포를 학습합니다.
• Autocomplete is sticky. service_role 키를 사용하는 코드 조각을 붙여넣으면 다음 파일의 템플릿이 됩니다. Cursor의 자동 완성 기능은 자신이 속하지 않은 클라이언트 구성 요소에 이를 제안합니다. 도구는 최적화된 작업(속도)을 수행하지만 보안 경계를 인식하지 못합니다.
• No long-term context or incident memory. WHERE 절이 누락되어 프로덕션 데이터베이스를 불태운 인간 개발자는 그 교훈을 수년 동안 이어갑니다. LLM에는 에피소드 메모리가 없습니다. 모든 파일은 새로운 시작입니다. 이 도구는 마지막 RLS 우회 또는 팀의 사고 사후 조사로부터 학습하지 않습니다.
• Speed is the rewarded metric. 개발자는 배송이 빠르기 때문에 이러한 도구를 선택합니다. 지연 시간 피드백은 즉각적이고 직접적입니다. 보안 피드백이 없거나 지연됩니다. 배송 3주 후 FixVibe 스캔에서 취약점이 발견되었습니다. LLM은 인간이 실시간으로 보상하는 측정항목에 최적화되었습니다.
• Implicit trust in platform defaults. Cursor이 Vercel 앱을 생성할 때 Vercel의 기본값이 강화되었다고 가정합니다. 그 중 일부는 auto-HTTPS, 서명된 쿠키, DDoS 보호입니다. 다른 것들은 그렇지 않습니다: 기본적으로 CSP 없음, HSTS 없음, CORS 허용. 생성된 코드는 항상 정당화되지 않는 플랫폼 가정을 상속합니다.

격차 1: 클라이언트 번들의 비밀

서비스 역할 API 키, OAuth 토큰 및 개인 키는 브라우저에 제공되는 JavaScript 번들에 포함됩니다. FixVibe은 이를 secrets.browser-storage 및 secrets.bundle-leak 조사 결과로 플래그 지정합니다. 키는 소스 맵, 축소된 코드 또는 일반 텍스트 JS에서 검색할 수 있습니다.

Why it happens: Cursor 서비스 역할로 클라이언트를 초기화하는 Supabase 조각을 붙여넣는 것은 코드가 이제 자동 완성에 있음을 의미합니다. 생성된 React 구성 요소는 "데이터베이스에서 모든 항목 가져오기"를 요청하고 Cursor은 서비스 클라이언트 가져오기를 제안합니다. 서버 전용 코드와 클라이언트 측 코드 사이의 경계는 LLM으로 추상화됩니다.

Fix: 공개 키에 대해서만 NEXT_PUBLIC_ 플래그가 지정된 환경 변수에 비밀을 저장합니다. 서비스 키, 개인 API 키 및 서명 비밀은 import 'server-only'과 함께 src/lib/secrets.ts에 있어야 합니다. 중요한 서비스를 호출하려면 클라이언트 구성 요소가 아닌 서버 작업이나 API 경로를 사용하세요.

격차 2: 행 수준 보안이 누락되거나 불완전함

Supabase 테이블은 RLS 활성화 없이 생성됩니다. Firebase Firestore 규칙은 작성되지 않거나 허용 테스트 모드로 유지됩니다. Anon 사용자는 모든 행을 읽고 쓸 수 있습니다. FixVibe은 이를 baas.supabase-rls 및 baas.firebase-rules으로 플래그 지정합니다.

Why it happens: RLS은 Postgres 전용 기능입니다. Rails, Django, Laravel 및 Express에 대한 교육을 받은 LLM은 애플리케이션 계층 인증 확인을 표준으로 봅니다. Supabase에서 RLS을 활성화하려면 명시적인 ALTER TABLE 문과 정책 정의가 필요합니다. 이는 훈련 데이터에서는 덜 일반적인 패턴입니다.

Fix: Supabase의 경우 모든 테이블에서 ALTER TABLE public.table_name ENABLE ROW LEVEL SECURITY; ALTER TABLE public.table_name FORCE ROW LEVEL SECURITY;과 함께 RLS을 적용합니다. 인증된 사용자 또는 조직으로 행 범위를 지정하는 정책을 작성합니다. Firebase의 경우 규칙을 기본 테스트 모드로 두지 마십시오. 인증된 사용자로 범위가 지정된 명시적인 규칙을 작성합니다.

격차 3: 인증 경계 혼란

세션은 getSession()(확인되지 않은 쿠키를 읽음)을 사용하여 클라이언트 측에서 검증됩니다. 매직 링크에는 만료 기간이 없습니다. JWTs aud 및 exp 검사를 건너뜁니다. 비밀번호 재설정은 되돌릴 수 있습니다. FixVibe은 이를 active.auth-flow 결과로 플래그 지정합니다.

Why it happens: Supabase Auth, Clerk 및 유사한 서비스는 세션 상태를 처리하지만 해당 API에는 안전 모드와 안전하지 않은 모드가 있습니다. getSession()은 편리하지만 검증되지 않았습니다. LLM은 훈련 데이터에서 안전한 것보다 편리한 것 API을 더 자주 봅니다. 서버 측 토큰 검증은 추상적이며 명시적인 HTTP 헤더 또는 미들웨어 호출이 필요합니다.

Fix: 항상 supabase.auth.getUser() 서버측을 사용하세요. 보호된 경로에서는 getSession()을 신뢰하지 마세요. exp, aud 및 서명을 확인하여 모든 요청에 ​​대해 JWTs의 유효성을 검사합니다. 액세스 토큰의 경우 토큰 만료를 1시간으로 설정하고 더 긴 세션의 경우 새로 고침 토큰을 사용하세요.

격차 4: HTTP 보안 헤더 누락

Content-Security-Policy 없음, X-Frame-Options 없음, Strict-Transport-Security 없음, X-Content-Type-Options 없음. FixVibe은 이를 headers.security-headers 조사 결과로 표시합니다.

Why it happens: 보안 헤더는 배포 플랫폼별로 다릅니다. Cursor은 Next.js에 대한 코드를 생성합니다. CSP 설정에는 next.config.js 조정, 미들웨어 또는 vercel.json 재정의가 필요합니다. 이는 기본 프로젝트 스캐폴드에 없습니다. "헤더는 DevOps용"이라는 정신 모델이 여전히 일반적입니다.

Fix: next.config.js 또는 nonce를 지원하는 미들웨어: Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-...'; ...에서 CSP을 설정합니다. HSTS 추가: Strict-Transport-Security: max-age=31536000; includeSubDomains. 정적 호스트에는 Vercel의 vercel.json 헤더나 미들웨어를 사용하세요.

격차 5: 타사 통합 구성 오류

Stripe 키, Sentry 토큰, Anthropic API 키는 하드코딩되거나 저장소에 커밋됩니다. 분석 원본이 과도하게 허용됩니다. npm 종속성이 오래되었습니다. FixVibe 스캔은 이를 discovery.tech-fingerprint 및 비밀 검사기의 결과로 표시합니다.

Why it happens: 문서 및 튜토리얼에서 통합을 붙여넣습니다. LLM은 하드코딩된 값을 포함하여 패턴을 복사합니다. Env-var 규율은 CI/CD에서 명시적인 규율을 요구하며 LLM에서는 시행할 수 없습니다.

Fix: 모든 타사 자격 증명에 환경 변수를 사용합니다. 배포 플랫폼(Vercel, Netlify, Heroku 또는 Vault)에 비밀을 저장합니다. 매월 npm audit으로 npm 종속성을 감사합니다. 보안 업데이트가 제공되면 자동화된 PR을 위해 Sendabot 또는 Renovate를 사용하세요.

수정 패턴

이러한 격차를 해소하기 위해 처음부터 다시 구축할 필요는 없습니다. 패턴은 일관됩니다.

1. Audit: 라이브 앱에 대해 FixVibe을 실행합니다. 저장소 스캔의 경우 FixVibe GitHub 앱을 활성화하세요. 비밀, RLS, 인증, 헤더, 타사 등 결과를 수집합니다.
2. 강화: 높은 확신도의 결과를 수정하세요. RLS + FORCE를 활성화하세요. 시크릿을 환경 변수로 옮기세요. 미들웨어에 CSP와 HSTS를 설정하세요. 서버 측 인증 검증을 사용하세요. 코딩 에이전트 프롬프트는 코드/구성 변경이 적용되는 곳에서만 사용하고, DNS나 공급자 측 수정에는 오퍼레이터 단계를 따르세요.
3. Monitor: 확인된 도메인에 대해 일일 수동 검색 또는 주간 활성 검색을 예약합니다. Slack에 웹훅을 설정합니다. 모든 중요한 발견은 배송 후 몇 분 이내에 알림을 트리거해야 합니다.
4. 대응: 결과가 발견되면 수정 담당에 맞는 FixVibe 수정 액션을 복사하세요. 코드/구성 작업에는 코딩 에이전트 프롬프트를, DNS·공급자 콘솔·시크릿 교체·수동 검토에는 오퍼레이터 단계를 사용하세요. 다시 스캔하여 확인하세요.

필드가 향하는 곳

이러한 격차를 해소하는 것이 오늘날 팀의 과제입니다. 향후 2~3년 동안 프레임워크 및 도구의 더 나은 기본값(Next.js 미들웨어 자동CSP, Supabase RLS 기본값), IDE-time 보안 피드백(서비스 키를 클라이언트 구성 요소에 붙여넣을 때 경고하는 Cursor 제안), MCP- 기반 자동 수정(코딩 에이전트가 FixVibe 결과에 액세스할 수 있고 자율적으로 수정할 수 있음) 등이 변경됩니다. FixVibe의 공개 changelog은 어느 격차가 먼저 줄어들고 있는지 추적합니다.

다음 단계

출시 전 go/no-go 체크리스트는 Pre-launch SaaS security checklist을 참조하세요. 코드 조각과 실제 실패 패턴을 포함한 단계별 강화 연습을 보려면 How to secure an app built with AI coding tools을 읽어보세요.