GitHub Copilot security review 사용법: PR 전 로컬 변경 보안 검사하기
PR 전에 현재 변경부터 빠르게 살펴봐요
PR을 열기 직전인데 보안 리뷰를 따로 돌리자니 흐름이 한 번 끊기죠. GitHub Copilot security review 사용법은 생각보다 단순해요. 변경이 있는 Copilot app 세션에서 /security-review를 실행하고, 나온 항목을 사람이 확인해 수정한 다음 기존 PR 보안 검사로 넘기면 됩니다. 딱 앞단 필터 역할.
다만 이름만 보고 전체 저장소를 감사해 주는 기능으로 받아들이면 곤란합니다. 2026년 8월 4일 공식 자료를 대조한 기준으로 이 기능은 공개 프리뷰이고, 현재 로컬 변경을 대상으로 하는 가벼운 온디맨드 AI 리뷰예요. 이 글은 직접 실행 후기가 아니라 GitHub 출시 공지와 제품 문서를 비교한 사용·운영 가이드입니다. 실제 화면, 처리 속도, 오탐률은 확인하지 않았음.
실행 전에 계정과 앱 정책부터 확인해요
필요한 것은 GitHub 계정, Copilot 액세스 또는 자체 모델 제공자, 로컬 Git입니다. Copilot app에 작업할 로컬 폴더나 저장소를 연결할 수 있어요. Business나 Enterprise 환경에서 앱이 보이지 않는다면 조직·기업 관리자가 GitHub Copilot app 정책을 활성화했는지 먼저 확인해야 합니다. 앱 정책과 CLI 정책은 별개라서, CLI가 허용된다고 앱도 자동으로 허용된다고 보면 안 돼요. 여기서 한 번 헷갈리기 딱 좋음.
지원 플랜 문구는 시점에 따라 조금 다릅니다. 2026년 7월 14일 출시 공지는 Free, Pro, Business, Enterprise 사용자에게 security review 공개 프리뷰를 제공한다고 적었고, 현재 Copilot app 시작 문서는 앱이 모든 Copilot 플랜에서 제공된다고 안내해요. 다만 출시 공지만으로 Pro+와 Max의 /security-review 포함 여부를 따로 확정할 수는 없습니다. 게시 전 다시 확인할 부분.
/security-review는 활성 세션에서 이렇게 실행합니다
공식 실행 흐름은 세 단계입니다.
- 작업 중인 코드 변경이 있는 active agent session을 엽니다.
- 프롬프트 입력창에 정확히
/security-review를 입력하고 Enter를 누릅니다. - Copilot이 제시한 우선순위 결과와 severity, confidence, 수정 제안을 읽고 코드를 고칩니다.
GitHub의 app session 문서는 수정 뒤 같은 세션에서 다시 검사를 요청할 수 있다고 설명합니다. 여기까지가 제품 사용법이고, 그다음부터가 더 중요해요. 제안 수정을 그대로 받아들이지 말고 입력 경로, 인증·권한 경계, 기존 보호 로직, 회귀 위험을 사람이 확인한 뒤 테스트를 실행해야 합니다.
제가 권하는 운영 순서는 아래처럼 잡으면 됩니다. 공식 알고리즘이 아니라, AI 결과를 안전 판정으로 오해하지 않기 위한 HuntLab의 판단이에요.
- 현재 변경에
/security-review실행 - 지적된 경로와 실제 공격 가능성 확인
- 수정 후 단위·통합·보안 테스트 실행
- 같은 세션에서 다시 검사
- PR을 열고 CodeQL/code scanning, secret scanning, Dependabot 또는 dependency review, CI 테스트 통과 확인
명령 한 번으로 끝내고 싶지만 보안은 그렇게 마음 편-안하게 끝나지 않더라고요. 특히 이 조사에서는 앱이나 CLI에 인증해 직접 실행하지 않았기 때문에, 실제 응답 모양이나 수정 후 결과가 어떻게 달라지는지는 단정하지 않습니다.
severity와 confidence는 다른 축으로 읽어야 해요
GitHub는 결과에 severity와 confidence가 포함된다고 설명하지만 점수 범위, 임계값, 산정법은 공개하지 않았습니다. 그래서 아래 표는 GitHub의 공식 등급 정의가 아니라 실무 판독 틀입니다.
| 결과 조합 | 먼저 할 일 |
|---|---|
| severity 높음 · confidence 높음 | 실제 경로를 우선 재현하고 PR 전에 수정 |
| severity 높음 · confidence 낮음 | 무시하지 말고 입력 제약, 실행 경로, 권한 경계를 먼저 확인하고 오탐이면 근거 기록 |
| severity 낮음 · confidence 높음 | 수정 비용과 같은 문제가 반복될 가능성을 보고 처리 |
| 결과 없음 | 고신뢰 결과가 나오지 않았다고만 해석하고 후속 검사 유지 |
각 finding을 볼 때는 질문을 조금 더 구체적으로 쪼개야 합니다.
- 외부 입력이 지적된 source에 실제로 도달하는가?
- 산타이징, 인코딩, 매개변수화가 해당 sink에 맞게 적용됐는가?
- 공격자가 그 코드 경로에 도달할 인증과 권한이 있는가?
- 암호 알고리즘과 키 크기, mode, nonce/IV, 키 관리가 실제 위협 모델에 맞는가?
- 제안 수정이 기능, 오류 처리, 성능을 깨지 않는가?
- 테스트와 CodeQL 후속 분석도 같은 판단을 지지하는가?
severity가 높다는 말과 그 지적이 확실하다는 말은 같지 않아요. 반대로 confidence가 낮다고 냅다 무시하면 피해가 큰 경로를 놓칠 수 있습니다. 점수보다 코드 문맥 확인이 먼저인 이유.
찾는 취약점과 보장하지 않는 범위를 구분합니다
GitHub가 공개한 튜닝 대상 예시는 injection flaws, cross-site scripting, 불안전한 데이터 처리, path traversal, 약한 암호화입니다. 고신뢰 항목에 집중해 우선순위와 수정 제안을 보여 주는 방식이에요.
하지만 이 목록을 전체 지원 범위로 읽으면 안 됩니다. 공식 자료에는 모든 지원 언어·프레임워크·CWE 목록이나 정확도 수치가 없어요. Copilot CLI 명령 레퍼런스도 /security-review [PROMPT]를 active local changes에 대한 집중 리뷰로 정의하면서, 전체 저장소 보안 감사가 아니라고 명시합니다.
따라서 다음은 보장되지 않습니다.
- 기본 브랜치, 전체 히스토리, 배포 설정까지 포함한 완전한 보안 감사
- 모든 언어·프레임워크·CWE의 완전한 탐지
- 고정 쿼리와 버전으로 똑같이 재현되는 분석
- 비밀값과 취약한 오픈소스 의존성의 완전한 탐지
- 결과가 없을 때 저장소가 안전하다는 결론
여기서 말하는 ‘로컬 변경’은 검사 대상이 현재 로컬 또는 workstream 변경이라는 뜻입니다. 코드가 로컬 밖으로 전혀 나가지 않는다는 뜻 아님. 이 차이는 데이터 정책을 볼 때 꽤 큽니다.
CodeQL과 기존 보안 도구는 그대로 유지합니다
GitHub도 이 기능이 code scanning, Dependabot, secret scanning을 보완한다고 설명합니다. 역할을 시점별로 놓으면 구분이 쉬워요.
| 도구 | 주요 시점·대상 | 맡길 역할 |
|---|---|---|
Copilot /security-review |
PR 전 현재 변경 | 빠른 AI 초기 필터와 수정 제안 |
| CodeQL/code scanning | 기본 브랜치·PR·정기 또는 푸시 분석 | 쿼리·데이터 흐름 기반 분석, check·annotation·alert, 감사와 머지 통제 |
| Dependabot/dependency review | 의존성과 manifest·lockfile 변경 | 알려진 취약 의존성과 정책 위반 확인 |
| Secret scanning | 저장소의 토큰·키 등 비밀 패턴 | 비밀값 alert와 관리 흐름 유지 |
CodeQL은 기본 브랜치와 PR을 분석하고, 소스에서 sink까지 데이터 흐름을 보여 줄 수 있습니다. PR 체크를 필수로 만들어 머지를 막는 운영도 가능해요. 반면 /security-review는 코딩 중 원하는 시점에 부르는 자문형 검사에 가깝습니다. 빠르게 고칠 기회를 앞당기는 장점은 있지만 재현성과 거버넌스까지 대신하지는 못함.
개인 플랜은 데이터 학습 설정도 확인해야 합니다
보안성이 높은 저장소라면 명령부터 입력하기 전에 어떤 계정과 좌석으로 로그인했는지 확인하는 편이 낫습니다.
- Business/Enterprise: GitHub은 고객 데이터를 AI 모델 학습에 사용하지 않으며, DPA가 고객 승인 없는 사용을 금지한다고 명시합니다.
- Free/Pro/Pro+/Max: 2026년 4월 24일부터 입력, 출력, 코드 스니펫, 관련 맥락을 AI 모델 학습·개선에 사용할 수 있습니다. 개인 Copilot 설정의
Allow GitHub to use my data for AI model training을 Disabled로 바꿔 opt-out할 수 있어요.
이 내용은 /security-review만의 별도 정책이 아니라 Copilot 전반에 관한 개인 정책 문서를 기준으로 합니다. 이 기능이 정확히 어떤 파일, diff, 맥락을 어떤 모델 제공자에게 보내고 얼마나 보존하는지는 공식 기능 문서만으로 확정할 수 없어요. 또 opt-out은 모델 학습 사용에 관한 설정이지, 서비스 제공을 위한 데이터 처리까지 없어진다는 뜻도 아닙니다.
자체 모델 제공자를 연결했다면 그 제공자의 데이터 정책도 따로 확인해야 합니다. 조직 허용 모델인지, 앱 사용이 승인됐는지까지 보고 실행하면 됨.
PR 전 빠른 필터로 쓰면 역할이 선명해요
Copilot security review는 수정 흐름을 끊지 않고 현재 변경을 한 번 더 살피고 싶은 개발자에게 잘 맞습니다. 반면 전체 저장소 감사나 머지 차단용 SAST를 찾는 상황이라면 이 명령 하나로는 부족해요.
운영 순서는 ‘로컬 변경 초기 필터 → 사람의 문맥 판독과 테스트 → PR의 재현 가능한 보안 통제’가 딱 적당합니다. 공개 프리뷰라 지원 플랜·정책·UI는 게시 직전 다시 확인해야 하고요. 가볍게 먼저 보되, 안전하다는 최종 도장은 사람과 기존 도구가 찍는 구조. 이 정도가 솔직한 자리인 듯.
다음 단계가 필요하다면 HuntLab의 GitHub 코드 스캐닝 AI 탐지 글에서 CodeQL 기반 PR 후속 검증법을 확인해보세요.
FAQ
/security-review 결과가 없으면 현재 변경이 안전한가요?
아니요. 현재 변경에서 Copilot이 고신뢰 결과를 제시하지 않았다는 뜻으로만 봐야 합니다. 전체 저장소 감사가 아니므로 CodeQL, secret scanning, 의존성 검사와 테스트를 그대로 진행해야 해요.
GitHub Copilot Free에서도 security review를 쓸 수 있나요?
2026년 7월 14일 출시 공지는 Free, Pro, Business, Enterprise에 공개 프리뷰를 제공한다고 안내했습니다. 현재 앱 문서는 모든 Copilot 플랜을 지원한다고 적지만, Pro+와 Max에서 /security-review가 개별적으로 포함되는지는 출시 공지만으로 확정하지 않는 편이 안전합니다.
severity는 높은데 confidence가 낮으면 무시해도 되나요?
무시하기보다 실제 입력 경로, 입력 제약, 인증·권한 경계를 먼저 확인해야 합니다. 피해 가능성이 큰 항목일 수 있으니 재현하고, 오탐이라면 판단 근거를 남기는 방식이 낫습니다. 이는 GitHub의 공식 임계값이 아니라 실무 판독 기준이에요.
Business 또는 Enterprise에서 Copilot app이 보이지 않으면 무엇을 확인하나요?
관리자가 별도의 GitHub Copilot app 정책을 활성화했는지 확인하세요. 앱 정책과 CLI 정책은 서로 다르므로 CLI 사용 가능 여부만으로 판단하면 안 됩니다.
/security-review는 CodeQL 코드 스캐닝을 대체하나요?
대체하지 않습니다. /security-review는 PR 전 현재 변경을 빠르게 살피는 온디맨드 AI 리뷰이고, CodeQL은 기본 브랜치와 PR에서 재현 가능한 분석·알림·검사·감사와 머지 통제를 맡습니다. 앞뒤로 함께 쓰는 구성이 맞아요.
