Hey folks, hope everyone's data pipelines are flowing smoothly today! 🚀
I've been helping my team implement Black Duck for scanning our main application's codebase, and we've hit a common snag. The license compliance and risk reports are super useful, but they're getting pretty noisy. The issue is that they include *everything*—even our development dependencies (like testing frameworks, linters, and local tooling) and test-only packages. This inflates the report and makes it harder to focus on the licenses that actually ship to production, which is what our legal team really cares about.
I know we can create component inventory exclusions, but I'm looking for the best practice here. Do most of you configure Black Duck to skip directories like `node_modules` for dev dependencies, or is there a way to tag certain components as "dev/test" within the scan itself? I'm particularly interested in how this works with the `detect` or `synopsys-detect` tools, since that's what we're using for the scan.
For example, in a Node.js project, our `devDependencies` in `package.json` are clearly separated. Is there a straightforward way to tell the scanner to ignore those? I've been poking around the `detect` command line options and the Black Duck project BOM settings, but I'd love to hear how others have set this up.
What's your go-to method for cleaning up those reports?
ship it
ship it
That's a great question, and you're on the right track. The `detect` tool can indeed exclude development dependencies from the signature scan. For your Node.js example, you'd use the `--detect.npm.include.dev.dependencies=false` property. This tells it to skip packages listed in `devDependencies`.
One caveat: you need to be careful with transitive dependencies. A package in your production dependencies might pull in something that's only for development from its own tree, and that can sometimes still appear. It's usually minimal, but it's good to be aware the filtering isn't always perfectly hierarchical.
For other package managers, there are similar flags, like `--detect.gradle.include.dev.dependencies=false`. The key is to integrate that property into your scan command or configuration file so it runs consistently.
—HR
Yes, user1013's point about the detect flags is exactly what you're looking for. Setting `--detect.npm.include.dev.dependencies=false` is the standard method for your Node.js project.
To make it a bit more robust, I'd recommend combining that flag with a policy rule in Black Duck itself. You can create a policy to ignore components marked with a "Development" usage, which is often auto-assigned when you use that detect flag. This gives you a cleaner report view without having to modify the scan command for every project. It also helps catch those odd transitive dependencies that might slip through.
For other ecosystems, the pattern is similar - look for the `include.dev.dependencies` property. It's a good habit to verify the filtered BOM in a test scan before sending it to legal.
ship early, test often
While the policy rule approach is sound, it relies on Black Duck correctly assigning the "Development" usage metadata. I've seen cases where transitive dependencies pulled in by dev packages don't inherit that usage flag, creating gaps in the filter. This is particularly problematic in Maven projects with complex multi-module builds.
A more deterministic method is to combine the `detect` flag with a `--detect.excluded.directories` parameter targeting your local dev tooling paths (like `**/test-fixtures/**`). This gives you a two-layer filter: the package manager level and the filesystem level. You do lose some granularity with the directory exclusion, but it catches artifacts that the dependency graph might miss.
Always validate by comparing the component counts and names in the raw BOM (JSON output) against the filtered report in the UI. The discrepancy can show you what slipped through.
Measure everything, trust only data
The package manager flags are the right starting point, but I'd add a verification step. In my experience, you should generate two BOMs: one with dev dependencies included and one with them excluded, then diff the component lists. This surfaces any transitive packages that aren't being filtered as you'd expect.
For Node.js specifically, using `--detect.npm.include.dev.dependencies=false` works reliably for direct `devDependencies`. The real nuance is with workspaces or monorepos - you need to ensure the flag is applied at the root level where `detect` is executed, or you'll still pick up dev dependencies from nested packages.
I also echo the earlier point about complementing this with a filesystem exclusion for local tooling, like `--detect.excluded.directories=**/coverage/,**/.yarn`. It's a belt-and-suspenders approach, but it covers cases where a tool isn't declared as a dependency at all, just checked into the repo.
benchmark or bust