Black Duck

Black Duck is the Software Factory’s most complete Software Composition Analysis (SCA ) solution. It combines four detection techniques to build a complete dependency inventory — including dependencies that other tools miss, such as copy-pasted open source code and components embedded in compiled binaries.

This process helps in identifying known security vulnerabilities (CVEs/BDSAs), license compliance violations, operational risks, and generating a comprehensive Bill of Materials (BOM) for your applications.

Key Concepts

• Project & Version: The structural mapping of your application and its specific release/branch in Black Duck.
• Component: An open-source library, framework, or third-party dependency detected in your code.
• SBOM (Software Bill of Materials): The comprehensive inventory of all components, licenses, and security risks identified in a specific Project Version.
• Synopsys Detect: The unified CLI scanner used to analyze your code and send results to the Black Duck server.

Inventory Coverage

The table below maps each analysis approach to its Black Duck method:

All scanning methods are invoked through Synopsys Detect . Each targets a different type of open source usage:

• Dependency analysis — reads manifest and lockfile files (pom.xml, package.json, requirements.txt, etc.) to identify declared direct and transitive dependencies.
• Snippet detection — matches source code fragments against the Black Duck KnowledgeBase to find copy-pasted or modified open source code not declared in any manifest.
• Binary analysis — analyzes compiled artifacts (JARs, DLLs, Docker images, etc.) without requiring access to source code.
• Container scanning — analyzes OS package databases within container images, identifying packages installed at each layer.

Analysis Capabilities

Vulnerability Detection

Black Duck checks components against the Black Duck KnowledgeBase , which tracks over 8.7 million open source components and 130,000+ known vulnerabilities.

In addition to the NVD, Black Duck publishes its own Black Duck Security Advisories (BDSAs). BDSAs include detailed exploitation information and remediation guidance, often published weeks ahead of NVD — sometimes within hours of a vulnerability’s initial discovery.

Obsolescence & Operational Risk

Black Duck tracks operational risk metrics per component: version age, time since last release, and maintenance status. Address these to avoid accumulating third-party Technical Debt and enable policies that flag components severely behind the latest release.

License Compliance

The Black Duck KnowledgeBase covers over 2,750 unique open source licenses, including full license text and detailed obligation information. It generates Notices reports to help fulfill attribution and disclosure requirements.

Scanning Process

The main steps for Black Duck analysis within your pipeline:

1. Launch CI Pipeline: Your CI/CD pipeline triggers Synopsys Detect.
2. Determine Scope: Detect assesses the repository, looking for package manager files.
3. Dependency Resolution: Detect invokes native package managers to map the full tree.
4. Signature Scanning (Optional): Detect scans the file system for source code snippets.
5. Results Submission: Signatures and dependency trees are sent to the Black Duck Server.
6. SBOM Generation & Policy Check: The SBOM is generated, vulnerabilities are linked, and Policies are evaluated. If a block policy fails, Detect fails the CI/CD pipeline.

Managing your scan scope

• Use Synopsys Detect properties (like --detect.detector.search.exclusion) to exclude test directories or internal proprietary libraries.
• Ensure build tools are properly configured before running Detect to resolve transitive dependencies accurately.

Integration Points

Continuous Monitoring

When a new vulnerability is published, the Black Duck server automatically re-evaluates the stored BOMs for all monitored projects and triggers relevant policies without requiring a new scan. Alerts can be routed via email, Jira, or MS Teams, keeping you informed of new risks.

Policy Management

Black Duck enforces governance through custom policies. Rules can be based on:

• Vulnerability criteria: BDSA or CVSS severity, exploitability.
• License type: Allowed or banned licenses.
• Operational risk: Component age, version lag, maintenance status.

When a rule fires, actions include blocking the build, creating a Jira ticket, or notifying teams.

Results and Reporting

All results are accessible from the Black Duck UI (project version dashboard). To facilitate audits, Black Duck provides several distinct reports generated via UI or API.

SBOMs (SPDX or CycloneDX ) and Notices Files can also be generated automatically during a CI pipeline scan or exported from the UI for supply chain transparency.

Getting Started

Initial Setup and Configuration

Similar to other tools, Projects and Versions are typically created automatically during their first pipeline scan. However, naming conventions are crucial:

• Project Name: Unique identifier matching your GitLab project (e.g., GBU_BL_ProjectName).
• Version Name: Represents the branch or release (e.g., main, v1.2.0).

Pipeline & Policy Workflow

• First scan — run Synopsys Detect locally to assess your project’s baseline before configuring any policy.
• Pipeline integration — use the NextGen CI/CD Black Duck step to automate scanning.
• Policy configuration — Configure policies once you have established a baseline.

Useful Resources

• For practical steps on running scans, visit our How-To perform a scan using Black Duck SCA guide.
• More info about IDE integrations at How to configure Blackduck IDE .
• Explore our practices: License Practice page , SBOM Practice page , and Vulnerability Practice page .