How to Scan a Local SBOM with CodeRiskTools Scanner

A software bill of materials (SBOM) gives a vulnerability workflow a concrete dependency inventory to inspect. CodeRiskTools Scanner 3.1.1 adds a local vuln scan --sbom FILE path for CycloneDX, SPDX, and Syft JSON documents. This is useful when the repository is not the right input boundary—for example, when you already have a container, VM, or package inventory—but the result still needs careful interpretation.

This guide uses the public CodeRiskTools Scanner 3.1.1 release and its versioned README as the source of documented behavior. The release also contains a reproducible local smoke claim against the signed starter database. CodeRiskTools did not scan your environment, validate your SBOM, or perform a customer security audit here. Treat the commands below as a local workflow, not a security guarantee.

What the SBOM mode changes

Repository scanning and SBOM scanning answer different questions. A repository scan reads a bounded local tree and can inspect files, diffs, or history. SBOM mode starts from package records already represented in a local JSON document. It does not magically reconstruct omitted packages, validate the build that produced the SBOM, or prove that a deployed image matches the file you supplied.

In the 3.1.1 documentation, exactly one of --root DIR or --sbom FILE is required for vulnerability scanning. The supported local SBOM formats are CycloneDX JSON, SPDX JSON, and Syft JSON. The database is a separate local SQLite input, either selected explicitly with --database or bootstrapped through the documented default path.

Before you run the scan

• Keep the SBOM in a controlled workspace and record its SHA-256 before review.
• Record which build, image digest, commit, or release produced the SBOM.
• Confirm the format is CycloneDX, SPDX, or Syft JSON rather than an HTML export or an unverified screenshot.
• Choose the database deliberately. A missing or stale database is a workflow problem, not a clean result.
• Keep the output local and redact secrets or private package paths before sharing evidence.

Install the released package

The versioned README documents Python 3.10–3.13 and a virtual-environment installation. A clean local setup keeps the scanner and its dependencies separate from the target project:

python -m venv .venv
. .venv/bin/activate
python -m pip install --no-deps coderisktools_scanner-3.1.1-py3-none-any.whl
secret-scanner --version

For a release review, pin the exact wheel or source archive from the GitHub release and compare its published SHA-256 digest before installing. The release page lists both the wheel and the source archive. Do not substitute an unverified artifact simply because it has the same filename.

Run a local SBOM scan

Once the signed starter database is present, the documented shape is:

secret-scanner vuln scan \
  --sbom ./bom.json \
  --database ~/.local/share/coderisktools/vuln-db/osv-partial.sqlite \
  --format json \
  --output ./reports/sbom-vulnerability-report.json

The command returns findings in the selected output format. The README defines exit code 0 as clean or warning-only, 1 as a finding at the configured failure threshold, and 3 as malformed, unsafe, oversized, or operationally rejected input. A non-zero finding exit is therefore not the same as a tool crash; preserve the report and inspect the reason.

Verify database identity and coverage

Version 3.1.1 describes the starter snapshot as explicitly partial and containing 243,381 real CVE/OSV records. The release notes report a local positive smoke where pkg:bitnami/abantecart@1.3.1 produced three findings against the active osv-partial-2026-07-23 database. Those are release-level facts, not results from your SBOM.

Before using a result as a gate, record the snapshot identifier, record count, signature verification outcome, database hash, scanner version, SBOM hash, and command-line policy. The documented future update path can support a much larger snapshot; the current starter profile remains partial. No match in a partial snapshot must never be described as proof that a dependency is safe.

Interpret findings without overclaiming

Observation	What it supports	What it does not support
A package and advisory match	Prioritize validation, upgrade, mitigation, or a documented exception.	That the package is exploitable in your deployment.
No match in the starter snapshot	No matching record was observed in that database profile.	That the dependency is safe or free of vulnerabilities.
Exit code 3	The input or operation needs correction or investigation.	A clean scan conclusion.
An SBOM from an earlier build	Evidence about the inventory that produced that file.	Proof about the currently deployed artifact.

Use a five-step review workflow

1. Bind the input. Hash the SBOM and link it to a build, image digest, or commit.
2. Validate the parser boundary. Confirm the document is the intended supported JSON format and that package identities are present.
3. Verify the database. Record signed-manifest identity, profile, completeness, and hash before relying on the result.
4. Reconcile findings. Check package version, advisory aliases, reachable deployment, fixed version, and the owner of the remediation decision.
5. Publish only redacted evidence. Keep private paths, credentials, internal package names, and customer data out of shared reports.

Common failure modes

• Wrong file: an HTML report is passed as JSON. Stop and regenerate the SBOM.
• Stale inventory: the SBOM describes an old image. Rebuild it and bind the new digest.
• Partial coverage presented as complete: retain the partial label in dashboards, reports, and release notes.
• Finding treated as exploitability: validate affected code paths and deployment context separately.
• Clean exit treated as certification: keep scanner output as one evidence source inside a broader review.

FAQ

Can I scan CycloneDX, SPDX, and Syft files?

Yes, the 3.1.1 README documents local JSON support for those three SBOM families. Confirm the exact parser contract and preserve the original input alongside the report.

Does SBOM mode download packages?

The documented SBOM inventory path is local. Vulnerability matching uses the selected local SQLite snapshot; first-use bootstrap is a separate database acquisition step that must be verified.

Does a no-match result mean the image is secure?

No. The starter database is explicitly partial, and a no-match result does not account for omitted inventory, configuration, exploitability, or unknown advisories.

Sources and next step

• CodeRiskTools Scanner 3.1.1 release — version, assets, release notes, and published digests.
• Scanner 3.1.1 README — supported inputs, CLI shape, output formats, and limitations.
• Public Scanner repository — source, tests, and product-boundary documentation.

For a compact review of an AI-generated change, use the free 5-point AI code review checklist. For intent-bound local change review before merge, see the documented scope of the AI Change Firewall. Use the single CodeRiskTools comparison hub when you need scope context; neither product replaces vulnerability triage or human judgment.