Introducing SecPod VEX Studio: Guided Vulnerability Exploitability Assessment for Open-Source Maintainers
A human-guided path from SBOM and vulnerability data to reviewable OpenVEX statements
Modern software is assembled from many direct and transitive dependencies.
That makes component visibility essential, but it also creates a familiar challenge for maintainers and security teams: a scanner reports a vulnerability in a package, yet the report alone does not explain what that vulnerability means for the product that contains it.
A component and version may match a known advisory.
The affected function may still be unreachable, disabled, excluded from the build, or protected by an existing control. In other cases, the vulnerable path is exposed and needs remediation.
The work begins with the match, but the decision depends on product-specific context.
The central question is not only "Is the component present?" It is also "Does the vulnerable behavior affect this product, and what evidence supports that conclusion?"
SecPod VEX Studio is designed to help maintainers work through that question and publish the result in a structured, reviewable form.
A CVE match is the beginning of the investigation
Software composition analysis and vulnerability scanners perform an indispensable function.
They identify packages and versions, correlate them with advisory databases, and surface known vulnerabilities.
Without that visibility, teams cannot begin a reliable investigation.
But a version match establishes a possibility, not the complete product impact.
Consider a vulnerable library introduced as a transitive dependency.
The library may be packaged with the product even though the affected API is never called.
A vulnerable feature may be disabled at build time or inaccessible through the product's public interface.
A compensating control may block the required attacker input.
Alternatively, the exact vulnerable path may be reachable in production.
These cases cannot be separated safely through package presence alone.
Someone who understands the product must examine its code, build, configuration, interfaces, and runtime behavior.
The conclusion should then be captured so customers and downstream users do not have to repeat the same investigation without the maintainer's context.
What is VEX?
Vulnerability Exploitability eXchange, or VEX, communicates the status of a product or component with respect to a specific vulnerability.
CISA's VEX resources describe it as a way for a software supplier or another party to clarify whether a vulnerability affects a product.
VEX is closely related to a Software Bill of Materials, but the two answer different questions:
- An SBOM inventories the components in a product. It answers: What is present?
- A VEX statement records the status of a product or component for a vulnerability. It answers: What does this vulnerability mean here?
A VEX statement typically connects four kinds of information: the product or component being assessed, the vulnerability identifier, an explicit status, and supporting context.
Common statuses include affected, not_affected, fixed, and under_investigation.
A not_affected conclusion should include a recognized justification and a clear impact statement.
An affected conclusion can include the action that users should take.
VEX does not replace vulnerability analysis, secure development, patching, or code review.
It makes the result of an analysis easier to review, exchange, and consume.
The quality of a VEX statement therefore depends on the quality of the evidence behind it.
The difficult part is deciding the status
Once a maintainer already knows the correct status, formatting that decision as JSON is comparatively straightforward. The harder task is reaching a defensible conclusion.
What behavior does the advisory actually describe? Which function, interface, configuration, or data flow is involved?
Does the product invoke that behavior? Can untrusted input reach it? Is a mitigation active in every supported deployment? Has the issue already been fixed in the assessed version?
These questions require security reasoning and product knowledge.
They are also easy to approach inconsistently when every maintainer starts from a blank page.
VEX Studio addresses this gap by turning the assessment into a guided workflow while keeping the maintainer in control.
How VEX Studio works
The current assess command brings four stages together:
- Generate or ingest an SBOM
VEX Studio can generate CycloneDX data from a package URL, supported project input, requirements file, or Python environment. It can also load existing CycloneDX or SPDX JSON. - Find known vulnerabilities
It queries OSV for the components in the SBOM and can optionally enrich the findings with GitHub Security Advisories. - Guide the prioritization
It selects CWE-aligned questions when matching guidance is available and uses general reachability questions otherwise. The maintainer reviews the evidence and answers the questions. A finding can be deferred as under_investigation when the available evidence is insufficient. - Publish OpenVEX
The reviewed answers are mapped to the appropriate VEX status and supporting context. VEX Studio then writes an OpenVEX 0.2.0 document and retains the triage session for review or continuation.
This is deliberately a human-in-the-loop process.
VEX Studio structures the investigation and makes security reasoning more reusable, but it does not independently inspect every product behavior or silently declare a vulnerability exploitable or non-exploitable.
What guided prioritization adds
Vulnerabilities are associated with different weakness types. T
The questions that matter for unsafe deserialization are not identical to those for cross-site scripting, path traversal, command injection, or an out-of-bounds operation.
VEX Studio uses the vulnerability's CWE context to choose more relevant questions.
For example, the workflow may ask whether the product calls an affected function, whether attacker-controlled data can reach that function, or whether a mitigation prevents the unsafe operation.
When specific guidance is unavailable, the tool falls back to a general reachability path rather than pretending to have knowledge it does not possess.
The answers form an audit trail.
A reviewer can see how the maintainer moved from advisory information to a status, and the maintainer can defer the decision instead of forcing certainty.
This is important: under_investigation is an honest and useful result when more evidence is needed.
The OpenVEX result
The current release produces OpenVEX 0.2.0.
Each statement identifies the vulnerability and product, records a status, and includes the context appropriate to that status.
The output is machine-readable, but it should also remain understandable to a human reviewer.
The objective is not to remove every vulnerability alert.
It is to communicate a product-specific determination accurately.
If the evidence shows that the product is affected, the VEX statement should say affected and record the relevant action.
If the investigation is incomplete, it should remain under_investigation. A not_affected statement should be used only when the maintainer can support the justification.
Try the current alpha version of VEX Studio
VEX Studio is currently version 0.1.0 and classified as alpha software.
It requires Python 3.11 or later and is installed from source; it is not yet published to PyPI.
Run the assessment in a test environment first. Review each answer and status and retain the supporting evidence.
The VEX Studio repository also documents separate commands for SBOM generation, scanning, triage, status review, and publishing.
What is available now in VEX Studio and what is not
The alpha release is intentionally focused.
Today it provides a local Python command-line workflow, CycloneDX and SPDX JSON input, OSV scanning with optional GHSA enrichment, CWE-guided human prioritization, resumable session state, and OpenVEX 0.2.0 output.
Additional vulnerability intelligence, other VEX formats, signing, a web interface, and AI assistance are roadmap items rather than released capabilities.
VEX Studio also does not automatically establish exploitability.
Maintainers must verify the product context and remain accountable for the published statement.
Why structured communication matters now
Software producers face growing expectations to understand dependencies, investigate vulnerabilities, and communicate status quickly.
The EU Cyber Resilience Act is part of that context.
Article 14 reporting obligations begin on September 11, 2026 for actively exploited vulnerabilities and severe security incidents affecting products with digital elements, as described in the European Commission's reporting guidance.
The CRA does not mandate VEX, and a VEX statement does not by itself satisfy legal or regulatory obligations.
VEX can support the broader operational discipline of recording product-specific decisions and communicating them consistently.
Organizations should interpret their obligations with qualified legal and compliance guidance.
Extend Your Help to Improve VEX Studio
VEX Studio will become more useful through real assessments and reviewable contributions.
Maintainers, developers, AppSec and DevSecOps teams, security practitioners, researchers, students, and enthusiasts can contribute in several ways:
- Test the workflow on a package or SBOM and report reproducible issues.
- Identify confusing questions, unsupported ecosystems, and missing edge cases.
- Improve installation guidance, examples, documentation, and tests.
- Add well-researched questions to the CWE questionnaire catalog.
- Contribute code for packaging, formats, integrations, and roadmap capabilities.
- Share examples of affected and under_investigation decisions that teach good evidence practices without overstating certainty.
Explore the VEX Studio overview, review the source code, and tell us where the guided workflow helps and where it needs to improve.
