OpenSSF Scorecard Integration with DefectDojo

OpenSSF Scorecard Integration with DefectDojo

OpenSSF Scorecard is an open source tool from the Open Source Security Foundation that grades a source repository's security practices with a set of automated checks. Each check, such as Branch-Protection, Pinned-Dependencies, Token-Permissions, SAST, Maintained, or Vulnerabilities, gets a score from 0 to 10 with a reason and supporting details, and the repository gets an aggregate score. Scorecard writes JSON or SARIF, and the project also publishes results for many public repositories. DefectDojo imports the native JSON, which carries the per-check numeric scores.

OpenSSF Scorecard Integration with DefectDojo

We run OpenSSF Scorecard on our own repositories and on the open source projects we depend on most, and we import the results into DefectDojo so weak practices get fixed rather than noted. A Scorecard run tells us that a repository lacks branch protection or uses unpinned actions. DefectDojo turns each failing check into a Finding on the repository's Asset, with a severity based on how far the check falls short, so the work can be assigned, scheduled, and tracked until the score improves.

Why OpenSSF Scorecard Matters

Supply chain attacks often succeed through process gaps: an unprotected branch, a workflow token with too many permissions, a dependency pulled by a moving tag.

• Scorecard checks those practices automatically and explains each result in plain language.
• Checks are independent, so a team can see exactly which control is missing rather than a single opaque grade.
• The same checks can be run against third-party projects, which helps when evaluating a dependency before adopting it.
• A score of -1 marks a check that couldn't reach a conclusion, which keeps "unknown" separate from "failed."

Advantages of This Integration

• Only shortfalls import. Checks scoring 10 (fully passing) and checks scoring -1 (inconclusive) are skipped, so the Test contains only practices that need work.
• Severity from the gap. Scores of 0 to 3 import as High, 4 to 6 as Medium, and 7 to 9 as Low, which gives Scorecard results a place in DefectDojo's SLA policy.
• One finding per check per repository. Deduplication hashes vuln_id_from_tool (the check name) and component_name (the repository), so a check stays one finding across runs even as its score and title change.
• Repository posture next to code findings. Scorecard results share the Asset with SAST and SCA findings for the same codebase, giving a fuller picture of how the repository is built and protected.
• Progress you can show. Reimporting after a fix mitigates the check once it reaches 10, and the Finding history shows when it was resolved.

How This Integration Works

DefectDojo imports Scorecard results with the OpenSSF Scorecard scan type.

1. Run Scorecard with JSON output. Scorecard reads repository data through the hosting platform's API and needs a GitHub token in its environment for GitHub repositories. Then run:

scorecard --repo=github.com/your-org/your-repo --format=json > scorecard.json

Results the Scorecard project already publishes for public repositories come back in the same JSON shape and can be imported the same way. Scorecard's SARIF output is a different path: DefectDojo's generic SARIF parser handles it, but SARIF lacks the per-check numeric score this parser relies on.

2. Import it. In the UI, open the Engagement, choose Import Scan Results, select OpenSSF Scorecard, and upload the file. To automate, use the API, which works in Community Edition and DefectDojo Pro:

curl "https://YOUR_INSTANCE/api/v2/import-scan/" 
  -H "Authorization: Token $DD_API_TOKEN" 
  -F "scan_type=OpenSSF Scorecard" 
  -F "file=@scorecard.json" 
  -F "product_name=your-repo" 
  -F "engagement_name=Supply Chain Posture" 
  -F "auto_create_context=true"

DefectDojo Pro users can use Universal Importer in CI:

universal-importer import 
  --defectdojo-url "https://YOUR_INSTANCE.cloud.defectdojo.com/" 
  --scan-type "OpenSSF Scorecard" 
  --report-path "./scorecard.json" 
  --product-name "your-repo" 
  --engagement-name "Supply Chain Posture" 
  --auto-create-context

3. Reimport on a schedule. Run Scorecard weekly or on changes to repository settings, and reimport into the same Test with /api/v2/reimport-scan/ so checks that reach a perfect score are mitigated.

Data Granularity: What Gets Imported

The parser sets no CWE, CVE, or mitigation. The check's documentation link explains the remediation for each check.

Use Cases

Hardening internal repositories: A platform team runs Scorecard across 60 repositories each week and imports each into its own Asset. High findings for Branch-Protection and Token-Permissions go to repository owners with an SLA, and the team reports how many repositories reached a passing score each quarter.

Vetting open source dependencies: Before adopting a new library, a security engineer imports Scorecard results for its repository into an evaluation Asset. Low Maintained or Vulnerabilities scores become a documented reason to choose an alternative or to accept the risk explicitly.

Tracking critical dependencies over time: For the handful of open source projects a product depends on most, scheduled Scorecard imports show when a project's practices slip, for example when maintenance activity drops.

Audit evidence for secure development: Scorecard findings and their history give auditors concrete evidence that repository controls such as branch protection and code review are checked and enforced.

Operational Tips

• Name the Asset after the repository and keep the --repo value stable. The repository name is part of the hash, so changing its form (with or without the host prefix) creates new findings.
• The title includes the current score, so expect titles to change between runs. Deduplication uses the check name and repository, not the title, so the finding itself stays the same.
• Inconclusive checks (-1) are not imported. If an important check keeps coming back inconclusive, give Scorecard the token permissions it needs rather than assuming it passed.
• Treat the Vulnerabilities check as a pointer. Its details list advisory links, but use your SCA tool's findings for package-level remediation.
• Set SLAs per severity with practices in mind. A High here usually means a missing control, which can often be fixed in minutes in repository settings.
• Risk-accept checks that don't fit your workflow, such as a check you have a documented exception for, with a note so the decision is visible to reviewers.