소스코드에 남은 비밀번호와 API 키

소스코드에서 인증정보를 삭제해도 과거 이력과 복제본에 남을 수 있습니다. 노출된 정보의 권한을 확인하고 사용 차단과 교체를 우선해야 합니다.

사례로 보는 문제

가상의 사례입니다. 개발자가 서비스 API 키가 든 설정파일을 외부 저장소에 올렸다가 삭제했습니다. 그러나 이전 버전에는 키가 남아 있었고, 그 키로 서비스에 접근하는 것도 가능했습니다.

파일 삭제와 인증정보의 무효화를 구분합니다

Git은 변경이력을 보관하므로 최신 파일에서 지워도 과거 커밋이나 복제본에 남을 수 있습니다. 저장소를 비공개로 바꾸는 조치 역시 이미 복제된 정보나 키의 유효성을 해결하지 못합니다.

먼저 해당 값이 실제로 접근 권한을 부여하는 비밀정보인지, 어떤 서비스와 자료에 접근할 수 있는지 확인합니다. API 키라는 이름의 모든 값이 같은 수준의 비밀성이나 권한을 갖는 것은 아닙니다. 악용 가능한 인증정보는 신속히 폐기·교체하고 기존 값으로 접근이 차단됐는지 확인합니다. 서비스 영향이 있다면 전환 순서와 임시 제한을 함께 관리합니다.

노출 범위와 실제 사용을 나누어 조사합니다

키가 노출됐다는 사실과 실제 악용이 확인됐다는 사실을 구분합니다. 최초 노출 시점, 저장소 접근 범위와 인증·조회·다운로드 기록을 대조합니다. 로그가 없거나 불완전하면 미사용을 단정할 수 없습니다.

차단과 필요한 증거보존을 병행한 뒤 과거 이력·복제본·빌드 산출물의 잔존 및 추가 정리 필요성을 평가합니다. 이력 재작성은 공동 작업에 영향을 주므로 협의해 수행하고, 모든 외부 복제본이 삭제됐다고 가정하지 않습니다. 재발 방지를 위해 비밀정보 전용 관리수단과 커밋 전 탐지를 적용합니다.

실무에서 확인할 사항

  • 노출된 값의 유효성·권한·사용 대상
  • 최초 노출 시점과 공개·접근 범위
  • 폐기·교체 결과와 서비스 영향
  • 노출 기간 중 실제 사용기록과 로그 공백
  • 이력·복제본·자동 빌드 산출물 및 재발 방지 설정

기업 내 부정·비리, 디지털 데이터로 끝까지 규명합니다

상담 문의
전화문의