loading
Loading content
loading
Scanners
Scan software bills of materials for known-vulnerable dependencies.
overview
Place bomber after an SBOM generator such as syft or trivy. It answers the supply-chain question: which declared components already carry known advisories.
Reach for it when the bill of materials exists and you need OSV or OSS Index matches before release. It does not invent the SBOM, and it does not probe a running app.
Feed sbom-file or sbom-folder, choose --provider (osv default, or ossindex with --username and --token), and set --output to json, xml, or stdout. Results land as a file and folder for triage.
use cases
Scan a project's SBOM so every shipped component is checked against an advisory database, catching vulnerable libraries before they reach production.
Point bomber at a folder of SBOMs to check a fleet of services or images at once and produce a single set of supply-chain findings.
Emit JSON and route the findings into a workflow step that fails when a high-severity component appears, keeping known-vulnerable dependencies out of a release.
Run against OSV with no credentials for a quick pass, or supply OSS Index credentials with --username and --token when you want that provider's coverage and detail.
reference
| Name | Type | Flag | Description |
|---|---|---|---|
| sbom-file | FILE | · | A single SBOM file to scan. |
| sbom-folder | FOLDER | · | A folder of SBOMs to scan in one run. |
| provider | STRING | --provider | Vulnerability provider: ossindex or osv (default osv). |
| output | STRING | --output | Output format: json, xml, or stdout (default stdout). |
| token | STRING | --token | API token for the chosen provider. |
| username | STRING | --username | Username for the chosen provider. |
Showing key inputs. bomber exposes 7 inputs in total.
| Name | Type | Flag | Description |
|---|---|---|---|
| sbom-file | FILE | · | Single SBOM file. |
| sbom-folder | FOLDER | · | Scan a folder of SBOMs. |
| provider | STRING | --provider | The vulnerability provider (ossindex, osv) (default "osv"). |
| output | STRING | --output | How bomber should output findings (json, xml, stdout) (default "stdout"). |
| token | STRING | --token | The API token for the provider being used. |
| username | STRING | --username | The user name for the provider being used. |
| debug | BOOLEAN | --debug | Displays debug level log messages. |
example
# scan a CycloneDX SBOM against OSV and emit JSON findingsbomber scan --provider osv --output json app.cyclonedx.jsonLoaded provider: osv Files: 1Packages: 214Vulnerabilities: 3 SEVERITY PACKAGE VULNERABILITYCRITICAL pkg:npm/lodash@4.17.15 CVE-2021-23337HIGH pkg:pypi/pyyaml@5.3.1 CVE-2020-14343MODERATE pkg:npm/minimist@1.2.5 CVE-2021-44906guidance
Use bomber when you already have an SBOM and need known-vulnerable components listed. Generate the SBOM first. For scanning container images or filesystems directly, use trivy instead.
Scans images, filesystems, and SBOMs broadly. bomber stays focused on SBOM-to-advisory checks.
Static analysis of Python source. bomber checks declared dependencies rather than your code.
Pattern-based static analysis of source. bomber answers the dependency advisory question instead.
faq
related
Reflection triage for parameter URLs during recon.
CMS detection and version fingerprinting.
OWASP Joomla vulnerability scanner for CMS flaws and misconfigurations.
Bundled web server checks for dangerous files and outdated software.
Bypass 403/40X restrictions through smart request manipulation.
YAML template scanner for live hosts; scope runs with tags and severity.
An SBOM feeds bomber, which checks each component against a vulnerability provider and writes the vulnerable dependencies as a queryable output.
Facts on this page come from the live Trickest tool library.