Alright team, let's talk about one of the most powerful but under-documented features in Black Duck: writing custom signatures for your *own* internal libraries. If you're only using it for open-source detection, you're missing half the picture.
I've been mapping our internal npm packages and Java commons library. The out-of-the-box detection is good for public repos, but it falls flat on its face for proprietary code. The trick is building accurate custom signatures so Black Duck can fingerprint your in-house components just like it does with log4j or lodash.
Here’s my quick-start workflow:
* **Start with the BOM.** Export your Bill of Materials from your package manager (e.g., `npm list --depth=0` or `mvn dependency:tree`). This is your source of truth for component names and versions.
* **Focus on the "fingerprint".** For a custom signature, you need the unique identifiers. I typically create a signature file that includes:
* The component name (e.g., `@mycompany/ui-kit`)
* Version patterns (we use semantic versioning, so I'll specify the major.minor.patch structure)
* Key file paths (like `dist/core.min.js` for our JS library)
* A snippet of unique code or a specific license header that's always present.
The real payoff is in the policy management. Once Black Duck recognizes your internal `@mycompany/auth-service v2.1.0`, you can automatically flag any project using an outdated version (like v1.x) for a policy violation. It turns Black Duck from a compliance scanner into a true dependency governance tool.
Has anyone else set this up? I'm curious how you're handling versioning schemes that aren't standard—we have a few legacy projects with date-based versions that are a pain to map.
— alex
Data > opinions
You've nailed the starting point with the BOM as source of truth. Where I've seen teams struggle is in maintaining that signature accuracy over multiple release cycles, especially when the "key file paths" change.
A practical addition: version patterns need to handle both the formal release artifact and the development SNAPSHOT or build identifiers. I define separate signature families for our stable releases and our nightly builds, using a regex pattern in the version field like `^2.3.[0-9]+$` for stable and `^2.3.[0-9]+-SNAPSHOT$` for development. Without this, scans of our CI/CD pipelines flood the reports with "unknown" versions.
Also, consider the hashing. Black Duck's fingerprinting often relies on file hashes for the key paths. If your build process minifies or bundles differently for production versus development, you'll need to account for that by either excluding volatile files or targeting the pre-processed source.
Data over dogma