Skip to main content

Goal

Turn a scan result into a pass or fail decision based on two rules:
  1. No component may carry a licence that your organisation does not allow.
  2. No component may have a known vulnerability at or above a chosen severity.

When to use it

  • In a pull request job, after the pull request scan.
  • In a release job, before you publish an SBOM.
  • In a scheduled job over a refreshed inventory, to catch vulnerabilities disclosed after release.
scanoss-cli reports what it finds and exits 0 whatever it finds. It does not decide what is allowed. This recipe writes that decision down as a script.

Prerequisites

  • scanoss-cli, jq, and SCANOSS_API_KEY (see Recipes)
  • A scan result in the raw format (the default) that includes the licenses and vulns layers:
    Add deps (--include deps,licenses,vulns) to also check the dependencies declared in your manifest files, not only the components detected in your code.
  • scanoss/unapproved.jq committed to the repository (see Approve components)
Without --include licenses,vulns, the result has no licence or vulnerability data and this check always passes. Always produce the input with both layers.

The script

Save this as ci/scanoss-policy.sh and make it executable.
Run it after the scan:

How the rules read the result

Both rules read fields of the scanoss-cli raw inventory:

Adjust the licence pattern

DENY_LICENSES is a regular expression (jq test). The default ^(AGPL|GPL|SSPL)- matches GPL-2.0-only, GPL-3.0-or-later, AGPL-3.0-only, and SSPL-1.0, but not LGPL-2.1-only. Some examples:
Licence policy is a legal decision. Agree the pattern with whoever owns open source compliance in your organisation, and keep it in the repository next to the script.

Approved exceptions

If your organisation accepts a component on the deny-list for your project, approve it with a bom.identify rule in scanoss.json and run the check with SKIP_IDENTIFIED=true. The component then passes the licence rule, but the vulnerability rule still checks it. See Approve components with scanoss.json.

What the output means

Each licence line names the component and the licences that matched the pattern. Each vulnerability line names the advisory, its severity, and the affected components. To fix a vulnerability, upgrade the component to a version without the advisory, and scan again.

How it fails the pipeline

If the scan before it fails, scanoss-cli exits 1 and the script never runs.

Use it with an SBOM instead

If you start from a CycloneDX file rather than the raw inventory, the same checks read different fields:
SPDX 2.3 has no vulnerability model, so only the licence rule applies to SPDX documents.