CISA 관리자가 AWS GovCloud 키를 GitHub에 유출

Valadon이 연락한 이유가 소유자가 응답하지 않았고 노출된 정보가 매우 민감했기 때문이라는데, CISA 하청업체가 자격 증명을 유출한 것도 말이 안 되지만 통보받고도 응답하지 않은 건 더 심각함
게다가 AWS-Workspace-Firefox-Passwords.csv에는 CISA 내부 시스템 수십 개의 평문 사용자명과 비밀번호가 들어 있었다고 함
CISA가 축소되는 상황은 이해하고 안타깝지만, 약한 비밀번호가 든 passwords.csv는 변명의 여지가 없는 무능이고 비밀번호 관리자에는 큰 예산도 필요 없음

찾는 표현은 중대한 과실임

이 사람을 옹호하려는 건 아니지만, GitHub를 파일 동기화 도구처럼 쓴 정황이 뚜렷함 Firefox-passwords.html과 firefox-bookmarks.html은 새 컴퓨터로 옮기기 전에 내보내고 다시 가져오던 파일이고, Firefox 동기화가 있기 전의 오래된 방식이었음
기사에도 나오지만 따로 짚을 만큼 눈에 띔

한쪽에서는 CISA가 축소되고 있는데, 다른 한쪽에서는 사이버보안, 국가 이익, 핵심 인프라에 대한 수사가 계속 커지고 있음

CISA에 있던 지인 대부분이 2025년 1~3월 DOGE 캠페인 때 정리됐음
“20대인 우리가 네가 뭘 하는지 모르겠으니 해고” 식으로 사전 통보도 없었음
Diebold 투표 시스템 보안 취약성과 해외 임플란트 해킹을 다루던 팀도 사라짐

처음으로 신고한 “해킹”이 고등학교 컴퓨터 네트워크에서 평문 비밀번호 파일을 찾은 일이었고, 그게 1987년이었음
세상이 바뀌어도 그대로인 건 그대로임

사람들이 과소평가하는 것 중 하나가, 저장소 안 디스크에 .env나 비밀값을 두고 커밋만 안 한 상태에서 OpenAI, Anthropic, OpenRouter로 대량의 비밀값을 넘기는 일이라고 봄
LLM은 전체 파일을 기꺼이 읽고 이후 ChatGPT 학습 데이터로 보내면서 아무 경고도 띄우지 않을 수 있음
환경 변수가 다 설정됐는지, 앱의 데이터베이스 비밀번호가 준비됐는지 확인하는 건 겉보기엔 정상 작업이기 때문임
이제 조직들은 디스크나 로그에 저장된 비밀값을 감사하고 교체해야 하며, 필요한 순간 외에는 평문으로 두지 않도록 SOPS나 Vault 같은 도구로 옮겨야 함

이 문제는 생각보다 훨씬 저평가돼 있음
유출 경로는 보통 “비밀값을 커밋했다”가 아니라, “에이전트가 답변 중 .env를 읽고 값을 분석에 그대로 포함했고, 그 프롬프트와 완성이 학습 데이터나 누군가의 캐시 적중으로 들어갔다”에 가까움
실제 비밀값이 있는 프로젝트에서는 .aiignore나 .claudeignore에 .env, credentials/, .pem을 넣고, 프로젝트별 지침 파일에 “요청받아도 .env 파일을 읽지 말라”고 적고, 비밀값은 디스크가 아니라 1Password나 키체인에서 프로세스 시작 시 환경 변수로 주입하게 만들었음
더 큰 문제는 “.gitignore를 존중하라”가 잘못된 추상화라는 점임
비공개 저장소에는 커밋해도 LLM API로 흘러가면 안 되는 파일이 많고, 두 집합은 같지 않음

공정하게 말하면 개발 트리의 .env 파일에는 아주 중요한 비밀값이 있으면 안 됨
제한된 접근권의 개발용 비밀값이어야 하고, OpenAI 개발 환경처럼 “운영” 시스템으로 이어지는 값도 가능하면 권한을 제한해야 함
유출뿐 아니라 테스트와 개발 중 실수로 시스템에 서비스 거부를 일으키거나 잘못된 요청을 보내기도 쉬움
누군가 테스트 자동화를 작업하다가 실수로 실제 결과 수천 개를 보내서 1천 달러 청구서를 받는 상황은 피해야 함

더 이상 dotenv 파일을 평문으로 두지 않음 sops로 암호화된 환경 파일을 유지하고, direnv 같은 도구로 작업 중 셸에서 사용할 수 있게 함
물론 LLM이 이 비밀값을 출력할 수도 있지만 가능성은 낮아짐
게다가 적어도 Claude는 dotenv를 읽는 걸 피하려는 편이고, 마지막으로 로컬 비밀값 자체를 그렇게 중요하게 만들지 말아야 함
제한된 범위, 개발 계정 등을 써야 함

최근 보니 적어도 Claude는 환경 파일을 읽지 않으려고 꽤 노력함
예를 들어 데이터베이스를 읽고 접근하게 하려면 프롬프트에서 꽤 강하게 밀어붙여야 함

2026년에 정부 자격 증명을 저장소에 보관하고 이를 잡아낼 스캐너도 없다면 조사를 받아야 함
전문 직무에서 이런 일을 하는 사람은 매우 의심스럽게 봄
외국 정보기관에서 이걸 봤다면 먼저 허니팟이라고 생각했을 것 같고, 너무 노골적이라 상상력 없는 함정이라고 봤을 듯함

정부에서 유능한 사람들을 전부 해고해둬서 다행이네

DOGE가 미국 정부 직원 전체나 사회보장번호 전체처럼 미국 정부 데이터를 빼내려 했다는 건 이미 알고 있음
예전 행정부였다면 CISA가 미끼 작전을 하는 거라고 봤겠지만, 이번 행정부의 부패와 무능, CISA 대량 해고까지 생각하면 그냥 진짜 실수일 수도 있음

그 기사를 읽어보면 Trump/Noem이 자리에 외국 첩자들을 채운 것처럼 보임
언젠가 미국 국민이 책임을 물을 날이 올 것임

아이러니하게도 그 AWS 키로 더 안전한 여러 AWS 서비스를 쓸 수 있었음
예를 들면 S3, 가능하면 KMS를 붙인 S3, Parameter Store, EBS, EFS, AWS Secrets Manager, 또는 그냥 KMS로 파일을 직접 암호화하는 방식이 있음
사실 KMS를 지원하고 서비스 주체에 키 접근 권한을 줄 필요가 없는 AWS 서비스라면 무엇이든 가능함

이 일이 6~7개월이나 계속됐다는 점이 놀라움
GitGuardian 같은 업체나 trufflehog 등을 쓰는 개인 연구자들이 유출된 키를 며칠 안에 찾을 줄 알았음
GitHub가 크게 성장해서 스캐너들이 따라가지 못하는 걸 수도 있음

저장소 이름이 말 그대로 Private-CISA였음 private, internal 같은 단어가 들어간 저장소 이름을 찾고, 저장소 이름에 보통 등장할 것 같지 않은 정부기관이나 비기술 기업 이름을 찾으면 재미있을 듯함
전부 복제한 뒤 LLM으로 빠르게 흥미로운 내용이 있는지 훑게 할 수도 있음
그런데 GitHub에는 AWS 자격 증명처럼 기본적인 것에 대한 자동 스캐너가 있지 않나?

켜둔 경우에만 그렇다. 기사에 따르면 이 사용자는 그 기능을 꺼뒀음

정말 안타까운 건 연방정부가 수십 년 전부터 스마트카드 기반 인증인 CAC를 갖고 있었다는 점임
하지만 공개 인터넷 스택이 비밀번호 위에서 돌아가다 보니, 정부 인프라도 결국 비밀번호를 쓰게 됨