GitHub의 시크릿 탐지 모델: 더 많은 시크릿을 더 적은 노이즈로 찾기

Dokebi · 2026년 10월 29일 · #tech #ai #security

소개

시크릿 스캐닝은 개발자가 탐지 결과를 신뢰할 때 가장 효과적입니다. 너무 적게 탐지하면 실제 자격 증명이 저장소에 남을 수 있고, 너무 자주 알림을 보내면 개발자가 시크릿이 아닌 문자열을 조사하는 데 시간을 낭비하게 됩니다.

제네릭 시크릿(generic secrets)은 이런 균형을 특히 어렵게 만듭니다. 같은 문자열이 실제 자격 증명일 수도 있고 문서화용 플레이스홀더일 수도 있기 때문에, 탐지하려면 주변 코드와 텍스트를 이해해야 합니다.

GitHub는 이 문제를 해결하기 위해 GitHub의 제품 요구사항에 맞는 시크릿 분류기를 학습했습니다. 실제 자격 증명과 유사한 문자열을 구분하면서, 대규모 스캐닝의 속도와 효율 요구사항을 충족하는 분류기입니다.

이 글에서는 컨텍스트 인식 분류기를 뒷받침하는 기술을 살펴봅니다: 어떻게 설계하고, 학습하고, 평가하여 더 많은 실제 시크릿을 더 적은 노이즈로 찾았는지.

주요 성과

지표	변화	설명
Owner-weighted alert precision	11.5% 향상	탐지된 결과에 대한 고객 수용률
Post-push scan execution time (중앙값)	86% 감소	프로덕션 스캔 실행 시간
Serving cost	98% 이상 절감	컴팩트 모델 vs. 원격 LLM 호출

시크릿 스캐닝의 두 가지 핵심 시점

GitHub 시크릿 스캐닝은 두 가지 핵심 시점에서 동작합니다.

Push protection: 푸시가 수락되기 전에 변경 사항을 스캔하여 시크릿이 저장소에 들어가는 것을 방지합니다. 개발자가 결과를 확인하고 조치할 기회를 제공합니다.
Post-push scanning: 코드가 커밋된 후 지속적으로 저장소 콘텐츠를 스캔하고, 잠재적 시크릿이 탐지되면 알림을 생성하여 개발자와 보안 팀이 조사하고 조치할 수 있게 합니다.

GitHub는 빠른 분류기를 개발하여 이전 LLM 기반 파이프라인 대비 post-push 스캔 실행 시간을 중앙값 기준 86% 줄였습니다. 이 효율성 덕분에 제네릭 시크릿 탐지를 push protection으로 확장하는 것이 실용적이 되었고, 코드가 커밋된 후뿐만 아니라 개발자가 푸시하기 전에 결과를 반환할 수 있게 되었습니다.

왜 시크릿 탐지가 어려운가

구조화된 자격 증명은 종종 고유한 접두사, 길이, 알파벳, 또는 체크섬을 포함합니다. 하지만 제네릭 시크릿은 그렇지 않습니다. 그 문법은 빌드 식별자, 체크섬, 에셋 해시, 샘플 값, 기타 민감하지 않은 문자열과 겹칩니다. 컨텍스트가 결정적 신호입니다.

실제 자격 증명일 가능성 높음	무해한 유사 문자열일 가능성 높음
프로덕션 데이터베이스 URL 옆에 할당된 패스워드	테스트 픽스처의 동일한 패스워드 형태 값
배포 설정의 연결 문자열	설정 가이드의 localhost 연결 문자열
API 자격 증명에 바인딩된 고엔트로피 값	고엔트로피 체크섬, 빌드 ID, 에셋 해시

이런 경우는 하드 네거티브(hard negatives)입니다: 자격 증명 패턴과 일치하지만 사용 가능한 자격 증명이 아닌 문자열입니다. 더 많은 규칙을 추가하면 일부를 억제할 수 있지만, 각 예외는 실제 시크릿을 숨길 위험이 있습니다. 학습된 분류기는 파일 경로, 시크릿 타입, 변수명, 주변 코드나 텍스트와 같은 신호를 대신 사용할 수 있습니다.

그래서 GitHub는 2단계 파이프라인을 출시했습니다:

후보 생성 (Candidate generation): 정규식 필터가 높은 재현율(recall)로 잠재적 시크릿을 스캔합니다. 이 단계는 자격 증명과 유사한 패턴의 넓은 패밀리를 빠르고 결정적으로 포착하도록 최적화되어 있습니다.
컨텍스트 인식 분류 (Context-aware classification): 파인튜닝된 ModernBERT 분류기가 각 후보와 그 주변 컨텍스트를 평가합니다. 플레이스홀더 값, 예제, 문서 스니펫, 생성된 콘텐츠, 민감하지 않은 식별자 등 실제 시크릿과 오탐을 구분하는 신호를 인식하도록 학습되었습니다. 모델이 작고 효율적이어서 추론 인프라에서 실행 비용이 훨씬 낮고, LLM 기반 파이프라인보다 스케일링이 간단합니다.

영향:

11.5% 사용자 수용률 향상 (오탐 감소)
Post-push 시크릿 탐지 실행 시간 86% 단축
LLM 기반 파이프라인 대비 98% 이상 비용 절감

파이프라인 동작 방식

콘텐츠가 스캔될 때, 정규식 패턴이 넓은 그물을 던져 자격 증명과 유사한 모든 것을 포착하므로 시작 단계에서 실제 시크릿이 놓치지 않습니다. 각 후보는 파인튜닝된 ModernBERT 분류기로 전달되며, 분류기는 값과 함께 파일 경로, 변수명, 주변 코드를 읽습니다. 실제 시크릿일 가능성을 추정하고, 고신뢰도 결과는 알림이 되며, 플레이스홀더, 테스트 픽스처, 체크섬 같은 유사 문자열은 개발자에게 도달하기 전에 필터링됩니다.

Broad first, careful second

Scan: 저장소 콘텐츠, 커밋, 풀 리퀘스트, 기타 스캔 대상.
Generate candidates: 정규식 패턴이 가능한 토큰, 키, 자격 증명과 유사한 문자열을 식별.
Classify: 파인튜닝된 ModernBERT가 후보 + 컨텍스트를 평가하고 실제 시크릿일 가능성 점수를 부여.
Alert or suppress: 고신뢰도 결과는 진행, 오탐 가능성은 필터링.

중요한 설계 선택은 모델이 결정적 스캐닝을 대체하지 않는다는 점입니다. 정규식은 후보 문자열을 빠르게 찾는 데 여전히 적합한 도구입니다. 분류기는 머신러닝이 가장 큰 가치를 제공하는 곳, 즉 "시크릿처럼 보이는 것"과 "실제 시크릿일 가능성"을 구분하는 데 사용됩니다.

하드 네거티브 문제: 거의 진짜처럼 보이는 시크릿

대부분의 오탐은 무작위가 아닙니다. 하드 네거티브입니다: 자격 증명 패턴과 일치하지만 사용 가능한 자격 증명이 아닌 문자열. 문서 플레이스홀더, 테스트의 예제 코드, 레닥션된 값, 민감하지 않은 ID, 생성된 픽스처 등이 해당됩니다. 이런 경우는 정규식이 매칭하기 쉽고, 순수 규칙 기반 시스템으로는 실제 시크릿을 잃지 않고 억제하기 어렵습니다.

ModernBERT는 후보와 주변 코드/텍스트를 함께 읽을 수 있어 도움이 됩니다. "example", "dummy", "fake", "replace-me" 같은 단어로 둘러싸인 후보는 배포 파일의 환경 변수에 할당된 후보보다 위험이 낮을 수 있습니다. 분류기는 모든 예외를 또 다른 규칙으로 인코딩할 필요 없이, 레이블된 예제로부터 이런 컨텍스트 차이를 학습합니다.

ModernBERT를 선택한 이유는 이 워크로드에 적합하기 때문입니다: 컴팩트하고 효율적이며, 코드 인접 텍스트에 대한 분류에 잘 맞습니다. 시크릿 스캐닝에서 모델은 짧은 후보 윈도우에 대한 보정된(calibrated) 결정을 높은 처리량과 낮은 지연시간으로 내려야 합니다.

파인튜닝된 인코더 분류기는 이 파이프라인 단계에서 범용 LLM보다 더 나은 서빙 형태입니다. 모델을 우리의 결정 경계에 직접 학습시키고, 시크릿 스캐닝 품질에 중요한 동일한 재현율과 정밀도 지표로 평가할 수 있습니다.

학습 방법

문법만으로는 오해하기 쉬운 사례에 대한 대표적인 데이터를 찾는 것이 과제였습니다. 학습 및 평가 전략은 세 가지 소스를 결합합니다.

제품 파생 예제: GitHub 저장소에서 시크릿 탐지 경험에 대한 피드백과 추가 인간 검증을 활용.
고재현율 정규식 후보: 인간 주석 예제와 커버리지 확장을 위한 약한 레이블(weak labels)을 포함한 GitHub 저장소 데이터.
합성 예제: 문서 시크릿, 테스트 픽스처, 공개 키, 체크섬, 구조화된 유사 문자열, 근접 쌍(near-miss pairs) 등 희소하고 어려운 사례를 타겟.

합성 행은 포함 전에 결정적 검증과 모델 기반 품질 검토를 거칩니다. 학습은 실제 시크릿, 현실적인 오탐, 정규식 전용 접근법을 자주 혼동시키는 하드 네거티브에 초점을 맞춥니다. 각 모델 입력에는 후보 값, 파일 경로, 시크릿 타입, 제한된 양의 주변 컨텍스트가 포함됩니다. 임계값은 오프라인 평가를 통해 선택한 후, 더 넓은 롤아웃 전에 프로덕션 유사 트래픽에서 동작을 검증합니다.

데이터를 분할하기 전에, 저장소, 후보 값, 또는 예제를 공유하는 행을 그룹화하여 근접 중복이 학습과 평가 양쪽에 나타나지 않도록 했습니다.

학습은 알림 품질에 가장 중요한 사례에 집중했습니다: 실제 시크릿, 현실적인 오탐, 정규식이 자주 매칭하는 하드 네거티브. 입력 표현에는 후보 시크릿 문자열, 파일 경로, 타입, 제한된 양의 주변 컨텍스트가 포함됩니다. 출력은 스캐너가 후보를 진행할지 결정하는 데 사용하는 분류 점수입니다.

제품 트레이드오프에 최적화했습니다: 재현율을 유지하거나 개선하면서 오탐과 서빙 비용을 줄이는 것. 실제로는 분류기 임계값을 오프라인 평가로 선택한 후, 롤아웃 전에 프로덕션 유사 트래픽에서 검증합니다.

가장 중요한 학습 원칙은 모델이 혼란스러운 예제를 보게 하는 것이었습니다. 문법적으로는 실제 시크릿과 유사하지만 의미적으로는 다른 후보를 포함하여, 모델이 시크릿이 어떻게 생겼는지뿐만 아니라 컨텍스트에서 오탐이 어떻게 생겼는지도 학습하도록 했습니다.

학습된 모델은 8비트 양자화(quantization)와 함께 ONNX 형식으로 내보내져 빠른 추론을 가능하게 합니다.

평가 결과

온라인 결과	이전 LLM 파이프라인 대비 변화	측정 대상
Repository owner-weighted acceptance	11.5% 향상	탐지된 결과에 대한 고객 수용률
Median post-push scan execution time	86% 감소	프로덕션 스캔 실행 시간
Serving cost	98% 이상 절감	컴팩트 분류기 vs. 원격 LLM 호출 비용

파인튜닝된 모델에 대한 고객 A/B 평가 결과 (이전 LLM 파이프라인과 비교).

새 파이프라인의 영향을 프로덕션에서 두 단계로 평가했습니다: 먼저 동일한 공개 트래픽에서 프로덕션 기준선과 비교한 후, 고객 A/B 실험을 통해 검증했습니다.

오프라인 평가: Post-push 스캐닝에서, 새 파이프라인은 동일한 공개 트래픽에서 이전 LLM 파이프라인 대비 정밀도 13% 향상, 재현율 19% 향상을 달성했습니다.
온라인 평가: A/B 실험을 통해 이러한 품질 개선이 고객 결과로 이어지는지 검증했습니다. Repository owner-weighted acceptance가 11.5% 증가했습니다. 한 번에 대량의 알림을 해결하는 고객의 영향을 줄이기 위해 owner별로 가중치를 부여합니다 (그렇지 않으면 단순 평균이 왜곡될 수 있습니다).

핵심 교훈

가장 좋은 보안 도구는 개발자가 사용할 만큼 신뢰하는 도구입니다. 더 높은 정밀도는 더 적은 산만한 알림을 의미합니다. 더 높은 재현율은 더 많은 실제 시크릿이 포착됨을 의미합니다. 더 낮은 비용은 스캐닝을 엄청나게 비싸게 만들지 않고도 커버리지를 계속 개선할 수 있음을 의미합니다.

개발자와 보안 팀에게 이것은 커밋, 풀 리퀘스트, 일상적인 개발 워크플로에서 시크릿이 가장 많이 도입되는 곳에서 더 적은 오탐과 더 빠른 피드백으로 이어져야 합니다.

하이브리드 시스템은 강력합니다. 정규식은 속도, 투명성, 넓은 후보 커버리지를 제공합니다. ModernBERT는 학습된 컨텍스트 이해와 오탐 감소를 제공합니다. 이 조합은 이 제품 제약 조건에서 어느 한 접근법만 사용하는 것보다 우수합니다.

모델 크기와 모델 유용성은 같지 않다는 것도 배웠습니다. 작업이 좁고, 결정 경계가 측정 가능하며, 서빙 효율이 중요할 때는 더 작은 파인튜닝 분류기가 올바른 답일 수 있습니다.

앞으로의 방향

시크릿 스캐닝을 더 정확하고, 확장 가능하며, 사용하기 쉽게 만드는 한 걸음입니다. 앞으로 두 가지 영역에 집중합니다:

지속적 개선 플라이휠 구축: 프로덕션 피드백 루프를 사용하여 새로운 오탐음성(false negatives)과 오탐양성(false positives)을 식별하고, 실제 세계 신호를 더 고품질의 학습 및 평가 데이터로 전환.
새로운 모델 아키텍처 탐색: 정확도와 규모를 유지하면서 파이프라인 복잡성을 줄이는 단일 단계 시크릿 탐지 및 추출을 수행할 수 있는 접근법 조사.

감사의 글

이 새로운 시크릿 스캐너를 위한 학습 데이터, 평가 스위트, 서빙 스택, 롤아웃 계획을 구축하는 데 도움을 준 GitHub와 Microsoft 전반의 엔지니어링, 사이언스, 제품 팀에 큰 감사를 드립니다.

원문: GitHub's model for secret detection: Finding more secrets with less noise (GitHub Blog)