1. 하드코딩된 시크릿·API 키

AI 코딩 어시스턴트는 일단 동작하는 코드를 빠르게 내놓는 데 최적화되어 있습니다. 그 과정에서 예시 API 키, 테스트용 DB 접속 정보, 샘플 JWT 시크릿이 코드 안에 그대로 남는 경우가 생깁니다.

엔키화이트햇이 수행한 레드팀 프로젝트에서도 비슷한 사례가 있었습니다. 모 기업 사내 코드 저장소에 그대로 저장돼 있던 API_KEY와 일부 시스템 계정의 크레덴셜 정보를 수집해, 내부 확산에 활용된 사례가 있었습니다. 이는 '화이트해커가 가장 많이 쓰는 공격 루트 TOP 5' 중 2위인 공급망 공격과 연결됩니다. 저장소 하나에 남은 토큰이 빌드 파이프라인 전체를 장악할 수 있는 열쇠가 되는 구조이지요.

해외 조사에서도 AI 어시스턴트가 관여한 커밋의 시크릿 누출률이 사람이 단독으로 쓴 커밋의 약 두 배 수준으로 보고되고 있고(Apiiro — 4x Velocity, 10x Vulnerabilities), 2025년 한 해에만 퍼블릭 깃허브에 새로 노출된 시크릿 규모 역시 계속 증가하고 있는 현황입니다. (GitGuardian — State of Secrets Sprawl 2026)

이러한 흐름에 따라 사내에서 할 수 있는 대응은 다음과 같습니다.

대응방법

• Git 히스토리 전 구간을 대상으로 시크릿 스캐너(gitleaks, trufflehog 등) 정기 실행

• .env, secrets.yaml 같은 파일은 시크릿 매니저(AWS Secrets Manager, HashiCorp Vault 등)로 이관

• 정적 분석(SAST) 파이프라인에 ‘하드코딩된 자격증명’ 룰 활성화

• 저장소에 공개적으로 게시된 크레덴셜 및 API key는 폐기 처리

• pre-commit 훅으로 민감 문자열이 커밋되기 전에 차단

2. 구버전 라이브러리·종속성

AI 코딩 어시스턴트는 학습 시점 기준의 라이브러리 버전을 기본값으로 추천하는 경향이 있습니다. 어시스턴트 추천을 그대로 적용하는 개발자라면, 수개월에서 1년 전 버전이 package.json이나 requirements.txt에 자연스럽게 자리 잡게 됩니다. 이는 TOP 5 공격 루트 4위인 1-day 취약점의 대표적 원인입니다. 이미 패치가 나왔고 CVE 번호까지 붙은 취약점이지만, 우리 팀만 업데이트하지 않은 상태로 남아 있는 상황입니다. 이전 레드팀 사례에서는 한 SaaS 제품의 AI 추천 템플릿이 CVE가 공개된 버전의 인증 라이브러리를 기본값으로 심어둔 경우도 확인됐습니다.

대응방법

• SBOM(Software Bill of Materials) 생성으로 어떤 버전이 배포되고 있는지 가시성 확보

• npm audit, pip-audit, osv-scanner를 CI 파이프라인 기본 루틴으로 추가

• Dependabot, Renovate 같은 자동 업데이트 도구 활용

• AI 어시스턴트가 제안한 종속성은 코드 리뷰 과정에서 버전 재검토

다만 최근에는 npm, PyPI 생태계를 노린 공급망 공격도 함께 증가하고 있습니다. 실제로 정상 패키지와 유사한 이름의 악성 패키지나, 탈취된 유지보수 계정을 통한 악성 업데이트 사례도 지속적으로 보고되고 있습니다. 최근 TeamPCP 공급망 공격 사례에서는 CI/CD 토큰 탈취와 오픈소스 패키지 업데이트 체인을 악용해, 자동화된 개발 환경 자체를 공격 경로로 활용하기도 했습니다. 이 때문에 자동 업데이트 도구 역시 "자동 반영" 자체보다, 신뢰 가능한 패키지 여부와 변경 내용을 함께 검증하는 운영 체계 안에서 사용하는 것이 중요합니다.

3. 불완전한 인증·권한 처리

AI가 생성하는 인증 및 인가 코드는 표준적인 케이스에는 잘 동작합니다. 로그인, 토큰 발급, 기본적인 역할 검사까지는 깔끔하게 나오죠. 문제는 엣지 케이스입니다. 엔키화이트햇이 OFFen PTaaS를 통해 반복적으로 확인한 패턴은 다음과 같습니다.

• JWT 만료 검증 로직이 누락되어 폐기된 토큰으로도 접근 가능한 엔드포인트

• IDOR(Insecure Direct Object Reference): 객체 ID만 바꾸면 다른 사용자 데이터가 노출되는 라우트

• 권한 체크가 프론트에만 적용되고 백엔드 라우트에서는 생략된 케이스

• 관리자 API와 일반 사용자 API가 같은 핸들러를 공유하면서 분기 처리가 빠진 경우

이 영역은 자동화 도구가 유독 잘 잡지 못합니다. 인가 호출은 코드에 들어 있지만 런타임에 실제로 강제되지 않는 구조인 경우가 많아, 정적 분석(SAST)에서 걸리지 않는 경우가 많습니다. 동적 분석(DAST)도 객체 ID를 바꿔가며 남의 자원을 요청하거나 프론트가 막아둔 입력을 우회해 서버만 직접 찌르는 시나리오는 돌리기 어렵고요. 공격자 관점에서 직접 로직을 봐야만 드러나는 영역입니다.

대응방법

• 인증·인가 로직은 코드 리뷰 필수 체크 항목으로 지정합니다. 그뿐만 아니라, 인가되지 않은 요청이 실제로 차단되는지 직접 확인해야 합니다.

• 새로 추가된 API나 라우트가 인증 없이 공개되어 있는지 함께 점검합니다. AI가 만든 코드에서는 권한 검증이 누락되거나, 테스트용 엔드포인트가 그대로 남는 경우가 있기 때문입니다.

• 배포 전 단위 테스트와 통합 테스트로 인증·인가 로직이 의도대로 동작하는지 확인합니다. 기능의 정상 동작 여부 뿐만 아니라, 권한이 없는 상황에서의 접근, 다른 사용자의 리소스 요청과 같은 정상적이지 않은 상황에 대해서도 함께 테스트해야 합니다.

• 자동 모의해킹 시나리오를 반복 실행해, 새로 추가된 API나 변경된 권한 로직에서 같은 문제가 다시 생기지 않는지 점검합니다.

• 분기 1회 이상, 또는 인증·인가 시스템에 변경 사항이 있을 경우엔 외부 PTaaS로 엣지 케이스를 검증합니다. 객체 ID 조작, 권한 우회처럼 자동화 도구가 놓치기 쉬운 패턴은 공격자 관점에서 직접 확인해야 합니다.