비교
AI 보안 도구는 코드를 읽습니다. 빌드는 여전히 누군가 기록해야 합니다.
AI 코드 리뷰와 AI 분류는 보안 프로그램에 유용한 추가 요소입니다. 이들은 완전하고 반복 가능한 데이터 위에서 가장 잘 작동합니다. CRACI가 자리하는 곳이 바로 그 계층입니다.
업데이트
여러분의 팀도 이미 보안에 AI를 도입하고 있을 것입니다
이제 대부분의 엔지니어링 팀은 보안 업무에 AI 도구를 하나 이상 사용합니다. 한 모델은 풀 리퀘스트를 리뷰합니다. 다른 모델은 정적 분석 알림에 대한 수정을 제안합니다. 세 번째 모델은 스캐너 발견 사항을 "확인 필요"와 "아마도 노이즈"로 분류합니다. 이 도구들은 실제로 시간을 절약해 주며, 이 페이지는 그 도구들에 반대하지 않습니다.
유용한 질문은 이 도구들이 어떤 일을 맡아야 하고, 어떤 일에 매번 같은 결과가 나오는 기록이 필요한가입니다. 함께 따라오는 질문은 AI 도구가 종속성에 대해 판단할 때 무엇을 읽고 있는가입니다.
AI 보안 도구가 잘하는 것
- AI 코드 리뷰. GitHub Copilot 코드 리뷰는 풀 리퀘스트에 자연어 코멘트와 코드 제안을 남기며, 리포지토리별 지침을 따를 수 있습니다. 바쁜 리뷰어가 건너뛰는 읽기 작업에 강합니다.
- AI 수정. GitHub Copilot Autofix는 "풀 리퀘스트와 기본 브랜치에서 발견된 CodeQL 알림에 대한 코드 변경 제안을 자동으로 생성"합니다. 개발자는 CWE 페이지 링크 대신 알림 옆에서 제안된 패치를 받습니다.
- AI 분류. Semgrep의 AI 기능은 Semgrep Code의 발견 사항을 자동 분류하고 수정을 제안합니다. Semgrep은 노이즈 필터링이 "Semgrep Code 발견 사항을 오탐으로 분류하는 데 95% 이상 정확하다"고 문서화하고 있습니다.
뒤의 두 가지에서 패턴을 볼 수 있습니다. Copilot Autofix는 CodeQL 알림을 대상으로 작동합니다. Semgrep의 분류는 Semgrep의 규칙 기반 엔진이 낸 발견 사항을 대상으로 작동합니다. AI는 결정론적 출력 위에 판단을 더할 뿐, 근본이 되는 발견 사항을 직접 만들어 내지는 않습니다.
공급업체가 말하는 한계
AI 도구가 어디서 멈추는지에 대한 가장 명확한 설명은 공급업체 자신에게서 나오며, 이는 높이 평가할 만합니다.
- 코드 리뷰에 대해 GitHub는 "Copilot은 코드에 존재하는 모든 문제를 식별하지 못할 수 있다"고, 또한 "환각의 위험이 있다"고 쓰고 있습니다. 존재하지 않는 문제를 지적할 수 있다는 뜻입니다.
- Autofix에 대해 GitHub는 "비결정론적인 생성형 모델을 사용한다. 같은 알림과 코드라도 실행 가능한 제안을 생성하지 못하거나, 시도할 때마다 제안이 달라질 수 있다"고 쓰고 있습니다.
- 역시 Autofix에 대해: "시스템은 어떤 종속성 버전이 지원되거나 안전한지 알지 못하며, 통계적으로 그럴듯한 이름으로 게시된 가공의 종속성을 제안할 수 있다."
그렇다고 이 도구들의 유용성이 줄어들지는 않습니다. 이는 그들의 역할을 정의합니다. 이 도구들은 사람이 확인할 제안을 만듭니다. 그것은 사람이 대조할 기준이 되는 기록을 만드는 일과는 다른 역할입니다.
두 계층, 두 역할
| 기능 | CRACI | AI 보안 도구 |
|---|---|---|
| 답하는 질문 | 이 빌드는 무엇을 가져왔고, 그것이 출시되었는가? | 이 코드나 이 발견 사항이 실제 문제인가? |
| 빌드가 가져온 것을 기록 | SBOM, 네트워크 추적, 출처 증명 데이터 | 다른 무언가가 기록한 것만 확인 |
| 같은 입력, 같은 출력 | 추론하는 것이 없음 | 공급업체 문서에 따르면 출력이 달라질 수 있음 |
| 완전성 명시 | 작업별 및 캐시별 | 제공된 코드와 발견 사항으로 한정 |
| 코드 로직 리뷰 | Copilot 코드 리뷰가 풀 리퀘스트에 코멘트 | |
| 발견 사항 분류 | 발견 사항을 분류해 팀에 배정 | Semgrep Assistant 자동 분류 |
| 최적의 용도 | 감사인이나 고객에게 제출할 수 있는 증거 | 사람 리뷰어가 판단에 활용하는 조언 |
- 포함
- 미포함
CRACI는 기록 계층에 있습니다. CRACI는 GitHub Actions 러너를 대체하며(runs-on을 craci로
바꾸면 됩니다), 작업이 실행되는 동안 패키지를 인식하는 프록시가 패키지 소스로 향하는 빌드 트래픽을 관찰합니다.
결과물은 작업이 실제로 가져온 것의 SBOM, 작업 및 캐시별 완전성 상태, 그리고 네트워크 추적입니다. API는 SBOM, 네트워크
추적, 출처 증명을 반환합니다.
결정론적 가시성이 필요한 곳
"우리가 영향을 받습니까?"
새로운 보안 권고가 나오면 가장 먼저 묻는 것은 영향을 받는 버전이 빌드에 포함되었는지입니다. CISA의 2026년 SBOM 최소 요소는 이 요건을 분명히 밝힙니다. SBOM을 받은 쪽은 "SBOM에 해당 구성 요소가 나열되어 있지 않다면 새로 보고된 취약점이 자신에게 영향을 주지 않는다고 결론 내릴 수 있어야 한다." 이 결론은 목록이 완전할 때만 성립합니다. 모델은 답을 읽는 데 도움을 줄 수 있지만, 빌드에 무엇이 있었는지 결정하는 주체가 되어서는 안 됩니다.
CRACI는 빌드와 리포지토리 전반의 취약점을 집계하고, 새로운 취약점이 공개될 때마다 모니터링 중인 SBOM을 재평가하므로, 이 질문에 기록된 내용으로 답합니다.
AI가 추가한 종속성
AI 코딩 어시스턴트는 종속성을 추가하며, 연구에 따르면 때때로 존재하지 않는 패키지 이름을 제시합니다. USENIX Security 2025에서 발표된 한 연구는 16개 모델로 코드 샘플 576,000개를 생성했으며, 환각 패키지의 평균 비율이 상용 모델은 최소 5.2%, 오픈 소스 모델은 21.7%라는 결과를 얻었습니다. 오늘 존재하지 않는 이름이 내일 등록될 수 있습니다. 누가 또는 무엇이 종속성을 추가했든, CRACI는 빌드가 실제로 내려받은 패키지를 기록하며, 네트워크 이그레스 정책으로 작업이 승인된 패키지 소스에만 접근하도록 제한할 수 있습니다.
감사와 고객 질의
감사인이나 고객의 보안 팀은 출시된 내용을 어떻게 아는지 물을 것입니다. "모델이 그렇게 말했다"는 약한 답입니다. "릴리스 빌드 중에 기록된 SBOM과 그 완전성 상태, 그리고 해당 작업의 네트워크 추적이 여기 있다"는 강한 답입니다. SBOM은 취약점을 포함해 CycloneDX 또는 SPDX로 내보낼 수 있으며, API는 SBOM, 네트워크 추적, 출처 증명을 반환합니다.
반복 가능한 답
어떤 질문은 누가 언제 묻든 같은 답이 필요합니다. 지난 화요일 릴리스는 어떤 패키지를 가져왔습니까? 생성형 모델은 그 답을 잘 표현할 수 있지만, 공급업체 스스로 밝히듯 매번 다르게 표현할 수 있습니다. 기록된 빌드는 하나의 답을 줍니다.
두 계층을 함께 쓰는 방법
효과적인 패턴은 Copilot Autofix와 Semgrep이 이미 쓰고 있는 방식입니다. 아래에는 결정론적 데이터, 그 위에는 AI의 판단입니다.
- AI 코드 리뷰와 AI 수정은 풀 리퀘스트에서 작동하게 하고, 모든 변경은 사람이 승인합니다.
- CRACI가 각 빌드가 가져온 것을 기록하고, 그 기록이 완전한지 명시하게 합니다.
- 종속성 위험에 AI의 도움이 필요할 때는 모델에 기록된 SBOM을 제공합니다. CRACI의 공개 REST API는 CycloneDX 형식의 SBOM, 작업의 네트워크 추적, 아티팩트의 출처 증명을 반환합니다.
- 증거로는 모델의 요약이 아니라 기록된 SBOM을 보관합니다.
팀이 코드의 상당 부분을 AI 어시스턴트로 작성한다면 AI 개발 보안 페이지에서 그 상황을 다루며, 빌드 시점 SBOM 생성에서 기록이 만들어지는 방식을 설명합니다.