취약점 익스플로잇 교환(VEX)
취약점 익스플로잇 교환(VEX)
소프트웨어 구성 요소 내 취약점의 익스플로잇 가능성 상태를 문서화하는 VEX 명세와, Docker Hardened Images가 사용하는 VEX 상태 및 정당화 코드를 알아봐요.
출처: 문서
본문
VEX란 무엇인가요?
VEX(Vulnerability Exploitability eXchange)는 소프트웨어 구성 요소 내 취약점의 익스플로잇 가능성 상태를 문서화하기 위한 명세예요. VEX는 주로 CSAF(OASIS)와 CycloneDX VEX 같은 업계 표준으로 정의되며, 미국 CISA(Cybersecurity and Infrastructure Security Agency)가 채택을 장려하고 있어요. VEX는 생산자가 주장한 상태 정보를 추가해 CVE(Common Vulnerabilities and Exposures) 식별자를 보완해요. 즉, 취약점이 출하된 그대로의 제품에서 익스플로잇 가능한지 여부를 나타내요. 이는 특정 제품 구성에 영향을 주지 않는 취약점을 식별해서 조직이 해결(resolution) 노력의 우선순위를 정하는 데 도움을 줘요.
VEX가 취약점 수와 스캐너 선택에 어떤 영향을 주는지는 Scanner integrations 문서를 봐요. VEX를 지원하는 DHI를 스캔하려면 Scan Docker Hardened Images 문서를 봐요.
VEX 상태 참조
각 VEX 문에는 특정 CVE와 이미지에 대한 Docker의 익스플로잇 가능성 평가를 기록하는 status 필드가 포함돼요. OpenVEX는 네 가지 상태 값을 정의하며, DHI는 그중 세 가지를 사용해요.
| Status | 의미 |
|---|---|
not_affected |
이미지의 패키지에 대해 CVE가 보고되었지만, Docker가 출하된 그대로는 익스플로잇 불가능하다고 평가했음 |
under_investigation |
Docker가 해당 CVE를 알고 있으며 이미지에 영향을 주는지 적극적으로 평가 중 |
affected |
Docker가 해당 CVE가 이미지에서 익스플로잇 가능하며 아직 수정이 없다는 것을 확인했음 |
fixed |
이 버전에서 취약점이 해결되었음. DHI는 이 상태를 사용하지 않음(아래 참조) |
Docker Scout를 사용해 모든 DHI에 대한 VEX 문을 볼 수 있어요. Scan Docker Hardened Images 문서를 참조하세요. 이미지 digest별로 억제된 CVE를 프로그래밍 방식으로 조회하려면 digest로 DHI의 억제된 CVE 조회 문서를 봐요.
not_affected 정당화 코드
not_affected 문에는 취약점이 왜 적용되지 않는지 설명하는 기계가 읽을 수 있는 justification 필드가 포함돼요.
| Justification | 의미 |
|---|---|
component_not_present |
취약한 구성 요소가 이 이미지에 없음. CVE가 다른 패키지와 이름이 일치해서 매칭됨 |
vulnerable_code_not_present |
취약한 코드 경로가 이 빌드에 컴파일되지 않았음 |
vulnerable_code_not_in_execute_path |
취약한 코드가 패키지에 존재하지만 이 이미지의 런타임 구성에서 호출되지 않음 |
vulnerable_code_cannot_be_controlled_by_adversary |
취약한 코드가 존재하지만 공격자가 이 구성에서 트리거할 수 없음 |
inline_mitigations_already_exist |
Docker가 해당 CVE를 처리하는 백포트 또는 패치를 적용했음 |
DHI가 fixed를 사용하지 않는 이유
DHI는 fixed를 사용하지 않아요. VEX 지원 스캐너가 fixed를 일관되게 처리하지 못할 수 있기 때문에, Docker가 버전 번호만으로는 수정이 반영되지 않는 업스트림 패치를 백포트할 때는 inline_mitigations_already_exist 정당화와 함께 not_affected를 사용해요.