Bearer CLI Integration with DefectDojo

Bearer CLI Integration with DefectDojo

Bearer CLI is a static application security testing (SAST) tool from Bearer, which has been part of Cycode since 2024. It scans source code for security weaknesses and for risky handling of sensitive data, such as personal information flowing into logs, third-party services, or unsanitized output. The free CLI supports Go, Java, JavaScript, TypeScript, PHP, Python, and Ruby, and its code is published on GitHub under the Elastic License 2.0. Bearer CLI writes reports in JSON, YAML, SARIF, HTML, and other formats; DefectDojo imports its JSON security report.

Bearer CLI Integration with DefectDojo

We picked Bearer CLI because its rules look at code the way a privacy reviewer would, not only for injection flaws but for where sensitive data ends up. Bringing Bearer CLI results into DefectDojo gives those findings an owner and a history. Each rule hit becomes a Finding on the Asset that owns the repository, with its CWE, the file and line, and a link to Bearer's rule documentation. Reimporting on every build closes what developers fixed and keeps the rest on an SLA clock with everything else we track.

Why Bearer CLI Matters

Many SAST tools focus on classic vulnerability classes and treat data handling as out of scope. Bearer CLI covers both in one scan.

• Its rules flag data security issues, for example personal data written to logs or sent to an external API, alongside weaknesses such as cross-site scripting or weak cryptography.
• Every rule maps to one or more CWE IDs, which gives a consistent taxonomy for reporting and policy.
• Each finding records the source and sink locations in code, so a reviewer can see where the risky data enters and where it lands.
• It runs locally from a single binary and needs no build, so it slots into CI or a developer laptop easily.
• Like any CLI scanner, it reports only what it sees today. Without a platform behind it, there is no record of when an issue appeared or whether it was ever fixed.

Advantages of This Integration

What running Bearer CLI through DefectDojo gives us:

• CWE-based reporting. The parser sets the primary CWE and attaches every CWE the rule lists, so Bearer findings group correctly in CWE-based metrics and policies.
• Deduplication across scans. DefectDojo hashes Bearer CLI findings on title and severity. Because the parser builds the title from the rule name, file, and line, a repeat finding at the same location is recognized as a duplicate.
• Clean reports. Within one report, the parser skips entries that share a Bearer fingerprint, so the same hit is not imported twice.
• Lifecycle on reimport. Reimporting into the same Test mitigates findings that are gone, adds new ones, and reactivates any that came back.
• Governance for data handling issues. Privacy-related findings get owners, SLAs, risk acceptance, and Jira tickets, which gives privacy and security teams one place to follow up.

How This Integration Works

DefectDojo imports Bearer CLI results with the Bearer CLI scan type, which reads the JSON output of bearer scan.

1. Produce a JSON report. Run a scan against the repository and write JSON to a file:

bearer scan ./my-service --format json --output bearer-report.json

The JSON report groups findings under severity keys (critical, high, medium, low, and warning). The parser reads each group, so the severity of a finding comes from the key it sits under.

2. Import it. In the UI, open the Engagement, choose Import Scan Results, select Bearer CLI, and upload the file. For automation, use the API, available in Community Edition and DefectDojo Pro:

curl "https://YOUR_INSTANCE/api/v2/import-scan/" \
  -H "Authorization: Token $DD_API_TOKEN" \
  -F "scan_type=Bearer CLI" \
  -F "file=@bearer-report.json" \
  -F "product_name=my-service" \
  -F "engagement_name=CI" \
  -F "auto_create_context=true"

DefectDojo Pro users can do the same from a pipeline with Universal Importer:

universal-importer import \
  --defectdojo-url "https://YOUR_INSTANCE.cloud.defectdojo.com/" \
  --scan-type "Bearer CLI" \
  --report-path "./bearer-report.json" \
  --product-name "my-service" \
  --engagement-name "CI" \
  --auto-create-context

3. Reimport on each run. Send later reports to /api/v2/reimport-scan/ against the same Test, so fixed findings are closed and the branch keeps one history.

Data Granularity: What Gets Imported

Remediation advice is part of the description text, since Bearer includes it in the rule description. The parser does not import Bearer's category_groups (for example PII or Personal Data).

Use Cases

In a merge request pipeline: A CI job runs Bearer CLI on each merge request and reimports results into a Test for the main branch after merge. Developers see new findings with the rule documentation link, and a gate can check DefectDojo for new High or Critical findings.

For privacy reviews: A privacy team wants to know which services log or forward personal data. Importing Bearer CLI results for every repository into the owning Assets lets them filter by the relevant CWEs and rule IDs across the portfolio instead of reading reports one at a time.

Alongside other SAST tools: Teams that already run a general SAST scanner add Bearer CLI for its data security rules. With both on the same Asset, AppSec leads can see where the tools overlap and where Bearer adds coverage.

For audit evidence: Findings keep their discovery date, status changes, and closure in DefectDojo, which helps answer data protection audit questions about how code-level data handling issues were addressed.

Operational Tips

• Decide what to do with warning-level results before you automate. DefectDojo has no Warning severity, and the parser passes the group name through as is. Restricting the report with --severity critical,high,medium,low keeps imports predictable.
• Expect refactors to create churn. The title includes the line number, and title is a dedupe field, so moving a flagged line closes one finding and opens another for the same issue.
• Scan from the same root directory every time so file paths in titles stay stable between runs.
• Use the rule ID in Vuln ID from Tool to build filters or risk acceptances for a rule your team has reviewed and accepted.
• Tag imports with the repository or branch (for example tags=main,my-service) to separate results in metrics.
• Use minimum_severity on import if Low findings would overwhelm a first rollout, then lower it once the backlog is manageable.