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 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 Copy 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 Copy 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 Copy 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 Copy 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. 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 Copy 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 forma...