2025 DBIR로 본 자격증명 악용과 타사 연동 위험

2026년 10월 3일 수정. 기존 글은 독자가 확인할 수 없는 Cremit 보고서의 발간을 소개했습니다. 여기서는 Verizon이 공개한 2025년 Data Breach Investigations Report(DBIR)의 수치와, 이를 자격증명 관리에 적용할 때 살펴볼 점을 정리합니다.

2025년 DBIR이 집계한 것

Verizon은 보안 사고 2만 2천 건 이상을 분석했고, 이 가운데 확인된 침해 사고는 1만 2,195건입니다. 침해의 초기 진입 경로 중 자격증명 악용은 22%, 취약점 악용은 20%였습니다. 제3자가 연루된 침해 비율은 두 배로 늘어 30%에 달했습니다. ‘2025년 보고서’지만 분석 대상 사고 기간은 2023년 11월부터 2024년 10월까지입니다.

이 비율은 Verizon이 수집한 침해 사례를 설명합니다. 비인간 신원이나 노출된 API 키만 따로 측정한 수치는 아니며, 특정 탐지 도구의 성능을 뜻하지도 않습니다. 직원 계정 암호와 서비스 토큰 모두 자격증명 악용에 쓰일 수 있지만, 모든 사례를 NHI 사고로 해석해서는 안 됩니다.

자격증명 관리를 어디서 시작할까

운영 시스템에 접근하는 타사 연동과 서비스 계정을 나열해 보세요. 각 항목에 담당자, 발급 서비스, 권한, 만료일, 저장 위치를 기록합니다. 특히 타사 연동은 프로젝트가 끝난 뒤에도 접근 권한이 남아 있을 수 있으므로 별도로 점검해야 합니다.

먼저 새 노출을 막습니다. 적절한 시크릿 관리 도구에 키를 보관하고, 가능하면 단기 자격증명을 사용하며, CI 워크플로 권한을 줄입니다. Git 제공자의 시크릿 검사와 푸시 차단 기능도 켜 두세요. GitHub는 검사 대상 저장소와 푸시 차단의 한계를 문서로 공개하므로 현재 요금제와 설정에서 실제 적용 범위를 확인해야 합니다.

그다음 과거 커밋, 협업 메시지, 문서, 저장 공간, 컨테이너 이미지처럼 예방 단계에서 놓친 곳을 살핍니다. Cremit Platform은 지원하는 연결 소스에서 자격증명을 찾고 일부 유형은 발급 서비스에 유효성을 확인할 수 있습니다. 연결하지 않은 소스는 검사할 수 없고, 탐지 결과만으로 공격자의 사용 여부를 단정할 수도 없습니다.

아직 작동하는 키를 찾았다면

담당자와 영향받는 시스템을 확인한 뒤 발급 서비스에서 키를 교체하거나 폐기하세요. 제공자의 접근 로그로 수상한 사용이 있었는지도 조사합니다. 저장소에서 키를 삭제해도 이미 유출된 키가 무효화되지는 않습니다. 새 키를 발급하기 전에 유출 경로를 막고 조치 내역을 남겨야 합니다.

2025년 DBIR은 자격증명과 타사 접근을 점검할 근거가 됩니다. 다만 우리 조직의 실제 신원 목록과 사고 대응 연습을 대신하지는 않습니다.

출처

Verizon, 2025 DBIR 발표: https://www.verizon.com/about/news/2025-data-breach-investigations-report

Verizon, DBIR 보고서 설명과 분석 기간: https://www.verizon.com/business/resources/reports/

GitHub 문서, 시크릿 검사 범위: https://docs.github.com/en/code-security/reference/secret-security/secret-scanning-scope

GitHub 문서, 푸시 차단 설정: https://docs.github.com/en/code-security/how-tos/secure-your-secrets/prevent-future-leaks/enable-push-protection