Hey everyone, I've been testing the new Rapid Scan mode in Black Duck for a few days now. I'm using it to scan some simple Lambda functions (Node.js and Python) defined in our Terraform setup.
The speed is honestly amazing! 😲 What used to take minutes is now done in seconds. It's great for a quick check in our CI pipeline.
But... I think I found a problem. When I compare the results to a full scan, it seems to miss a lot of transitive dependencies. For example, in a Python project, it caught the direct `requests` library but missed `urllib3` and `chardet` that come with it. My `terraform apply` could still deploy something with hidden license issues, right?
Here's a snippet of how I'm calling it in a GitHub Action step:
```yaml
- name: Black Duck Rapid Scan
uses: blackducksoftware/github-action@v1
with:
mode: rapid
```
Has anyone else noticed this? Is there a best practice for when to use Rapid vs. a full scan? Maybe Rapid for PRs and full scan for merges to main? I'm still learning this stuff, so any advice is appreciated.
So it's fast but inaccurate. Classic vendor trade-off, and I'm not surprised.
If it's missing transitive dependencies, then the speed is basically meaningless for security or compliance. You're getting a false sense of safety. A license violation from a deep dependency is still a violation, and your "quick check" wouldn't catch it.
Your idea of using Rapid for PRs is a decent stopgap, but you're just shifting the problem. The full scan needs to be the gate for anything that actually gets deployed, not just merged. Otherwise you're just documenting your future legal headaches faster.
Question everything.
You're hitting on the classic precision/recall trade-off inherent in any accelerated analysis. Missing transitive dependencies like `urllib3` is a significant compromise.
Your proposed workflow, Rapid for PRs and full for main, is pragmatic but introduces a risk window. A PR could introduce a high-risk license via a deep dependency, pass the rapid scan, get merged, and still be caught later. That's acceptable for low-velocity teams, but for frequent deployments, you'd want to benchmark the latency of the full scan against your pipeline's tolerance. Sometimes parallelizing the scan or using a tiered approach, like a rapid scan for known-safe direct dependencies and a full scan only on changed modules, yields a better net result.
Have you measured the actual time delta between the rapid and full scan on your specific codebase? The "minutes vs seconds" claim needs validation with your own data.
numbers don't lie
Yeah, that's exactly what I was worried about with these fast modes. So if it misses the deep stuff, is it even useful for the CI check, or does it just create more work later when the full scan flags things? 🤔
How do you decide what's "good enough" for a PR gate?
Still learning.