Search

Search the docs, blog, and marketplace.

PostBomly CLIBomly Guardby Ahmed ElMallah7 min read

Announcing Bomly

A free, open-source CLI and GitHub Action for dependency diffs, SBOMs, vulnerability and license audits, and explaining why packages are present in your builds.

Modern applications ship with hundreds or thousands of dependencies, but dependency review still often comes down to staring at a lockfile and asking:

  • What changed?
  • Why is this package here?
  • Did this PR introduce new vulnerability or license risk?
  • Is this finding actually relevant to the code we run?
  • Can I get the same answers locally, in CI, and in a pull request?

Bomly is my attempt to make those questions easier to answer with one open-source workflow you can use locally, in CI, and in pull requests.

TL;DR

Bomly helps you:

  • Scan dependency graphs from source projects, Git refs, containers, and existing SBOMs
  • Generate SPDX, CycloneDX, SARIF, Markdown, JSON, and text output
  • Enrich packages with vulnerability, license, lifecycle, package metadata, and scorecard signals
  • Explain why a package is present in your graph
  • Compare dependency changes between Git refs, container images, and SBOMs
  • Gate pull requests with Bomly Guard
  • Expose dependency data to AI agents through MCP

Bomly CLI help output showing scan, diff, explain, MCP, plugin, and version commands

Bomly turns dependency data into a graph you can inspect locally, in CI, or directly inside a pull request.

Try it in 60 seconds

go install github.com/bomly-dev/bomly-cli/cmd/bomly@latest
bomly scan --enrich --audit

Or install with Homebrew, WinGet, Scoop, Linux packages, or the install script from the installation guide.

What is Bomly?

Bomly is an open-source dependency scanner and review system for modern software projects. Use Bomly CLI locally or in CI to scan dependency graphs, produce SBOMs, audit vulnerabilities and licenses, compare dependency changes, and expose dependency data to AI agents over MCP. Use Bomly Guard when you want Bomly's dependency-diff and audit workflow packaged as a GitHub Action for pull requests.

Bomly is free, Apache-2.0 licensed, and developed in the open. The CLI is the core interface; Bomly Guard wraps the same scan, diff, and audit workflow for pull requests.

What makes Bomly different?

Dependency review is rarely just one ecosystem, one input, or one policy. A useful tool needs to meet the workflow where it already exists.

Bomly can scan source projects, Git refs, containers, and SBOMs; enrich packages from multiple data sources; audit the results; and export findings as text, JSON, Markdown, SARIF, SPDX, or CycloneDX. The same workflow also works interactively in the terminal, in CI, in pull requests with Bomly Guard, and through MCP for agent workflows.

The plugin system is the part I am most excited to grow with the community. Plugins can add detectors for new manifest formats, matchers for external package or advisory sources, and auditors for team-specific rules. That makes Bomly a starting point for ecosystem support rather than a closed list of what the core project knows today.

What can Bomly do?

Scan common project types across 30+ ecosystems

Point Bomly at a target and it resolves the dependencies it can find. A target can be a local directory, a Git repository, a container image, or an existing SPDX or CycloneDX SBOM. For common projects, Bomly can start from committed manifests and lockfiles with little or no setup; some ecosystems can produce richer graphs when their package-manager tooling is available.

bomly scan

Bomly detects package evidence across 30+ ecosystems including npm, Go modules, PyPI, Maven, Cargo, RubyGems, NuGet, Composer, and more. The same command family works on SBOMs you've already generated and on container images, local or remote. When Bomly does not understand a project type yet, plugins can add detectors for new manifest formats without changing the core binary.

bomly scan --container ghcr.io/your-org/your-app:latest

Vulnerability and advisory enrichment

Network enrichment is opt-in. When you want advisory, license, lifecycle, and package metadata from public sources, pass --enrich:

bomly scan --enrich

This calls enabled matchers and attaches the results to each package: vulnerability IDs, severity scores, fix versions, license identifiers, scorecard data, and lifecycle signals where available — enough to support triage, reporting, and policy decisions.

Bomly scan pipeline — detect, enrich, audit

Under the hood, --enrich can run multiple selected matchers in parallel, including vulnerability, license, package metadata, scorecard, and lifecycle matchers. Every output derives from the same resolved graph.

Audit findings and CI gating

--audit turns enrichment data into structured findings with a pass/fail verdict. --fail-on is repeatable, so you can layer constraints — for example, failing only when high-severity findings are present:

bomly scan --enrich --audit --fail-on high

As reachability analysis matures, the same policy model can also include reachability-aware gates where supported.

In CI, that gives you a clear policy gate: exit 0 when the scan passes, exit 2 when a finding matches your threshold, and exit 4 for invalid input. For pull requests on GitHub, Bomly Guard wraps this flow with comments, summaries, and SARIF upload.

Output formats for every workflow

Bomly speaks the formats your toolchain already understands. Use --json as a shortcut for structured output, combine multiple outputs in a single pass, or target both SBOM formats at once:

# Stream structured JSON to stdout
bomly scan --enrich --json

# Write text (default format) to stdout; also save markdown and SARIF
bomly scan --enrich --audit \
  -o markdown=summary.md \
  -o sarif=bomly.sarif

# Produce both SBOM formats in one scan
bomly scan \
  -o spdx=sbom.spdx.json \
  -o cyclonedx=sbom.cdx.json

Detector and matcher work runs once — all outputs derive from the same in-memory graph. Available formats: text, json, markdown, sarif, spdx, cyclonedx.

Walk the dependency graph interactively

Sometimes you want to explore rather than report. --interactive opens a full terminal UI that lets you walk the dependency graph by hand: fuzzy-find a package, see every path that brought it into your build, pivot to a finding, and read the full advisory — without writing anything to disk.

bomly scan --enrich --audit --interactive

Bomly interactive TUI showing dependency posture, vulnerabilities, licenses, and audit findings

The dashboard shows components with relationship depth and scope, vulnerabilities, license distribution, project posture, and audit findings — all without leaving the terminal.

Explain any package

bomly explain gives you a deep-dive on a single package: every dependency path that brought it into the graph, its license, any advisories, and where it sits in the ecosystem.

bomly explain minimist --enrich -q

Bomly explain output showing why minimist is present in a JavaScript project and which advisories apply

It works whether or not you ran a scan first — point it at any package name and it resolves the context from your current project.

Track what changes between targets

bomly diff compares two dependency snapshots and reports only what changed: new packages, removed packages, version bumps, and any advisories or license issues introduced by those changes:

bomly diff --base main --head feature/new-auth --enrich --audit

Findings are classified as introduced, resolved, or persisted. --fail-on only matches against the introduced set, so a clean PR passes even when the repo has pre-existing debt. This is the foundation that Bomly Guard is built on.

Gate pull requests with Bomly Guard

Bomly Guard is the Bomly GitHub Action that wraps bomly diff and runs it on pull requests. It compares the PR head against its merge base, posts a summary comment, uploads findings as SARIF annotations, and fails the required check when policy isn't met.

- uses: bomly-dev/bomly-guard@v1
  with:
    fail-on: high
    comment-summary-in-pr: on-failure

Bomly Guard required check on a pull request

Bomly Guard compares the pull request against its merge base and focuses policy decisions on introduced findings, so teams can review new dependency risk without requiring every existing issue to be fixed first. The policy you test locally with --fail-on is the same policy Guard can enforce on PRs — no separate policy language to keep in sync.

AI agents can query your dependencies directly

Bomly runs an MCP server that AI coding agents can connect to and call as a tool:

bomly mcp serve

With this running, tools like Claude can ask questions about your dependency graph — what packages are present, whether any carry known issues, what licenses are in scope — without you having to copy-paste output or write a script. It's the same data the CLI surfaces, made available as structured tool calls your agent can invoke mid-conversation.

Extend with plugins

Bomly's plugin system lets you add new detectors, matchers, and auditors without rebuilding the binary. Plugins are Go binaries using the public sdk package, distributed and installed through Bomly's plugin manager:

bomly plugin install github.com/your-org/your-plugin@latest
bomly plugin enable your-plugin

This means you can teach Bomly to detect a custom internal manifest format, enrich packages from a private advisory feed, or implement org-specific policy checks — and share those plugins across teams without touching the core.

What's coming

A few capabilities are planned or in progress:

Reachability analysis

bomly scan --analyze is being developed to help distinguish findings that are merely present from findings that appear to be reachable from application code.

For Go, Bomly uses govulncheck for symbol-level analysis, tracing call paths from your code to known vulnerable functions where that data is available.

For JavaScript, Python, and Java, analysis currently runs at package level. That can still help with prioritization and policy decisions, but it is not the same as symbol-level reachability. Ecosystem coverage and precision will continue to improve over time.

SBOM attestations

Signing and attesting SBOMs as build provenance artifacts, so downstream consumers can verify that the SBOM was produced from a known build and hasn't been tampered with.

Get started

go install github.com/bomly-dev/bomly-cli/cmd/bomly@latest
bomly scan

For Homebrew, WinGet, Scoop, install scripts, and packaged release artifacts, see the installation guide. The getting-started guide walks from install to your first enriched scan in a few minutes.

Bomly is open source under Apache-2.0. If this sounds useful, the most helpful next steps are:

Get started with Bomly

The support page has the full list of ways to support the project.