Vex + SPDX  ## Metadata - Author: [[YouTube]] - Full Title: Vex + SPDX - Category: #articles - Document Note: --- tags: [SPDX, VEX, software-security] author: SPDX source: YouTube reference: https://www.youtube.com/watch?v=GPV3f5YvslQ date created: 2024-12-20 10:30 --- # 🏷️ Title: Vex + SPDX ## 🧰 Action Inbox - [H1] Implement VEX messaging to reduce false positive vulnerabilities — 00:45 #security - [H2] Create under investigation messages when CVEs affect your software — 09:15 #vulnerability-management - [H3] Issue mitigation messages when components are patched but still contain vulnerable dependencies — 12:30 #supply-chain ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - [SPDX Security Profile](https://spdx.dev/) - [VEX Working Group](https://cisa.gov/) ## 📝 Summary - VEX (Vulnerability Exploitability Exchange) integration with SPDX provides a way to communicate the actual impact vulnerabilities have on software products - VEX addresses false positives in security dashboards by allowing authoritative sources to communicate vulnerability status changes over time - SPDX 2.3 includes VEX implementation using relationship overloading to convey security information - The system enables machine-readable vulnerability impact communication separate from static SBOMs - Bottom line: VEX + SPDX reduces security noise while maintaining supply chain visibility ## 📖 Main Content VEX (Vulnerability Exploitability Exchange) represents a critical advancement in software security communication, designed to address the growing problem of false positives in security dashboards. As supply chain visibility increases through SBOMs, organizations face more vulnerability alerts, many of which may not actually impact their software due to unused components or mitigated risks. The integration with SPDX leverages existing relationship structures to communicate changing vulnerability assessments. Unlike SBOMs which remain static after software release, VEX messages flow at different cadences to reflect evolving security understanding. This allows authoritative sources (typically software vendors) to communicate whether vulnerabilities actually affect their products. The system supports multiple vulnerability tracking systems beyond CVEs, making it applicable to internal defect tracking and other security databases. SPDX joins OpenVEX as fully compliant VEX implementations, with CSAF and CycloneDX providing partial compatibility. ## 🗒️ Notes #### ⏱️ [00:45](https://www.youtube.com/watch?v=GPV3f5YvslQ&t=45) — [H1] VEX Introduction and Problem Statement - Key idea: VEX conveys actual vulnerability impact on software to reduce false positives - Evidence: "Sometimes when you ship software due to things like base images who include software that you don't really need they start to light up in Flag vulnerabilities that may not necessarily impact your piece of software" #### ⏱️ [02:30](https://www.youtube.com/watch?v=GPV3f5YvslQ&t=150) — [H2] Information Flow Cadences in Security - Key idea: Security information flows at different cadences - SBOMs are static, vulnerabilities change over time - Evidence: "The first one is you have the esbom which is supposed to be static because once you bullish a piece of software it's supposed to never change... but the assessments of those vulnerabilities start to change" #### ⏱️ [03:45](https://www.youtube.com/watch?v=GPV3f5YvslQ&t=225) — [H3] Bob's Browser Example Setup - Key idea: Practical example showing how VEX works with dependent components - Evidence: "Bob's browser contains a version of Carl's compression engine... someone is going to find a CV that affects that it's contained in Carol's compression engine" #### ⏱️ [05:15](https://www.youtube.com/watch?v=GPV3f5YvslQ&t=315) — [H2] VEX Authoritative Sources - Key idea: Software vendors serve as authoritative VEX sources for their products - Evidence: "The Vex author which in this case you should have like a another an authoritative source... is going to be Bob right because if you're running Bob's software then you can pretty much give him you're already trusting him" #### ⏱️ [06:30](https://www.youtube.com/watch?v=GPV3f5YvslQ&t=390) — [H3] SPDX Relationship Enhancement - Key idea: SPDX security profile enhances existing relationships with VEX messaging capabilities - Evidence: "What we did in the security profile is overload I don't know if that's the right word but supercharge might be better those relationships with more information to convey the Vex Services" #### ⏱️ [08:00](https://www.youtube.com/watch?v=GPV3f5YvslQ&t=480) — [H3] Under Investigation Status - Key idea: VEX supports "under investigation" status for newly discovered vulnerabilities - Evidence: "Once the CV hits and it gets published Bob starts looking into it and the first thing that he should do is inform people then okay I'm looking at this vulnerability" #### ⏱️ [09:15](https://www.youtube.com/watch?v=GPV3f5YvslQ&t=555) — [H3] Affected Status Communication - Key idea: VEX enables clear communication when vulnerabilities do affect software - Evidence: "Bob will determine okay I'm affected he sends the affected message on the wire and people can react to it so you can enact policy because all of this is machine readable" #### ⏱️ [10:30](https://www.youtube.com/watch?v=GPV3f5YvslQ&t=630) — [H2] Mitigation Scenarios - Key idea: VEX handles cases where vulnerabilities are mitigated despite containing affected components - Evidence: "Bob May issue like take action and fix it and by himself... he's still shipping this as a vulnerability that's a as a component it may still show up in the scanners" #### ⏱️ [11:45](https://www.youtube.com/watch?v=GPV3f5YvslQ&t=705) — [H3] Not Affected Status - Key idea: VEX allows marking components as not affected even when containing vulnerable dependencies - Evidence: "What Bob's issues is a new message that says even though I'm Shipping You Carl's compression Engine... I have mitigated it and... I'm marking it as not affected" #### ⏱️ [12:30](https://www.youtube.com/watch?v=GPV3f5YvslQ&t=750) — [H2] VEX Working Group and Implementations - Key idea: VEX is standardized by CISA working group with multiple implementation formats - Evidence: "Vex is defined by a working group organized by sisa from the US... spdx now joins a number of Vex implementations" #### ⏱️ [13:15](https://www.youtube.com/watch?v=GPV3f5YvslQ&t=795) — [H3] Compliance Levels - Key idea: SPDX and OpenVEX are fully compliant implementations while others lose information - Evidence: "spdx joins open Vex in being the only two fully compliant implementations of of X... the other two implementations you can go from there to Vex but not the other way around" #### ⏱️ [14:00](https://www.youtube.com/watch?v=GPV3f5YvslQ&t=840) — [H3] Beyond CVE Support - Key idea: VEX extends beyond CVEs to support other defect tracking systems - Evidence: "it can extend beyond cves... as long as you've got that's why we call the group defects as opposed to vulnerabilities" #### ⏱️ [15:30](https://www.youtube.com/watch?v=GPV3f5YvslQ&t=930) — [H3] Document Flow Architecture - Key idea: VEX creates separate relationship documents that reference static SBOMs - Evidence: "You could issue just the document with the reference for the vulnerability and the reference for the product... we only need those three in the document" #### ⏱️ [17:00](https://www.youtube.com/watch?v=GPV3f5YvslQ&t=1020) — [H3] Cross-Version Compatibility - Key idea: VEX documents can reference older SPDX versions and compile information from multiple formats - Evidence: "You can point to 2.3 document... you can compile that all of that information to piece together the impact story which may not necessarily come all from spdx" ## 📚 References - [SPDX Security Profile Documentation](https://spdx.dev/) - [CISA VEX Working Group](https://cisa.gov/) - [OpenVEX Implementation](https://github.com/openvex) ## 🗣️ Paraphrase - VEX solves the false positive problem in vulnerability scanning by allowing software vendors to communicate the real impact of CVEs on their products - The system works by enhancing SPDX relationships to carry security status messages that change over time, unlike static SBOMs - Practical implementation involves separate VEX documents that reference existing SBOMs and can communicate investigation status, affected status, and mitigation information ## 📰 Newsletter **VEX + SPDX: Cutting Through Security Noise** The latest SPDX security profile brings VEX (Vulnerability Exploitability Exchange) capabilities that could revolutionize how we handle vulnerability management. Instead of drowning in false positives from unused components, VEX lets authoritative sources communicate real vulnerability impact. Key benefit: Machine-readable security status that evolves independently of static SBOMs. When a CVE hits your dependency chain, vendors can now communicate "under investigation," "affected," "mitigated," or "not affected" status through standardized messaging. This addresses the growing pain point where increased supply chain visibility creates security dashboard noise. Base images and unused components trigger alerts that don't reflect actual risk. **Resources:** [SPDX Security Profile](https://spdx.dev/), [VEX Working Group](https://cisa.gov/), [OpenVEX](https://github.com/openvex) ## ✅ Action Items #### DevRel - Developer advocacy: Create VEX adoption presentations for security conferences, demonstrate false positive reduction metrics - Education: Develop workshops on VEX message lifecycle, create hands-on labs with Bob's Browser example - Developer experience: Build VEX message validation tools, create SPDX relationship debugging utilities - Developer marketing: Campaign around "security signal vs noise" messaging, VEX adoption case studies - Community management: Moderate VEX implementation discussions, gather feedback on relationship overloading approach #### OSPO - Policy & Governance: Establish VEX authoritativeness policies, define vendor responsibility for security messaging - License Compliance: Integrate VEX status into compliance scanning workflows, update SBOM policies - Security Management: Implement VEX message intake processes, establish vulnerability assessment cadences - Software Inventory: Enhance SBOM strategy with VEX relationship tracking, define product-level grouping - Developer Support: Train teams on VEX message creation, provide relationship mapping consultation - Community Engagement: Fund VEX tooling development, establish vendor communication agreements - Strategic Alignment: Define VEX adoption KPIs, measure false positive reduction metrics #### Community - Maintainers: Provide VEX messaging templates, support security profile governance decisions - Contributors: Create VEX message onboarding guides, establish first-issue programs for tooling - Sponsors: Fund VEX implementation development, support cross-format interoperability testing - Ecosystem: Coordinate between SPDX, OpenVEX, CSAF, and CycloneDX communities ## 🧪 Hypotheses - VEX implementation will reduce security dashboard false positives by 40-60% in organizations with complex dependency chains - Authoritative VEX messaging will improve vulnerability response times by providing clear impact guidance - SPDX relationship overloading approach will enable better cross-format VEX information compilation - Machine-readable VEX status will enable automated policy enforcement for vulnerability management ### 📊 Methodology - A/B testing comparing security workflows with and without VEX messaging integration - Longitudinal study tracking false positive rates before and after VEX adoption in enterprise environments - Cross-format interoperability testing between SPDX, OpenVEX, CSAF, and CycloneDX implementations ### ❓ Questions - How will organizations establish trust relationships with VEX authoritative sources beyond direct vendors? - What happens when multiple authoritative sources provide conflicting VEX assessments for the same vulnerability? - How can VEX messaging scale to handle the volume of vulnerability assessments in large software ecosystems? ### 🔮 Future Research - Integration patterns between VEX messaging and existing vulnerability management platforms - Automated VEX message generation using static analysis and runtime behavior detection - Blockchain or cryptographic verification methods for VEX message authenticity ### 💡 Implications - Practice: Security teams need new workflows for consuming and acting on VEX messages from multiple sources - Policy: Organizations must establish criteria for trusting VEX authoritative sources and handling conflicting assessments - Security: VEX reduces alert fatigue while maintaining visibility into actual vulnerability impact - Education: Security professionals need training on VEX message lifecycle and SPDX relationship interpretation - Funding: Investment in VEX tooling and cross-format interoperability testing becomes critical for adoption ### 🧠 Learning Styles Assessment Reading level estimate: Flesch-Kincaid Grade Level 12 #### 👀 Visual learners - Present: Bob's Browser dependency diagram, VEX message flow illustration - Improve: Timeline visualization of message cadences, relationship mapping diagrams #### 🔊 Aural learners - Present: Video presentation with clear narration and examples - Improve: Podcast-style discussion of VEX use cases, audio walkthrough of implementation steps #### 🗣️ Verbal learners - Present: Concrete Bob/Carol example, clear terminology definitions - Improve: Analogy-driven explanations of relationship overloading, story-based implementation scenarios #### 🧩 Kinesthetic learners - Present: Step-by-step VEX message creation example - Improve: Interactive VEX message builder, hands-on SPDX relationship editing exercises #### 🧠 Logical learners - Present: Clear information flow cadences, structured message types - Improve: Decision trees for VEX status selection, formal specification references #### 🧑‍🤝‍🧑 Social learners - Present: Q&A discussion with community feedback - Improve: Working group collaboration examples, peer review processes for VEX messages #### 🧘‍♀️ Solitary learners - Present: Technical specification details, implementation requirements - Improve: Self-assessment checklists for VEX readiness, independent study materials #### 🌿 Naturalistic learners - Present: Software ecosystem relationships, dependency chain analogies - Improve: Biological network comparisons, environmental impact of reduced false positives ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear heading structure, descriptive example names - Improve: Alt text for diagrams, ARIA labels for relationship visualizations #### Keyboard navigation - Present: Standard video controls, logical tab order - Improve: Skip links for different topics, keyboard shortcuts for timestamp navigation #### Contrast and readability - Present: Standard video player interface - Improve: High contrast mode for diagrams, larger text options for specifications #### Text resizing and reflow - Present: Responsive video player - Improve: Scalable diagram elements, reflowable transcript layout #### Media and captions - Document Tags: [[supply]] [[security]] [[vulnerability]] - Summary: Vex + SPDX - URL: https://www.youtube.com/watch?v=GPV3f5YvslQ okay um Adolfo is going to go over Vex and how you would show you know maybe a vulnerability is affected and then maybe you do more research and you realize it's not affected he's going to cover how you would show those changing statuses of relationships all right yeah so let's um go a little bit on on two of eggs so for those who are not familiar Vex which stands for vulnerability exploitability exchange is a way of conveying the actual impact that a vulnerability has on a given piece of software because once uh as we are seeing as well information starting to increase and flow even more so do the number of false positives and other information and detailing like starting to light up security dashboards across right because you have more visibility into your supply chain and those components start to show up especially this is especially true for and because sometimes when you ship software due to for example things like base images who include software that you don't really need they start to light up in Flag vulnerabilities that may not necessarily impact you're a piece of software um so to okay so to understand this I want to give like a short example um so the first thing I want to point out is if you saw when Rosa's previous examples um the security profile is about conveying the disclosure of security information so and you you have to think about the information flowing regarding to security as uh flowing different cadences so the first one is you have the esbom which is supposed to be static because once you bullish a piece of software it's supposed to never change right because if you issue a new piece of software it's it needs a new version because it's a different thing and then on top of that you have the security information you have a vulnerability and that when that's released it has a set Cadence it should also not change but the assessments of those of those vulnerabilities start to change and more information can it's known more people are looking at it are amid like issuing opinions of the developing and it starts to change and the same is true for the impact of the vulnerability with a given piece of software so I'm going to retake the example of Bob's browser I think I took a subset of that by centering out on the on Bob's browser so Bob's browser contains a version of Carl's compression engine so in this um in this case what's going to happen is that someone is going to find a CV that affects that it's contained in Carol's compression engine so if Carl's compression engine has that CV that means that at some point Bob's browser is going to start being to get flagged as vulnerable so the first thing that's going to happen in this the Vex author which in this case you should have like a another an authoritative source of Base information is going to be Bob right because if you think about it if you're running Bob's software then you can pretty much give him uh you're already trusting him of understanding what he's shipping and he may understand uh the impact that this CV has on his browser which came through this dependence here so the first thing that a Vex author might do is issue and under investigation um and another investigation message invex um it's the idea of X is people start sending down the wire messages of the known impact and vulnerability has on software and if you think about spdx the great thing about spdx is that it has all of these wonderful sets of relationships that let you communicate had this this all of these pieces relate to each other so what we did in the security profile is overload I don't know if that's the right word but supercharge might be better those relationships with more information to convey the Vex Services just as we did with the security assessments so once the CV hits and it gets published Bob starts looking into it and the first thing that he should do is inform people then okay I'm looking at this vulnerability and how it affects my software and then after that he may found ah so the under investigation relationship has a like a field where it lets you point I'm looking at this cve in my browser but assessed like looking at it through the because I know it's containing Carol's compression engine v31 and then the next one is Bob will determine okay I'm affected he sends the affected message on the wire and people can react to it so you can enact policy because all of this is machine readable so if your idea is okay I should patch I should like take care like take care of it in my own hands this is the the there's your studying message that you should start acting or the next one is okay let's say that Bob goes to Carol and says Carol can you patch the vulnerability Kyle may say well I'm the lonely maintainer in Nebraska I cannot do that just now so Bob May issue like take action and fix it and by himself so he really says uh b221 with a mitigation for that uh for the cve containing in Carol's compression engine but if you think about it and he's still shipping this as a vulnerability that's a as a component it may still show up in the scanners because it's still contained in there even though he Bob has mitigated it in his piece of software the the the CV is still contained in his offer so what Bob's issues is a new message that's it that says even though I'm I'm Shipping You Carl's compression Engine with which is a factor in a CV I have mitigated it and in the the it's not like the security document in spdx I'm marking it as not affected and so this is the the way of that Vex convex messages on the underwear and so Vex is defined by a working group uh organized by sisa from the US and this means that now spdx joins a number of Vex implementations so the working group defines Vex as a an idea as a spec of specs in spdx now joins uh openvx csap and Cyclone DX as Vex implementations and the as as we are just releasing it and the final Vex specification or document defining what the minimal requirements Forex was released in January spdx joins open Vex in being the only two uh fully compliant implementations of of X so the other two implementations you can go from there to Vex but not the other way around because you lose information which is critical for a proper functioning effect implementation um so that's that's the base of it so and this is a one and okay so I'm gonna turn it over to Karen and out yeah this is the Legend This is a pointer and cve reporting right but there are some time some defects in the software how do you intend to use Vex so you can communicate some unpatched software I'm thinking more on not from CI but more on a availability perspective like you know buffer overflow Etc that is software developer can include have you guys thought about that okay the question is um this whole schema relies on cve reporting so you can include CV are there a an option where software developer can include some software defects that can be related to end user using wax it can extend beyond cves it's been designed to work with other bug systems that are out there so as long as you've got that's why that's why we call the group defects as opposed to vulnerabilities because there are defects out there that we need to report in on and so this is a mechanism that should extend there but if it doesn't we want to know this right now this is why we're bringing this stuff forward yeah and the other thing is Vex is not based around a software version it says around the product and so it has this like level notion around product so uh product can be an spdx package but also a bigger software package and um and it also has a vulnerability like just plain building it doesn't it's not tied to a cve it can also I think if we if I remember correctly the definition that we added to the vulnerabilities any vulnerability that can be tracked that is registered in a tracking system so if you have like an in-house tracking system it can point to that like you can if it if it has a reference you can relate to it that's where you can use the external identity that's where you can use the security external identifiers to say that you know I am the agency that's who assigned this ID for this defect and then you can also use the external um references to point to you know information about that defect s it's a more generic question to all the presenters can you please upload your presentations to the schedule thanks can you go back to this slide with Bob and Carol for a second I'm trying to get my understanding of the document flow uh improved that's that's the one so today if I look at a 2.3 implementation I create an s-bomb I have the description of what's in that particular application so I've got Bob's s-bomb includes Carol I understand that I've got one document that was created with Vex am I effectively having a series of spdx documents that are going to be part of the flow and if so what out of the original s-bomb contents are part of that flow so in other words am I overloading A system that is just starting to figure out what s-bombs are all about with this additional data set that now needs additional mapping so I'm just trying to get that clear in my head thanks no ideally you could issue just the the document with the so vaccine spdx is a relationship so you could issue just that document with a with the reference for the vulnerability and the reference for the product and just the even the soup component is it's just the identifier so we only need those three in in the in the document so you start shipping those so then I have a an s-bomb document itself that represents whatever was shipped so Bob's 2.2 and now I'm going to have a number of relationship documents that will refer back to that original spdx document exactly which should be remain static because it's the same piece of software okay then when Bob creates 2.2.1 sorry what so then when Bob creates 2.2.1 well there might be a component change if he did patch Carol's engine or maybe there was something else that came along for the ride as part of the mitigation effort but theoretically that s-bomb is close enough but it's still a mapping from that point exactly I mean in in that case it's a new S1 because it's a new piece of software right right so it's an additional but yeah like Rose said it uh yeah I was just going to say that you can have multiple relationships and multiple multiple vulnerability elements in one you know security profile s-bomb so you don't have to create a new quote-unquote document for each relationship security relationship or each vulnerability so that then allows me potentially a question uh to create a vulnerability mapping back to a previously piece of software that is using an older version of spdx oh yeah I don't to spdx 2.3 okay yeah so you can point to 2.3 document but cool thank you and not only that you can also Point like the idea of fix is when once you have like once we start getting like Vex processors you can compile that all of that information to piece together the impact story which may not necessarily come all from spdx it can come from the other formats as well, Vex + SPDX, YouTube, 01ka7pbs1rzyw5xsvvtzw56bat.