GitHub가 노출된 시크릿의 PR 병합을 막는다, AI 탐지는 제외다
GitHub는 2026년 9월 9일, 시크릿 검사가 끝나지 않았거나 새 시크릿 경고가 열린 pull request(PR)의 병합을 막는 repository ruleset을 공개 미리보기로 출시했다. GitHub의 변경 공지 에 따르면 GitHub Secret Protection 또는 GitHub Advanced Security 고객이 선택한 저장소와 브랜치에 적용할 수 있다.
같은 날 공개된 규칙의 이름은 Require secret scanning alerts are resolved다. PR의 head commit 검사가 완료되고, 해당 PR의 커밋이 도입한 대상 시크릿 경고가 모두 해소돼야 병합할 수 있다. 다만 이 공개 미리보기는 provider·custom·generic patterns만 지원하며 AI-detected secrets는 병합 차단 조건으로 사용할 수 없다.
병합 전에 검사 완료와 열린 경고를 따로 확인한다
새 규칙은 두 조건을 독립적으로 검사한다. 첫째, PR의 최신 상태인 head commit에 대한 secret scanning이 끝나야 한다. 둘째, PR의 커밋이 도입했고 ruleset에서 선택한 시크릿 유형과 일치하는 열린 경고가 없어야 한다. GitHub의 병합 차단 설정 문서 는 어느 한 조건이라도 충족되지 않으면 병합이 차단된다고 명시한다.
검사 중인 PR에 아직 경고가 표시되지 않는다고 해서 병합 가능한 상태가 되는 것은 아니다. head commit의 검사 완료가 먼저 확인돼야 한다. 반대로 검사가 끝났더라도 PR의 커밋이 만든 대상 경고가 열린 상태라면 차단은 유지된다. 새 커밋을 추가해 head commit이 바뀌면 최신 커밋의 검사 결과가 판단 기준이 된다.
차단 범위는 저장소에 남아 있는 모든 과거 경고가 아니다. 규칙이 보는 것은 해당 PR의 커밋이 도입한 열린 경고다. 또한 ruleset에서 선택하지 않은 시크릿 유형의 경고까지 자동으로 병합 조건에 포함되는 것도 아니다.
열린 경고 때문에 차단된 경우에는 선택된 유형과 일치하는 경고를 각각 해결해야 한다. 다만 GitHub의 출시 공지는 우회 권한이 없는 개발자에게 이 조건이 적용된다고 설명한다. 사용자, 팀 또는 GitHub App에 ruleset 우회 권한을 부여했다면 그 예외가 실제 집행 범위를 바꿀 수 있다.
세 가지 패턴은 지원하지만 AI 탐지는 별도다
지원 범위는 이름이 비슷한 탐지 기능을 구분해서 봐야 한다. provider patterns는 기본 차단 범주이며, custom patterns와 generic patterns는 ruleset의 Secret types에서 추가로 선택할 수 있다. AI-detected secrets는 현재 이 규칙이 지원하지 않는다.
- Provider patterns: 서비스 제공자가 발급하는 토큰이나 키처럼 알려진 형식의 시크릿을 탐지한다. 새 ruleset은 이 범주를 기본값으로 사용한다.
- Custom patterns: 조직이 내부 자격 증명이나 독자적인 토큰 형식에 맞춰 정의한 패턴이다. ruleset에서 선택한 경우 해당 패턴이 만든 열린 경고가 병합 조건에 포함된다.
- Generic patterns: 특정 제공자에 종속되지 않은 개인 키 등 결정적 방법으로 식별되는 시크릿을 다룬다. 병합 차단에 사용하려면 Secret types에서 선택해야 한다.
- AI-detected secrets: 코드 문맥을 이용해 비밀번호 같은 비정형 시크릿을 찾는 탐지 방식이지만 이번 병합 규칙에서는 지원되지 않는다.
generic patterns와 AI 탐지는 GitHub 화면에서 모두 generic alerts 목록에 나타날 수 있지만 같은 탐지 방식은 아니다. GitHub의 시크릿 경고 설명 은 결정적 패턴으로 찾은 generic secrets와 AI가 찾은 비밀번호 등을 같은 목록에서 제공하면서도 별도의 기능으로 구분한다. 따라서 generic patterns를 ruleset에 포함해도 AI 탐지 경고까지 병합을 막는 것은 아니다.
push protection보다 늦은 병합 경계에서 작동한다
Push protection과 새 ruleset의 핵심 차이는 방어 시점이다. Push protection은 지원되는 시크릿을 push하는 순간 차단해 저장소에 들어오는 것을 막는다. 새 규칙은 변경이 PR 흐름에 들어온 뒤 선택한 브랜치로 병합되기 직전에 검사 결과와 경고 상태를 확인한다.
두 기능은 대체 관계가 아니다. 예를 들어 generic pattern에 대한 push protection을 사용하지 않더라도 PR ruleset에서 generic patterns를 선택할 수 있다. 이 구성에서는 해당 변경의 push가 허용될 수 있지만, 열린 경고가 남아 있으면 대상 브랜치로 병합되지 않는다.
반대로 병합 차단은 이미 커밋이나 PR에 들어간 자격 증명의 노출을 되돌리지 않는다. 실제 자격 증명이 발견됐다면 경고를 해결하는 작업과 함께 폐기·교체 및 노출 범위 조사가 필요할 수 있다. 병합 차단이 풀렸다는 상태만으로 자격 증명 대응까지 끝났다고 볼 수는 없다.
ruleset은 지정된 브랜치에만 적용된다. 기본 브랜치를 보호하려면 해당 브랜치가 ruleset 대상에 포함돼야 한다. Push protection의 적용 범위, PR ruleset의 대상 브랜치, 우회 권한은 서로 다른 설정이므로 하나가 켜졌다는 이유로 나머지까지 집행된다고 가정하면 안 된다.
저장소 또는 조직 ruleset에서 활성화한다
설정 전제조건은 대상 저장소에서 GitHub Secret Protection 또는 GitHub Advanced Security와 secret scanning이 활성화돼 있는 것이다. 이 기능을 설정할 수 있는 주체는 조직 소유자, security manager, 또는 관리자 역할을 가진 조직 구성원이다.
개별 저장소에서는 Settings의 Code and automation 아래에 있는 Rulesets로 이동해 새 branch ruleset을 만들거나 기존 ruleset을 편집한다. 보호할 브랜치를 대상으로 지정한 뒤 Branch protections에서 Require secret scanning alerts are resolved를 선택한다.
Secret types에서는 병합을 차단할 provider, custom, generic patterns를 고른다. Provider patterns가 기본 범주라고 해서 조직의 custom patterns나 generic patterns까지 자동으로 포함되는 것은 아니다. 저장 시 enforcement 상태가 Active이면 규칙이 즉시 적용되며, Disabled 상태에서는 병합 관문으로 집행되지 않는다.
조직 단위에서는 Organization Settings의 Repository, Rulesets 경로에서 대상 저장소와 브랜치를 지정할 수 있다. REST API는 require_secret_scanning_alert_resolution 규칙 유형과 secret_types 매개변수를 사용하고, GraphQL에서는 REQUIRE_SECRET_SCANNING_ALERT_RESOLUTION로 표현한다.
이번 기능은 정식 출시가 아니라 변경될 수 있는 공개 미리보기다. 현재 확인된 범위는 완료된 head commit 검사와 provider·custom·generic patterns의 열린 경고를 병합 관문에 연결하는 데까지다. 일반 제공 전환 시점과 AI-detected secrets의 지원 계획은 공개되지 않았다.
함께 읽기:
뉴스레터 구독
최신 Web3, AI, 암호화폐 뉴스를 이메일로 받아보세요.