SBOM Dashboard

After uploading an SBOM, one can view the SBOM Dashboard by clicking on the SBOM name in the Group Dashboard, under the "Name" column. From there, the SBOM can be scanned for vulnerabilities by clicking the "Scan" button along the header section, and once a vulnerability report is generated, vulnerability info will also appear in the SBOM Dashboard.

SBOM Dashboard Header

At the top of the SBOM Dashboard is a header with an information section on the left and action section on the right. In the information one can find:

Name/Description: Edit these by clicking on them.
SBOM Uploaded: Date/time in UTC.
SBOM Token: Vigiles's unique identifier for this SBOM, which can be provided to the Vigiles CLI to perform API actions.
Version: If SBOM Linking is enabled, this shows the current version of the SBOM and has a link to the CVE Report History page.

The button group on the right side of the header contains the following buttons:

Notifications: In this dropdown, you can set a frequency for Vigiles to automatically generate vulnerability scans (defaulting to "None" for only manual scanning). If you change the frequency value here, the date of the next automatic scan is based on the date of your change (e.g. if you change the notifications to "Weekly", in one week the next automatic scan will occur).
- Note - This has the same functionality as the "Notifications" setting on the group dashboard.
Compare: This links to the "Compare SBOMs" page, where you can compare this SBOM and its reports to another.
Download: Here you can download the SBOM, either in its original format or converted to a new format.
Edit: This links to the SBOM Editor, giving you a way to modify the components of the current SBOM. Not available for SPDX SBOMs.
Latest Report: This links to the latest Vulnerability Report for this SBOM.
(Re)scan SBOM: This will trigger a new scan and vulnerability report for the SBOM. Unlike the Group Dashboard, this button will not redirect you to the new vulnerability report; click the "Latest Report" button to navigate there.

NTIA Compliance

The National Telecommunications and Information Administration (NTIA) sets a standard for compliance regarding the minimum elements required in an SBOM. Under the header, the SBOM Dashboard has a field showing whether your SBOM is NTIA compliant, and clicking the field will provide more details on why it may not meet compliance. Currently, Vigiles only supports NTIA checking on SPDX SBOMs, so you can use the Download button to convert the SBOM to SPDX and check its compliance.

Unfixed Vulnerabilities and Vulnerability Graph

Once the SBOM has been scanned, a label below the header will show a count of its unfixed vulnerabilities. Below this label is a graphic displaying the proportion of vulnerabilities fixed by the latest vulnerability report compared to the one before it, as well as a bar displaying a breakdown of the CVSSv3 score among unfixed vulnerabilities (divided into Critical, High, Medium, Low, and None).

Components Table

The SBOM Components table provides an in-depth view of your SBOM's packages, listing for each its version, license, and vulnerability count. Click a package to expand into the following information:

CPE: The package's Common Platform Enumeration string
PURL: The package's Package URL
CVE Product: The product as associated with the Common Vulnerabilities and Exposures system
CVE Version: The version as associated with the Common Vulnerabilities and Exposures System
Checksum: A unique string of characters generated against the contents of the package, as well as the encoding used to generate it
Download Location: The source of the package
Package Supplier: The supplier or vendor of the package
Homepage: Where more info about the package can be located
Recipe: A collection of non-executable metadata used by BitBake to set variables and define additional build-time tasks
Summary: A short string summary detailing information about the package
Component Type: Indicates how the package is used. It can be build, runtime or component. Packages with only build or runtime or both are dependency-only packages.
Patches: Any backport patches that have been applied to remediate a vulnerability
Dependencies: A dropdown containing all the dependencies for the package. Click a dependency to view it in the Components table, if it exists. Specific categories of dependency include:
- Build Dependencies: Packages required during a build
- Runtime Dependencies: Packages required during runtime
Component Life Cycle: This section provides details about the package lifecycle:
- Release date: The release date for a specific version of a package
- End of life: The expiration date for a specific version of a package
- Level of support: The support status of a package indicates whether it receives updates or not. It can have one of the following keys or values:
  - not_available - Not available
  - actively_maintained - Actively maintained
  - no_longer_maintained - No longer maintained
  - abandoned - Abandoned

SBOM Info

Unlike the previous sections regarding the contents of the SBOM, this section contains details on the SBOM file itself. For SBOMS generated through build systems such as Yocto, OpenWrt, or Buildroot, this section will simply list that format as well as the date and time the SBOM was uploaded, with further details in the Build System Info section below. For SPDX and CycloneDX SBOMs, this section will also contain the encoding format (e.g. JSON, XML, CSV, etc.), the spec version (e.g. SPDX 2.2), and some further details:

SPDX: The "Creation Information" label will contain any info from the "Creators" field of the SPDX specification, such as the person, organization, and/or tool that generated the SBOM.
CycloneDX: The "Tool(s) used" label will describe tools as in the "metadata" field of the CycloneDX specification. This includes their name, author(s), publisher, etc.

Build System Info

For SBOMs generated from Yocto, OpenWrt or Buildroot, this section will display the SBOM's generating machine, distro, and (for Yocto) image. If the SBOM was generated by Timesys Factory, then the board and Factory version will be displayed. This section does not appear for any SBOM not generated by one of the above.

License Policy Violations and New Components

If you have either of these Compliance Settings enabled, then the matching alerts will be shown here. See the linked page for more details on these sections.

Component Life Cycle

In contrast to the details of the component life cycle found in the components table section, this section outlines the fields used to store this information in various SBOM formats.

Yocto, OpenWrt or Buildroot SBOM
- The details for the packages are stored in the package information under the following attributes:
  - release_date
  - end_of_life
  - level_of_support
- For additional packages, the details are stored in the package+version attribute within the additional_packages_info:

e.q.:

"packages": {
    "base-files": {
        "cve_product": "base-files",
        "cve_version": "reboot-29054-g7a303d861a",
        "license": "GPL-2.0",
        "name": "base-files",
        "version": "reboot-29054-g7a303d861a",
        "release_date": "2025-09-05T00:00:00Z",
        "end_of_life": "2025-09-27T00:00:00Z",
        "level_of_support": "Actively maintained"
    }
},
"additional_packages": {
    "LZO": [
        "0.0.1"
    ]
},
"additional_packages_info": {
    "LZO0.0.1": {
        "release_date": "2025-09-23T10:37:09Z",
        "end_of_life": "2025-09-23T10:37:09Z",
        "level_of_support": "No longer maintained"
    }
}

CycloneDX SBOM: Values are stored within component properties in the following attributes:
- release_date
- end_of_life
- level_of_support

e.q.:

"components": [
    {
        "bom-ref": "pkg-base-files-reboot-29054-g7a303d861a",
        "type": "library",
        "name": "base-files",
        "version": "reboot-29054-g7a303d861a",
        "cpe": "cpe:2.3:a:*:base-files:reboot-29054-g7a303d861a:*:*:*:*:*:*:*",
        "properties": [
            {
                "name": "release_date",
                "value": "2025-09-19T16:30:00Z"
            },
            {
                "name": "end_of_life",
                "value": "2025-09-23T16:34:53Z"
            },
            {
                "name": "level_of_support",
                "value": "Actively maintained"
            }
        ]
    }
]

SPDX SBOM: In SDPX SBOM below fields are used to store values:
- SPDX 2.3
  - The release_date is stored in the predefined SPDX field called ReleaseDate.
  - The end_of_life is stored in the predefined SPDX field called ValidUntilDate.
  - The level_of_support is stored under ExternalRef with the attribute supportLevel.
- SPDX 2.2: All values are stored in ExternalRef with the following attributes:
  - release_date
  - end_of_life
  - supportLevel

e.q:

SPDX 2.3:

## Package Information
PackageName: base-files
SPDXID: SPDXRef-base-files-reboot-29054-g7a303d861a
PackageVersion: reboot-29054-g7a303d861a
ReleaseDate: 2025-09-19T16:30:00Z
ValidUntilDate: 2025-09-23T16:34:53Z
ExternalRef: OTHER supportLevel actively_maintained

SPDX 2.2:

## Package Information
PackageName: base-files
SPDXID: SPDXRef-base-files-reboot-29054-g7a303d861a
PackageVersion: reboot-29054-g7a303d861a
## License information from files
ExternalRef: OTHER release_date 2025-09-19T16:30:00Z
ExternalRef: OTHER end_of_life 2025-09-23T16:34:53Z
ExternalRef: OTHER supportLevel actively_maintained

Note:

At present, CSV and factory SBOMs do not support this information.

Release date and end of life date should be formatted as ISO strings in the format %Y-%m-%dT%H:%M:%SZ.

Use camel case attributes name in the SPDX 2.3 JSON format for release date and end of life, e.g., ReleaseDate should be formatted as releaseDate.

For other SBOMs, use the support level value from here. If it's an SPDX SBOM, map it to the key instead of the value, as external references cannot have spaces in the value.