Categories
Software Composition Analysis (SCA) / SBOM
Integrates With
Black Duck
Black Duck Binary Analysis
File Types
CSV
ZIP
Black Duck
Black Duck is a comprehensive software composition analysis (SCA) solution by Synopsys that identifies, tracks, and manages security vulnerabilities, license compliance risks, and code quality issues within open source and third-party components across applications, containers, binaries, and firmware throughout the software development lifecycle. The platform utilizes multifactor scanning including dependency analysis, binary inspection, and snippet detection to provide complete visibility into software supply chains, while leveraging the proprietary Black Duck KnowledgeBase containing over 132,000 vulnerabilities and 3.9 million open source projects to deliver automated risk assessment and remediation guidance.
Black Duck Integration with DefectDojo
Black Duck by Synopsys is one of the most established and comprehensive software composition analysis platforms available — built for enterprises that need deep open source visibility across complex, multi-language codebases where dependency trees run deep and license compliance is as much a concern as security. It identifies open source components, maps them against a continuously updated vulnerability database, evaluates license obligations, and flags operational risk signals like abandoned or unmaintained packages. What Black Duck doesn't provide is a cross-functional vulnerability management workflow. Findings need to move from Black Duck's project dashboard into a platform where security teams can track remediation commitments across dozens of application teams, enforce SLAs, manage risk acceptance decisions with documented rationale, and report on open source security posture longitudinally. Integrating Black Duck with DefectDojo provides exactly that operational layer — turning Black Duck's deep SCA signal into a managed, auditable remediation program.
Why Black Duck Matters
Black Duck's position in the enterprise SCA market is built on database depth, multi-ecosystem breadth, and a level of component detection accuracy that matters in large, complex codebases.
- Black Duck's KnowledgeBase is one of the largest curated open source vulnerability and license databases available, with coverage spanning millions of components across hundreds of package ecosystems — including binary analysis for components that aren't declared in manifests
- Binary scanning and snippet analysis allow Black Duck to detect open source usage even in compiled artifacts and obfuscated code, capturing dependency risk that manifest-based scanners miss entirely in codebases where build outputs are the primary deliverable
- License risk analysis goes beyond flagging GPL and AGPL — Black Duck categorizes license obligations, identifies conflicts between licenses in the same dependency tree, and surfaces components with ambiguous or missing license declarations
- Operational risk signals cover component age, maintenance status, contributor activity, and community health — giving teams visibility into which dependencies are abandoned or nearing end-of-life before they become security liabilities
- Black Duck integrates with IDEs, CI/CD pipelines, and build tools (Maven, Gradle, npm, pip, NuGet, and more) via the Synopsys Detect scanner, making it practical to run as part of the normal build process rather than as a standalone scan
- Findings are exportable via the Black Duck REST API in JSON format, which DefectDojo's Black Duck parser consumes for lifecycle management import
Advantages of This Integration
Black Duck identifies open source risk with enterprise-grade depth. DefectDojo turns that risk into an accountable, tracked remediation program across your application portfolio.
- Persistent finding records across scan cycles: Each time Black Duck scans a project, reimporting into DefectDojo updates existing findings rather than generating a fresh pile of unrelated records. You can see which CVEs have persisted across multiple scans, which were resolved by a dependency upgrade, and which have been open for 60 days without action — without manually comparing Black Duck project snapshots.
- SLA enforcement for open source vulnerabilities: DefectDojo applies configurable SLA policies by severity across all imported Black Duck findings. Critical CVEs in production-deployed components get a 7-day remediation target; High severity findings get 30 days. Breach tracking surfaces overdue items in dashboards and weekly reports — turning Black Duck severity ratings into enforceable deadlines that the vulnerability management program can hold teams to.
- License risk management alongside security findings: Black Duck flags license compliance issues that carry legal and business risk alongside security vulnerabilities. Importing both categories into DefectDojo gives security and legal teams a single place to track open source risk in its entirety — not just the CVE side — with the same lifecycle management workflow applied to both.
- Cross-team remediation routing: Open source vulnerabilities span multiple owners — a vulnerable transitive dependency may be owned by a platform team that controls shared build tooling, while a direct dependency vulnerability belongs to the application team. DefectDojo's assignment model routes each finding to the right owner with the right context, without a manual triage handoff for every Black Duck scan cycle.
- False positive management that persists across scans: Black Duck findings marked as false positives or risk-accepted in DefectDojo are retained across reimports. If Black Duck reports the same component vulnerability on the next scan, DefectDojo recognizes the existing record and doesn't re-open it — eliminating repetitive triage for known, documented decisions.
- Portfolio-level open source posture reporting: Security teams managing dozens or hundreds of applications get aggregated metrics in DefectDojo — open findings by severity, ecosystem, age, and SLA status — across the entire portfolio. This aggregate view is what security leadership needs for board reporting, compliance evidence, and resource prioritization decisions.
- Ticketing workflow for remediation handoff: Triaged Black Duck findings push from DefectDojo to Jira, GitHub Issues, or ServiceNow with CVE details, affected component name and version, fix version guidance, and license information included — giving developers and build engineers what they need to act without requiring Black Duck console access.
How This Integration Works
Black Duck findings are exported via the Black Duck REST API and imported into DefectDojo using the Black Duck parser. Synopsys Detect is the recommended scanner for generating scan data that populates the Black Duck server.
Step 1 — Run Synopsys Detect and export findings via the Black Duck API
Run Synopsys Detect to scan your project and upload results to the Black Duck server:
# Download and run Synopsys Detect
bash <(curl -s -L https://detect.synopsys.com/detect9.sh) \
--blackduck.url=https://<blackduck-host> \
--blackduck.api.token=<api-token> \
--detect.project.name=<project-name> \
--detect.project.version.name=<version> \
--detect.source.path=.
Once the scan completes and results are uploaded, export vulnerability findings via the Black Duck REST API:
# Get the project version ID
PROJECT_VERSION_URL=$(curl -s -X GET \
"https://<blackduck-host>/api/projects?q=name:<project-name>" \
-H "Authorization: Bearer <api-token>" \
-H "Accept: application/vnd.blackducksoftware.project-detail-4+json" \
| jq -r '.items[0]._meta.href')
# Export vulnerability findings for the project version
curl -s -X GET \
"${PROJECT_VERSION_URL}/versions/<version-id>/vulnerable-bom-components" \
-H "Authorization: Bearer <api-token>" \
-H "Accept: application/vnd.blackducksoftware.bill-of-materials-6+json" \
-o blackduck-results.json
For automated pipeline export, Synopsys provides the detect CLI with built-in result export options:
# Run detect with JSON risk report output
bash <(curl -s -L https://detect.synopsys.com/detect9.sh) \
--blackduck.url=https://<blackduck-host> \
--blackduck.api.token=<api-token> \
--detect.project.name=<project-name> \
--detect.project.version.name=<version> \
--detect.risk.report.pdf=false \
--detect.notices.report=false \
--detect.output.path=./blackduck-output \
--detect.source.path=.
Step 2 — Import into DefectDojo
Use Black Duck API Scan as the scan type:
curl -X POST https://<defectdojo-host>/api/v2/import-scan/ \
-H "Authorization: Token <your-api-token>" \
-F "scan_type=Black Duck API Scan" \
-F "file=@blackduck-results.json" \
-F "engagement=<engagement-id>" \
-F "product=<product-id>" \
-F "active=true" \
-F "verified=false"
Step 3 — Reimport for recurring scans
For projects scanned on a regular CI/CD cadence, 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=Black Duck API Scan" \
-F "file=@blackduck-results.json" \
-F "test=<test-id>"
DefectDojo marks findings absent from the new scan as resolved, creates records for new findings, and leaves previously accepted or false-positived findings untouched.
Data Granularity: What Gets Imported
|
Field |
Source in Black Duck Output |
Notes |
|---|---|---|
|
Title |
vulnerabilityWithRemediation.vulnerabilityName |
CVE or BDSA identifier with component name |
|
Severity |
vulnerabilityWithRemediation.severity |
CRITICAL, HIGH, MEDIUM, LOW |
|
CVE ID |
vulnerabilityWithRemediation.vulnerabilityName |
CVE or Black Duck Security Advisory (BDSA) identifier |
|
CVSS Score |
vulnerabilityWithRemediation.cvss3 |
CVSS v3 score and vector from Black Duck KnowledgeBase |
|
CWE ID |
vulnerabilityWithRemediation.cweId |
Where Black Duck maps to CWE |
|
Description |
vulnerabilityWithRemediation.description |
Vulnerability description from Black Duck KnowledgeBase |
|
Component Name |
componentName |
The open source component containing the vulnerability |
|
Component Version |
componentVersionName |
Installed version of the vulnerable component |
|
Fix Version |
vulnerabilityWithRemediation.remediationStatus |
Remediation guidance and fixed version where available |
|
License |
licenses[].spdxId |
SPDX license identifier for the component |
|
License Risk |
licenseRiskProfile.counts |
License risk classification (HIGH, MEDIUM, LOW) |
|
Usage |
usages[] |
How the component is used e.g., DYNAMICALLY_LINKED, SOURCE_CODE |
|
Origin |
origins[].externalNamespace |
Package ecosystem e.g., npmjs, maven, pypi, nuget |
|
Remediation Status |
vulnerabilityWithRemediation.remediationStatus |
NEW, REMEDIATED, IGNORED, PATCHED, MITIGATED |
|
Published Date |
vulnerabilityWithRemediation.publishedDate |
When the vulnerability was published |
|
References |
vulnerabilityWithRemediation.references |
Links to NVD, vendor advisories, and exploit databases |
Use Cases
For enterprise AppSec programs managing large application portfolios: A financial services organization with 200+ applications runs Black Duck via Synopsys Detect in every CI/CD pipeline. Results import into DefectDojo, organized by application product with one engagement per release cycle. The AppSec team uses DefectDojo's aggregated view to identify which applications carry the most unresolved Critical and High open source findings, which teams are missing SLA targets, and where shared transitive dependency vulnerabilities span multiple applications — enabling portfolio-level risk management that isn't visible from individual Black Duck project dashboards.
For binary analysis of third-party and acquired software: Organizations that incorporate third-party commercial software or acquire companies with unknown codebases use Black Duck's binary scanning capability to assess open source risk in compiled artifacts. Findings from these binary scans import into DefectDojo as a dedicated engagement, giving security and legal teams a tracked record of open source obligations and CVEs discovered in software they didn't write — with remediation routing to the vendor management or M&A integration teams as appropriate.
For license compliance alongside security remediation: A software company distributing products commercially needs to track GPL and AGPL license obligations in its open source dependencies. Black Duck identifies license risk; DefectDojo tracks the compliance disposition — which license findings have been reviewed by legal counsel, which have been accepted with documented rationale, and which require remediation before the next product release. The finding lifecycle in DefectDojo serves as the compliance record alongside the security vulnerability record.
During a pre-release security gate review: Black Duck scans run against a release branch as part of the release readiness process. Results import into a DefectDojo engagement scoped to the release version. Security and engineering triage new Critical and High findings, assign remediation, and document risk acceptances for findings addressed by compensating controls. The engagement record serves as the documented open source security review artifact for the release — auditable and timestamped without manual report compilation from Black Duck's console.
For tracking operational risk in long-lived applications: Black Duck's operational risk signals — component age, maintenance status, contributor activity — are valuable for applications with long maintenance lifecycles where abandoned dependencies accumulate quietly. Importing operational risk findings into DefectDojo alongside vulnerability findings gives security teams a proactive view of which dependencies are becoming liabilities before CVEs are published, enabling planned dependency replacement as part of normal technical debt management.
Operational Tips
- Use BDSA identifiers alongside CVEs for complete coverage: Black Duck publishes Black Duck Security Advisories (BDSAs) for vulnerabilities that predate CVE publication or that Black Duck's research team identifies independently. BDSAs often carry richer remediation context than the corresponding CVE record. Ensure your DefectDojo import pipeline captures both CVE IDs and BDSA identifiers so findings are searchable by both identifiers during triage.
- Separate security and license findings into distinct DefectDojo engagements: Vulnerability findings are owned by security and engineering teams; license findings are owned by legal and compliance. Keeping them in separate engagements — with separate assignment and SLA policies — prevents security remediation queues from being cluttered with license review items that have fundamentally different resolution workflows.
- Map one DefectDojo product per application, not per Black Duck project: Black Duck may create multiple projects for the same application (one per branch, one per release). Map these to a single DefectDojo product and use engagements to represent scan cycles, branches, or release versions — this keeps deduplication clean and makes portfolio reporting accurate.
- Coordinate Black Duck ignore decisions with DefectDojo risk acceptances: Black Duck supports component-level and vulnerability-level ignore decisions within its platform. Where possible, mirror these decisions as risk acceptances in DefectDojo — the rationale is then documented, tied to an approver, and carries an expiration date in the vulnerability management platform rather than existing only as an opaque ignore setting in Black Duck's console.
- Leverage usage type for prioritization context: Black Duck records how each component is used — DYNAMICALLY_LINKED, SOURCE_CODE, DEV_TOOL_EXCLUDED, TEST_TOOL_EXCLUDED. Components used only in test or build tooling carry different runtime risk than dynamically linked production dependencies. Capture usage type in DefectDojo finding notes during triage to inform SLA prioritization — a Critical CVE in a test-only dependency may warrant a different SLA treatment than the same CVE in a production runtime library.
- Run detect with --detect.tools=DETECTOR for dependency-only scans in CI: Full Synopsys Detect runs include signature scanning and other analysis modes that add scan time. For frequent CI pipeline runs where speed matters, limiting to the DETECTOR tool (manifest-based dependency analysis) keeps scan time low while still capturing the majority of actionable open source findings. Reserve full binary and signature scanning for release-gate and periodic deep assessments.
- Align scan frequency with your dependency update cadence: If your teams update dependencies monthly, weekly Black Duck scans with DefectDojo reimport provide more data than the remediation workflow can consume. Match scan frequency to the pace at which findings can realistically be acted on — daily scans for active development branches, weekly for maintenance branches, per-release for release-gate assessments.