VEX: Vulnerability Exploitability eXchange 문서가 말하는 것

VEX란 무엇입니까?

VEX는 Vulnerability Exploitability eXchange의 약자로, 특정한 알려진 취약점이 제품에 영향을 미치는지를 밝히는 기계 판독 가능한 진술입니다. 공급업체는 제품 사용자가 어떤 취약점에 조치가 필요하고 어떤 취약점은 필요 없는지 알 수 있도록 이를 게시합니다. 대부분의 조직에서 공급업체 측의 이 업무는 제품 보안 사고 대응팀(PSIRT)이 맡습니다.

CISA의 Minimum Requirements for VEX(2023년 4월)는 VEX를 특정 파일 형식과 무관하게 정의합니다. VEX 문서는 하나 이상의 VEX 진술을 담는 컨테이너이며, 각 진술은 하나 이상의 제품에 있는 하나의 취약점에 대해 하나의 상태를 제시합니다. VEX는 SBOM, 취약점 데이터베이스, 보안 권고와 함께 쓰이도록 설계되었지만, 이들 중 어느 것도 반드시 필요하지는 않습니다.

VEX가 필요한 이유: SBOM 노이즈

SBOM은 전이적 종속성을 포함해 제품의 모든 구성 요소를 나열합니다. 스캐너는 이 구성 요소를 권고와 대조하고, 발견한 모든 버전의 모든 CVE를 보고합니다. 그중 상당수는 해당되지 않습니다. 취약한 함수가 호출되지 않거나, 빌드 옵션으로 컴파일 시 제외되거나, 제품 구성이 공격을 차단하기 때문입니다. VEX가 없으면 고객마다 이를 직접 판단하거나, 공급업체에 지원 티켓을 보내 문의해야 합니다.

VEX는 이 분석을 모든 사람을 위해 한 번에 수행할 수 있는 당사자, 즉 공급업체에게 넘깁니다. 고객의 스캐너는 VEX 문서를 읽고, 공급업체가 제품에 영향이 없다고 표시한 발견 사항을 숨깁니다.

VEX는 여러 수단 중 하나입니다. 취약점 노이즈를 줄이는 방법에서는 출시하는 것과 일치하는 인벤토리부터 시작해 이 수단들을 순서대로 정리합니다.

VEX의 4가지 상태

모든 VEX 진술은 다음 4가지 상태 중 정확히 하나를 가집니다.

상태	의미	추가로 필요한 항목
not_affected	조치나 완화가 필요하지 않습니다. 해당 취약점은 나열된 제품에 영향을 미치지 않습니다.	근거, 또는 이유를 설명하는 영향 설명
affected	해당 취약점이 나열된 제품에 영향을 미치며, 작성자가 조치를 권고합니다.	조치 설명: 사용자가 해야 할 일
fixed	나열된 제품 버전에 수정 사항이 포함되어 있습니다.	추가 항목 없음
under_investigation	작성자가 조사 중이며 아직 결론을 내리지 않았습니다.	추가 항목 없음, 변경될 것으로 예상

not_affected에 대한 VEX 근거

not_affected 진술은 이유를 밝혀야 합니다. CISA 요구 사항에 따르면 5가지 근거 중 하나를 사용해야 하며(SHOULD), 사용하지 않는 경우 자유 형식의 영향 설명을 반드시 제시해야 합니다(MUST). OpenVEX와 CSAF도 같은 5가지 근거를 사용합니다.

• component_not_present: 취약한 구성 요소가 제품에 포함되어 있지 않습니다.
• vulnerable_code_not_present: 구성 요소는 포함되어 있지만, 대개 구성 방식이나 빌드 방식 때문에 취약한 코드는 포함되어 있지 않습니다.
• vulnerable_code_not_in_execute_path: 취약한 코드가 존재하지만 제품이 이를 호출하지 않습니다.
• vulnerable_code_cannot_be_controlled_by_adversary: 코드가 존재하고 사용되지만, 공격자가 이를 제어해 취약점을 악용할 수 없습니다.
• inline_mitigations_already_exist: 사용자가 비활성화할 수 없는 내장 보호 기능이 악용을 막습니다.

근거마다 필요한 증거가 다릅니다. component_not_present에는 제품에 무엇이 들어 있는지에 대한 정확한 기록이 필요합니다. 가운데 3가지 근거에는 도달 가능성 분석이나 수동 검토 같은 코드 분석이 필요하며, 고객이 가장 자주 의문을 제기하는 근거이기도 합니다.

VEX 진술에 포함되는 내용

CISA의 최소 요구 사항은 다음 요소를 제시합니다.

• 문서 메타데이터: 문서 ID, 변경할 때마다 증가하는 버전, 작성자(도구가 아닌 개인 또는 조직), 최초 발행 시점과 최종 업데이트 시점.
• 제품 정보: 하나 이상의 제품 식별자. 패키지 URL(purl)처럼 제품의 SBOM이 사용하는 것과 같은 식별자가 이상적입니다. 진술에는 취약점이 있는 하위 구성 요소를 명시할 수도 있습니다.
• 취약점 정보: 진술당 하나의 취약점 ID(대개 CVE)와 설명 또는 설명으로 연결되는 링크.
• 상태와, 상태에 따라 필요한 근거, 영향 설명 또는 조치 설명.
• 진술 메타데이터: 진술 자체의 ID, 버전, 타임스탬프.

VEX 문서 예시

다음 OpenVEX 문서는 example-api 3.2.0이라는 제품이 취약한 버전의 log4j-core를 포함하지만, 취약한 클래스가 빌드 중에 제거되므로 Log4Shell의 영향을 받지 않는다고 밝힙니다.

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "@id": "https://example.com/vex/2026-0042",
  "author": "Example Corp PSIRT",
  "timestamp": "2026-10-02T09:00:00Z",
  "version": 1,
  "statements": [
    {
      "vulnerability": { "name": "CVE-2021-44228" },
      "products": [
        {
          "@id": "pkg:generic/example/[email protected]",
          "subcomponents": [
            { "@id": "pkg:maven/org.apache.logging.log4j/[email protected]" }
          ]
        }
      ],
      "status": "not_affected",
      "justification": "vulnerable_code_not_present",
      "impact_statement": "The JndiLookup class is removed from log4j-core at build time."
    }
  ]
}

제품과 그 하위 구성 요소는 패키지 URL로 식별되므로, 스캐너가 이를 제품 SBOM의 구성 요소와 대조할 수 있습니다. CycloneDX나 CSAF로 작성한 같은 진술은 같은 사실을 다른 구조로 담습니다.

VEX 형식: OpenVEX, CycloneDX VEX, CSAF VEX

VEX는 파일 형식이 아니라 요구 사항의 집합입니다. CISA는 VEX를 담을 수 있는 3가지 형식을 제시하며, 이들은 서로 호환되지 않습니다.

	OpenVEX	CycloneDX VEX	CSAF VEX
개요	VEX 전용으로 만든 작은 JSON 형식	CycloneDX 문서의 vulnerabilities 섹션	CSAF 권고 표준의 csaf_vex 프로필
표준	공개 사양, v0.2.0	ECMA-424(CycloneDX 1.6 이상)	OASIS 표준(CSAF 2.0, 2022년)
상태	VEX의 4가지 상태	자체 분석 상태: not_affected, exploitable, in_triage, resolved, resolved_with_pedigree, false_positive	제품 상태 목록: known_not_affected, known_affected, fixed, under_investigation
근거	CISA의 5가지 근거	code_not_reachable, requires_configuration 등 자체 근거 9가지	CISA의 5가지 근거(플래그 형태)
적합한 팀	가능한 한 작은 VEX 파일을 원하는 팀	이미 CycloneDX SBOM을 제공하는 팀	이미 CSAF 보안 권고를 게시하는 팀
Trivy 지원	지원	지원(SBOM 스캔 시)	지원
Grype 지원	지원	목록에 없음	지원

OpenVEX는 가장 가벼운 형식으로, 작성자, 타임스탬프, 버전, 진술 목록으로 이루어진 문서입니다. 사양은 VEX를 일련의 진술로 취급하며, 각 진술은 이전 진술을 덮어쓰거나 보완합니다.

CycloneDX VEX는 CycloneDX가 다른 모든 데이터에 쓰는 것과 같은 vulnerabilities 구조를 사용하며, analysis 객체에 상태, 근거, update나 will_not_fix 같은 대응 값, 자유 형식의 세부 정보를 담습니다. VEX 데이터는 SBOM 안에 둘 수도 있고, BOM-Link로 SBOM을 가리키는 별도의 CycloneDX 문서에 둘 수도 있습니다. 근거 어휘가 CISA의 것과 다르므로 OpenVEX나 CSAF와 상호 변환하려면 매핑이 필요하다는 점에 유의하세요. SBOM 측면은 CycloneDX vs SPDX를 참조하세요.

CSAF VEX는 카테고리가 csaf_vex인 완전한 CSAF 문서입니다. 제품 트리, CVE 또는 기타 ID, 노트, 그리고 제품별로 영향 설명(영향이 없는 경우) 또는 조치 방법(영향이 있는 경우)이 필요합니다. OpenVEX보다 무겁지만, 이미 CSAF 제공자를 통해 CSAF 권고를 배포하는 조직에 적합합니다.

VEX와 VDR 비교

VDR(Vulnerability Disclosure Report)은 제품에 실제로 영향을 미치는 취약점을 분석 및 조치 방법과 함께 나열합니다. NIST SP 800-161은 공급망 관행으로 VDR을 권장하며, CycloneDX는 두 가지를 모두 지원합니다. CycloneDX 예시는 그 차이를 다음과 같이 설명합니다.

• VDR은 어떤 취약점이 제품에 영향을 미치는지 밝힙니다. 다른 곳에 공개된 적 없는, 자체 코드에서 발견된 취약점도 다룰 수 있습니다.
• VEX는 주로 부정적 진술입니다. 어떤 알려진 취약점이 제품에 영향을 미치지 않는지와 그 이유를 밝힙니다. 알려진 취약점만 다룹니다.

많은 공급업체가 둘 다 게시합니다. VDR은 "무엇을 수정해야 하는가"에, VEX는 "무엇을 무시해도 되는가"에 답합니다.

스캐너가 VEX를 활용하는 방식

VEX 문서는 고객의 도구가 읽을 때에만 작업을 줄여 줍니다. 널리 쓰이는 두 오픈 소스 스캐너가 VEX를 읽습니다.

• Trivy는 --vex 옵션(실험적 기능으로 표시)을 통해 로컬 파일, VEX 리포지토리, OCI 증명, SBOM 내 참조에서 VEX를 받습니다. OpenVEX, SBOM 스캔 시의 CycloneDX VEX, CSAF VEX를 읽으며, not_affected로 표시된 취약점은 보고하지 않습니다.
• Grype는 --vex를 통해 OpenVEX와 CSAF VEX를 받습니다. not_affected와 fixed 매칭 결과를 무시 목록으로 옮기며, 이 목록은 --show-suppressed로 표시됩니다. 선택적으로 affected와 under_investigation 진술을 결과에 추가할 수도 있습니다.

매칭은 식별자에 달려 있습니다. VEX가 SBOM과 다른 식별자로 제품을 지칭하면 스캐너가 둘을 연결하지 못하고 발견 사항은 그대로 남습니다.

VEX를 게시하는 주체

VEX는 대개 제품을 출시하는 공급업체, 즉 벤더, 오픈 소스 배포판 또는 기기 제조사가 작성합니다. 공급업체 내부에서는 PSIRT의 업무이며, 권고와 수정 사항을 만들어 내는 것과 같은 취약점 관리 라이프사이클의 일부입니다. 예를 들어 Red Hat은 CSAF 피드의 전용 디렉터리에 권고와 나란히 CSAF VEX 문서를 게시합니다. PSIRT 엔지니어의 일상 업무는 PSIRT 역할을 참조하세요.

고객도 자체 용도로 VEX를 작성합니다. 공급업체 제품에 대한 분류 결정을 기록해 스캐너가 더 이상 같은 항목을 보고하지 않도록 하는 것입니다. EU Cyber Resilience Act 같은 규정은 제조사에 출시하는 구성 요소의 취약점을 처리하도록 요구하며, VEX는 그중 어떤 취약점이 해당되는지 사용자에게 알리는 한 가지 방법입니다.

VEX를 최신 상태로 유지하기

• 상태는 바뀝니다. 진술은 대개 under_investigation으로 시작해 not_affected로 끝나거나, affected를 거쳐 fixed가 됩니다. 변경될 때마다 게시하세요. CISA는 매번 버전을 올리도록 요구합니다.
• 새 릴리스에는 새 진술이 필요합니다. 3.2.0에 대한 not_affected 판정은 3.3.0에 대해서는 아무것도 말해 주지 않습니다. 구성 요소, 그 버전 또는 빌드 구성이 바뀔 때마다 다시 확인하세요.
• VEX를 SBOM과 분리하세요. SBOM은 릴리스를 설명하며 고정되어 있습니다. VEX는 릴리스 후에도 계속 바뀌므로, 별도 문서로 게시하면 SBOM을 다시 발행할 필요가 없습니다.
• 도구가 찾는 곳에 게시하세요. SBOM 옆, 컨테이너 이미지의 증명, 또는 권고 피드에 게시하고, 그 위치를 공개 정책에 명시하세요. 조정된 취약점 공개를 참조하세요.

VEX의 한계

• 증명이 아니라 주장입니다. not_affected 진술은 작성자의 평가입니다. CISA는 작성자의 신원을 문서에 암호학적으로 연결하도록 권장하지만, 대부분의 사용자는 여전히 공급업체를 신뢰하기 때문에 VEX를 신뢰합니다.
• 진술이 없다는 것은 아무 의미도 없습니다. VEX에는 기본 상태가 없습니다. 진술이 없는 취약점은 영향이 없는 것이 아니라 알 수 없는 상태입니다.
• 형식 간 일대일 대응이 되지 않습니다. CycloneDX는 OpenVEX 및 CSAF와 다른 상태와 근거를 사용하므로, 변환 과정에서 세부 정보가 손실됩니다.
• 인벤토리의 품질을 넘어설 수 없습니다. 구성 요소가 없다고 말하려면 전이적 종속성과 빌드가 패키지 관리자 밖에서 내려받은 모든 것을 포함해, 제품에 무엇이 들어 있는지 정확히 알아야 합니다.

VEX는 정확한 SBOM에서 시작합니다

모든 VEX 진술은 구성 요소를 가리키며, 가장 입증하기 쉬운 근거인 component_not_present는 인벤토리가 완전할 때에만 참입니다. 사후에 잠금 파일을 스캔해 생성한 SBOM은 출시되지 않는 개발 종속성을 나열하고, 빌드가 다른 방식으로 가져온 패키지를 놓칠 수 있습니다.

CRACI는 GitHub Actions 빌드를 CRACI가 운영하는 러너에서 실행하고, 전이적 종속성, 캐시에서 복원된 패키지, 어떤 잠금 파일에도 없는 종속성을 포함해 각 작업이 실제로 가져온 패키지를 기록합니다. 각 SBOM에는 완전성 상태가 표시되며 CycloneDX 또는 SPDX로 내보낼 수 있습니다. 모니터링 중인 SBOM은 지속적으로 재평가되고, 빌드 이력에서 과거 어떤 빌드에 취약한 종속성이 포함되었는지 확인할 수 있으며, CRACI는 VEX를 지원합니다. SBOM 생성과 취약점 추적을 참조하세요.

VEX: 자주 묻는 질문

VEX는 무엇의 약자입니까?

VEX는 Vulnerability Exploitability eXchange의 약자입니다. 특정한 알려진 취약점이 제품에 영향을 미치는지를 밝히는 기계 판독 가능한 진술로, 사용자가 보고된 취약점 중 어떤 것에 조치가 필요한지 알 수 있도록 게시됩니다.

SBOM과 VEX의 차이는 무엇입니까?

SBOM은 제품의 구성 요소를 나열합니다. VEX는 특정 취약점에 대해 그 제품이 영향을 받는지를 밝힙니다. SBOM은 릴리스 후 거의 바뀌지 않지만, VEX 진술은 공급업체가 조사하고 수정함에 따라 바뀝니다. 그래서 VEX는 보통 SBOM에 포함되지 않고, 제품을 참조하는 별도 문서로 게시됩니다.

VEX의 4가지 상태는 무엇입니까?

not_affected, affected, fixed, under_investigation입니다. not_affected 진술에는 근거나 영향 설명이 필요하고, affected 진술에는 사용자가 해야 할 일을 밝히는 조치 설명이 필요합니다.

어떤 VEX 형식을 사용해야 합니까?

사용자와 그들의 도구가 읽는 형식을 사용하세요. OpenVEX는 가장 작고 Trivy 및 Grype와 함께 작동합니다. CycloneDX VEX는 이미 CycloneDX SBOM을 제공하는 팀에 적합합니다. CSAF VEX는 이미 CSAF 보안 권고를 게시하는 조직에 적합하며, 이는 산업용 및 엔터프라이즈 소프트웨어에서 흔합니다. 많은 공급업체가 결국 형식 간 변환을 하게 됩니다.

VEX는 보안 권고와 같은 것입니까?

아닙니다. 보안 권고는 주로 사람을 위해 취약점, 영향을 받는 대상, 수정 방법을 설명합니다. VEX는 주로 도구를 위한, 제품 및 취약점별의 좁은 범위의 기계 판독 가능한 상태입니다. 둘은 흔히 함께 제공됩니다. CSAF 표준에는 보안 권고 프로필과 VEX 프로필이 모두 있습니다.

VEX 문서는 누가 작성합니까?

대개 제품의 공급업체, 흔히 그 제품 보안 사고 대응팀(PSIRT)이 작성합니다. 제품이 어떻게 빌드되고 구성되는지 알기 때문입니다. CISA의 최소 요구 사항은 제3자의 VEX 작성도 허용하며, 모든 문서에는 작성자를 명시해야 합니다.

취약점 스캐너는 VEX를 읽습니까?

여러 스캐너가 읽습니다. Trivy는 --vex 옵션을 통해 OpenVEX, CycloneDX, CSAF VEX를 받고 not_affected로 표시된 발견 사항을 제외합니다. Grype는 --vex를 통해 OpenVEX와 CSAF VEX를 받고 not_affected 및 fixed 발견 사항을 무시 목록으로 옮깁니다.