Bundler-Audit

Bundler-Audit Integration with DefectDojo

Bundler-Audit is the standard tool for auditing Ruby gem dependencies against the Ruby Advisory Database — a community-maintained, open-source vulnerability database covering CVEs and security advisories for the RubyGems ecosystem. For Ruby and Rails teams, it fills a specific and essential gap: fast, accurate, zero-configuration scanning of Gemfile.lock against known vulnerabilities in the gems your application actually depends on. It's typically the first security tool added to a Ruby CI pipeline and often the one with the most immediate return, surfacing CVEs in production gems that developers haven't noticed because gem changelogs bury security advisories in release notes. The operational challenge is the same one every point-in-time scanner faces: Bundler-Audit output lives in terminal output and CI logs unless a workflow platform brings it into a managed lifecycle. Integrating Bundler-Audit with DefectDojo closes that gap — gem vulnerability findings enter a persistent workflow with SLA enforcement, remediation tracking, deduplication, and portfolio-level reporting across every Ruby application in your organization.

Why Bundler-Audit Matters

Bundler-Audit occupies a foundational role in Ruby security programs — it is purpose-built for the RubyGems ecosystem, actively maintained against the Ruby Advisory Database, and fast enough to run on every commit without meaningful CI overhead.

• Bundler-Audit scans Gemfile.lock against the Ruby Advisory Database (GHSA and CVE records for RubyGems), covering both direct dependencies and the full transitive dependency tree — the transitive layer is where a significant proportion of real-world gem vulnerabilities originate
• It detects insecure gem sources — HTTP instead of HTTPS in Gemfile source declarations — alongside CVE findings, surfacing a common configuration risk that pure vulnerability databases don't cover
• Output includes CVE identifiers, advisory titles, affected gem version ranges, and patched version information — structured data that gives developers exactly what they need to act: which gem to upgrade and to which version
• JSON output via --format json produces structured data that DefectDojo can ingest directly without preprocessing, enabling straightforward CI pipeline integration
• As a lightweight gem with no external API dependencies, Bundler-Audit works offline against a locally cached copy of the Ruby Advisory Database (updated via bundle-audit update), making it reliable in air-gapped or network-restricted CI environments
• It runs in seconds on any Gemfile.lock, regardless of project size, making it practical to run on every pull request, every commit to main, and every release branch without scan time becoming a bottleneck

Advantages of This Integration

Bundler-Audit identifies vulnerable Ruby gems in your dependency tree. DefectDojo tracks whether your team upgraded them — and how long it took.

• Persistent finding records across Ruby scan cycles: Each time Bundler-Audit runs against an application, reimporting into DefectDojo updates existing findings rather than generating a disconnected new record set. You can see which gem CVEs have persisted across multiple scans, which were resolved by a gem upgrade, and which have been open for weeks without a bundle update — context that CI terminal output doesn't retain.
• SLA enforcement for Ruby gem vulnerabilities: DefectDojo applies configurable SLA policies by severity across all imported Bundler-Audit findings. Critical gem CVEs get a 7-day remediation target; High severity findings get 30 days. Breach tracking surfaces overdue items in dashboards and weekly reports — turning Bundler-Audit's advisory output into enforceable remediation deadlines rather than informational scan results.
• Deduplication across Ruby repositories: The same CVE in a widely used gem — rails, nokogiri, devise, puma, rack — appearing across fifteen Ruby services doesn't generate fifteen independent unrelated findings if your DefectDojo product structure is organized appropriately. Shared gem vulnerabilities surface as portfolio-level issues worth addressing as a coordinated upgrade effort, not piecemeal per repository.
• False positive management that persists across reimports: Bundler-Audit rarely produces false positives given the precision of the Ruby Advisory Database, but risk acceptance decisions — accepting a CVE in a gem used only in a non-exploitable context — are retained across reimports in DefectDojo. The next Bundler-Audit scan won't re-open accepted findings, and the documented rationale is auditable.
• Cross-repository Ruby portfolio visibility: Security teams managing multiple Ruby and Rails applications get aggregated metrics in DefectDojo — open gem vulnerabilities by severity, gem name, application, age, and SLA status — without manually reviewing individual Bundler-Audit outputs per repository. This aggregate view surfaces systemic gem debt and drives coordinated upgrade initiatives.
• Developer-facing remediation tickets with upgrade guidance: Triaged Bundler-Audit findings push from DefectDojo to Jira, GitHub Issues, or ServiceNow with CVE identifier, affected gem name and version, patched version, and advisory description — giving developers a directly actionable upgrade ticket without requiring access to security tooling or manual CVE lookup.
• Audit trail for compliance: For Ruby applications subject to software composition analysis requirements — PCI DSS, SOC 2, SSDF, or internal AppSec policy — DefectDojo's engagement history and finding lifecycle records provide documented evidence of continuous gem dependency scanning and remediation tracking.

How This Integration Works

Bundler-Audit produces JSON output via its CLI that DefectDojo's Bundler-Audit parser consumes directly.

Step 1 — Install Bundler-Audit and run a scan

Add Bundler-Audit to your Gemfile (development group) or install as a standalone gem:

# Install as standalone gem

gem install bundler-audit

# Or add to Gemfile

# gem 'bundler-audit', require: false

# Update the local Ruby Advisory Database before scanning

bundle-audit update

# Run a scan with default text output

bundle-audit check

# Run with JSON output for DefectDojo import

bundle-audit check --format json --output bundler-audit-results.json

# Update the database and scan in a single command

bundle-audit check --update --format json \

--output bundler-audit-results.json

For CI pipeline integration:

# Update the advisory database and capture JSON output

# Use || true to prevent pipeline failure on findings

bundle-audit update

bundle-audit check --format json \

--output bundler-audit-results.json || true

If the Gemfile.lock is in a non-standard location:

bundle-audit check --gemfile-lock /path/to/Gemfile.lock \

--format json --output bundler-audit-results.json || true

Step 2 — Import into DefectDojo

Use Bundler-Audit Scan as the scan type:

curl -X POST https://<defectdojo-host>/api/v2/import-scan/ \

-H "Authorization: Token <your-api-token>" \

-F "scan_type=Bundler-Audit Scan" \

-F "file=@bundler-audit-results.json" \

-F "engagement=<engagement-id>" \

-F "product=<product-id>" \

-F "active=true" \

-F "verified=false"

Step 3 — Reimport for recurring scans

For repositories scanned on every CI run or merge to main, use the reimport endpoint to update existing findings rather than accumulate redundant test records:

curl -X POST https://<defectdojo-host>/api/v2/reimport-scan/ \

-H "Authorization: Token <your-api-token>" \

-F "scan_type=Bundler-Audit Scan" \

-F "file=@bundler-audit-results.json" \

-F "test=<test-id>"

DefectDojo marks findings absent from the new scan as resolved, creates records for new findings, and leaves previously false-positived or risk-accepted findings untouched.

Data Granularity: What Gets Imported

Use Cases

In a CI/CD pipeline for a Rails application: Bundler-Audit runs on every pull request and merge to main. Results import into DefectDojo via the API at the end of the scan stage. Security engineers triage new findings weekly — Critical and High CVEs in production gems like rails, puma, or rack are assigned immediately; Medium findings in development-only gems are reviewed in batch. Previously risk-accepted findings — a CVE in a gem used only for an internal admin tool with network access controls — don't re-appear on subsequent scans, keeping the active queue focused on genuine risk.

Across a portfolio of Ruby microservices: An engineering organization with 25 Ruby services — a mix of Rails APIs, Sinatra services, and background job processors — runs Bundler-Audit in every service's CI pipeline and imports results into DefectDojo. The security team identifies that a critical vulnerability in nokogiri appears in 18 of 25 services simultaneously. Rather than waiting for 18 individual teams to upgrade independently at their own pace, the security team opens a coordinated upgrade initiative tracked in DefectDojo — with per-service assignment, a shared deadline, and progress visible in a single dashboard view. The coordinated response resolves the fleet-wide exposure weeks faster than uncoordinated individual upgrades.

During a Ruby version or Bundler upgrade: When updating Ruby or Bundler versions, Gemfile.lock changes significantly as gem compatibility requirements shift. Running Bundler-Audit before and after the upgrade and importing both results into a dedicated DefectDojo engagement shows which CVEs were resolved by the upgrade's implicit gem version changes and which new advisories were introduced by newly required gem versions. The before-and-after record provides a clear security impact assessment of the runtime upgrade.

For compliance evidence in regulated Ruby applications: A fintech company's Rails application handles payment data and is subject to PCI DSS software security requirements. DefectDojo's engagement history showing weekly Bundler-Audit scans, finding lifecycle records, and remediation tracking across every gem CVE provides the continuous SCA coverage evidence that a QSA examiner expects — without manual compilation of scan reports from CI logs across multiple sprints.

Operational Tips

• Always run bundle-audit update before scanning in CI: Bundler-Audit works against a locally cached copy of the Ruby Advisory Database. If the cache isn't updated, scans miss advisories published since the last update. Running bundle-audit update as a CI step immediately before bundle-audit check ensures findings reflect the current advisory database state. In air-gapped environments, pre-seed the cache in a base Docker image updated on a regular schedule.
• Use || true to decouple scan exit code from pipeline failure: Bundler-Audit exits non-zero when findings are present, which fails CI pipeline stages by default. Using || true allows the JSON output to be captured and imported into DefectDojo regardless of finding state. Handle pipeline gate logic separately — failing builds only on Critical findings that aren't already tracked in DefectDojo as accepted — rather than blocking on any finding.
• Commit Gemfile.lock to enable accurate transitive dependency scanning: Bundler-Audit requires Gemfile.lock to resolve the full dependency tree including transitive gems. Projects that don't commit Gemfile.lock — sometimes the case for gem libraries rather than applications — will not have a complete dependency picture for scanning. For application repositories, enforce Gemfile.lock commits as a repository policy.
• Map one DefectDojo product per Ruby repository: A one-to-one mapping between Ruby repositories and DefectDojo products keeps deduplication clean, ownership clear, and SLA tracking meaningful. For monorepos containing multiple Ruby services with separate Gemfile.lock files, map products to individual service directories and run Bundler-Audit per service.
• Handle insecure_source findings as configuration findings, not vulnerabilities: Bundler-Audit's insecure_source finding type flags HTTP gem sources in Gemfile — a configuration issue rather than a CVE. These import into DefectDojo as separate finding records. Tag them or assign them to a different engagement than CVE findings so they don't inflate your vulnerability finding counts or compete with CVE SLA targets.
• Pair Bundler-Audit with Brakeman for complete Ruby application security coverage: Bundler-Audit covers gem dependency CVEs; Brakeman covers security issues in application code. Neither covers the other's domain. Running both and importing results into DefectDojo — Bundler-Audit findings in an SCA engagement, Brakeman findings in a SAST engagement, both under the same product — gives complete Ruby application security coverage in a single tracked workflow.
• Review advisory criticality versus actual exploitability during triage: The Ruby Advisory Database's criticality ratings don't always reflect exploitability in your specific deployment context. A High criticality advisory for a gem feature you don't use, or a CVE in a gem that's only loaded in test environments, may warrant a lower SLA target or a risk acceptance. Document the exploitability context in DefectDojo finding notes during triage so the rationale is clear when the finding re-appears in the next scan cycle.