Managing vulnerabilities in the software supply chain has become one of the biggest challenges in recent years, and Software Bill of Materials (SBOM) and Vulnerability Exploitability eXchange (VEX) play a critical role in this process. While SBOM lists a software's components and dependencies, VEX is a notification that determines whether vulnerabilities found in these components are truly exploitable in the context of the product. Reducing the false positive alarm burden significantly increases operational efficiency by allowing security teams to focus on real threats. The integration of these two concepts brings our software security posture to a more realistic and manageable level.
As the complexity of a software project increases, so do the open-source libraries and third-party components it contains. This makes manual vulnerability analysis processes impossible and increases reliance on automated tools. However, these automated tools cannot always understand the specific usage context of the software, which can lead to a high rate of false positive alerts.
Why SBOM Falls Short and What Problems It Creates
A Software Bill of Materials (SBOM) provides a detailed inventory of all components, versions, and sources of a software product. This inventory is a fundamental step for supply chain security, as it clearly shows which open-source libraries or third-party components are being used. For example, tracking each of the hundreds of open-source libraries we use in an ERP system for a manufacturing company would be almost impossible without an SBOM.
However, SBOM itself does not contain vulnerability information; it only lists components. This creates a significant operational challenge for security teams. The presence of a component in an SBOM causes automated vulnerability scanners to report all known CVEs (Common Vulnerabilities and Exposures) associated with that component. Often, these CVEs do not pose a real risk due to how the software uses that component, applied patches, or configurations.
ℹ️ Common SBOM Problems
False positive alerts waste security teams' time and lead to "alert fatigue." Truly critical vulnerabilities can be overlooked amidst this noise. Furthermore, manually reviewing and verifying each false positive alert is a lengthy and costly process. This slows down security processes and hinders innovation, especially in projects with rapid release cycles.
For example, let's assume a vulnerability in a component only manifests when a specific function is called. If your application never uses this function or protects it with a different security control, this vulnerability is practically "ineffective" for you. SBOM cannot make this distinction; it only reports the component's existence. At this point, VEX, a more context-aware solution, comes into play.
What is VEX and How Does It Reduce False Positives?
Vulnerability Exploitability eXchange (VEX) is a security advisory that explains whether a known vulnerability in a software component is applicable in the context of a specific product or environment. VEX provides clear information such as, "There's a CVE in this component, but our product is not affected by it due to X." This enriches the raw component list provided by SBOM with operationally meaningful security information.
VEX documents are created by the software developer or supplier and state the status of a particular CVE on the product. These statuses are generally expressed in four main categories:
- Not Affected: Even if the vulnerability exists in the component, the product is not affected due to the product's usage, applied mitigations, or configurations. For example, the vulnerable code path is never called.
- Affected: The vulnerability is effective on the product and poses a risk. Corrective actions are required in this case.
- Fixed: The vulnerability has been fixed in a newer version or with a patch. The VEX advisory specifies which version the fix was made in.
- Under Investigation: The impact of the vulnerability on the product has not yet been fully determined, and analysis is ongoing.
This detailed contextual information allows us to filter out the hundreds of alerts from security scanners to identify those that truly require action. Many CVEs reported by vulnerability scanners for the open-source libraries I use in the backend of my side project can be marked as "Not Affected" thanks to VEX documents. This significantly reduces the number of actual vulnerabilities that the security team needs to review.
💡 Benefits of Using VEX
VEX reduces the manual review burden on security analysts, helps prioritize patching processes, and provides more accurate reporting in compliance audits. It also enables more transparent communication about the security posture between suppliers and customers.
VEX's greatest contribution is directing resources to the right place. In situations where investigating every vulnerability alert is costly, VEX saves development teams a significant amount of time. This provides a critical advantage, especially in continuous integration/continuous delivery (CI/CD) environments, as rapid feedback loops accelerate the early detection and remediation of security flaws.
How SBOM and VEX Integration Works
SBOM and VEX are two complementary components in software supply chain security. SBOM provides the basic inventory, while VEX adds context to vulnerabilities in that inventory. This integration enables security tools and processes to operate more intelligently.
The integration process typically involves the following steps:
- SBOM Creation: First, as part of the software development process, the software's SBOM is generated using automated tools (e.g., Syft, CycloneDX CLI). This lists all components and dependencies.
- Vulnerability Scanning: The generated SBOM is compared against known vulnerability databases (NVD, GitHub Advisories, etc.) to perform a vulnerability scan. This step reveals potential CVEs.
- VEX Creation/Consumption:
- On the Supplier Side: Software suppliers create VEX documents for the components in their products. This is typically done through manual analysis by security teams or context-aware analysis by automated tools.
- On the Consumer Side: Organizations using the software receive VEX documents from their suppliers and integrate them into their vulnerability management systems. If VEX is not provided by the supplier, they can generate VEX-like advisories through their own internal analysis.
- Vulnerability Management and Prioritization: SBOM and VEX data are combined to filter security alerts. Vulnerabilities marked as "Not Affected" are removed from the priority list or downgraded. This allows security teams to focus on vulnerabilities that are truly "Affected."
This flow represents one of the most efficient security processes I've seen in a software project. Especially in an automation system developed for an internal platform at a bank, this integration significantly reduced the false positive rate in weekly vulnerability reports. Development teams could now focus directly on fixing effective vulnerabilities, instead of constantly being preoccupied with questions like "does this CVE really affect us?".
Methods for Producing and Managing VEX Data
Producing and managing VEX data requires careful planning, especially for large and complex software projects. For suppliers, this should be an integral part of the product lifecycle, and for consumers, the ability to effectively process incoming VEX advisories must be developed.
Approaches for VEX Production:
- Manual Analysis and Notification: For small projects or special cases, security experts can manually review known vulnerabilities and assess their impact in the product context. As a result of this analysis, VEX documents are created manually. While this method provides in-depth analysis, it is limited in terms of scalability.
- Automated Tool-Assisted Creation: Some automated vulnerability scanning tools can provide VEX-like suggestions by performing static or dynamic analysis on how components are used. For example, they can detect that a vulnerable function in a library is never called in the application's code. Tools like Kubescape are leading the way in automatically generating VEX documents. These tools are very useful for initial screening.
- Supplier-Provided VEX: The ideal scenario is for software suppliers to publish official VEX documents in standard formats (e.g., CycloneDX or SPDX-based VEX) for their own products. This significantly reduces the burden on consumers.
- Internal VEX Repository: An organization can create an internal VEX repository for its self-developed software and third-party components. This repository makes it easier to manage and update VEX advisories from a central location.
VEX Management and Integration:
For effective management of VEX data, this data needs to be integrated into existing vulnerability management systems. This integration enables automatic comparison of vulnerability scan results with VEX advisories and filtering of alerts accordingly.
- API Integrations: Since VEX documents are typically presented in machine-readable formats like JSON or XML, vulnerability management platforms can retrieve and process this data via APIs.
- Versioning and Updating: VEX documents should be updated along with software versions. When a new software release is published or a new vulnerability is discovered, it is important to update and distribute the relevant VEX document.
- Signing and Verification: Digital signing mechanisms can be used to verify the integrity and origin of VEX documents. This helps prevent malicious or erroneous VEX advisories.
In my Android spam blocker application, I had to mark some vulnerability alerts from third-party libraries as "Not Affected" because I wasn't using a specific feature of the library. If the developers of this library had published official VEX documents, this manual analysis burden would have been eliminated for me. This experience once again showed me the importance of VEX in the supplier-consumer chain.
Application Areas and Challenges
The application areas of VEX are quite broad and can provide benefits at every stage of the software supply chain. However, the adoption and effective use of this new standard also bring some challenges.
Application Areas:
- Software Development Life Cycle (SDLC): Developers can use VEX data in their CI/CD pipelines to filter out false positives that arise during code scanning at an early stage. This reduces unnecessary security remediation efforts.
- Security Operations (SecOps): SecOps teams can focus on truly critical vulnerabilities thanks to VEX, which shortens incident response times and increases operational efficiency.
- Compliance and Auditing: Regulators and auditors can use VEX documents to better assess the maturity of an organization's vulnerability management processes. For example, in SOC 2 or ISO 27001 audits, VEX can be presented as proof of supply chain security commitments.
- Customer and Supplier Relationships: Suppliers provide transparent and context-aware information about the security status of their products to customers by providing VEX documents. This builds trust and increases customer satisfaction.
- Open Source Projects: Maintainers of open-source projects can publish VEX documents to facilitate security management for their users and increase the adoption of their projects.
Challenges Encountered:
- Standardization and Adoption: Since the VEX concept is new, it is not yet widely adopted and standardized across the entire industry. Different organizations may use different formats or approaches.
- Production Burden: Creating VEX documents can require significant effort, especially for suppliers with a large product portfolio. While automation tools can alleviate this burden, manual verification may still be necessary.
- Data Freshness: VEX documents are difficult to keep constantly updated as vulnerabilities are continuously discovered and software components are updated. This requires a continuous tracking and updating process.
- Trust and Verification: Trusting the accuracy of VEX documents is important. A supplier providing incorrect or incomplete VEX information can lead to misleading security perceptions for consumers. Therefore, digitally signing and verifying VEX data is critically important.
In a customer project, during a security audit, dozens of CVEs were identified in the SBOM of a component from a supplier. However, since the supplier did not provide VEX, we had to perform days of manual analysis to understand whether these CVEs were truly effective in the product context. This is a real operational cost that arises when VEX is not yet sufficiently adopted.
The Future of VEX and Software Supply Chain Security
Software supply chain security will continue to be at the top of the technology agenda in the coming years. Developments in this area will further solidify VEX's role and make it an indispensable tool. There are some predictions and potential developments regarding how VEX will evolve in the future.
The Future of VEX:
- Wider Adoption and Standardization: VEX formats (CycloneDX, SPDX, CSAF) will become more standardized across the industry and adopted by more software suppliers. This will facilitate the consumption and integration of VEX data.
- Automation and AI-Powered VEX Generation: Artificial intelligence and machine learning techniques will play a greater role in the automatic generation of VEX documents. Especially in code analysis and vulnerability context assessment, AI models will significantly reduce manual effort. For example, a RAG system could work on known vulnerability data and the codebase to provide automatic VEX suggestions.
- Real-time VEX: VEX data will be updated and distributed synchronously with the discovery and remediation of vulnerabilities. This will enable more dynamic and real-time monitoring of the security posture.
- Centralized Repositories for VEX: Centralized VEX repositories managed by trusted third-party organizations or industry consortia may emerge. These repositories will provide a platform for software suppliers to publish VEX documents and for consumers to easily access this data.
- VEX in Microservice Architectures: In microservice-based architectures, each service will need its own SBOM and VEX documents. This will provide more granular security management and more clearly define the scope of impact of vulnerabilities.
These developments will enable us to manage security risks in the software supply chain more proactively and efficiently. For example, the numerous dependency vulnerabilities we encountered while developing a manufacturing ERP will be able to be assessed and addressed much faster in the future with the more widespread use of VEX. This will allow development teams to focus on innovation while also reducing the operational burden.
⚠️ Potential Obstacles
One of the biggest obstacles to the widespread adoption of VEX is the lack of resources and expertise required for small and medium-sized software suppliers to adopt it. Additionally, doubts about the accuracy and reliability of VEX data may persist; this increases the importance of signed and verifiable VEX documents.
In conclusion, VEX, when used in conjunction with SBOM, is a powerful tool that enables software security teams to focus on the right threats. This integration makes security processes more efficient, minimizing unnecessary costs and time loss caused by false positives.
Conclusion
One of the most significant problems we face in software supply chain security is the high number of false positive alerts generated by vulnerability scanning tools. This unnecessarily consumes security teams' resources and can lead to truly critical vulnerabilities being overlooked. While a Software Bill of Materials (SBOM) provides a starting point, it cannot solve this problem alone due to its lack of contextual information.
Vulnerability Exploitability eXchange (VEX) addresses this lack of context by clearly stating whether a vulnerability in a component is truly exploitable in the context of a specific product. Thanks to status declarations like "Not Affected," "Affected," and "Fixed," security teams can more accurately determine which vulnerabilities to prioritize. This increases operational efficiency, lightens the workload of security analysts, and enables a focus on real threats. The widespread adoption and standardization of VEX will allow us to embrace a more transparent, manageable, and proactive approach in the world of software security.
Top comments (0)