VEX가 SBOM을 단순한 부품 목록에서 검증 가능한 감사 증거로 전환하는 방법

주요 내용

• VEX(Vulnerability Exploitable eXchange) 성명은 하나 이상의 제품에 걸쳐 하나의 취약점에 대해 하나의 상태를 나타냅니다.
• VEX 진술은 작성자의 주장인 만큼, 감사인은 누가 이를 발표했는지, 내용이 변경되었는지, 그리고 해당 상태를 뒷받침하는 분석이 무엇인지 확인합니다.
• 미국 사이버보안 및 인프라 보안국(CISA)은 네 가지 VEX 상태를 정의하고 있으며, ‘영향 없음(not affected)’ 상태인 경우 그 이유를 정당화 값이나 서면 영향 평가서를 통해 명시해야 합니다.
• VEX를 포함할 수 있는 형식은 여러 가지가 있으며, CycloneDX는 자체적인 상태 및 정렬 레이블을 사용하므로 해당 문서의 용어를 CISA의 명칭으로 변환해야 할 수도 있습니다.
• 업스트림에서 수정 사항이 없는 경우, 공급업체는 ‘영향 없음’을 명시하고 그 근거를 제시하거나, ‘영향 있음’을 명시하고 조치 사항을 기재하거나, 패치된 버전이 빌드에 포함되면 ‘수정됨’을 표시할 수 있습니다.

소프트웨어 부품 목록(SBOM)은 릴리스에 어떤 구성 요소가 포함되어 있는지 알려주지만, 스캐너가 해당 구성 요소와 일치시키는 취약점 중 어떤 것이 실제로 귀사의 제품에 적용되는지는 알려주지 않습니다. VEX(Vulnerability Exploitability eXchange)는 이러한 공백을 메워줍니다. 이는 공급업체나 제3자가 알려진 취약점이 특정 소프트웨어 제품에 영향을 미치는지 여부를 명시하는 방식입니다.

CISA의 VEX 지침은 각 진술을 작성자의 주장으로 간주합니다. 독자가 해당 진술을 어느 정도 신뢰할 수 있는지는 누가 발표했는지, 어떻게 서명되었는지, 그리고 감사인의 규정 준수 프레임워크가 어떤 증거를 인정하는지에 따라 달라집니다. 이 기사에서 ‘검증 가능한 감사 증거’란 감사인이 그 배경이 되는 분석과 대조하여 확인할 수 있는 주장을 의미합니다. VEX 진술은 그 자체만으로는 증거가 되지 않습니다.

Vulnerability Exploitability eXchange란 무엇인가

CISA의 설명에 따르면, VEX는 소프트웨어 제품 또는 구성 요소의 취약점 관련 상태를 표시하는 방법입니다. 2023년 4월 발표된 CISA의 ‘VEX 최소 요구사항(버전 1.0.0) ’에 따르면, VEX 문서는 하나 이상의 진술을 포함하는 컨테이너입니다. 각 진술은 하나 이상의 제품에 걸쳐 단일 취약점에 대한 단일 상태를 전달합니다.

VEX는 SBOM, 취약점 데이터베이스 및 보안 권고 사항과 연동되도록 설계되었으나, CISA는 이들 중 어느 것도 필수 요건은 아니라고 밝혔습니다. CISA가 2022년 4월에 발표한 사용 사례 문서에서는 VEX 문서를 그 자체로 일종의 보안 권고 사항으로 설명하고 있습니다.

VEX는 데이터 형식입니다. 이는 법이 아니며, CISA의 최소 요구 사항에 따르면 이는 공식적인 CISA 정책이 아니며 준수를 강제하지도 않습니다. 또한 CISA와 그 파트너 기관들이 제시한 2026년 SBOM 최소 구성 요소에도 VEX는 포함되어 있지 않습니다.

공급업체나 제3자가 VEX 문서를 작성할 수 있습니다. 작성자는 개인 또는 조직으로 명시되어야 하며, 해당 내용에 대한 책임을 집니다.

VEX가 감사인에게 무엇을 입증하고 무엇을 입증하지 않는가

VEX 문서의 내용에 대한 책임은 작성자에게 있으므로, 문서에 포함된 모든 내용은 해당 작성자의 주장으로 간주됩니다. CISA의 지침에 따르면 문서와 진술서에는 서명이 있어야 하며, 작성자의 신원은 서명과 암호학적으로 연동되어야 합니다. 또한 내용이 변경될 때마다 문서 버전을 상향 조정해야 하며, 최초 발행 및 최종 업데이트 타임스탬프를 기재해야 합니다. 이를 통해 감사관은 누가, 언제 해당 주장을 했는지, 그리고 그 이후로 내용이 변경되었는지 여부를 확인할 수 있습니다.

CISA의 ‘사용 사례’ 문서에 따르면: 2022년 4월 발간된 이 문서는 VEX 등급이 논의를 종결하기 위한 것이 아니라고 밝히고 있습니다. 이 등급은 소비자가 충분한 정보를 바탕으로 결정을 내릴 수 있도록 돕기 위해 마련된 것이므로, 독자는 이를 최종적인 것으로 간주하기보다는 해당 등급에 대해 의문을 제기할 수 있습니다.

CISA와 협력 기관들은 2026년 7월 29일 ‘2026년 소프트웨어 부품 명세서(SBOM) 최소 구성 요소’를 발표했습니다. 이 문서의 “SBOM과 보안 권고 사항의 연계” 섹션에서는 VEX와 공통 보안 권고 프레임워크(CSAF)를 다루고 있습니다. 이 섹션에 따르면, 신뢰할 수 있는 출처가 잠재적 위험이 실제 위험으로 이어지지 않는다고 판단할 경우, 상태 업데이트를 통해 불필요한 노력을 피할 수 있다고 설명합니다. 이러한 이점은 정보 출처에 대한 신뢰에 달려 있으므로, 발행자의 신원이 독자가 해당 상태 정보를 바탕으로 조치를 취할 수 있는지 여부를 결정합니다.

VEX를 SBOM과 연동하려면 완전한 SBOM이 필요합니다. 2026년 문서의 ‘커버리지(Coverage)’ 항목에 따르면, 수신자는 SBOM에 해당 구성 요소가 나열되어 있지 않을 경우 새로 보고된 취약점이 자신에게 영향을 미치지 않는다고 판단할 수 있어야 하며, 이러한 판단은 SBOM에 모든 항목이 나열되어 있을 때만 안전합니다. 동일한 문서는 SBOM의 정확성, 적용 범위 및 완전성 확인을 최소 필수 요소 범주 밖으로 분류하고 있으므로, SBOM에 의존하는 VEX 진술은 SBOM에 포함된 오류가 무엇이든 그대로 반영될 수 있습니다.

또한 VEX 보고서는 해당 구성 요소의 취약점만을 다루기 때문에, 가져온 패키지가 변조되었는지 또는 악성인지 여부에 대해서는 아무런 정보를 제공하지 않습니다. 제품이 오픈소스 패키지를 기반으로 구축된 경우, VEX 보고서의 신뢰성은 각 빌드에 어떤 구성 요소가 포함되었는지에 대한 기록의 정확성에 달려 있습니다.

일부 심사관은 각 발견 사항에 대한 분석 근거를 요청하기도 합니다. 의료 기기의 경우, 미국 식품의약국(FDA)이 2026년 2월에 발표한 비구속적 시판 전 사이버 보안 지침에 따르면, 제조사는 자사 구성 요소의 알려진 각 취약점에 대한 안전 및 보안 위험 평가와 이를 해결하기 위한 위험 통제 조치를 제시해야 합니다. 분석 근거가 없는 상태에서는 심사관이 검증할 내용이 거의 없기 때문에, 다음에서 다룰 근거를 설명하는 항목들이 가장 중요합니다.

네 가지 지위와 ‘영향을 받지 않는다’는 진술이 반드시 설명해야 할 사항

CISA의 최소 요구사항(버전 1.0.0)에 따르면, 모든 진술은 네 가지 상태 중 하나를 사용해야 합니다. 이 중 두 가지 상태에는 필수 세부 사항이 포함되며, 표에는 어떤 항목인지 나와 있습니다.

2022년 4월 사용 사례 문서에서는 ‘영향을 받지 않음’으로 명시된 모든 항목에 대해 영향 분석서를 제출하도록 요구하고 있습니다. 반면 2023년 4월 최소 요구 사항에서는 이를 대신하여 근거 설명을 제출할 수 있도록 허용하고 있습니다.

최소 요구 사항에는 다섯 가지 정당화 기준이 정의되어 있으며, 그중 마지막 기준은 이름에서 연상되는 것보다 더 엄격합니다:

• ‘구성 요소 미포함’은 취약한 하위 구성 요소가 제품에 포함되어 있지 않은 경우에 적용됩니다.
• ‘취약점이 있는 코드가 존재하지 않음’은 취약점이 있는 코드는 없지만 해당 구성 요소는 존재하는 경우를 말하며, 이는 대개 빌드 구성에서 해당 구성 요소가 제외되었기 때문입니다.
• 실행 경로에 포함되지 않은 취약한 코드는, 해당 제품이 이를 사용하는 방식을 고려할 때 실행될 수 없는 코드에 해당합니다.
• ‘취약점이 있는 코드가 공격자에 의해 제어될 수 없다’는 표현은, 해당 코드가 존재하고 사용되고 있지만 공격자가 이를 조종하여 취약점을 악용할 수는 없는 경우를 의미합니다.
• 인라인 완화 조치는 이미 존재하며, 이는 공격자가 우회할 수 없고, 사용자가 구성하거나 비활성화할 수 없으며, 알려진 공격 경로를 통한 악용을 완전히 차단하는 내장형 보호 기능을 필요로 합니다.

각 값에는 대개 서로 다른 종류의 근거 자료가 필요합니다. SBOM이나 기타 구성 기록, 빌드 구성, 호출 경로 분석, 입력 처리 분석, 또는 완화 조치 자체가 그 예입니다. CISA의 요구사항에 따라 진술문에는 해당 상태가 어떻게 결정되었는지에 대한 상태 메모를 포함할 수 있으므로, 해당 근거 자료를 진술문 내 또는 그 옆에 기록해 두십시오. 정당화 값만으로는 검토자가 귀하가 왜 그러한 주장을 했는지 알 수 없습니다.

상태를 수행한 작업에 맞게 지정하십시오. ‘영향 발생(Affected)’ 상태는 독자에게 해당 제품이 노출되었으며 작성자가 조치를 권고하고 있음을 알립니다. 아직 분석하지 않은 발견 사항에는 이 상태를 사용하지 마십시오. 분석이 진행 중인 동안에는 해당 발견 사항을 ‘조사 중(Under investigation)’으로 표시하십시오. CISA는 조사가 종료되면 해당 상태가 변경될 것으로 예상하므로, 업데이트 없이 이 상태를 그대로 유지하는 경우 검토자에게 분석이 지연되었을 수 있음을 시사하게 됩니다.

VEX를 탑재할 수 있는 형식 및 사양

CISA의 2023년 최소 요구사항에는 VEX 문서를 포함하거나 이를 생성하는 데 사용할 수 있는 세 가지 형식, 즉 CSAF, CycloneDX 및 OpenVEX가 명시되어 있습니다. 이 요구사항은 특정 형식과 무관하게 해당 데이터 요소를 정의하고 있습니다. CISA의 목록에는 명시되어 있지 않은 소프트웨어 패키지 데이터 교환(SPDX)도 네 가지 상태를 모두 포함할 수 있습니다. 버전 3.0.1의 보안 프로필에는 각 상태에 대한 VEX 관계 클래스가 포함되어 있습니다. 각 형식의 VEX 사양은 고유한 필드를 정의하며, 버전과 상태는 서로 다릅니다.

모든 형식이 CISA의 레이블을 사용하는 것은 아닙니다. OpenVEX의 프로젝트 문서에 따르면 CycloneDX VEX는 자체적인 상태 및 근거 레이블을 정의하므로, 문서를 CISA의 명칭에 맞게 변환해야 할 수도 있습니다. 이 글에서는 전반적으로 CISA의 명칭을 사용합니다. VEX 데이터 요소는 형식에 구애받지 않으므로, 사용 중인 툴체인과 고객이 이미 다루고 있는 형식을 선택하시기 바랍니다.

상류 측에서 해결할 방법이 없는 경우

입증해야 할 사항은 수정 패치가 존재하는지 여부에 따라 달라집니다. 업스트림에서 수정 패치를 공개했고 이를 적용하여 배포한 경우, 성명서에는 ‘수정됨’이라고 명시하고 해당 패치가 포함된 제품 버전을 기재할 수 있습니다. '수정됨'이라는 발표는 해결책을 제시하는 것이므로, 일반적으로 취약한 코드가 실행될 수 있는지 여부에 대한 분석은 필요하지 않습니다. 이를 뒷받침하는 근거는 대개 패치된 아티팩트와 버전 기록입니다. 이 발표는 여전히 발표자의 주장인 만큼 정확한 버전이 중요합니다. CISA의 사용 사례 문서는 복잡한 버전 범위는 해석하기 어렵기 때문에, 가능한 경우 버전을 명시적으로 기재할 것을 권장합니다.

수정 조치가 없는 경우, 세 가지 방법이 있습니다. 발견된 문제를 분석하여 근거를 제시하고 ‘영향 없음’으로 처리하거나, 조치 사항을 명시하여 ‘영향 있음’으로 처리하거나, 패치된 버전을 빌드에 반영하여 ‘수정됨’으로 처리할 수 있습니다. 첫 번째 방법은 코드가 변경됨에 따라 분석 결과가 구식이 되어버린다는 단점이 있습니다. CISA의 사용 사례 문서는 모든 버전에 대한 진술이 향후 버전까지 포함하며, 이미 지원 종료된 버전도 포함될 수 있다고 경고합니다. 예를 들어, Rust 프로그램이 Java 취약점의 영향을 받을 수 없다는 주장이 있는데, 이후 버전에서 Java를 채택했음에도 문서를 업데이트하지 않으면 이는 오해를 불러일으킬 수 있습니다. 두 번째 방법에도 자체적인 제약이 있습니다. 분석 결과 제품이 취약한 것으로 드러난 경우, 조치 사항에서 독자들에게 아직 존재하지 않는 수정된 릴리스로 업그레이드하라고 안내할 수는 없습니다. 대신 독자들이 취할 수 있는 완화 조치나 다른 조치를 설명해야 합니다.

세 번째 경로는 유지보수가 이루어지지 않는 구성 요소로 인해 어려워지는 경우입니다. 업스트림에서 여러분이 원하는 수정 사항을 작성하고 있는 사람이 아무도 없을 수 있으므로, 누군가가 여러분이 실행 중인 버전에 패치를 적용한 다음, 해당 패치가 여전히 제품에서 기대하는 대로 작동하는지 확인해야 합니다. 패치 적용 대신 구성 요소를 교체하는 방법도 있지만, 이는 대개 코드에서 해당 구성 요소가 사용되는 모든 부분을 수정해야 함을 의미합니다.

직접 발언을 할 때 효과적인 순서는 다음과 같습니다:

1. SBOM을 실제 출하된 제품과 일치시켜야 합니다. 실수로 특정 부품이 SBOM에 포함된 경우, 해당 부품에 대해 ‘영향 없음’ 성명을 발표하는 대신 SBOM을 수정하십시오.
2. 기존에 있는 수정 사항을 적용한 다음, 해당 수정 사항이 포함된 버전을 명시하는 수정 내역서를 발행하십시오.
3. 수정 방법이 없는 구성 요소의 경우, 빌드에 패치된 버전을 포함시킬지, ‘영향을 받지 않음’이라는 문구를 추가하여 분석할지, 아니면 ‘영향을 받음’이라는 문구와 함께 조치 사항을 명시할지 결정하십시오.
4. 분석이 아직 진행 중인 항목은 ‘조사 중’으로 표시하고, 작업이 완료되면 해당 내용을 업데이트하십시오. 변경 사항이 있을 경우 문서 버전이 갱신됩니다.

각 단계마다 감사자가 확인할 수 있는 기록이 남습니다. 수정된 SBOM, 수정된 버전, 상태 메모에 포함된 분석 내용, 그리고 문서의 버전 이력 등이 바로 그것입니다.

빌드에 포함될 항목 제어하기

VEX 상태만으로는 패키지가 변조되었는지, 아니면 해당 프로젝트가 공개한 소스와 일치하는지 여부를 확인할 수 없으므로, 빌드 무결성을 확인하기 위해서는 별도의 검증 절차가 필요합니다.

TuxCare의 SecureChain은 각 패키지의 소스 코드를 스캔하여 악성코드 및 의심스러운 코드 패턴을 탐지하고, 검사에서 불합격된 패키지는 차단하며, 나머지 패키지는 강화되고 격리된 환경에서 소스 코드부터 재컴파일합니다. 업스트림에서 여전히 수정 사항을 배포하는 동안, SecureChain은 계약상 SLA에 따라 각 패키지에 패치를 적용합니다. 모든 패키지는 SLSA(소프트웨어 아티팩트 공급망 수준) 레벨 3 출처 정보, SBOM 및 VEX 성명서와 함께 제공됩니다. 앞서 언급한 세 번째 경로의 경우, 업스트림에서 구성 요소에 대한 수정 지원을 중단하면 SecureChain이 자동으로 Endless Lifecycle Support(ELS)로 이관하며, ELS는 업스트림 유지보수가 종료된 후에도 계속해서 수정 사항을 제공합니다. 지원 범위는 JavaScript, Python, Java, Go 및 PHP 생태계를 아우릅니다.

빌드에 어떤 구성 요소가 포함되었는지 설명할 수 없거나, 업스트림에서 더 이상 수정하지 않는 패키지 문제로 인해 조사 진행이 계속 지체된다면, SecureChain이 이를 어떻게 처리하는지 저희 팀에 문의해 주십시오.

자주 묻는 질문

VEX는 법적으로 의무화되어 있나요?

VEX(Vulnerability Exploitability eXchange) 형식은 법이 아닙니다. 미국 사이버보안 및 인프라 보안국(CISA)은 자사의 VEX 최소 요구 사항이 공식 정책이 아니며 준수를 의무화하지 않는다고 밝혔으며, 2026년 소프트웨어 부품 목록(SBOM) 최소 구성 요소에도 VEX가 필수 항목으로 명시되어 있지 않습니다. 다만 고객 계약서에서는 이를 요구할 수 있습니다.

누가 VEX 문장을 작성할 수 있나요?

미국 사이버보안 및 인프라 보안국(CISA)에 따르면, VEX(Vulnerability Exploitable eXchange) 성명은 해당 소프트웨어의 공급업체나 제3자가 발표할 수 있다. 작성자는 개인 또는 조직으로 명시되어야 하며, 해당 내용에 대한 책임을 진다. 또한 작성자는 ‘공급업체’와 같은 역할을 기재할 수도 있다.

VEX 파일에는 무엇이 들어 있나요?

미국 사이버보안 및 인프라 보안국(CISA)이 ‘VEX 문서’라고 부르는 VEX(Vulnerability Exploitable eXchange) 파일에는 문서 메타데이터와 최소 한 개의 문장이 포함되어 있습니다. 각 문장은 하나 이상의 제품에 걸쳐 하나의 취약점에 대한 하나의 상태를 나타내며, 여기에 조치 사항이나 근거 설명 등 해당 상태에 필요한 세부 정보도 함께 포함됩니다.

취약점에 VEX 상태가 없다면 이는 무엇을 의미하나요?

이것만으로는 어떤 결론도 내릴 수 없다. 미국 사이버보안·인프라보안국(CISA)은 ‘취약점 악용 가능성 교환(VEX)’이 성명서에 명시된 내용 이외의 기본 상태를 암시하지 않으며, 문서가 불완전할 수도 있다고 밝혔다. 성명서가 없는 취약점은 영향을 받지 않는 것으로 선언된 것이 아니다.

VEX 문서에는 서명이 필요한가요?

미국 사이버보안 및 인프라 보안국(CISA)은 취약점 악용 가능성 교환(VEX) 문서 및 진술서에 서명이 포함되어야 한다고 밝혔으며, 이에 따라 서명을 권장하고 있습니다. 작성자의 신원은 서명과 연계되어야 하며, 문서의 서명은 해당 문서의 모든 메타데이터와 진술서를 포괄해야 합니다. 구현 시에는 일반적으로 인정되는 서명 메커니즘을 지원해야 합니다.

SBOM 없이 VEX를 사용할 수 있나요?

네. 미국 사이버보안 및 인프라 보안국(CISA)에 따르면, 취약점 악용 가능성 교환(VEX)은 소프트웨어 부품 명세서(SBOM), 취약점 데이터베이스 및 보안 권고 사항과 연동되도록 설계되었으나, 이들 중 어느 것도 필수 요건은 아닙니다. SBOM이 존재하는 경우, VEX 제품 식별자는 해당 SBOM의 기존 식별자를 참조해야 합니다.

요약

기사 이름

VEX가 SBOM을 검증 가능한 감사 증거로 전환하는 방법

설명

VEX(Vulnerability Exploitability eXchange)가 취약점이 귀사의 제품에 영향을 미치는지 여부를 어떻게 판단하는지, 그리고 VEX가 무엇을 입증할 수 있고 무엇을 입증할 수 없는지 알아보세요.

작성자

아르템 카라세프

게시자 이름

TuxCare

게시자 로고