자동화된 취약점 조치: 발견부터 수정까지

자동화된 취약점 조치의 의미

취약점 조치는 영향받는 패키지를 업그레이드하거나, 패치를 적용하거나, 구성 요소를 교체해 소프트웨어에서 알려진 취약점을 제거하는 일입니다. 자동화된 조치는 이 작업의 기계적인 부분을 소프트웨어에 맡깁니다. 발견 사항을 읽고, 어떤 버전이 이를 수정하는지 파악하고, 매니페스트, 잠금 파일 또는 코드를 변경한 뒤, 대개 풀 리퀘스트로 변경을 제안합니다.

현대 코드베이스의 알려진 취약점 대부분이 존재하는 서드파티 종속성의 경우, 이 순환 과정은 어떤 도구에서나 같습니다.

1. 인벤토리. 출시하는 각 결과물에 어떤 패키지가 어떤 버전으로 들어 있는지 파악합니다.
2. 매칭. 그 인벤토리를 보안 권고와 대조하고, 새 권고가 발표될 때마다 계속 대조합니다.
3. 우선순위 지정. 심각도, 악용 여부, 노출 정도에 따라 무엇을 먼저 수정할지 결정합니다.
4. 수정. 수정된 버전을 선택해 업데이트하고, 업그레이드로 무언가가 깨지면 코드를 조정합니다.
5. 검증. 변경 사항을 빌드하고 테스트한 뒤, 실제로 출시된 것이 수정된 버전인지 확인합니다.
6. 기록. 무엇이 영향을 받았고, 언제, 어떤 릴리스에서 수정되었는지 이력을 남깁니다.

자동화는 작업이 반복적인 2, 4, 6단계에서 가장 강력합니다. 입력이 잘못된 곳에서 가장 약하며, 나머지 모든 단계의 입력은 1단계입니다.

자동화된 조치의 네 가지 유형

접근 방식	하는 일	예시	한계
종속성 업데이트 봇	취약한 종속성을 수정된 버전으로 올리는 풀 리퀘스트 생성	Dependabot 보안 업데이트, Renovate	리포지토리의 매니페스트와 잠금 파일을 바탕으로 작동하며, 호환성을 깨는 업그레이드는 여전히 사람이 코드를 조정해야 함
SCA 수정 풀 리퀘스트	상용 SCA 도구가 제기한 발견 사항에 대한 업그레이드 풀 리퀘스트 생성	Snyk, Black Duck, Aikido, Endor Labs	적용 범위가 다양함: 직접 종속성만 수정하는 도구도 있고, 패치나 백포트를 추가하는 도구도 있음
AI 코드 수정	발견 사항(주로 정적 분석 알림)에 대한 코드 변경 생성	GitHub Copilot Autofix	검토가 필요한 비결정적 제안. AI 취약점 수정 참고
인프라 자동 조치	규칙이 발동하면 잘못된 구성을 되돌리거나 호스트를 패치	클라우드 보안 태세 관리 및 엔드포인트 도구	실행 중인 인프라를 다루며, 출시하는 소프트웨어 내부의 종속성은 다루지 않음

앞의 세 가지는 모두 출시하는 코드를 수정하며, 하나의 가정을 공유합니다. 수정 대상인 취약한 패키지 목록이 올바른 목록이라는 가정입니다.

모든 수정은 인벤토리에 의존합니다

조치 도구는 자신이 알고 있는 취약점만 수정할 수 있고, 알고 있는 취약점은 인벤토리에 들어 있는 것뿐입니다. 대부분의 인벤토리는 매니페스트, 잠금 파일, 설치된 패키지 또는 완성된 컨테이너 이미지 같은 파일로부터 재구성됩니다. 이러한 재구성은 예측 가능한 방식으로 무언가를 놓칩니다.

• 파일에 선언되지 않은 패키지. 빌드가 내려받는 도구, 베이스 이미지, 플러그인, 스크립트로 설치되는 모든 것은 잠금 파일에 나타나지 않으므로, 이에 대한 수정 풀 리퀘스트는 결코 열리지 않습니다.
• 잠금 파일과 다른 버전. 특히 커밋된 잠금 파일이 없을 때 빌드는 스캐너가 읽는 버전과 다른 버전으로 확정할 수 있습니다. 잘못된 버전을 기준으로 한 수정은 확신에 찬 오답입니다.
• 캐시에서 복원된 패키지. 캐시된 종속성은 다시 레지스트리를 거치지 않으므로, 빌드가 사용한 것이 리포지토리에 적힌 것보다 뒤처질 수 있습니다.

해법은 빌드가 실제로 사용한 것에서 출발하는 것입니다. 빌드 시점 SBOM은 빌드가 실행되는 동안 기록되므로, 매니페스트상 필요하다고 적힌 것이 아니라 작업이 실제로 가져온 패키지를 전이적 종속성까지 포함해 나열합니다. 여기서 출발하는 조치는 출시되는 것을 수정합니다.

무엇을 자동화하고 무엇을 남길 것인가

조치를 제대로 운영하는 대부분의 팀은 다음과 같이 나눕니다.

• 발견과 매칭은 자동화합니다. 새로운 보안 권고는 매일 발표됩니다. 출시된 모든 빌드를 수작업으로 다시 대조하는 일은 확장되지 않으며, 바로 소프트웨어가 잘하는 종류의 작업입니다.
• 제안은 자동화합니다. 수정된 버전을 고르고 변경을 여는 일은 기계적입니다. 관련 업데이트를 묶어 검토자가 20개가 아닌 하나의 풀 리퀘스트를 보게 하세요.
• 머지는 테스트로 통제합니다. 테스트 스위트가 다루는 패치 수준 보안 업데이트는 자동 머지하세요. 호환성을 깨는 업그레이드와 테스트 커버리지가 없는 항목은 사람에게 맡기세요.
• 판단은 사람이 합니다. 취약점이 제품에 영향을 미치는지, 위험한 업그레이드를 이번 주에 할 가치가 있는지는 결정의 문제입니다. 같은 질문을 두 번 하지 않도록 예를 들어 VEX 문으로 기록하세요.

조치 도구를 평가하는 방법

도구가 리포지토리에 풀 리퀘스트를 열도록 맡기기 전에 다음을 물어보세요.

1. 취약점 목록은 어디서 오는가: 리포지토리의 파일, 스캔한 이미지, 아니면 빌드 자체인가?
2. 전이적 종속성을 수정하는가, 아니면 선언한 직접 종속성만 수정하는가?
3. 수정 버전을 어떻게 선택하는가: 최소 패치 버전, 최신 버전, 아니면 고정한 버전인가?
4. 수정이 보이기 전에 빌드되고 테스트되는가, 아니면 풀 리퀘스트가 처음 실행되는 시점인가?
5. 검토자가 넘쳐나지 않도록 업데이트를 묶고 일정을 잡을 수 있는가?
6. 어떤 릴리스가 영향을 받았고 각 수정이 언제 출시되었는지 기록하는가?

현재 CRACI의 역할

CRACI는 GitHub Actions 작업을 CRACI 러너에서 실행하고, 전이적 종속성과 캐시에서 복원된 패키지를 포함해 각 작업이 실제로 가져온 패키지를 모든 작업의 완전성 상태와 함께 기록합니다. 이 기록이 조치 워크플로의 출발점이 되어야 하는 인벤토리입니다.

CRACI는 모니터링 중인 SBOM을 지속적으로 재평가하므로, 새로운 보안 권고가 발표되면 리포지토리 전반에서 어떤 출시 빌드가 영향을 받는지 확인할 수 있습니다. 보안 팀은 각 발견 사항을 트리아지해 수정 책임이 있는 팀에 보내며, CRACI는 취약점이 제품에 어떤 영향을 미치는지 기록할 수 있도록 VEX를 지원합니다. 그다음 빌드의 SBOM은 빌드가 실제로 수정된 버전을 사용했는지 보여 줍니다. 전체 기능은 취약점 추적 페이지에서 다룹니다.

EU Cyber Resilience Act에 따라 제조사는 보안 업데이트를 포함해 취약점을 지체 없이 해결하고 조치해야 합니다. 각 빌드에 무엇이 들어 있었고 각 수정이 언제 출시되었는지에 대한 기록이 이 프로세스에 필요한 증거입니다.

자동화된 취약점 조치: 자주 묻는 질문

자동화된 취약점 조치란 무엇인가요?

자동화된 취약점 조치는 사람이 수고를 들이지 않아도 취약점 발견 사항을 수정으로 바꿔 주는 소프트웨어입니다. 수정된 버전을 파악하고, 매니페스트, 잠금 파일 또는 코드를 변경하며, 대개 풀 리퀘스트로 변경을 제안합니다. 무엇을 머지할지는 여전히 사람이나 팀이 신뢰하는 정책이 결정합니다.

취약점 조치와 완화의 차이는 무엇인가요?

조치는 예를 들어 수정된 버전으로 업그레이드하거나 패치를 적용해 취약점을 제거합니다. 완화는 예를 들어 영향받는 기능을 비활성화하거나 공격 경로를 차단해, 취약점이 남아 있는 동안 위험을 줄입니다. 완화는 시간을 벌어 주고, 조치는 발견 사항을 종결합니다.

취약점 조치를 완전히 자동화할 수 있나요?

일부는 가능합니다. 영향받는 빌드 찾기, 보안 권고 매칭, 버전 업 제안은 기계적인 작업이라 자동화가 잘 됩니다. 호환성을 깨는 업그레이드가 안전한지, 취약점이 제품에 영향을 미치는지 판단하는 일에는 여전히 판단력이 필요합니다. 대부분의 팀은 제안을 자동화하고, 머지는 테스트의 뒷받침을 받는 사람에게 맡깁니다.

Dependabot은 자동화된 취약점 조치를 하나요?

Dependabot 보안 업데이트는 GitHub가 리포지토리의 종속성 그래프에 대해 제기하는 알림에 대해, 취약한 종속성을 최소 패치 버전으로 업데이트하는 풀 리퀘스트를 엽니다. 이는 매니페스트와 잠금 파일이 선언한 것에 대한 자동화된 조치입니다. 선언된 것과 출시된 것이 어디서 다른지는 CRACI vs Dependabot에서 다룹니다.

취약점 조치 도구에서 무엇을 확인해야 하나요?

취약점 목록이 어디서 오는지, 전이적 종속성을 처리하는지, 수정 버전을 어떻게 고르는지, 수정이 보이기 전에 빌드되고 테스트되는지, 무엇이 언제 수정되었는지 기록하는지를 확인하세요. 마지막 항목은 감사와 제조사에게 취약점을 지체 없이 조치하도록 요구하는 CRA에 중요합니다.