Vulnerability Reports

Once an SBOM is uploaded, Vigiles automatically generates a vulnerability report and redirects to the vulnerability report dashboard page containing the sections below.

Summary section

This section gives an overview of the vulnerabilities that Vigiles has identified affecting the packages in your SBOM, broken down into:

• Unfixed: Count of vulnerabilities that need to be addressed
  • The Kernel is the count of unfixed vulnerabilities from any of the packages identified as the Linux kernel
  • The User space is for all other packages
• Fixed: Count of vulnerabilities that are applicable but already addressed
  • Yocto/Buildroot/OpenWrt/Factory/SPDX/CycloneDX: If a patch is being applied and vulnerability ID is present in the patch file name or header, Vigiles marks the vulnerability as fixed
  • BOM CSV: If the CSV specifies vulnerability IDs that are fixed
• High/Critical CVSS (Unfixed): Count of vulnerabilities with a Common Vulnerability Scoring System (CVSS) score greater than 7. The CVSS score (0 to 10 range) is an industry standard that gives an insight into how easy it is to exploit and how damaging the vulnerability is. These are the vulnerabilities that typically should be addressed first.
• Filtered Vulnerabilities: Count of vulnerabilities that are filtered out based on applied filters

Compliance

This section contains a list of vulnerabilities that are gathered on upload or rescan that fit the CVSS compliance settings. These settings are set in the Compliance Policy on the group sidebar. Clicking on the vulnerability will bring up a vulnerability details modal which will give more details about the vulnerability.

Package section

This section gives a high-level summary of the vulnerabilities in each package broken down into Unfixed, Fixed, Not Affected (vulnerabilities marked to be ignored), and filtered vulnerabilities. Unfixed is also broken down into the CVSS score count for the vulnerabilities. Additionally, license information is provided, for packages that contain it.

By default, only packages with unfixed vulnerabilities are displayed. They are sorted by the number of critical vulnerabilities, followed by high, medium, and low counts. To view all packages, uncheck the “Show Unfixed Only” box.

Clicking on any package applies a package filter to the vulnerability table, only showing vulnerabilities of that package.

Vulnerabilities section

This section provides details about vulnerabilities grouped by the SBOM components' package and version with the following info:

Fixed Version

This section provides, the minimum version of the package that includes a fix for the vulnerability. If this is left blank then either a fix is not yet available or Vigiles does not yet know of a version that can fix the vulnerability.

ID

Corresponds to the vulnerability ID. Clicking on it displays details about the vulnerability along with any Timesys curated information. A section of particular interest might be “Affected Configurations” which shows all the package and version combinations affected by this vulnerability.

Status

Specifies one of states from below types:

• Fixed – The vulnerability has been remediated.
• Resolved with Pedigree - The vulnerability has been remediated, with evidence of the changes provided in the affected component's pedigree, containing verifiable commit history and/or diffs.
• Affected - The vulnerability may be directly or indirectly exploitable.
• In triage - The vulnerability is being investigated.
• False Positive - The vulnerability is not specific to the component or service and was falsely identified or associated.
• Not Affected - The component or service is not affected by the vulnerability. Justification should be specified for all not affected cases.

NVD Status

Similar to the previous information, This corresponds to the package's status as determined by the National Vulnerability Database (NVD):

This information is taken directly from the NVD Vulnerability Status Documentation

• Not Present: The vulnerability is not found within the NVD
• Received: CVE has been recently published to the CVE List and has been received by the NVD.
• Awaiting Analysis: CVE has been marked for Analysis. Normally once in this state the CVE will be analyzed by NVD staff within 24 hours.
• Under Going Analysis: CVE is currently being analyzed by NVD staff, this process results in association of reference link tags, CVSS scores, CWE association, and CPE applicability statements.
• Analyzed: CVE has had analysis completed and all data associations made.
• Modified: CVE has been amended by a source (CVE Primary CNA or another CNA). Analysis data supplied by the NVD may be no longer be accurate due to these changes.
• Deferred: When a CVE is given this status the NVD does not plan analyze or re-analyze this CVE due to resource or other concerns.
• Rejected: CVE has been marked as "REJECT" in the CVE List. These CVEs are stored in the NVD, but do not show up in search results.

CVSSv3

As noted in the summary section, the CVSS score determines the severity of the vulnerability. By default, CVSSv3 scores are displayed but will fall back to CVSSv2 for older vulnerabilities without a CVSSv3 score. "None" is displayed when a CVSS score is not yet assigned (typically when NIST NVD has yet to analyze the vulnerability).

The CVSS3 score and subsequent ranking are as follows:

• Critical 9.0 - 10.0
• High 7.0 - 8.9
• Medium 4.0 - 6.9
• Low 0.0 - 3.9
• None No CVSSv3 Score was found

Attack Vector

This determines the context in which the vulnerability can be exploited:

• Network: “Remotely exploitable” and can be thought of as an attack at the protocol level from one or more network hops away

• Adjacent: Attacks must be launched from the same shared physical (e.g., Bluetooth) or logical (e.g., local IP subnet) network, or from within a secure or otherwise limited administrative domain (e.g., VPN)

• Local: The vulnerable component is not bound to the network stack and the attacker's path is via read/write/execute capabilities. (e.g.: keyboard, console, valid ssh credentials, user interaction via social engineering techniques, etc.)

• Physical: The attack requires the attacker to physically touch or manipulate the vulnerable component (e.g., via inserting a USB device).

References, patches, and config options

Clicking anywhere on the vulnerability row provides more information including links to patches or mitigation along with links to possible exploits. It would be prudent to prioritize fixing high CVSS score vulnerabilities with public exploits first.

For packages like the Linux Kernel and U-Boot, Vigiles provides links to mainline commits that address the vulnerability along with information on which config options result in the vulnerability.

Custom Score/Notes/Status

Refer to the Triaging Vulnerabilities section for details on these user entered fields.

EPSS

The Exploit Prediction Scoring System (EPSS) value can be found in the Vulnernability table section. The EPSS percentile can be seen on hover.

Filtered Vulnerabilities

This section provides insight into vulnerabilities that were filtered out after applying filters. The "Reason for filtering" column shows filters that apply to the vulnerability.

Filters

Use the various filter options to quickly drill down to vulnerabilities that matter.

• Package: If only particular packages are of importance, use the dropdown to select them to see vulnerabilities for those packages only.
• Status: The typical use case is to filter vulnerabilities by status.
• NVD Status: Similar to "Status" but for status outlined by NVD.
• References: Used to filter vulnerabilities having patches, migrations, or exploits.
• Attack Vectors: Filter based on the context from which the vulnerability can be exploited. Typical use cases:
  • For remote exploits, select “Network”
  • For air-gapped devices with no user input, select “Physical”
• Minimum CVSS: Filter based on severity threshold. The typical use case is to set it to "High" to show only High and Critical vulnerabilities.
• Minimum Custom Score: Filter based on a threshold for the user-entered scores and priority.
• Affected Platforms: Used to filter vulnerabilities affecting a particular OS and architecture platform.
• Kernel/U-Boot configuration: This is an extremely handy feature if the Linux kernel and U-Boot packages are in your SBOM. Uploading the full configuration for these packages results in reporting vulnerabilities based on what is being used (i.e. don't show vulnerabilities for drivers/sub-systems not being compiled).

For Yocto, Buildroot, and OpenWrt users, the kernel/u-boot config is automatically uploaded by default along with the SBOM from the command line. All other users need to upload the kernel config manually using the web interface. Click on the Kernel/U-boot config filter and upload the full config file (not defconfig) from your computer

Note: The configs are stored at an SBOM level, so if a new SBOM is uploaded then the config will need to be re-uploaded for it.

Triaging vulnerabilities

Once the summary is reviewed, the next step is to prioritize and investigate vulnerabilities. Vigiles automatically filters vulnerabilities that do not apply to the product based on features or portions of code that are not being used (e.g.: Linux kernel or u-boot config filtering), platform applicability (e.g.: windows only) which, in combination with Timesys curated vulnerability data, reduces the triage burden on the end user and keeps false positives to a minimum.

Notes

The notes field is intended for saving user triage information. Click on the vulnerability row you wish to, enter a note into, add your note in the text field, and click "Save."

More details about how this feature behaves:

• The note is unique per vulnerability per package and version
• Notes are stored at a Sbom Chain level (i.e. a note added for a vulnerability affecting a package and version shows up on all reports across all linked SBOMs under that group)
• Notes do not get lost on a rescan or the upload of a new SBOM
• Notes can be imported into another sbom chain
• The author of the note will have their user info and a timestamp saved to the note to allow for an audit of notes at any time

Status

When investigating vulnerabilities, it might be that the vulnerability is not applicable (fixed or false positive) or is not important to your security. The status feature allows you to mark a specific vulnerability or all vulnerabilities for a package to be fixed, not affected, or unfixed. Managing status allows a user to focus on Unfixed type vulnerabilities that need to be addressed.

To update the status:

• In the vulnerability row, click on the dropdown
• Click on the "Update Status" button
• Go to the Vulnerability status wizard
• Choose the appropriate Status state and set it as "Vulnerability Status."
• Update "Status Justification"
• Set "Justification Details"
• Selecting the "Apply status to the package" option will set the status to all vulnerabilities for that package and version instead

More details about how this feature's behavior below:

• Statuses are stored at a Sbom Chain level (i.e. a vulnerability not affected for a package and version shows up as not affected on all reports across all linked SBOMs)
• Updated status does not get lost on a rescan or the upload of a new SBOM
• Status can be imported into another sbom chain
• The user who updates the status will have their user info and a timestamp saved to the status entry to allow for an audit at any time

Custom scores

This will allow you to assign a custom severity or priority score to a vulnerability based on your organization's internal metrics. In the vulnerability row under the "Custom Score" column, you may assign a value (0.0 to 10.0) and click the checkmark to save. The vulnerability table can be sorted and filtered based on these custom scores, which allows you to easily prioritize vulnerabilities closer to your organization's metrics.

More details about how this feature behaves is below:

• The custom score is unique per vulnerability per package and version
• Custom scores are stored at a Sbom Chain level (i.e. A custom score added for a vulnerability affecting a package and version shows up on all reports across all linked SBOMs under that group)
• Custom scores are not lost on a rescan or the upload of a new SBOM
• Custom scores can be imported into another sbom chain

Feedback / Reporting errors

If there are vulnerabilities in the report that are false positives, not applicable, or are not being reported, please click on the “Send Feedback” button on the vulnerability dashboard sidebar and notify us. The team responsible will typically get back within 72 hours with a response or a fix. It is recommended to read through the FAQ before reporting an error.

Remediating vulnerabilities

After triage, the next step is to remediate or mitigate your vulnerabilities. Timesys offers a service that will maintain and remediate vulnerabilities, in your build system, for you, called BSP Maintenance. However, Vigiles will provide you with various suggestions on how to remediate these vulnerabilities on your end, examples below:

Package upgrade

The ideal option is to upgrade to the latest version of the package because this typically resolves most of the vulnerabilities. Upgrade the package version to the value in the vulnerability's “Fixed Version” column to determine if upgrading the package might resolve the vulnerability. For Linux kernel vulnerabilities, Vigiles tracks if the fix has been backported to the LTS versions of the kernel, in order to avoid any major kernel update.

Backport patch

Sometimes upgrading a package might not be an option due to various reasons like API changes requiring custom application changes, package license changes, potential regression issues, and/or needing an emergency patch for severe vulnerabilities. In such cases, refer to the References or Patch links provided by Vigiles and try to apply or backport a patch.

Mitigate

In some cases disabling a config option for an unused feature might mitigate the vulnerability. Use the References or Config options provided by Vigiles to see if this is possible.

For example: Consider "CVE-2018-12233":https://{your vigiles url}/cves/CVE-2018-12233/. As per the ‘Config Options Affected' list in the ‘Curated Info' section, CONFIG_JFS_FS results in the vulnerability. So if journaled file system support is not required, then disabling this config option will result in mitigating the vulnerability.

SBOM Vulnerability Monitoring

After the initial SBOM upload and vulnerability report generation, there are two ways to get alerted of new vulnerabilities:

• On-demand scans
• Email notifications via automatic scheduled scans

If a component is upgraded or patched, a new SBOM needs to be uploaded to inform Vigiles about the change. If not, it will continue to alert about vulnerabilities corresponding to the components in the old SBOM. There are 3 ways to inform Vigiles of changes to the SBOM:

1. Running a Vigiles check from the command line automatically results in uploading the latest version of the SBOM and generating a new report. Older SBOMs are still available for viewing/generating reports online.
2. Use the "Upload SBOM" feature on the web to upload the latest SBOM
3. Use the "Edit SBOM" feature on the vulnerability Dashboard to specify the changes

On-demand Scans

• Rescan from build system Plugin: Running a Vigiles check from the command line for Yocto, Buildroot, OpenWrt, or Factory automatically generates the new report with a link that will show the latest report with changes highlighted.

• Rescan from the web: On the Group dashboard page, vulnerability report page or SBOM Dashboard, clicking on the "Rescan" button will generate a new report which will highlight new vulnerabilities and any other changes since the last scan.

Automated Scans

Subscribing to Automated Scans (daily/weekly/monthly) will result in Vigiles performing automatic vulnerability scans based on your chosen frequency. After each scan, Vigiles will send an email with a summary of new vulnerabilities and links to vulnerability report.

• To Subscribe: On the Vigiles Groups page under the "Notifications" column, select the desired frequency of scan.
• To Unsubscribe: Change the "Notifications" value to “None”.

Vigiles offers the ability to link SBOMs (similar to automatic SBOM revision control) which is enabled by default when a new Product is created. If SBOM linking is enabled, then the notification is for the product (i.e. when new SBOMs are uploaded to that product, notifications are sent based on the latest SBOM). If linking is disabled then the notification is at the SBOM level and needs to be subscribed on every new SBOM upload. A better explanation of linking behavior is found further down

To unsubscribe from all security and update emails, visit your Vigiles Profile page, and toggle the "Email Notifications" field off.

Vulnerability Report Compliance

Compliance settings can be configured by accessing the "Compliance" sidebar item on the group and folder pages. When saving compliance information you can choose to apply the settings to just the base group or all subgroups and folders within the group.

Changes to Compliance settings will only take effect on newly generated vulnerability reports.

When enabled, a Compliance section will be added to your vulnerability reports. Additionally, you may choose to enable email notifications to alert you to compliance violations when a new report is generated, or the automatic creation of a Jira issue if a compliance policy violation is found.

CVSS Policy

On the compliance settings page, you can set a policy for vulnerabilities with a CVSS greater than or equal to your defined value. You may also choose to compare to previous reports which will highlight any new vulnerabilities fitting the compliance policy criteria in the report.

License Policy

A policy to alert if a specified license is found connected to a package in your SBOM. These alerts can be set for two matching modes:

• Contains: this will be triggered if any occurrence (i.e. A package with multiple licenses) is found in the licenses for a package.
• Exact: will only match the license if the exact license name is found.

For example, the licenses for a package are "BSD & GPLv2+ & LGPLv2+ & PD" and a compliance policy for "GPL" is set to "contains" the policy will issue an alert. If the policy is set to exact, it will not be issued. However, if an exact alert is set for "GPLv2+", the policy will issue an alert.

This can also be used to highlight if a new or existing package is found with a specified license, as compared to previous reports.

New Component Policy

You can also create a compliance policy to issue alerts if any new component has been added to an SBOM.

Exporting Reports

Vigiles provides multiple options for exporting vulnerability reports, allowing integration with compliance workflows and security monitoring tools. Reports can be exported in the following formats:

• PDF (Summary and Full Report)
• CSV
• XLSX
• VEX (Vulnerability Exploitability eXchange)

To export a report:

1. Navigate to the Export Report option in the sidebar menu.
2. Select your desired export format from the list.

PDF Reports

Vigiles supports exporting a summary or full vulnerability report PDF document.

PDF - Summary

• A summary chart of the total number of vulnerabilities.
• A list of packages, each with its corresponding count of vulnerabilities.

PDF - Full Report

• A detailed list of all vulnerabilities.
• Grouping by package name.
• Organization by vulnerability status: Fixed, Unfixed, Not Affected, and Filtered.
• Detailed information for each vulnerability, including:
  • Vulnerability ID
  • Suggested remediation steps
  • CVSS v3 score
  • Attack Vector

CSV and XLSX Reports

These tabular formats include detailed rows for each vulnerability, enabling easy sorting, filtering, and integration with external data analysis tools or spreadsheets.

VEX Export Support

Vigiles supports exporting vulnerability data in VEX (Vulnerability Exploitability eXchange) format based on CycloneDX 1.6 specifications. VEX BOMs can bee downloaded as a standalone document or embedded within an SBOM.

VEX BOM

• Exports only the VEX data, providing exploitability status for vulnerabilities.

SBOM With Embedded VEX

• Exports a bundled document that includes both:
  • The full Software Bill of Materials (SBOM)
  • The corresponding VEX entries for identified vulnerabilities.

These exports can be integrated into software supply chain workflows, enabling precise vulnerability triage and streamlined compliance auditing.

Additional Information

Why is my package not being tracked?

Vigiles uses the NVD CPE dictionary for tracking vulnerabilities against package names. If a * is indicated against a package, it means that the package does not exist in the NVD CPE dictionary.

Here are some possible reasons why your package might not be tracked:

1. The package name does not match the name specified in the NVD CPE dictionary in which case the user is supposed to review the packages with * and fix up using the CVE_PRODUCT variable to match it.
2. The package has no vulnerabilities reported and the maintainer of the package has not requested a CPE entry. In this case a user can submit a CPE name request to NVD, the CPE name will match the package name in which case Vigiles will report the vulnerability correctly.
3. The package is either a proprietary package or a build system artifact which can be safely ignored.

To obtain the correct cve-product name under which a vulnerability is reported, use the NIST NVD CPE product dictionary which specifies the CPE

Yocto

Use the variable "CVE_PRODUCT" to set the CVE product to something other than the recipe name.

To set the variable follow the format below:

CVE_PRODUCT = ""

excerpt from the wpa-supplicant recipe in poky to illustrate its use:

CVE_PRODUCT = "wpa_supplicant"

Buildroot

Currently, Buildroot has not added a standard variable to set a CVE product. There is an open issue for this and vigiles-buildroot will be updated upon the release of it.

vigiles-buildroot supports the use of the variable "CVE_PRODUCT" to set the CVE product to something other than the recipe name.

To set the variable follow the format below:

CVE_PRODUCT = ""