Evaluate open source components

An open source package comes with no supplier to ask and no contract behind it. What you can check is the project: whether anyone still maintains it, whether it follows common security practices, and whether the version you run was built from its public source. The OSS Insights tab on a component's page collects this from deps.dev, Google's open source insights service.

Use it when a decision depends on the project rather than on one vulnerability: a vulnerable dependency has no fix yet and you must choose between waiting and replacing it, a policy flags a component, or you review the dependencies a critical application relies on.

Open OSS Insights

Read the project's activity

Source Repository shows where the code lives and how active the project is: how many versions have been published, how many issues are open, and the repository's stars and forks. The rows link to the repository, or to the issue tracker for open issues.

Project Links lists the package's page on its registry (Origin), the homepage, the issue tracker, the source repository, and the provenance Attestation if the registry has one.

These numbers describe popularity and activity, not quality. A popular project can stop being maintained, and a small one can be well run. Read them together with the Scorecard's Maintained check below.

Check the OpenSSF Scorecard

The OpenSSF Scorecard checks a repository for security practices such as code review, branch protection, pinned dependencies, and signed releases. Each check scores 0 to 10, and the Scorecard combines them into one score, shown at the top with the commit it was computed for and the date.

SBOM Observer sorts the checks by risk level, from Critical to Low, and puts the lowest scores first within each level, so a low score on a high-risk check is near the top. A check that could not be evaluated shows ? and is listed last. Select a check to see the reason for its score and a link to the check's documentation.

For a decision about whether to keep relying on a project, start with:

• Maintained: whether the project is at least 90 days old and still has recent activity.
• Code-Review: whether changes are reviewed before they are merged.
• Dangerous-Workflow and Token-Permissions: whether its GitHub Actions workflows avoid dangerous patterns and run with read-only tokens.
• Vulnerabilities: whether the project has unfixed vulnerabilities.

Check provenance

For an npm package published with provenance, the Provenance Attestation section shows where this exact version was built: the SLSA Version, the source Repository with the commit, the Build Config and Workflow run that produced it, and the Log Date and Log Index of its entry in the Sigstore transparency log.

Compare the repository with the one under Source Repository. They should be the same project. Follow Workflow run to see the build itself, and Log Index to open the transparency log entry. SBOM Observer imports the provenance automatically when you upload an SBOM; see Attestations.

Troubleshooting

Related

• Concept: Attestations
• How-to: Analyze vulnerability impact
• Reference: Components