GitHub Secret Scanning 2026, 공개 저장소 API 키 유출·Push Protection 기준

GitHub Secret Scanning 공개 저장소 API 키 유출 모니터링과 Push Protection 운영 장면 — API 키 유출 대응은 탐지보다 회전, 감사, 예외 승인 흐름이 더 중요하다.

GitHub Secret Scanning은 저장소 보안 기능 이름으로 끝나지 않는다.

개발자가 토큰을 커밋했을 때 누가 몇 분 안에 키를 폐기하고, 어떤 로그로 사용 흔적을 확인하며, 어떤 예외를 승인할지 정하는 운영 체계다.

이번 GitHub 변경에서 봐야 할 부분은 새 detector 목록보다 public monitoring, push protection 기본값 확대, webhook payload의 secret_category 추가다.

이 조건이면 단순 알림 구독보다 보안팀의 라우팅 정책과 개발팀의 우회 승인 절차를 먼저 정해야 한다.

핵심 요약

GitHub Secret Scanning은 저장소 안의 토큰뿐 아니라 이슈, PR, Discussions, wiki, secret gist 같은 비코드 표면까지 확인한다.
Public monitoring은 엔터프라이즈 소유 저장소 밖의 공개 저장소 유출까지 멤버와 검증 도메인 기준으로 연결해 보여준다.
Push Protection은 유출 후 알림이 아니라 push 시점 차단이므로 우회 사유, 감사 로그, 관리자 알림 정책이 같이 필요하다.
Webhook의 secret_category는 default와 generic 탐지를 구분해 자동화 큐를 나눌 때 실무 가치가 크다.

이 글이 필요한 사람

GitHub Enterprise 또는 조직 저장소에서 API 키 유출 대응 SLA를 정해야 하는 보안 관리자
개발자 경험을 해치지 않으면서 push protection 우회 정책을 설계해야 하는 플랫폼 엔지니어
GitHub webhook, REST API, SIEM, 티켓 시스템을 연결해 secret alert를 처리하려는 DevSecOps 담당자
외주, 개인 계정, 공개 저장소 커밋에서 회사 도메인 유출을 추적해야 하는 보안 운영팀
GitHub Advanced Security 또는 Secret Protection 비용을 실제 리스크 감소 기준으로 판단해야 하는 기술 리더

GitHub Secret Scanning 변경을 기능 뉴스로만 보면 놓치는 것

GitHub Changelog는 Resend 파트너 추가, APIclub과 Resend secret type 탐지, VolcEngine secret의 push protection 기본 차단을 함께 공지했다.

같은 공지에서 secret_scanning_alert 웹훅에 secret_category 필드가 들어가 default와 generic 탐지를 구분할 수 있다고 설명했다.

Public monitoring alert list에는 attribution breakdown, enterprise member count, verified domains 같은 insight card가 추가됐다.

운영 관점의 변화는 detector가 몇 개 늘었다는 사실보다 알림을 어떤 큐로 보낼 수 있는지가 명확해졌다는 점이다.

default provider pattern은 키 발급자와 회전 절차가 비교적 분명한 편이다.

generic 또는 AI-detected secret은 실제 비밀값인지, 테스트 데이터인지, 내부 포맷인지 사람이 더 많이 확인해야 한다.

판단표: 저장소 알림, Push Protection, Public Monitoring 차이

영역	주요 목적	운영자가 볼 신호	주의할 점
Secret scanning alert	이미 저장소에 들어온 credential leak 탐지	secret type, validity, repository, alert state	알림을 닫기 전에 회전 증거와 사용 흔적 감사를 남긴다
Push Protection	토큰이 저장소에 들어가기 전 push 차단	bypass reason, audit log, 관리자 알림	테스트용 키라는 주장만으로 우회를 허용하지 않는다
Public monitoring	조직 밖 공개 저장소의 회사 관련 유출 가시화	enterprise member, verified domain attribution	개인 계정과 외주 커밋 소유자 확인 절차가 필요하다
Webhook automation	알림을 SIEM과 티켓 큐로 라우팅	secret_category, validity, public leak tag	서명 검증 없이 자동 폐기나 알림 전파를 하지 않는다
REST API reporting	조직 단위 알림 조회와 지표화	state, resolution, provider, validity filters	hide_secret과 권한 범위를 기본값으로 점검한다

이 표에서 가장 중요한 차이는 발견 시점이다.

Secret scanning은 이미 들어온 비밀값을 빨리 찾는 장치이고, Push Protection은 들어오는 순간을 막는 장치다.

Public monitoring은 회사가 소유하지 않은 공개 공간까지 보는 장치라서 소유권 확인 절차가 더 까다롭다.

도입 전 1단계: 탐지 범위를 저장소 바깥까지 적는다

GitHub Docs는 secret scanning이 전체 Git history와 all branches를 스캔한다고 설명한다.

문서 기준으로 이슈, PR, Discussions, wiki, secret gist 같은 비코드 표면도 자동 스캔 대상에 들어간다.

보안팀이 저장소 코드만 보는 정책을 유지하면 유출면을 과소평가한다.

실무 시나리오 1은 고객 지원팀이 이슈 댓글에 임시 API 키를 붙여 넣은 경우다.

코드 리뷰는 깨끗해도 이슈 댓글에 남은 키가 외부 통합 시스템을 호출할 수 있다.

이 조건이면 개발 저장소 권한보다 이슈 템플릿, 지원 채널, secret gist 사용 금지 교육을 먼저 정리해야 한다.

도입 전 2단계: Public monitoring 요구 조건을 비용 항목으로 분리한다

GitHub Enterprise Cloud 문서는 public monitoring을 public preview로 설명하고, 기업 멤버와 verified domain 기준 attribution을 사용한다고 밝힌다.

또한 사용 조건으로 GitHub Advanced Security 또는 GitHub Secret Protection 활성화가 필요하다고 적는다.

여기서 비용 판단은 “보안 기능 하나 추가”가 아니라 조직 밖 공개 저장소 유출을 볼 필요가 있는지다.

외주 개발, 개인 계정 커밋, 오픈소스 기여, 회사 도메인 이메일 사용이 많다면 public monitoring의 가치가 커진다.

반대로 모든 개발이 폐쇄망과 사내 계정으로만 움직이는 조직이라면 저장소 내부 secret scanning과 push protection부터 고정하는 편이 낫다.

도입 전 3단계: Push Protection 우회 사유를 정책으로 다룬다

GitHub Docs는 Push Protection이 command line push, GitHub UI commit, file upload, REST API 요청 등 여러 경로에서 비밀값을 차단한다고 설명한다.

문서에는 GitHub MCP server와의 상호작용도 public repository 조건에서 차단 표면에 포함된다고 적혀 있다.

Repository 수준 push protection에서는 write 권한 사용자가 우회 사유를 남길 수 있다.

우회가 발생하면 알림, audit log, 이메일 알림 흐름이 생기므로 security manager가 사후 확인해야 한다.

실무 시나리오 2는 테스트 fixture에 토큰처럼 보이는 문자열이 반복되는 monorepo다.

이 경우는 false positive와 used in tests를 구분해 닫아야 하지만, “나중에 고치겠다” 우회는 open alert와 티켓을 남겨야 한다.

개발 속도를 위해 우회를 열어두더라도 승인권자, 만료 시간, 예외 저장소 목록을 문서화하지 않으면 통제가 무너진다.

도입 전 4단계: secret_category로 알림 큐를 나눈다

GitHub Changelog는 secret_scanning_alert 웹훅 payload에 secret_category 필드가 추가됐다고 설명한다.

default는 provider pattern과 custom pattern, generic은 generic pattern과 AI-detected secret을 구분하는 용도로 제시됐다.

이 차이는 자동화에서 바로 쓸 수 있다.

provider default alert는 cloud key, payment key, SaaS token처럼 회전 담당자와 runbook이 명확한 경우가 많다.

generic alert는 private key, connection string, 비정형 password처럼 실제 영향 확인이 먼저 필요한 경우가 많다.

실무 시나리오 3은 webhook이 모든 alert를 같은 Slack 채널로 보내던 조직이다.

이 조건이면 default active key는 incident queue로 보내고, generic unknown alert는 AppSec triage queue로 보내는 분리가 더 낫다.

비용 기준: 라이선스 비용보다 처리 SLA 비용을 계산한다

Secret Scanning 예산은 제품 과금표만 보고 판단하면 부족하다.

실제 비용은 알림을 처리하는 사람, 키 회전 자동화, 클라우드 감사 로그 조회, 티켓 시스템 연동, 개발자 교육 시간에서 나온다.

Public monitoring을 켜면 소유하지 않은 공개 저장소와 개인 계정까지 확인해야 하므로 연락과 소유자 식별 비용이 늘어난다.

Push Protection을 강하게 걸면 초기에는 개발자 우회 요청과 false positive 검토가 늘 수 있다.

그래도 active key가 공개 저장소에 남아 무단 사용된 뒤 클라우드 비용 폭탄이 나는 리스크와 비교해야 한다.

보안 기준: 키 회전과 사용 흔적 감사를 닫힘 조건으로 둔다

GitHub Docs는 secret scanning alert를 받으면 credential을 즉시 rotate하라고 안내한다.

Git history에서 secret을 지우는 작업은 시간이 들며, 이미 revoke했다면 항상 우선 작업은 아닐 수 있다고 설명한다.

운영 문서의 닫힘 조건도 이 순서를 따라야 한다.

먼저 키를 폐기하고, 새 키를 안전한 secret manager에 넣고, 노출 시간 동안 사용된 로그를 확인한다.

그다음 history rewrite나 commit 제거가 필요한지 저장소 공개 범위와 감사 요구 기준으로 판단한다.

이 경우는 alert state가 resolved인지보다 cloud provider나 SaaS 발급자 쪽에서 키가 실제로 폐기됐는지가 더 중요하다.

운영 기준: 저장소별 설정보다 조직 기본값을 먼저 고정한다

저장소 관리자가 각자 켜는 방식은 빠르게 시작할 수 있지만, 누락 저장소가 생기기 쉽다.

조직과 enterprise 수준에서 기본 정책을 정하고, 예외 저장소는 만료일을 가진 승인 목록으로 관리하는 편이 낫다.

REST API를 쓰는 조직은 조직 단위 alert 조회, state, resolution, provider, validity, publicly leaked 필터를 기준으로 주간 지표를 만들 수 있다.

단, API 토큰 권한은 security_events나 필요한 최소 범위로 제한하고, hide_secret 옵션과 결과 저장소의 접근권한을 점검해야 한다.

SIEM 연동도 원문 secret 값을 저장하지 않는 설계를 기본값으로 둔다.

실무 스켈레톤: Secret alert 라우팅 정책 YAML

아래 YAML은 GitHub Secret Scanning 알림을 조직 보안 운영 큐로 연결하기 위한 정책 뼈대다.

# secret-alert-routing-policy.yaml
# 목적: GitHub Secret Scanning 알림을 저장소 알림으로 끝내지 않고 회전, 감사, 예외 승인으로 연결한다.
# 실제 팀명, SLA, 토큰 종류, 요금제 조건은 조직의 GitHub 설정과 공식 문서를 기준으로 바꾼다.

owner:
  security: application-security
  platform: devsecops-platform
  incident: security-incident-response

scope:
  repositories:
    default_secret_scanning: enabled
    push_protection: enabled_for_protected_repositories
    custom_patterns: reviewed_by_security
  public_monitoring:
    enterprise_verified_domains: required
    enterprise_member_attribution: enabled
    preview_change_watch: required
  webhook:
    event: secret_scanning_alert
    verify_signature: x-hub-signature-256

routing:
  provider_default:
    sla_minutes: 30
    action: rotate_revoke_audit
  generic_or_ai_detected:
    sla_minutes: 120
    action: security_triage_before_rotation
  push_protection_bypass:
    sla_minutes: 60
    action: reviewer_approval_and_reason_check
  public_monitoring_alert:
    sla_minutes: 30
    action: owner_identification_domain_audit

stop_conditions:
  - active_cloud_key_in_public_repository
  - bypass_reason_fix_later_without_ticket
  - webhook_signature_unverified
  - alert_closed_before_rotation_evidence

핵심은 public monitoring, push protection bypass, generic alert를 같은 SLA로 처리하지 않는 것이다.

특히 active cloud key와 공개 저장소 유출은 ticket 생성보다 rotate와 revoke가 먼저다.

웹훅 라우터 예시

아래 Python 코드는 secret_scanning_alert 웹훅을 받을 때 서명 검증과 우선순위 분기를 분리하는 스켈레톤이다.

#!/usr/bin/env python3
# secret_alert_triage.py
# 목적: secret_scanning_alert 웹훅을 받아 알림 우선순위를 정하는 스켈레톤이다.
# 실제 토큰, 저장소명, 사용자명, 엔드포인트는 넣지 않는다.

from __future__ import annotations

import hashlib
import hmac
import json
from typing import Any


def verify_signature(body: bytes, header: str, secret: str) -> bool:
    if not header.startswith("sha256="):
        return False
    expected = "sha256=" + hmac.new(secret.encode(), body, hashlib.sha256).hexdigest()
    return hmac.compare_digest(expected, header)


def classify(payload: dict[str, Any]) -> dict[str, str]:
    alert = payload.get("alert", {})
    category = alert.get("secret_category", "unknown")
    validity = alert.get("validity", "unknown")
    secret_type = alert.get("secret_type", "unknown")
    publicly_leaked = bool(alert.get("is_publicly_leaked"))
    bypassed = bool(alert.get("is_bypassed"))

    severity = "medium"
    queue = "appsec-triage"
    next_action = "review-alert-and-confirm-owner"

    if validity == "active" or publicly_leaked:
        severity = "critical"
        queue = "incident-response"
        next_action = "rotate-revoke-and-audit-usage"
    elif category == "generic":
        severity = "medium"
        queue = "appsec-triage"
        next_action = "validate-before-rotation"
    elif bypassed:
        severity = "high"
        queue = "security-manager-review"
        next_action = "check-bypass-reason-and-ticket"

    return {
        "severity": severity,
        "queue": queue,
        "next_action": next_action,
        "secret_type": secret_type,
        "category": category,
        "validity": validity,
    }


def main(raw_body: bytes, signature: str, webhook_secret: str) -> None:
    if not verify_signature(raw_body, signature, webhook_secret):
        raise SystemExit("invalid webhook signature")
    payload = json.loads(raw_body.decode("utf-8"))
    print(json.dumps(classify(payload), ensure_ascii=False))

실제 운영에서는 GitHub Webhooks 문서의 X-Hub-Signature-256 검증 절차를 그대로 적용하고, 원문 secret 값을 로그에 남기지 않아야 한다.

자동화가 키를 바로 폐기하는 구조라면 provider별 revoke API 실패와 재시도 정책도 별도로 둬야 한다.

CI 증적 게이트 예시

Secret alert 대응은 말로 닫히면 안 되며, 회전 티켓과 runbook 증적이 있어야 한다.

name: secret-leak-response-gate
on:
  workflow_dispatch:

env:
  ALERT_ID: set-by-manual-dispatch
  ROTATION_TICKET: set-by-incident-record

jobs:
  evidence:
    runs-on: ubuntu-latest
    steps:
      - name: Require rotation evidence
        run: |
          test -n "$ALERT_ID"
          test -n "$ROTATION_TICKET"
      - name: Check response checklist exists
        run: |
          test -s security/secret-response/runbook.md
      - name: Block empty remediation notes
        run: |
          grep -R "rotated\|revoked\|false-positive-reviewed" security/secret-response/runbook.md

이 workflow는 실제 회전을 수행하지 않는 증적 점검용이다.

운영 환경에서는 alert ID, rotation ticket, 감사 로그 링크, 담당자 승인 흔적을 같은 incident record에 묶어야 한다.