저장소에서 키를 삭제해도 이미 복사된 값이 유효하다면 대응이 끝난 것이 아닙니다. 비밀값 소유자와 provider를 확인하고 키를 폐기하거나 교체한 뒤, 종속 서비스를 새 값으로 전환하고 노출 기간의 사용 기록을 점검해야 합니다.
GitHub의 공식 leaked secret 대응 지침도 파일 삭제만으로 악용을 막을 수 없다고 설명합니다. 저장소 이력 정리는 자격 증명 폐기와 별도이며, 협업·보존·준수 영향이 있으므로 승인 없이 파괴적 이력 수정을 하지 않습니다.
파일을 지워도 이미 복사된 키는 계속 유효할 수 있습니다
저장소의 최신 파일에서 API key를 지워도 이전 commit, 빌드 산출물, 로그, fork나 사람이 복사한 값까지 자동 삭제되지는 않습니다. GitHub 공식 가이드는 secret이 노출되면 즉시 침해된 것으로 간주하고 provider에서 revoke하라고 권고합니다. 키가 공개돼 있었거나 production credential이라면 위험을 높게 평가하고, 소유자·보안 담당자와 사용 중단 및 교체 순서를 신속히 정합니다.
다운타임 가능성이 있다고 예전 키를 계속 유효한 채 방치하는 것이 기본 해답은 아닙니다. GitHub 가이드는 상황에 따라 새 값을 먼저 발급해 서비스가 새 값으로 전환한 뒤 폐기하는 접근을 언급합니다. 고위험 키는 즉시 revoke가 우선일 수 있으므로 provider 기능, 위험도, 종속 서비스 영향과 사고 책임자를 함께 판단합니다. 모든 값은 예시에서 [REDACTED]로 가리며 비밀값 자체를 저장하거나 공유하지 않습니다.
창작 대응표에서 남은 공백을 찾습니다
| 항목 | 창작 현황 | 필요한 다음 확인 |
|---|---|---|
| 저장소 파일 | config.sample에서 [REDACTED]로 교체 | 제거가 old key를 무효화하지 않는다는 점을 분리 기록 |
| provider 상태 | EDU-KEY-01이 active로 표시됨 | 소유자와 provider가 허용한 절차로 revoke·재발급 계획 수립 |
| 서비스 종속성 | 보고서 앱과 주간 작업이 같은 key를 참조 | 새 key로 앱·작업을 전환하고 정상 동작 검증 |
| 사용 흔적 | 노출 기간의 audit log를 아직 확인하지 않음 | 정상 principal·source·시간과 다른 사용을 provider 로그에서 검토 |
| 저장소 이력 | 오래된 commit에 값이 남았을 가능성 | 증거 보존·협업자 영향·승인을 검토한 별도 정리 계획 |
GitHub 가이드는 영향을 받는 앱과 통합을 확인하고 새 credential로 업데이트한 뒤 서비스가 동작하는지 검증하고, 노출 기간의 무단 접근 기록도 살피도록 안내합니다. 무단 사용 검토는 파일 검색만으로 끝나지 않습니다. provider의 audit log에서 키가 사용된 시각·principal·허용 범위를 확인하고, 기대했던 서비스 동작과 대조합니다. secret scanning에서 ‘inactive’로 보이는 값도 provider가 유효성을 판단하는 가장 직접적인 출처인지 확인합니다.
폐기부터 검증까지 순서대로 추적합니다
- 실제 비밀값을 복사하지 말고 secret 유형·provider·소유자·노출 위치·기간을 식별합니다.
- 노출 범위와 키 권한, 공개 여부, 최근 사용·감사 기록을 바탕으로 위험과 서비스 중단 영향을 평가합니다.
- 소유자와 provider가 승인한 계획에 따라 구 키를 revoke하거나, 즉시 중단이 불가하면 새 키 발급·서비스 전환·구 키 폐기 시점을 조정합니다.
- 모든 종속 앱·배치·통합이 새 값으로 바뀌었는지 확인하고 기능을 시험합니다. 노출된 이전 키가 더 이상 승인 요청에서 통하지 않는지도 검증합니다.
- 노출 기간의 provider audit log와 애플리케이션 기록을 검토해 비정상 사용 여부 또는 확인 불가 사유를 남깁니다.
- 저장소 파일·캐시·산출물 사본을 검토합니다. commit history 정리는 force push와 협업자 영향이 있을 수 있으므로 security lead 승인을 별도로 받습니다.
- 조치자·시각·상태·남은 미확인 점을 기록하고 secret 값은 보고서·이슈에 쓰지 않습니다.
폐기·새 값 전환·이력 정리는 서로 다른 완료 조건입니다
새 key를 발급해 앱이 작동한다고 해도 예전 key가 여전히 유효하면 노출 대응이 끝난 것은 아닙니다. 반대로 provider에서 예전 값을 취소했어도 앱이 새 값을 받지 못해 장애가 나면 복구와 교체 검증이 남아 있습니다. repository history에서 사본을 제거하는 작업은 credential의 효력을 바꾸지 않고 협업 상태를 건드릴 수 있습니다. 각 완료 조건을 별도 상태로 남깁니다.
복습: 파일에서 지운 것만으로 안전한가요?
문제: 최신 파일에서는 EDU-KEY-01을 삭제했지만 provider 화면에는 active로 보입니다. 무엇이 아직 남아 있나요?
정답: key는 여전히 유효할 수 있으므로 provider 폐기·새 값 전환, 종속 앱 검증, 노출 기간 audit log 확인이 남아 있습니다. 저장소 이력 정리는 별도 승인 작업입니다.
정답을 가리고 확인해 보세요
이 글을 위해 만든 학습 예시이며 공식 기출문제나 판매 카드의 인용이 아닙니다.
가상 API key를 최신 파일에서 제거했고 app A·배치 B는 새 값으로 바꿔 테스트했습니다. Provider에는 예전 EDU-KEY-01이 active로 표시되고 audit log도 아직 검토하지 않았습니다. 남은 핵심 조치 두 가지를 쓰세요.
정답과 해설 확인
provider 승인 절차로 예전 key를 revoke하고, 노출 기간 provider audit log에서 비정상 사용을 조사합니다. 저장소 이력 정리는 증거 보존·협업 영향 승인을 받은 별도 작업으로 둡니다.파일 삭제와 새 값 전환은 이전 credential을 무효화하거나 과거 사용 여부를 밝히지 않습니다. Provider 폐기와 감사가 별도로 필요합니다.