Skip to content

v1.5.0 — Exploitability data reaches the dashboard

Choose a tag to compare

@lab700xdev lab700xdev released this 07 Sep 14:33
· 9 commits to main since this release

What's new

The dashboard can now tell you whether a finding is exploitable, not just that it exists.

aisbom scan --vex writes VEX documents stating, per finding, whether each scanned artifact is actually affected. It landed in v1.4.0 without a mention in those release notes, so this is the first time it appears in a changelog.

Those documents stayed on the runner. The Action uploaded only the SBOM, so a connected repo's inventory could show what the repo contained and never whether any of it was actually exploitable. That is the question the EU Cyber Resilience Act and FDA §524B ask about most directly.

Setting the Action's token input now also runs the scan with --vex, and the resulting OpenVEX and CycloneDX VEX documents are uploaded alongside the SBOM in the same request.

- uses: Lab700xOrg/aisbom@v1
  with:
    directory: models/
    token: ${{ secrets.AISBOM_TOKEN }}   # now also uploads VEX
  • Nothing to change in your workflow. If you already set token, the next run carries exploitability data.
  • Nothing changes if you don't use the dashboard. No token means no --vex, no VEX files written into your workspace, and no request. The scan runs exactly as it did in v1.4.0.
  • The CI log says what was sent. The existing upload log group now reports vex-documents=N alongside the trigger and run id.

The VEX documents are derived entirely from findings already described in the SBOM you were uploading anyway. They add no new information about your files. As always, the model files themselves never leave the runner. The README privacy section describes the payload in full.

Fixed: repos with CRITICAL findings were missing from the dashboard

If you use the token input with the default fail-on-risk: true, and a scan found a CRITICAL artifact, that scan never reached your dashboard.

aisbom scan exits 2 on a CRITICAL finding but still writes its SBOM. The Action honoured fail-on-risk before running the upload, so the job stopped and uploaded nothing. The inventory was quietly omitting the repos that most needed to be in it, and it has behaved this way since the dashboard upload shipped.

The upload now runs before the risk gate. Two consequences worth knowing:

  • Repos you thought were clean may not be. A repo whose scans always failed on CRITICAL will now appear in your inventory, possibly for the first time, showing findings that were always there.
  • Exit codes are unchanged for every case that could previously occur. Where a CRITICAL scan also has a failed upload, the job exits 2 rather than 3, so your required check reports the dangerous model rather than the plumbing.

If you do not set token, this does not affect you.

Also in this release

  • A corrupt VEX file no longer costs you the upload. An unreadable or non-object sibling document is skipped with a log line. The SBOM still reaches your inventory, because that is the part you actually need there.
  • An unparseable SBOM is posted as-is rather than wrapped, so the server returns its own specific rejection reason instead of a confusing one.

What's not changing

Scanner behaviour, detection coverage, output formats and the meaning of each exit code are identical to v1.4.0. Sharing stays opt-in and off by default (share: false); --vex never triggers a share upload. aisbom scan --vex on the command line behaves exactly as before. Model weights and file contents have never left your machine and still don't.