GitHub가 10월 5일 비밀 탐지(secret scanning) 대상에 새 유형 다섯 가지를 추가했다. 비밀 탐지는 저장소에 커밋된 API 키 같은 자격 증명을 찾아내는 기능이다.
추가된 유형은 lovable_api_key, logfire_token, pydantic_ai_gateway_api_key, supabase_oauth_access_token, supabase_scoped_personal_access_token이다.
Lovable Labs는 비밀 탐지 파트너 프로그램에도 합류했다. 공개 저장소에서 lovable_api_key가 발견되면 GitHub가 Lovable에 전달해 폐기나 교체를 할 수 있게 한다.
자격 증명을 식별하는 것과 대응할 수 있는 곳으로 알리는 것은 연결돼 있지만 같은 변화가 아니다. 모든 토큰에 같은 보호가 적용된다는 뜻은 아니다.
저장소 알림, 파트너 알림, 패턴별 기능
GitHub는 알림을 두 경로로 나눈다. User 유형은 공개·비공개 저장소에서 발견될 때 저장소 사용자에게 비밀 탐지 알림을 만들고, Partner 유형은 공개 저장소에서 발견될 때 발급업체에 자동 보고된다.
문서에 따르면 파트너 알림은 발급업체에 직접 보내지며 저장소의 Security and quality 탭에는 나타나지 않는다.
지원표는 푸시 보호와 유효성 검사를 패턴별로 따로 표시한다. 이번 다섯 유형은 모두 푸시 보호와 유효성 검사가 없음으로 표시돼 있다.
지원표에서 logfire_token과 pydantic_ai_gateway_api_key는 공개 저장소 항목에 표시되지 않고, GitHub Advanced Security를 쓰는 비공개 저장소 항목에만 표시된다.
파트너 전달은 발급업체가 대응할 기회를 주는 경로다. 자동 폐기를 보장한다는 뜻은 아니다.
토큰 유형과 대응 경로의 조합
탐지 유형의 개수로는 답할 수 없는 운영 질문이 남는다. 누가 사고를 보고, 누가 노출된 자격 증명을 무효화할 수 있는가.
저장소 관리자는 코드 정리를 맡고 서비스 계정은 다른 팀이 관리하는 경우가 흔하다. 제공업체 통지는 유용하지만 조직의 사고 기록을 대신하지 않는다.
반대로 저장소 화면이 조용하다는 사실만으로 제공업체에 알림이 가지 않았다고 판단할 수도 없다. 검토 단위는 제품 이름이 아니라 토큰 유형과 대응 경로의 조합이다.
실제 쓰는 자격 증명 목록에서 출발하는 점검
점검은 애플리케이션이 실제로 쓰는 자격 증명 유형 목록에서 출발하는 것이 효율적이다. 그 식별자를 현재 지원표와 저장소에서 켠 기능에 대조한다.
알림 조사, 유출 자격 증명의 폐기·교체, 의존 서비스 갱신을 맡을 사람이나 팀을 기록해 둔다.
이는 권장하는 운영 점검이며 고객 계정에서 검증한 절차가 아니다. 책임 배정을 확인하려고 실제 자격 증명을 커밋할 이유는 없다.
허가된 범위에서의 통제 검증
통제된 검증이 필요하다면 제공업체가 승인한 더미·테스트 자격 증명과 명시적으로 허가된 테스트 저장소만 쓰는 것이 원칙이다.
기대하는 관측을 먼저 정한다. 로컬 차단, 저장소 알림, 발급업체의 대응은 서로 다른 결과이고, 하나를 입증한 시험이 다른 것까지 입증하지는 않는다.
증거에 쓸 수 있는 비밀을 남기지 않는다. 시험 커밋을 지워도 실제 자격 증명이 공개됐던 사실은 취소되지 않는다.
주의할 점: 인식 범위 확대와 검증하지 않은 부분
이번 출시의 직접적인 이점은 인식 범위의 확대이며, 사고 처리 절차가 완성됐다는 뜻은 아니다.
이 기사는 발표와 문서를 검토했을 뿐 탐지, 비공개 저장소 이용 자격, 제공업체 대응을 시험하지 않았다. 다섯 유형의 개별 기능도 직접 실행해 검증하지 않았다.
새 탐지 유형이 알려 주는 것은 비밀을 찾을 수 있다는 사실까지이고, 그 알림을 누가 받아 무엇을 할지는 여전히 조직이 정할 몫이다.