.env 파일에 API 키를 넣고 Git에만 올리지 않으면 안전하다고 생각하기 쉽습니다. 하지만 AI 개발환경에서는 그보다 넓게 봐야 합니다. 키를 어디에 저장했는지뿐 아니라, 그 키에 접근할 수 있는 코드와 패키지가 무엇인지도 중요하기 때문입니다.
Microsoft는 23일 LiteLLM 1.107.0 공급망 공격을 상세히 분석했습니다. 공급망 공격은 개발자가 신뢰하는 라이브러리나 배포 경로에 악성 코드가 섞여 들어오는 방식입니다. 개발자는 평소처럼 pip install을 실행했을 뿐인데, 설치한 패키지 안에 예상하지 못한 코드가 포함될 수 있습니다.
가져오지 않은 라이브러리도 실행될 수 있습니다
이번 사례에서 특히 주의할 부분은 악성 패키지가 Python 시작 과정에서 실행될 수 있었다는 점입니다. 개발자가 LiteLLM을 코드에서 직접 import하지 않아도, 감염된 환경에서 Python을 실행하는 것만으로 악성 코드가 동작할 수 있었습니다.
즉, “이 라이브러리는 현재 기능에서 쓰지 않았으니 괜찮다”는 판단만으로는 부족합니다. 설치된 패키지가 어떤 방식으로 초기화되고, 실행 환경의 정보에 접근하는지를 함께 살펴봐야 합니다.
AI 개발환경에는 공격자가 찾는 정보가 많습니다
악성 코드는 환경 변수와 설정 파일에서 AI 키, 클라우드 인증 정보, Git 토큰, 데이터베이스 접속 정보 등을 찾을 수 있습니다. .env 파일은 이런 정보를 코드와 분리해 관리하는 데 유용하지만, 파일 자체가 비밀 정보를 보호해 주는 장치는 아닙니다.
AI 개발 서버에는 OpenAI나 Claude API 키뿐 아니라 AWS 키, GitHub 토큰, DB 비밀번호, Docker Registry 인증 정보, SSH 키 등이 함께 존재하기도 합니다. 하나의 키만 노출되는 문제가 아니라, 연결된 여러 시스템으로 접근 범위가 넓어질 수 있다는 뜻입니다.
개발용 서버도 운영 환경처럼 다뤄야 합니다
개발 환경은 운영 서버보다 보안이 느슨해지기 쉽습니다. 테스트용이라는 이유로 권한이 넓은 토큰을 두거나, 여러 사람의 편의를 위해 인증 정보를 오래 유지하는 경우도 있습니다. 그러나 AI 기능을 개발하고 배포하는 서버는 오히려 다양한 Credential이 모이는 장소가 될 수 있습니다.
CI/CD 환경도 마찬가지입니다. 빌드와 배포를 위해 저장소, 클라우드, 컨테이너 레지스트리에 접근할 권한을 갖기 때문입니다. 개발용이라는 이유만으로 보호 수준을 낮추기보다, 실제로 어떤 비밀 정보가 있고 어떤 권한까지 연결되는지 확인하는 편이 현실적입니다.
.env 관리에서 한 단계 더 확인할 부분
비밀 정보를 코드 저장소에 올리지 않는 것은 기본입니다. 여기에 설치하는 패키지의 출처와 버전을 확인하고, 토큰에는 필요한 범위만 권한을 부여하며, 더 이상 쓰지 않는 키는 정리하는 관리가 필요합니다. 의심스러운 패키지 설치나 환경 노출 가능성이 있었다면 관련 키를 교체하는 판단도 늦추지 않는 편이 좋습니다.
.env는 Secret을 담는 장소일 뿐입니다. AI 시대의 보안은 “파일에 숨겨 두었는가”보다 “그 파일을 읽을 수 있는 환경과 코드가 얼마나 믿을 만한가”를 점검하는 데서 시작됩니다.
