AI 취약점 수정: AI 수정 풀 리퀘스트로 할 수 있는 것

AI 수정이란

AI 취약점 수정은 언어 모델을 사용해 알려진 취약점의 수정 사항을 만들어 냅니다. 세 가지 형태가 있습니다.

• 코드 수정 제안. 모델이 정적 분석 알림 옆에 패치를 제안합니다. 예를 들어 GitHub Copilot Autofix는 "풀 리퀘스트와 기본 브랜치에서 발견된 CodeQL 알림에 대한 코드 변경 제안을 자동으로 생성"합니다.
• 코드까지 맞춰 고치는 종속성 업그레이드. 버전을 올리는 것은 쉽습니다. 어려운 부분은 새 버전이 가져오는 함수 이름 변경이나 기본값 변경입니다. 모델은 이런 후속 변경을 같은 풀 리퀘스트 안에서 처리할 수 있습니다.
• 에이전트 기반 수정. 에이전트가 여러 단계에 걸쳐 스스로 수정을 진행합니다. 코드를 변경하고, 빌드와 테스트를 실행하고, 실패 내용을 읽고, 다시 시도하며, 검사를 통과했을 때만 풀 리퀘스트를 엽니다.

AI 수정이 제 몫을 하는 곳

규칙 기반 업데이트 봇은 이미 취약한 패키지를 수정된 버전으로 올리는 풀 리퀘스트를 엽니다. 그러나 업그레이드가 무언가를 깨뜨리면 멈춥니다. 호출 코드를 맞춰 고치는 일은 규칙으로 정할 수 없기 때문입니다. 백로그가 쌓이는 곳이 바로 여기입니다. 메이저 버전 변경을 처리할 시간이 아무에게도 없어 몇 달째 열려 있는 보안 업데이트가 그렇습니다.

변경 로그를 읽고, 호출 위치를 찾아 다시 작성하는 일은 언어 모델이 잘하는 종류의 작업입니다. 업그레이드와 코드 변경을 함께 담고 빌드와 테스트까지 마친 AI 수정은 누군가의 일주일짜리 작업을 한 번의 검토로 바꿉니다.

AI 수정이 잘못되는 곳

한계를 가장 분명하게 설명하는 것은 공급업체 자신입니다. Copilot Autofix에 대해 GitHub는 이렇게 씁니다.

• "비결정적인 생성 모델을 사용합니다. 같은 알림과 코드라도 실행 가능한 제안을 만들지 못하거나, 시도할 때마다 제안이 달라질 수 있습니다."
• "이 시스템은 어떤 종속성 버전이 지원되거나 안전한지 알지 못하며, 통계적으로 그럴듯한 이름으로 게시된 가공의 종속성을 제안할 수 있습니다."

두 번째 지적은 가정이 아닙니다. 코드 생성 모델에 관한 연구는 모델이 존재하지 않는 패키지를 얼마나 자주 추천하는지 측정했습니다. 그런 이름은 공격자가 등록해 멀웨어로 채울 수 있습니다. 환각으로 만들어진 패키지를 설치하는 수정은 취약점 하나를 더 나쁜 것으로 바꿔 놓습니다.

세 가지 안전장치로 위험 대부분을 막을 수 있습니다.

1. 모든 수정을 빌드하고 테스트합니다. 사람이 검토하기 전에 해 두면 검토 시간이 실제로 작동하는 수정에 쓰입니다.
2. 추가되거나 변경된 모든 패키지를 확인합니다. 레지스트리와 예상한 버전에 비추어 대조합니다.
3. 병합은 사람이 맡습니다. AI 수정은 기여자의 풀 리퀘스트이지 결정이 아닙니다.

잘못된 입력에서는 잘못된 풀 리퀘스트가 나온다

AI 수정 도구는 주어진 취약점을 고칩니다. 그 목록이 잠금 파일이나 스캔한 이미지에서 재구성된 것이라면, 재구성의 모든 빈틈을 그대로 물려받습니다. 어떤 매니페스트에도 선언되지 않은 채 빌드가 내려받는 도구, 빌드가 실제로 확정한 것과 다른 버전, 캐시에서 복원된 패키지가 그렇습니다. 그러면 도구는 일부 취약점에 대해서는 자신 있게 풀 리퀘스트를 열고, 다른 취약점에 대해서는 아예 알지 못합니다.

일부 팀은 한발 더 나아가 모델에게 종속성 자체를 파악하게 합니다. 그러면 인벤토리마저 비결정적이 됩니다. 프로세스에서 매번 같은 결과가 나와야 하는 유일한 부분이 바로 인벤토리인데도 말입니다. 추정한 인벤토리가 증거가 될 수 없는 이유는 AI 생성 SBOM에서 다룹니다.

효과가 있는 패턴은 아래에 결정적 데이터를, 그 위에 AI의 판단을 두는 것입니다. 각 빌드가 실제로 포함하는 것을 기록한 목록을 조회 방식으로 권고와 대조하고, 수정 코드는 AI가 작성합니다.

CRACI의 역할

CRACI는 결정적 계층입니다. GitHub Actions 작업을 CRACI 러너에서 실행하고, 전이적 종속성과 캐시에서 복원된 패키지를 포함해 각 작업이 실제로 가져온 패키지를 모든 작업의 완전성 상태와 함께 기록합니다. 모니터링 중인 SBOM을 지속적으로 재평가하므로 새 권고가 나오면 영향을 받는 빌드에 바로 나타나고, 보안 팀은 각 발견 사항을 분류해 수정을 담당하는 팀에 보냅니다.

AI 수정이 출발점으로 삼아야 하는 목록이 바로 이것이며, 수정이 병합된 뒤에는 다음 빌드의 SBOM이 수정된 버전을 빌드가 실제로 사용했는지 보여 줍니다. 전체 기능은 취약점 추적에서, 각 접근 방식이 어디에 맞는지는 AI vs 결정적 보안에서 확인하세요.

AI 취약점 수정: 자주 묻는 질문

AI 취약점 수정이란 무엇입니까?

AI 취약점 수정은 언어 모델을 사용해 취약점의 수정 사항을 만들어 냅니다. 정적 분석 결과에 대한 코드 변경일 수도 있고, 종속성 업그레이드와 그 업그레이드에 필요한 코드 변경일 수도 있습니다. 결과물은 대개 사람이 검토할 제안이나 풀 리퀘스트입니다.

에이전트 기반 수정이란 무엇입니까?

에이전트 기반 수정은 AI 에이전트에게 도구를 주어 여러 단계에 걸친 수정을 스스로 수행하게 합니다. 발견 사항을 읽고, 코드를 변경하고, 빌드와 테스트를 실행하며 통과할 때까지 반복한 뒤 풀 리퀘스트를 엽니다. 일회성 제안과 다른 점은 사람이 보기 전에 에이전트가 자신의 작업을 직접 검증한다는 것입니다.

AI가 생성한 보안 수정은 병합해도 안전합니까?

다른 기여자의 풀 리퀘스트와 똑같이 다루세요. GitHub는 Copilot Autofix가 비결정적이며 존재하지 않는 종속성을 제안할 수 있다고 경고합니다. 따라서 변경 내용을 검토하고, 테스트를 실행하고, 추가되는 모든 패키지가 실제로 존재하며 예상한 바로 그 패키지인지 확인해야 합니다.

AI가 종속성의 취약점을 찾을 수 있습니까?

그 부분에는 맞지 않는 도구입니다. 어떤 패키지 버전이 알려진 권고의 영향을 받는지는 조회의 문제이며, 매번 같은 결과가 나와야 합니다. 취약한 패키지 목록은 결정적 도구가 기록된 SBOM에서 만들게 하고, AI는 판단이 도움이 되는 곳, 즉 수정 사항을 작성하고 조정하는 데 쓰세요.

AI 수정 도구가 제대로 작동하려면 무엇이 필요합니까?

실제로 취약한 것의 정확한 목록, 수정 사항을 검증할 수 있는 빌드와 테스트 스위트, 그리고 병합을 맡는 사람입니다. 가장 자주 빠지는 것은 첫 번째입니다. 제품에 포함되지 않는 패키지에 대한 수정 풀 리퀘스트는 소음일 뿐이며, 인벤토리가 놓친 취약한 패키지에는 수정 풀 리퀘스트가 아예 만들어지지 않습니다.