Continuous Vulnerability & VEX Monitoring

A vulnerability assessment performed before product release only reflects the security status at that particular time.

After release, the threat environment continues to evolve. New CVEs are published, software dependencies change, exploit methods become available and component maintainers release fixes or additional security information.

Organisations therefore need to answer more than:

“Does our product contain a component with a known vulnerability?”

They also need to determine:

• Is the affected component actually present?
• Which product versions contain it?
• Is the vulnerable functionality enabled?
• Can the vulnerable code be reached or exploited?
• Are technical protections already in place?
• Does the issue require remediation?
• Has the vulnerability already been fixed?
• What evidence supports the decision?

Continuous monitoring provides the process needed to answer these questions consistently and keep the results documented.

The monitoring scope can be defined according to the organisation's products, software architecture and available component information.

Depending on the agreed scope, monitoring may include:

• Released product versions
• Embedded software and firmware
• Operating systems
• Open-source libraries
• Third-party dependencies
• Software packages
• Mobile and web applications
• APIs and connected services
• Software Bills of Materials
• Supplier security advisories
• Published vulnerability databases and notices

The objective is to maintain a clear connection between the product, its components, disclosed vulnerabilities, exploitability decisions and remediation activities.

Practical Vulnerability and VEX Monitoring Process

A structured process helps transform vulnerability information into clear product-security decisions.

This process helps prevent vulnerability management from becoming a collection of disconnected alerts without clear decisions or ownership.

A component vulnerability does not automatically mean that every product containing that component is exploitable.

The actual product context must be considered.

A vulnerability assessment may need to determine whether:

• The affected version is installed
• Vulnerable code is included
• The vulnerable function is enabled
• The execution path can be reached
• External input can reach the vulnerable function
• Product configuration changes the exposure
• Existing controls reduce or prevent exploitation
• The issue has already been corrected

This is where VEX becomes valuable.

VEX allows organisations to document whether a product is affected, not affected, fixed or still under investigation, supported by technical reasoning and evidence.

VEX documentation should support transparent and repeatable decision-making.

Each significant vulnerability assessment should be linked to the relevant product and version and supported by sufficient evidence to explain the outcome.

A practical VEX or vulnerability record may include:

• Vulnerability identifier
• Affected component
• Component version
• Product version
• Assessment date
• Current vulnerability status
• Technical justification
• Supporting evidence
• Required remediation
• Responsible owner
• Verification status
• Change history

If new information changes the technical understanding of the vulnerability, the assessment and VEX record should be reviewed accordingly.

Maintain Accurate Product and Component Data

Reliable monitoring depends on accurate product and software-component information.

Organisations should maintain clear product versions, software versions, firmware versions and, where available, up-to-date SBOM information.

Match Vulnerabilities to Exact Versions

Avoid assuming that an entire product family is affected because a component name appears in a vulnerability record.

The affected component version and the corresponding product versions should be confirmed.

Separate Detection From Decision-Making

Automated vulnerability matching can identify potential risks, but technical assessment is still required to determine whether the vulnerability is relevant to the finished product.

Document the Reason Behind Decisions

A vulnerability status should be supported by clear reasoning.

Teams should record why a vulnerability is considered affected, not affected, fixed or under investigation.

Assign Remediation Ownership

Relevant vulnerabilities should have a defined owner and clear next action.

Actions may include updating a dependency, creating a patch, applying mitigation, requesting supplier information, conducting additional testing or continuing investigation.

Preserve the Remediation History

Previous assessments should not simply be overwritten.

An auditable history should show when the vulnerability was identified, how it was assessed, what actions were taken and when the issue was closed.

Supporting Cyber Resilience Act Readiness

Continuous vulnerability management is also relevant for organisations preparing for the EU Cyber Resilience Act (CRA).

The CRA introduces cybersecurity and vulnerability-handling requirements for products with digital elements within its scope. Manufacturers are expected to establish processes for identifying, documenting and addressing vulnerabilities during the applicable support period.

Continuous monitoring can support this wider vulnerability-handling framework by providing:

• Visibility of vulnerabilities affecting released products
• Product and component traceability
• Documented exploitability assessments
• Remediation records
• Evidence of corrective actions
• Historical vulnerability decisions
• Structured escalation and follow-up processes
• Inputs for technical cybersecurity documentation

The precise regulatory requirements depend on the product, the organisation's role and the applicable conformity strategy.

ComplyMarket supports organisations with product cybersecurity, SBOM assessment, vulnerability management and cybersecurity compliance activities.

Its existing cybersecurity services include areas such as software-component review, vulnerability matching, dependency assessment, remediation planning, CRA readiness and technical-documentation support.

Within an agreed Continuous Vulnerability and VEX Monitoring scope, ComplyMarket can support activities such as:

• Product and software-component baselining
• SBOM review
• Vulnerability matching
• Product-specific vulnerability assessment
• Exploitability decision support
• VEX documentation support
• Remediation prioritisation
• Vulnerability-handling process review
• Technical evidence management
• CRA readiness
• Verification and retesting following corrective actions

The monitoring framework can be tailored according to the products involved, available SBOM data, monitoring frequency, technical responsibilities and required documentation.

This creates a more structured approach to post-release cybersecurity in which organisations can understand what changed, which products are affected, why the vulnerability matters, what action is required and how the issue was resolved.

New vulnerabilities will continue to emerge throughout the life of a digital product.

A structured vulnerability and VEX monitoring process helps organisations identify relevant risks earlier, prioritise remediation, maintain reliable technical evidence and support ongoing cybersecurity responsibilities.