Module 6: Vulnerability Management and Continuous Monitoring

1. Where This Fits in the CRA Lifecycle

In Modules 4 and 5 you saw that the EU Cyber Resilience Act (CRA) requires security-by-design and ongoing risk management.

This module focuses on what happens after your product is on the market:

• You must monitor your product for new vulnerabilities.
• You must handle vulnerabilities in:
• your own code
• third-party proprietary components
• open-source software (OSS) components
• You must provide free security updates for at least the expected product lifetime or the minimum support period set by the CRA (whichever is longer, once specified in the final text and related standards).
• You must cooperate with vulnerability disclosure processes, including coordinated vulnerability disclosure (CVD) with security researchers.

Think of this module as: “What are my ongoing duties once users are actually using my software?”

2. CRA Obligations for Monitoring Products in the Field

Under the CRA (political agreement reached 2023–2024; final text expected to apply after a transition period), manufacturers must:

1. Continuously monitor:

• Public vulnerability databases (e.g., NVD, CERTs, EU-level advisories)
• Supplier and open-source project security advisories
• Bug bounty platforms or internal reporting channels

1. Detect and assess:

• New vulnerabilities affecting your product’s components
• Exploited vulnerabilities ("in the wild")
• Misconfigurations that undermine security-by-default

1. React appropriately:

• Prioritize vulnerabilities by severity and exploitability
• Provide security updates and/or mitigations in a timely way
• Inform users and authorities when required (e.g., for actively exploited or severe vulnerabilities)

In practice, this means you must have a documented vulnerability management process and not just rely on ad‑hoc fixes.

3. Example: Monitoring in a Connected Home Router

Imagine you are the manufacturer of a Wi‑Fi router sold across the EU.

Your continuous monitoring might look like this:

• You maintain a software bill of materials (SBOM) listing all libraries and components (e.g., Linux kernel version, OpenSSL, BusyBox, web UI framework).
• Every day, an automated tool checks:
• CVE feeds for vulnerabilities affecting these components
• Security advisories from the Linux distribution and OpenSSL project
• When a new critical OpenSSL vulnerability is published:

1. Your security team receives an alert.
2. They check: Does our router use the vulnerable version? If yes:

• Assess impact: Can this lead to remote code execution or data theft?
• Evaluate exploitability: Is there public exploit code?

1. They schedule an urgent security patch release and prepare a security advisory for users.
2. They ensure the update is pushed automatically (security-by-default), or at least strongly prompted.

Under the CRA, failing to do this systematically could be considered non‑compliance with post‑market cybersecurity obligations.

4. Thought Exercise: Design a Simple Monitoring Plan

Imagine you are responsible for a cloud-based note‑taking web app used by EU customers.

Sketch a minimal monitoring plan (just think it through, or jot down notes):

1. Sources to monitor

• Which vulnerability databases or feeds would you check?
• Which third‑party vendors’ advisories would you follow (e.g., your cloud provider, database vendor, major frameworks)?

1. Tools and automation

• What tools could you use for:
• Dependency scanning (e.g., GitHub Dependabot, GitLab Dependency Scanning, Snyk, OWASP Dependency-Check)?
• Container image scanning?

1. Response rules

• How quickly would you aim to patch:
• Critical remotely exploitable bugs?
• Medium‑severity issues?
• Who on your (hypothetical) team would approve emergency patches?

Compare your ideas with this minimal CRA‑aligned checklist:

• [ ] At least weekly automated scans of dependencies for known vulnerabilities.
• [ ] Named person or role responsible for reviewing alerts.
• [ ] Documented criteria for what counts as critical and high severity.
• [ ] A basic playbook: detect → assess → patch/mitigate → notify users if needed.

5. Handling Vulnerabilities in Own, Third‑Party, and Open‑Source Code

The CRA makes it clear: you are responsible for the overall security of the product, even if vulnerabilities come from third‑party or open‑source components.

A typical CRA‑aligned vulnerability handling process:

1. Identification

• From monitoring tools, user reports, bug bounty submissions, or researchers.

1. Triage and risk assessment (ties to Module 5)

• Classify severity (often using CVSS or similar).
• Check whether there is known exploitation.
• Map the vulnerability to affected versions and configurations.

1. Remediation strategy

• Own code: fix the bug, add tests, maybe add extra logging.
• Third‑party proprietary: request or obtain a patch from the vendor; decide whether to replace or remove the component if vendor is slow.
• Open‑source: pull upstream patches, backport if needed, or temporarily disable vulnerable features.

1. Release and communication

• Provide a security update (patch, configuration change, or workaround).
• Publish release notes / advisories explaining impact and urgency.

1. Documentation and learning

• Update your risk assessment, SBOM, and secure development guidelines.
• Record the incident in your post‑market surveillance log (a CRA expectation).

6. Practical Example: Automating Dependency Checks

Below is a simplified example using Node.js with `npm audit` and a GitHub Actions workflow to continuously check for vulnerable dependencies.

```yaml

.github/workflows/security-audit.yml

name: Security Audit

on:

schedule:

• cron: '0 3 *' # run daily at 03:00 UTC

workflow_dispatch: # allow manual run

jobs:

npm-audit:

runs-on: ubuntu-latest

steps:

• name: Checkout repository

uses: actions/checkout@v4

• name: Use Node.js

uses: actions/setup-node@v4

with:

node-version: '20'

• name: Install dependencies

run: npm ci

• name: Run npm audit

run: |

npm audit --json > audit-report.json || true

• name: Fail on high/critical vulnerabilities

run: |

node << 'EOF'

const fs = require('fs');

const report = JSON.parse(fs.readFileSync('audit-report.json', 'utf8'));

const vulnerabilities = Object.values(report.vulnerabilities || {});

const highOrCritical = vulnerabilities.filter(v =>

['high', 'critical'].includes(v.severity)

);

if (highOrCritical.length > 0) {

console.error('High/critical vulnerabilities found:', highOrCritical.length);

process.exit(1); // fail the pipeline

}

console.log('No high/critical vulnerabilities found.');

EOF

```

This kind of automation supports CRA obligations by:

• Providing continuous monitoring of dependencies.
• Creating an audit trail of security checks.
• Helping you react quickly when new vulnerabilities appear.

7. Security Updates and Minimum Support Periods under the CRA

The CRA introduces explicit obligations to provide security updates:

1. Free security updates

• Manufacturers must provide security updates at no additional cost to users.
• Updates must be designed to minimize disruption and maintain security-by-default (e.g., automatic updates enabled by default where feasible).

1. Support period

• You must support the product for at least its expected lifetime as declared in your documentation, or for a minimum period specified by the CRA/implementing acts, whichever is longer (once fully specified in the final legal and standardization texts).
• You must clearly inform users about:
• How long they will receive security updates.
• How updates will be delivered (automatic, manual, etc.).

1. Timeliness

• The CRA expects you to address vulnerabilities without undue delay, especially for critical vulnerabilities.
• Sectoral rules (e.g., NIS2 for essential entities) may impose stricter timelines in some contexts.

1. End‑of‑support

• When the support period ends, you must clearly communicate this to users and avoid giving a false impression that the product is still secure.

In short: you cannot ship a product and then silently stop patching it while people are still using it in the EU.

8. Quiz: Security Update Obligations

Test your understanding of CRA security update expectations.

9. Coordinated Vulnerability Disclosure (CVD) and Reporting

The CRA aligns with modern coordinated vulnerability disclosure (CVD) practices.

Manufacturers are expected to:

1. Provide a clear reporting channel

• e.g., `security@company.com`, a web form, or a security.txt file on your domain.
• Describe how to report vulnerabilities securely (e.g., encrypted email).

1. Acknowledge and coordinate

• Confirm receipt to the reporter.
• Agree on a reasonable disclosure timeline (for example, 90 days, adjustable for complexity and severity).

1. Assess and fix

• Integrate the report into your vulnerability management process.
• Prepare patches, mitigations, and advisories.

1. Notify authorities when required

• For certain serious or actively exploited vulnerabilities, CRA and related EU rules may require notification to national authorities or CSIRTs.

1. Respect good‑faith researchers

• Policies should make it clear that good‑faith security research is welcomed, as long as it respects legal boundaries and user privacy.

CVD is not just “nice to have” – it is part of demonstrating that you take post‑market cybersecurity seriously.

10. Activity: Draft a Simple CVD Policy Outline

Mentally (or on paper) outline a one‑page CVD policy for a hypothetical mobile app.

Include at least:

1. Scope

• Which domains, apps, and services are in scope?

1. How to report

• Contact details and preferred formats.
• Optional: PGP key for encrypted reports.

1. What you promise

• Acknowledge reports within X days.
• Provide a status update within Y days.
• Not to take legal action against good‑faith researchers following the policy.

1. What you ask from researchers

• Avoid privacy violations and data destruction.
• Avoid service disruption.
• Give you reasonable time to fix before public disclosure.

Think about how this policy helps you comply with CRA expectations on vulnerability handling and how it improves trust with your users.

11. Review Key Terms

Flip the cards (mentally) to review important concepts from this module.

12. Final Check: Applying CRA Principles

One last question to connect everything in this module.