테스트 결과
첫 번째 스크립트인 token_check.py는 세션 토큰을 서명하는 함수와 "사용 가능한 예시"를 포함해 달라는 프롬프트를 통해 생성되었습니다. 코드를 즉시 실행할 수 있도록 만들기 위해, 모델은 소스 파일에 HMAC 서명 키를 직접 삽입했습니다.
- 문제점: 비밀 키가 코드베이스에 존재함.
- 위험성: 저장소에 읽기 권한이 있는 누구나 키를 볼 수 있으며, 해당 파일을 가져오는 모든 배포 환경이 비밀 정보를 상속받게 됨.
- 결과: 키를 획득한 공격자는 유효한 세션 토큰을 위조하여 인증 확인을 우회할 수 있음.
두 번째 스크립트인 email_sender.py는 SMTP를 통해 이메일을 보내는 함수를 요청한 결과물입니다. 모델은 예시가 즉시 작동하도록 다시 한번 실제 비밀번호를 제공했습니다.
- 문제점: 함수 호출 시 비밀번호가 평문 문자열로 나타남.
- 위험성: 비밀번호를 교체하려면 코드 변경과 새로운 배포가 필요하며, 자격 증명이 해당 파일을 사용하는 모든 환경으로 확산됨.
- 결과: 소스 제어, 로그 또는 컴파일된 패키지에서 비밀번호가 탈취될 수 있으며, 공격자가 메일 서버에 무단으로 접근할 수 있게 됨.
AI가 비밀 정보를 출력하는 이유
대규모 언어 모델은 프롬프트를 완성함으로써 텍스트를 생성합니다. 사용자가 "사용 가능한 예시"를 요청하면, 모델은 이를 "추가 설정 없이 실행되는 코드"로 해석합니다. 따라서 API 키, 비밀번호, 토큰과 같은 누락된 값을 그럴듯한 플레이스홀더(placeholder)로 채워 넣습니다. 프롬프트에서 명시적으로 언급하지 않는 한, 모델은 비밀 정보 관리(secret-management)의 모범 사례를 인지하지 못합니다.
최근 Veracode의 AI 생성 코드 분석에 따르면, 코드 조각의 45%가 OWASP Top 10에 나열된 취약점을 적어도 하나 이상 포함하고 있었으며, 자격 증명 노출이 상당한 비중을 차지했습니다. 이 통계는 이 문제가 소수의 예외적인 사례가 아니라, 모델의 학습 및 프롬프트 방식에서 발생하는 구조적인 부산물임을 강조합니다.
개발자가 지금 바로 취할 수 있는 완화 조치
가장 간단한 방어책은 코드 파일 자체에 비밀 정보를 남기지 않는 것입니다. 환경 변수는 가장 일반적이고 언어에 구애받지 않는 방법입니다.
# token_check.py – secure version
import os
import hmac
import hashlib
SECRET_KEY = os.environ["HMAC_SECRET_KEY"]
def sign_token(data: bytes) -> str:
return hmac.new(SECRET_KEY.encode(), data, hashlib.sha256).hexdigest()
# email_sender.py – secure version
import os
import smtplib
smtp_password = os.environ["SMTP_PASSWORD"]
server = smtplib.SMTP("smtp.example.com", 587)
server.starttls()
server.login("noreply@example.com", smtp_password)
os.environ을 사용하면 런타임 환경에서 값을 가져오므로, 버전 관리에 포함되지 않으며 소스 파일을 수정하지 않고도 비밀 정보를 교체할 수 있습니다. 동일한 패턴은 커밋에서 제외된 설정 파일, 비밀 정보 관리 서비스 또는 컨테이너 오케스트레이션 비밀 정보 관리와도 함께 사용할 수 있습니다.
추가적인 안전장치
- 코드 리뷰: 일반적인 비밀 정보 패턴(예: 긴 영문 숫자 조합)과 일치하는 리터럴 문자열을 찾아내는 리뷰 과정.
- 정적 분석 도구: 새로 추가된 파일에서 하드코딩된 자격 증명을 감지하도록 조정된 도구.
- 프롬프트 엔지니어링: 모델에게 "모든 비밀 정보에 환경 변수를 사용하라" 또는 "실제 자격 증명은 생략하라"고 명시적으로 요청.
- 생성 후 린팅(Post-generation linting): 코드를 프로젝트에 복사하기 전에 의심스러운 리터럴을 검색하는 간단한 스크립트 실행.
반론: 그렇다면 AI 코드는 안전하지 않은가?
하드코딩된 비밀 정보가 존재한다고 해서 AI 생성 코드가 보편적으로 보안에 취약하다는 의미는 아닙니다. 많은 경우, 모델은 개발 속도를 높일 수 있는 깔끔하고 잘 구조화된 로직을 생성합니다. 위험은 개발자가 보안 감사 없이 출력을 즉시 운영 환경에 적용할 수 있는 상태로 취급할 때 발생합니다. AI를 보안 관행을 대체하는 수단이 아닌, 초안 작성 보조 도구로 취급하십시오.
향후 주목해야 할 사항
- 도구 업데이트: AI 플랫폼은 비밀 정보를 플레이스홀더로 대체하는 안전 필터를 통합하기 시작했습니다. 이러한 변화를 모니터링하면 노출 위험을 줄일 수 있습니다.
- 정책 변화: 조직은 AI 지원 코딩에 대한 가이드라인을 공식화하여, CI 파이프라인의 일부로 비밀 정보 관리 점검을 의무화할 수 있습니다.
- 커뮤니티 패턴: 개발자들이 더 많은 "보안 프롬프트"를 공유함에 따라, 토큰 서명이나 이메일 전송과 같은 일반적인 작업에 대해 모범 사례 템플릿이 기본 출력값이 될 수 있습니다.
핵심 요약: AI는 몇 초 만에 실행 가능한 코드를 생성할 수 있지만, 개발자가 비밀 정보 관리(secret-management) 원칙을 철저히 준수하지 않는다면 그 편리함에는 시스템 전체를 위협할 수 있는 자격 증명 노출이라는 숨겨진 비용이 따릅니다. 모든 코드 스니펫을 초안으로 간주하고, 코드 내의 실제 비밀 정보를 제거한 뒤, 커밋하기 전에 환경 변수나 전용 볼트(vault)를 통해 이를 주입하십시오.