GitHub 코드 스캐닝 AI 보안 탐지를 PR에서 검증하는 법
GitHub 코드 스캐닝 AI 보안 탐지는 PR 변경분에서 취약점 후보를 찾아 보여주는 공개 미리보기 기능이에요. 이름만 보면 기존 CodeQL 체크가 더 똑똑해져서 병합까지 막아줄 것 같지만, 결론은 조금 다릅니다. CodeQL의 커버리지를 보완하는 별도 AI 스캔이며, 결과 자체는 advisory라 현재 병합 게이트로 쓸 수 없음.
GitHub가 2026년 7월 14일 공개한 공식 명칭은 AI-powered security detections in pull requests입니다. 이 글은 2026년 7월 28일 기준 GitHub Changelog와 Code Security 문서를 바탕으로, 누가 켤 수 있는지부터 PR에서 무엇을 기록해야 하는지까지 순서대로 정리했어요. 아직 public preview라 지원 범위와 조건은 바뀔 수 있습니다.
먼저 확인할 결론, CodeQL 대체가 아니라 사각지대 보완
CodeQL은 지원하는 언어와 쿼리를 대상으로 고정밀 정적 분석을 수행합니다. AI-powered security detections는 PR의 변경 코드와 코드 검색으로 얻은 저장소 문맥을 살펴보고, 기존 커버리지 밖의 언어와 프레임워크에서 취약점 후보를 찾는 방식이에요.
공식 문서가 제시하는 언어·프레임워크 예시는 PHP, Shell/Bash, Terraform의 HCL, Dockerfile, JSP, Blazor입니다. 다만 이 목록은 전체 지원표가 아니라 예시예요. “CodeQL 미지원 언어라면 전부 된다”로 읽으면 너무 멀리 감.
탐지 범주는 다음 9개로 안내돼 있습니다.
| 탐지 범주 | 살펴보는 대표 위험 |
|---|---|
| String injection | SQL·HTML·shell·JSON·YAML 문자열의 잘못된 escaping 또는 sanitization |
| Weak cryptography | 약한 알고리즘·키·난수, 암호화 누락, 약한 비밀번호 해싱 |
| Broken access control | path traversal, CSRF 누락, open redirect |
| Sensitive data exposure | secret·token·password·stack trace의 부적절한 저장·로그·전송 |
| Security misconfiguration | 보안 통제 비활성화, debug 기능 활성화 같은 위험한 설정 |
| Authentication failures | TLS·검증 누락, 불안전한 인증 흐름, rate limiting 누락 |
| Data integrity failures | 안전하지 않은 역직렬화, prototype pollution, 신뢰하지 않는 콘텐츠 실행 |
| SSRF | 공격자가 제어하는 URL·host·protocol을 서버가 가져오는 흐름 |
| Supply chain risks | 고정되지 않은 action·package·image, 무결성 검증 없는 다운로드 |
범주와 지원 언어는 모델 발전에 따라 달라질 수 있습니다. 파일럿 문서에는 “지원됨”이라고 크게 적기보다 테스트한 언어, 날짜, 실제 결과를 함께 남기는 편이 안전해요. 공개 미리보기는 역시 직접 확인이 답.
기능이 안 보인다면 라이선스보다 설정 계층부터 확인
이 기능은 GitHub.com에서 제공되며, 유료 Code Security 계열 라이선스와 GitHub Copilot 라이선스가 필요합니다. 공식 자료 사이에서 GitHub Code Security (GitHub Advanced Security)와 GitHub Advanced Security license라는 표현이 함께 나오므로, 실제 보유 SKU는 구매 화면과 계약에서 확인해야 해요.
그리고 라이선스만 있다고 바로 켜지는 구조가 아닙니다. 아래 조건이 모두 맞아야 합니다.
- 엔터프라이즈 소유자가
Policies→Advanced Security Code security→AI Findings에서 사용을 허용합니다. 기본값은Not allowed예요. - 조직 관리자가 글로벌 Code scanning 설정의
AI-powered security detections를 명시적으로 켭니다. - 대상 저장소에 CodeQL default setup이 활성화돼 있어야 합니다.
- 저장소가 조직 설정을 상속하는지, 관리자가 개별 opt-out하지 않았는지 확인합니다.
여기서 잘 걸리는 부분이 두 군데예요. 엔터프라이즈에서 허용해도 조직 설정이 자동으로 켜지지 않고, CodeQL advanced setup만으로 조건을 충족한다고 공식 문서는 말하지 않습니다. 조직 옵션도 default setup을 사용하는 저장소를 대상으로 해요. 설정은 네 층인데 화면에서는 결과 하나만 기다리게 되니, 살짝 총체적난국 가능.
이 기능을 위해 별도 모델을 선택할 필요는 없습니다. 반대로 /.github/copilot-instructions.md나 /CLAUDE.md 같은 사용자 지침 파일로 탐지 방식을 조정할 수도 없어요.
PR의 AI 결과와 CodeQL 체크는 따로 기록해야 함
탐지는 PR 생성 시점과 이후 새 커밋마다 자동 실행됩니다. 빌드 시스템 없이 PR 코드에서 직접 동작하며, 저장소 문맥도 가져와 살펴봐요. CodeQL default setup은 선행 조건이지만 실행 상태는 독립적이라 CodeQL이 대기 중이거나 실패해도 AI 스캔은 실행될 수 있습니다.
결과도 모든 도구가 끝날 때까지 줄 세워 기다리지 않습니다. 준비되는 대로 게시되므로 AI 결과가 CodeQL보다 먼저 뜰 수도, 나중에 뜰 수도 있어요.
PR에서는 다음을 확인하면 됩니다.
- Conversation과 Files changed: 두 탭에서 결과가 보이는지 확인
AI라벨: 일반 code scanning 결과와 구분되는지 확인- 설명과 위험 해설: 후보로 판단한 근거가 무엇인지 기록
- 수정 제안: 제공 여부를 기록하되 모든 finding에 있다고 가정하지 않기
- Copilot Autofix: 가능한 경우에만 권장 코드 변경이 표시되는지 확인
가장 중요한 포인트는 병합 차단입니다. 일반 CodeQL 또는 SARIF 기반 code scanning 결과는 심각도 설정과 required check/ruleset에 따라 병합을 막을 수 있어요. 하지만 이 AI finding은 현재 정보 제공용이고 ruleset의 병합 요구 조건으로 사용할 수 없습니다. 저장소 Security view에 backlog alert로 쌓이지도 않아요.
다만 branch protection에서 모든 대화 해결을 요구한다면 알림 대화의 처리 여부가 팀의 병합 절차에 간접 영향을 줄 수 있습니다. 그래도 “AI finding 자체가 required check로 PR을 차단했다”와는 다른 이야기예요. 파일럿 표에 AI finding과 Code scanning results / CodeQL을 한 칸에 섞어 적으면 원인 찾기 어려움.
비프로덕션 PR로 유효성·오탐·비용을 함께 검증하는 법
실제 운영 저장소에 바로 넓게 켜기보다 비프로덕션 조직이나 격리된 테스트 저장소에서 시작합니다. 실사용 언어 하나와 공식 탐지 범주 하나를 골라 작은 PR로 확인하는 방식이 깔끔해요.
1단계: 시작 상태를 고정합니다
Code Security와 Copilot 라이선스, 엔터프라이즈 AI Findings, 조직 opt-in, 저장소 opt-out, CodeQL default setup 상태를 캡처합니다. 테스트 전 조직의 AI credits 사용량과 관찰 시점도 함께 기록해요.
이 기준 상태가 없으면 결과가 안 떴을 때 기능 문제인지 설정 문제인지 구분하기 어렵습니다. 첫 단추 중요함.
2단계: 양성 PR과 음성 대조 PR을 만듭니다
실제 자격 증명이나 운영 비밀은 넣지 않습니다. 실행되지 않는 테스트 fixture 또는 폐쇄된 샘플에서, 공식 탐지 범주에 대응하는 최소 변경만 준비해요.
- 양성 사례: 사용자 입력을 shell 문자열에 직접 결합하거나, HCL/Docker image tag를 고정하지 않거나, 검증 없이 사용자 URL을 가져오는 변경
- 음성 대조: allowlist 검증, parameterized API, 고정 digest처럼 같은 기능을 안전하게 구현한 변경
한 PR에 취약 유형을 여러 개 넣지 않는 게 좋습니다. 무엇을 탐지한 건지 애매해지고, 새 커밋마다 실행되는 AI credits 소비 원인도 흐려지거든요.
PR 생성 시각, 각 커밋 시각, AI 결과가 처음 표시된 시각, CodeQL 완료 시각은 따로 남깁니다. “대충 금방 떴음”은 나중에 비교가 안 됨.
3단계: 화면과 병합 동작을 분리해 봅니다
Conversation과 Files changed 양쪽에서 AI 라벨을 확인하고, 설명·위험 해설·수정 제안·Autofix 유무를 기록합니다. 그다음 병합 버튼과 Code scanning results / CodeQL 체크 상태를 별도로 살펴봐요.
새 커밋을 push한 뒤 재실행되는지도 확인합니다. 수정 후 finding이 사라지는지 또는 다른 상태로 바뀌는지 보고, Security view에 backlog alert가 생기지 않는지도 확인하면 PR 전용이라는 제약까지 한 번에 검증 가능.
4단계: AI의 말보다 실제 공격 경로를 판정합니다
AI가 찾았다고 취약점 확정은 아닙니다. 각 finding에 아래 질문을 붙이고 예/아니오/불명과 근거를 남겨야 해요.
- 공격자가 제어할 수 있는 입력이 실제로 있는가?
- 그 입력이 위험한 sink 또는 보안 설정까지 도달하는가?
- 프레임워크의 기본 escaping, validation, authorization, network control을 놓치지 않았는가?
- 제안된 수정이 기능을 유지하면서 위험 경로를 제거하는가?
- 수정 커밋 뒤에도 같은 패턴이 다시 탐지되는가?
- 담당 개발자와 AppSec 검토자의 판정이 일치하는가?
명백히 부정확하다면 thumbs down으로 피드백할 수 있습니다. 다만 thumbs up/down은 품질 개선용이지 조직의 판정 기록은 아니에요. 내부 이슈나 PR 댓글에 사람의 판단 근거를 별도로 남겨야 나중에 같은 패턴을 다시 볼 때 마음 편-안.
5단계: 판정표로 도입 여부를 비교합니다
| 항목 | 기록값 |
|---|---|
| 저장소·언어/프레임워크 | 테스트 대상 |
| 취약 범주 | 공식 9개 범주 중 하나 |
| 예상 결과 | 탐지 / 미탐지 |
| 실제 AI finding | 있음 / 없음 |
AI 라벨 |
있음 / 없음 |
| 설명·수정 제안 | 있음 / 없음 |
| 사람 판정 | true positive / false positive / 불명 |
| CodeQL 결과 | 별도 기록 |
| 병합 차단 | AI 자체 / 다른 체크·정책 / 없음 |
| PR 생성→표시 시간 | 측정값 |
| 수정 후 재검증 | 해소 / 지속 / 불명 |
| credits 변화 | 관찰값과 혼입 가능성 |
탐지율이나 오탐률을 말하려면 양성·음성 fixture 수, 버전, 반복 횟수, 판정자를 미리 정하고 공개해야 합니다. 작은 파일럿 숫자를 제품 전체 정확도처럼 확대하면 안 돼요. 공식 벤치마크 수치도 현재 확인되지 않았습니다.
AI credits는 쓰지만 PR당 가격은 계산할 수 없음
공개 미리보기에서는 탐지가 실행될 때만 조직의 AI credits가 소모됩니다. PR 생성뿐 아니라 새 커밋마다 실행되므로 커밋 횟수도 비용 변수가 될 수 있어요.
2026년 7월 28일 기준 Copilot 과금 문서는 1 AI credit을 미화 0.01달러로 정의합니다. 조직용 포함량은 Business 사용자당 월 1,900 credits, Enterprise 사용자당 월 3,900 credits이며 청구 주체 수준에서 공유돼요. 여기에 GitHub Code Security/Advanced Security 라이선스와 Copilot 라이선스도 필요합니다.
문제는 이 보안 탐지에 쓰이는 모델, 입력·출력 토큰, 실행 1회당 credits가 공개되지 않았다는 점입니다. 그래서 포함량만 보고 “PR 몇 개까지 가능” 또는 “PR당 얼마”를 역산할 수 없어요. 숫자가 있으니 계산기부터 켜고 싶지만 여기서는 후퇴.
테스트 전후 공유 credits 사용량을 같은 시간대에 기록하되, 다른 Copilot 사용이 섞였다면 이 기능만의 소비량으로 단정하지 않습니다. Advanced Security의 실제 계약 단가와 구매 조건도 계정 계약 및 최신 공식 과금 문서에서 확인해야 해요.
AI 라벨은 확인 가능, confidence 점수는 다른 기능 이야기
PR용 AI 탐지 공식 문서에서 확인되는 신뢰 표시는 AI indicator와 결과 설명, 위험 해설, thumbs up/down입니다. 대부분의 finding에는 수정 제안이 제공되지만, severity나 confidence 점수가 표시된다고 명시하지는 않습니다.
같은 날 공개된 Copilot 앱의 /security-review는 별도 기능입니다. 사용자가 명령으로 실행하는 on-demand 검사이고, high-confidence findings를 severity와 confidence로 점수화한다고 발표됐어요. 반면 PR AI 탐지는 조건이 갖춰진 저장소에서 PR 생성과 새 커밋에 자동 실행됩니다.
날짜도 비슷하고 이름도 비슷해서 섞기 딱 좋은 조합… 실제 PR 화면을 확인하기 전에 “confidence가 낮은 결과는 무시하면 된다” 같은 운영 규칙을 만들지 않는 게 안전합니다. PR에서는 AI 라벨로 출처를 구분하고, 유효성은 앞의 공격 경로 체크리스트로 사람이 판정하면 됩니다.
도입 판단은 탐지 개수보다 팀이 처리할 수 있는지로
이 기능은 CodeQL이 다루지 못한 영역의 PR 변경분을 한 번 더 살펴볼 수 있다는 점이 매력적입니다. 반면 advisory 결과이고, 전체 지원 언어·정확도·실행당 비용이 확정 공개되지 않았으며, Security view backlog와 ruleset 병합 게이트도 제공하지 않아요. 장점과 운영 부담이 아주 선명한 공개 미리보기입니다.
그래서 탐지가 몇 개 떴는지만 볼 게 아니라, 팀이 true positive와 false positive를 같은 기준으로 판정할 수 있는지, 수정 뒤 재검증이 되는지, credits 변화를 추적할 수 있는지를 봐야 해요. AppSec 검토자와 개발자가 제한된 PR 몇 개를 함께 보는 방식이라면 도입 판단에 필요한 그림이 꽤 또렷해질 듯.
도입 전 공식 문서에서 현재 공개 미리보기 조건과 조직의 AI credits 예산을 확인한 뒤, 비프로덕션 저장소의 제한된 PR로 먼저 검증하세요.
FAQ
공개 저장소에서도 Copilot 라이선스와 AI credits가 필요한가요?
일반 code scanning과 일부 Advanced Security 기능이 공개 저장소에서 무료라는 사실을 이 기능까지 확장하면 안 됩니다. 현재 공개 미리보기 상세 문서는 Advanced Security와 Copilot 라이선스를 요구하고, 발표문은 탐지 실행 시 조직 AI credits를 소비한다고 설명합니다.
CodeQL advanced setup만 사용하는 저장소에서도 켤 수 있나요?
공식 문서가 선행 조건으로 명시한 것은 CodeQL default setup입니다. advanced setup만으로 충족된다고 안내하지 않으므로, 파일럿 전에 대상 저장소의 default setup 상태를 확인해야 합니다.
AI finding이 뜨면 Code scanning results 체크가 실패하나요?
그렇게 연결되지는 않습니다. AI finding은 현재 advisory이며 ruleset 병합 요구로 사용할 수 없어요. 일반 CodeQL·SARIF 결과의 required check와 AI finding을 따로 기록해야 정확히 판단할 수 있습니다.
AI 결과가 저장소 Security view에 계속 남나요?
아니요. 이 기능은 PR 전용이며 AI finding을 Security view의 backlog alert로 만들지 않습니다.
AI 결과에 confidence 점수가 표시되나요?
PR용 기능의 공식 문서는 AI 라벨과 설명, 위험 해설, thumbs up/down을 명시하지만 confidence 점수 표시는 명시하지 않습니다. severity·confidence 점수는 별도 Copilot 앱 /security-review 발표와 혼동하지 않아야 해요.
오탐은 어떻게 처리하나요?
먼저 공격자 제어 입력에서 위험한 sink까지 실제 경로가 있는지, 기존 완화책을 놓쳤는지, 제안 수정이 기능을 보존하는지 사람이 확인합니다. 부정확한 결과에는 thumbs down을 남길 수 있지만, 팀의 판정 근거는 내부 이슈나 PR 댓글에 별도로 기록하는 편이 좋습니다.
