SBOM과 VEX: 구성 요소와 취약점 영향
Sytance · 업데이트
SBOM은 제품의 소프트웨어 구성 요소를 식별합니다. 취약점 악용 가능성 교환(Vulnerability Exploitability eXchange, VEX)은 특정 취약점이 해당 제품에 영향을 미치는지 전달합니다. 평가는 제품 버전, 구성, 구성 요소의 사용 방식에 따라 달라집니다.
구성 요소 목록, 일치 여부, 영향
목록에는 구성 요소의 포함 여부가 기록됩니다. 취약점 일치 항목은 권고문에 해당 구성 요소 또는 버전이 언급되었음을 보여줍니다. 영향 분석에서는 실제 빌드 및 사용 환경에서 취약한 코드가 존재하고 악용 가능한지 확인합니다.
CycloneDX는 특정 제품에 대한 평가를 전달하기 위해 VEX를 사용합니다. 예를 들어 구성 요소는 포함되어 있지만 빌드 중 선택적 취약 기능은 제외될 수 있습니다. 이러한 구분을 위해서는 빌드 정보와 분석이 필요합니다.
OpenVEX의 네 가지 상태
OpenVEX는 네 가지 상태를 정의합니다. 각 상태는 문서에서 식별한 제품 버전 및 취약점에 적용됩니다.
| OpenVEX 상태 | 의미 |
|---|---|
| under_investigation | 영향을 계속 평가 중 |
| affected | 식별된 제품이 영향을 받음 |
| fixed | 식별된 버전에 수정 사항이 포함됨 |
| not_affected | 식별된 제품은 영향을 받지 않음 |
게이트웨이의 선택적 디코더 예시
선택적 디코더가 포함된 파서 라이브러리가 탑재된 가상의 게이트웨이를 생각해 보세요. 취약점이 해당 디코더에 영향을 준다고 가정합니다. 먼저 제공된 이미지에 포함된 라이브러리 빌드를 확인하고 디코더가 그 빌드에 컴파일되었는지 확인해야 합니다.
빌드 설정과 바이너리 분석으로 취약한 디코더가 없음을 확인할 수 있다면, 그 근거를 vulnerable_code_not_present 사유의 not_affected 상태 문서에 사용할 수 있습니다. 이 문서는 해당 빌드에 적용됩니다.
코드는 존재하지만 실행 여부가 명확하지 않다면 진입점과 실행 경로를 확인하는 동안 평가를 조사 중 상태로 유지하세요. 제품이 영향을 받고 이후 릴리스에 수정 사항이 포함되더라도 이전 릴리스는 여전히 영향을 받습니다. 이후 릴리스에는 별도의 상태 문서를 작성하세요.
not_affected 상태 사유
OpenVEX는 not_affected 상태 문서에 정당화 근거 또는 영향 설명을 포함하도록 요구합니다. 기계 판독 가능한 정당화 코드는 구성 요소 누락, 취약한 코드 부재, 실행 경로 외부의 코드, 공격자 제어의 한계, 내장 완화 조치를 구분합니다.
각 사유에는 서로 다른 조건이 적용됩니다. 네트워크 제한은 취약한 코드를 제거하지 않습니다. 내장 완화 조치 사유의 경우 OpenVEX는 악용을 방지하며 사용자가 비활성화하거나 재구성할 수 없는 보호를 명시합니다.
코드 경로에 대한 결론이라면 영향을 받는 기능, 확인한 경로, 구성상의 제한을 밝혀야 합니다. 해당 조건이 바뀌면 평가를 다시 검토하세요. 결론이 고객이 제어하는 설정에 달려 있다면 그 종속 관계를 명확히 전달하세요.
공급업체 VEX 문서 사용
공급업체의 VEX 문서는 경보를 걸러내거나 우선순위를 조정하는 데 도움이 될 수 있습니다. 사용하기 전에 출처를 신뢰할 수 있는지, 제품 버전이 일치하는지 확인하세요. 게시 시각, 개정 이력, 적용 구성, 권장 조치도 확인해야 합니다.
신뢰할 수 있는 공급업체의 문서와 자체 분석 결과가 다르면 두 기록을 모두 보존하고 차이를 해소하세요. 제품군 전체를 포괄하는 문서가 구성 요소나 옵션이 다른 맞춤 빌드까지 다루지 않을 수 있습니다.
VEX 문서가 발행된 뒤에도 SBOM은 유용합니다. 새로운 권고문에 따라 조사 대상이 달라질 수 있고, 제품이 개정되면 이전 결론이 더는 유효하지 않을 수 있습니다. 목록 업데이트와 영향 평가를 연결하되 각각의 이력은 별도로 보존하세요.