2025-03-18
In this Keymaster episode, we explore VEX (Vulnerability Exploitability Exchange), a structured way to communicate whether vulnerabilities impact a product. While it is gaining traction, there is still limited mainstream content on it, so we’re here to break it down.
Our guest, Olle E. Johansson, is an experienced and appreciated speaker, teacher, open-source developer, and consultant who brings valuable insights to the discussion. Thank you for joining us and sharing your expertise on VEX!
Here’s a summary of the conversation between Sven Rajala, Keyfactor’s international PKI man of mystery, and Olle Johansson.
When organizations receive SBOMs (Software Bill of Materials), they often get bombarded with vulnerability reports. The problem? Many of these flagged issues do not actually pose a risk because they are in unused parts of the software. This leads to unnecessary patching, confusion, and operational slowdowns.
That is where VEX comes in. It allows vendors to clarify which vulnerabilities truly matter and which ones do not impact their product, cutting through the noise. It also enables vendors to communicate mitigation steps or ongoing investigations, providing better transparency to customers.
But how do you actually consume a VEX file? Right now, vendors typically publish them on their websites, which is not scalable. The missing piece is automation—integrating VEX data into security workflows. That is why initiatives like the OWASP Transparency Exchange API are being developed to make vulnerability intelligence more actionable.
Of course, trust is a major concern. How do you know if a vendor’s VEX file is accurate? Regulations like the Cyber Resilience Act (CRA) are changing the game—forcing vendors to provide security updates for up to five years after a product’s release. This shifts the responsibility from just releasing software to maintaining its security over time.
While automation helps, human expertise is still crucial for assessing vulnerabilities. AI and automation can assist, but ultimately, software architects and engineers need to make the final call on exploitability.
There’s also an ongoing discussion about whether third parties could generate independent VEX files to validate vendor claims. This could bring security firms or industry authorities into the mix to provide a more balanced view, especially when vendors might be incentivized to downplay risks.
VEX is still an evolving piece of the security puzzle, but it is becoming a vital tool for modern software security. As the ecosystem matures, we will see more automation, better standards, and stronger accountability.
Thanks for tuning in, and stay secure!
Olle E. Johansson is an experienced and appreciated speaker, teacher as well as an Open Source developer and consultant. He is currently project lead for OWASP Project Koala, developing the Transparency Exchange API (TEA), member of the CycloneDX industry working group, the OWASP SBOM Forum, co-founder of SBOMEurope.eu and a leader for the DNS TAPIR Open Source project.
While not trying to save the world with SBOMs, he is helping clients with the journey towards CRA compliance as a consultant in his company Edvina AB. Once a year, he organises the Nordic Software Security Summit conference in Stockholm, Sweden. Olle has been a core developer of Asterisk - the Open Source PBX, part of the core team in Kamailio.org and is currently also a member of the team that tries to put some new energy into SoftHSM.org.