GitHub 비밀 스캔 경보 누락 막기: 11월 12일 전에 바꿀 로그 필터

자료형은 그대로지만 기업 표시 이름이 slug로 바뀐다

GitHub의 10월 20일 변경 안내에 따르면, 11월 12일부터 영향받는 감사 이벤트의 business 값이 enterprise 표시 이름에서 slug로 바뀐다. 자료형은 문자열로 유지되고 이벤트 이름과 숫자 business_id는 바뀌지 않는다.

GitHub는 기존 표시 이름을 기준으로 필터링하는 연동을 전환 전에 수정하라고 권고한다. 선택지는 두 형식을 모두 수용하거나 business_id를 사용하는 것이다. 문자열인지 확인하는 검사만으로는 값의 의미가 바뀐 문제를 잡기 어렵다.

비밀 탐지 경보와 푸시 보호 우회 로그가 대상이다

공지가 지정한 범위는 secret_scanning_alert.* 계열 중 영향받는 이벤트와 secret_scanning_push_protection.bypass다. 모든 GitHub 감사 이벤트의 필드가 일괄 변경된다는 발표는 아니다.

공식 이벤트 목록에서 secret_scanning_alert.create는 비밀을 탐지해 경보를 생성한 사건이다. secret_scanning_alert.resolve는 경보가 해결된 사건이며, secret_scanning_push_protection.bypass는 사용자가 비밀 탐지에 따른 푸시 보호를 우회했을 때 발생한다.

이 이벤트들은 발생 사실만 저장하는 데 그치지 않고 기업별 대시보드나 보안팀 알림에 쓰일 수 있다. 실제 연동이 어떤 이벤트와 필드를 읽는지부터 목록으로 잡아야 수정 범위를 좁힐 수 있다.

로그가 들어와도 기존 이름 필터에는 걸리지 않을 수 있다

다음은 실제 기업 로그가 아닌 가상 예시다. 한 기업의 표시 이름이 Dima Example, slug가 dima-example, 숫자 ID가 9001이라고 가정한다.

외부 보안 시스템이 첫 번째 이름과 정확히 일치하는 로그만 고른다면 새 형식은 그 조건을 통과하지 못한다. 수집기는 정상 응답을 받고 저장소에도 이벤트가 남지만, 해당 기업의 경보 화면에서는 사라진 것처럼 보일 수 있다.

이 사례에서 숫자 ID를 연결 기준으로 삼으면 표시 이름의 변화와 기업 식별을 분리할 수 있다. 화면에 보여줄 이름은 별도로 유지하고, 조회·분류에 사용하는 값과 같은 역할로 취급하지 않는 편이 관리하기 쉽다.

파서, 필터, 경보 전달을 차례로 점검한다

운영팀이 준비할 수 있는 검증은 세 단계다. 먼저 현재 저장한 대상 이벤트에서 실제 필드 값을 확인한다. 다음으로 가상 예시처럼 이전·새 이름을 가진 표본을 각각 만들고 같은 기업으로 분류되는지 본다. 마지막으로 다른 기업 ID를 넣은 표본이 잘못 통과하지 않는지도 확인한다.

파서가 JSON을 읽는 데 성공했다는 결과만 남겨서는 부족하다. 기업별 검색 결과, 경보 생성 여부, 알림을 받을 팀까지 이어서 봐야 한다. 실제 비밀값을 새로 커밋할 필요 없이 연동의 테스트 입력으로 이 조건을 점검할 수 있다.

GitHub의 감사 로그 접근 문서는 웹 화면, JSON·CSV 내보내기, REST API, 외부 스트리밍을 구분한다. 각 방법이 노출하는 데이터 범위는 다르므로 현재 연동이 실제로 쓰는 경로에서 표본을 확보해야 한다. 스트리밍은 켠 이후의 활동만 수집하며 과거 기록을 소급해 채우지 않는다.

11월 전환 준비는 수집 성공 표시에서 끝나지 않는다. 같은 기업의 이전·새 형식이 같은 경보 흐름으로 도착하는지 확인해야 한다.

자주 묻는 질문