Skip to content

Vulnerability Management

Introduction

Vulnerability management is the ongoing work of identifying security issues in the software included in a product, determining whether they affect the deployed system, deciding what action is appropriate, and tracking the result over time.

A common industry method for tracking publicly known software vulnerabilities is the CVE (Common Vulnerabilities and Exposures) system. A CVE identifier (CVE ID) is assigned by a CVE Numbering Authority (CNA) to identify a publicly disclosed vulnerability within the CNA’s defined scope. The same vulnerability can affect multiple versions of a component and sometimes multiple products that share the same affected code. Separate vulnerabilities, including similar bugs in different codebases, are typically tracked with separate CVE IDs.

For embedded products, vulnerability management is not limited to checking whether a package name appears in a CVE feed. A CVE may refer to code that is present in the software baseline but not included in the deployed software, not enabled, not used by the product, or not reachable in the deployed system. Each CVE must be assessed against the actual software version, software configuration, product usage, and access path.

Common assessment questions include:

  • Software version and patch level: Does the deployed software include a version affected by the CVE?
  • Software configuration: Is the affected code included and enabled in a way that applies to the product? For example, a Linux kernel CVE may affect a driver that is not enabled for the product.
  • Product usage: Is the affected functionality actually used by the product?
  • Access path: Can the attacker reach the vulnerable code path in the deployed system? For example, a vulnerability may require network access, local user access, physical access, or a specific hardware interface.

A CVE match should therefore be treated as an input to assessment, not as a final determination that the product is vulnerable.

What vulnerability management looks like in practice

Vulnerability management typically includes four connected activities:

Software inventory

Start from the exact release and image that were used to build the product, then identify the software that is actually shipped. This is where SBOMs and build metadata become useful.

Monitoring

Monitor the sources relevant to that software baseline. This may include upstream Linux and package maintainers, build metadata, and silicon-vendor release updates and security advisories.

Assessment

Determine whether a published issue is relevant to the deployed product. Relevance depends on the affected component version, enabled features, reachable attack surface, privilege boundaries, and whether the vulnerable code path is present in the shipped image.

Response

When an issue is relevant, the response may involve patching, rebasing to a newer maintained release, backporting a fix, applying a mitigation, or documenting why a specific issue is not applicable to the deployed product.

How Variscite helps

Variscite provides Yocto reference releases and documentation that can help customers build their own vulnerability-management workflow on top of a supported software baseline.

For Yocto releases, this includes:

  • An SBOM documenting the software components included in the image
  • The output of Yocto cve-check at the time of the release
  • Instructions for regenerating the SBOM and CVE-report outputs
  • Release documentation that identifies the software baseline in use
  • Release notes that call out critical known vulnerabilities when Variscite becomes aware of them

Implementation details vary by SoM and release.

Next steps

For the exact release-specific workflow, refer to the documentation for the release in use, including the release notes and the guides for generating SBOMs and CVE reports where available.