GitHub AI 비밀 탐지 모델 공개: 에이전트가 만든 코드에서 토큰 유출을 막는 방법

GitHub가 2026년 10월 7일 비밀 정보 탐지를 위한 목적 특화 모델을 공개했다. 기존 secret scanning은 정형화된 토큰 패턴을 찾는 데 강했다. 이번 업데이트의 초점은 주변 코드 문맥을 읽어 “형식이 뚜렷하지 않은 비밀번호와 자격 증명”까지 잡는 것이다. GitHub는 이 모델을 secret scanning alerts, push protection, Copilot의 /security-review 흐름에 단계적으로 연결한다고 밝혔다.

개발팀 입장에서 이 소식이 중요한 이유는 AI 코딩 에이전트 사용이 늘수록 비밀 정보 유출 경로도 바뀌기 때문이다. 사람이 직접 붙여 넣은 토큰만 문제가 아니다. 에이전트가 예제 환경변수, 테스트 계정, 임시 패스워드, 복사된 설정 파일을 코드에 남길 수 있다. 리뷰어가 기능 변경만 보고 넘어가면 노출은 PR 머지 뒤에 발견된다.

이번 GitHub 발표의 핵심

GitHub의 새 모델은 코드 주변 맥락을 보고 자격 증명일 가능성이 높은 값을 찾는다. 공식 설명에 따르면 이 모델은 코드나 산문을 생성하지 않고 secret detection에 특화됐다. 즉 범용 LLM 리뷰어가 “보안상 의심됩니다”라고 말하는 방식이 아니라, 비밀 정보 탐지라는 좁은 문제를 더 정밀하게 다루는 접근이다.

적용 경로는 세 가지다. 첫째, GHSP 또는 GHAS 고객의 기존 AI-detected password alerts는 새 모델로 자동 업그레이드된다. 둘째, push protection에서 비정형 자격 증명을 푸시 시점에 탐지하는 기능은 private preview로 제공된다. 셋째, GitHub Copilot CLI와 Copilot app의 /security-review 명령에 secret classifier 기반 검사가 추가될 예정이다.

요금 구조도 구분해야 한다. 기존 AI-detected secret alerts는 GHSP와 GHAS에 포함되며 추가 비용이 없다고 안내됐다. 반면 push protection의 AI 검사와 /security-review의 새 secret 검사처럼 opt-in 기능은 GitHub AI Credits를 사용한다. 관리자가 예산과 정책을 확인하지 않고 켜면 비용 관리 문제가 생길 수 있다.

왜 정규식만으로 부족해졌나

전통적인 secret scanning은 API 키, OAuth 토큰, 클라우드 액세스 키처럼 잘 알려진 형식에 강하다. 예를 들어 특정 prefix, 길이, 문자 집합, 체크섬 패턴이 있으면 높은 확률로 잡을 수 있다. 문제는 모든 비밀 정보가 그런 형태를 갖지 않는다는 점이다.

실무 코드에는 adminPassword = "summer2026!", db_pass: "test-prod-sync", basic_auth = "user:pass" 같은 값이 들어간다. 값 자체만 보면 평범한 문자열일 수 있다. 하지만 파일 경로가 deployment config이고, 변수명이 password이며, 옆에 production endpoint가 있다면 의미가 달라진다. 문맥을 읽지 않으면 놓치기 쉽다.

AI 에이전트가 코드를 작성하는 상황에서는 이런 문제가 더 자주 생길 수 있다. 에이전트는 문서 예제나 기존 파일을 참고해 빠르게 설정을 만든다. 사람이 “실제 값은 나중에 바꿔야지”라고 생각하고 넣은 임시 문자열도, 에이전트가 생성한 파일에서는 그대로 커밋 대상이 될 수 있다. 이때 필요한 것은 생성 후 리뷰가 아니라 푸시 전 차단이다.

push protection이 중요한 이유

비밀 정보는 repository history에 들어간 뒤부터 대응 비용이 급격히 올라간다. 파일에서 지우는 것만으로 끝나지 않는다. 토큰 폐기, 재발급, 접근 로그 확인, 히스토리 정리, 고객 영향 조사, 보안 보고까지 이어질 수 있다. 그래서 가장 좋은 위치는 커밋 전 또는 푸시 시점이다.

GitHub의 AI push protection은 푸시 시점에 비정형 자격 증명을 검사하는 방향이다. 다만 private preview이고, 조직이나 엔터프라이즈 정책에 따라 관리자가 켜야 한다. 또한 AI Credit을 소비할 수 있으며, 차단 여부와 무관하게 검사가 실행되면 크레딧이 사용될 수 있다고 안내됐다. 보안 기능이지만 비용 관리 대상이기도 하다.

운영팀은 이 기능을 켜기 전에 예산 한도, 알림, 사용량 리포트, 예외 처리 절차를 먼저 정해야 한다. 예외가 너무 쉽게 허용되면 차단 효과가 떨어지고, 너무 엄격하면 개발자가 임시 우회 경로를 만든다. “누가 예외를 승인하는가”, “예외 사유는 어디에 남기는가”, “승인된 값은 언제 폐기하는가”가 같이 필요하다.

Copilot /security-review와 연결될 때 달라지는 흐름

GitHub는 Copilot CLI와 Copilot app의 /security-review 명령에도 새 secret classifier 기반 검사를 붙일 계획이라고 밝혔다. 이 흐름은 커밋, 푸시, PR 요청 전 활성 변경사항을 읽고 보안 취약점과 수정 제안을 반환하는 방식이다. 새 secret 검사는 기존 LLM 기반 리뷰에 추가되는 형태로 설명됐다.

여기서 중요한 점은 “읽기 전용”이라는 경계다. 리뷰 명령은 변경사항을 분석하고 우선순위가 있는 결과를 제시하지만, 에이전트가 임의로 조직 정책이나 과금 설정을 켜면 안 된다. GitHub 발표도 새 검사는 기본적으로 꺼져 있으며, 실행한다고 자동 활성화되지 않는다고 명시한다. 관리자가 정책과 예산을 보고 opt-in해야 한다.

개발팀은 /security-review를 PR 템플릿이나 pre-push 체크와 함께 쓰는 방식을 고려할 수 있다. 단, 모든 발견을 자동 차단으로 다루면 개발 흐름이 막힌다. 우선순위를 나눠 “확정 secret은 차단, 의심 secret은 리뷰어 확인, 낮은 신뢰도는 경고”처럼 단계화하는 편이 현실적이다.

조직에서 먼저 정해야 할 정책

첫째, secret의 범위를 정의해야 한다. 클라우드 키와 OAuth 토큰만 볼 것인지, 내부 관리자 비밀번호, DB 연결 문자열, 테스트 계정, 서명 키, webhook URL까지 포함할 것인지 정해야 한다. 범위가 넓어질수록 false positive도 늘어난다.

둘째, 예외 정책이 필요하다. 테스트용 fixture에 의도적으로 가짜 토큰을 넣는 경우가 있다. 이때 값이 실제로 무효인지, 네트워크 접근이 없는지, 이름이 명확히 fake인지 확인해야 한다. 예외는 코드 주석 하나로 끝내지 말고 중앙 정책이나 allowlist로 관리하는 편이 낫다.

셋째, 에이전트 권한을 제한해야 한다. 코딩 에이전트가 비밀 값을 읽고 테스트를 실행해야 할 수는 있다. 하지만 실제 production secret을 프롬프트나 로그에 노출하면 안 된다. 에이전트용 계정에는 최소 권한을 주고, secret store 접근은 짧은 수명 토큰과 감사 로그를 붙여야 한다.

실행 체크리스트

• 현재 조직이 GHSP, GHAS, Copilot 중 어떤 플랜과 기능을 쓰는지 확인한다.
• 기존 secret scanning alert가 새 모델로 자동 전환되는 범위를 확인한다.
• push protection AI 검사는 private preview와 AI Credit 과금 조건을 검토한 뒤 켠다.
• /security-review에 secret 검사를 붙일 경우 예산, 정책, opt-in 권한을 관리자에게 묶는다.
• pre-commit, pre-push, PR review, repository scanning의 역할을 나눈다.
• 가짜 토큰 fixture에는 fake, dummy, example 같은 명확한 표식을 쓰고 실제 권한이 없음을 테스트한다.
• 에이전트가 생성한 설정 파일은 사람이 만든 코드와 같은 기준으로 secret scanning을 통과시킨다.
• 유출이 확인되면 코드 삭제보다 먼저 토큰 폐기와 접근 로그 확인부터 진행한다.