공개 전 저장소에서 비밀키를 찾는 보안 체크리스트

공개 버튼을 누르기 직전에 발견했다

사이드 프로젝트 저장소를 공개로 바꾸기 전 git log -p를 훑다가 테스트용 API 토큰이 오래된 커밋에 남아 있는 것을 찾았다. 현재 파일에서는 지웠기 때문에 검색 결과만 보면 안전해 보였지만, Git 객체에는 여전히 값이 있었다. 토큰을 지우는 커밋만 추가하고 끝낼 일이 아니었다.

우선 해당 자격 증명을 폐기하고, 저장소의 현재 파일과 이력을 각각 검사했다.

git grep -n -I -E '(API_KEY|SECRET|TOKEN|PASSWORD)' -- ':!*.lock'
git log --all -p -- .env .env.* config/ || true

공개 전 순서

1. 키를 먼저 revoke/rotate한다. 삭제 커밋보다 이 순서가 앞이다.
2. .env*를 무조건 무시하지 말고 필요한 예제 파일만 남긴다. .env.example에는 값 대신 설명을 쓴다.
3. 전체 Git 이력과 태그를 검사한다.
4. CI 로그와 이슈·문서에 복사된 값도 찾는다.
5. 공개 후에는 새 클론에서 애플리케이션이 비밀값 없이도 안전하게 실패하는지 확인한다.

GitHub에 올리기 전 로컬에서 secret scanner를 실행하는 것도 유용하다. 도구의 탐지 결과를 맹신하지 않고, 오탐은 allowlist로 좁게 관리한다.

python3 -m pip install --user detect-secrets
detect-secrets scan --all-files > .secrets.baseline
detect-secrets audit .secrets.baseline

비밀값이 이미 이력에 들어갔다면 단순 삭제는 충분하지 않다. 팀에서 사용하는 호스팅 서비스의 이력 정리 절차를 따르고, force push 전에 다른 작업자의 브랜치와 태그 영향을 확인한다. 작은 저장소라도 백업과 공지를 남긴 뒤 진행한다.

내가 남긴 공개 체크리스트

• 클라우드·DB·외부 API 키를 회전했는가
• .gitignore와 실제 추적 파일을 함께 확인했는가
• 커밋·태그·브랜치 이력을 검사했는가
• CI 변수와 로그에 값이 노출되지 않는가
• README의 예시가 작동 가능한 가짜 값인가
• 앱이 환경 변수 누락을 조용히 기본값으로 대체하지 않는가

마무리 기준

“현재 파일에 키가 없다”는 공개 조건의 일부일 뿐이다. 나는 이제 공개 직전에 검색 한 번을 하는 대신, 키 폐기 → 이력 검사 → CI 검사 → 새 클론 실행을 한 묶음으로 본다. 특히 테스트 토큰도 실제 권한이 있다면 개발용이라는 이유로 예외를 두지 않는다.