Anyone using Black Duck after signing up? Any hidden costs?

Thanks for starting this, Harry. It's a really important conversation to have. I've seen a few threads where folks were caught off guard by the training and enablement costs. While they're often presented as optional, the reality for many teams is that the platform's complexity makes them almost a necessity for a proper rollout, and that can be a significant line item not in the initial proposal.

On the support side, I've generally heard it's predictable, but there can be a gap between standard support and getting help with complex integration scenarios or performance tuning, which sometimes falls into a premium services bracket. It's always worth asking for a very clear matrix of what's included in your annual fee versus what constitutes a paid engagement. Anyone else run into that distinction?

Good point about the annual fees being predictable. Has anyone run into extra charges for things like pulling historical data into the system, or is that typically covered? I'm also curious if the cost per scan stays fixed when your codebase grows, or if there's a usage tier that can trigger unexpectedly.

The point about cost per scan is critical. In my analysis, the base scan cost often scales with lines of code or development seats, but the historical data ingestion is usually treated as a one-time professional services engagement, not covered by annual support. That initial data load can become expensive depending on the volume and format of your existing audit trails.

You should also watch for the definition of a "scan" in your contract. Some vendors meter it per pipeline execution, while others define it per repository branch or commit. If your team increases its CI/CD frequency, your effective cost per line of code can shift dramatically even if your codebase size is stable. Always model costs based on your actual development velocity, not a static snapshot of your repository.

Regarding usage tiers, many contracts have soft limits that trigger a re-negotiation rather than an automatic overage charge. The unexpected cost comes from the pressure to upgrade your entire tier mid-contract, often at less favorable terms than your initial deal. Get clarity on the thresholds and the prescribed process for a true-up.

Mandatory professional services? Try mandatory infrastructure scaling. The sales deck never mentions the compute footprint for their on-prem scanner. We provisioned what we thought was a decent VM. The first full scan of a monorepo choked it for 18 hours and triggered auto-scaling alerts. The real "hidden cost" was the emergency infra review and the subsequent argument about whether a scanner node with 32GB RAM was now a core platform requirement.

And on support, the annual fee buys you a ticket queue. Getting them to acknowledge that their scanner's resource estimation is fundamentally broken? That's a "consulting engagement." The predictable part is the invoice. The unpredictable part is what you'll actually need to run the thing.

Historical data ingestion is almost always a billable professional service, not covered by the annual support fee. The cost depends entirely on the volume and format of your existing data.

Regarding the cost per scan staying fixed, it rarely does. Your contract will define the unit they meter, like pipeline executions or repository commits. If your team's CI/CD frequency doubles, your costs can double even if your codebase stays the same size. You need to model costs based on your actual development velocity, not a static code snapshot. Some contracts have usage tiers, and exceeding them can trigger a renegotiation or a true-up charge.

That support matrix is the real gotcha. You're spot on about the "premium services" bracket. Had a case where the scanner kept dying on a particular microservice pattern. Standard support just recycled the docs. To get an engineer who understood our stack, we needed a paid "technical account manager" add-on.

So yeah, ask for that matrix, but also get them to define what a "complex integration" is in writing. Otherwise, anything outside their cookie-cutter Jenkins pipeline example becomes a billable event.

Harry, you're asking the right questions, but I think you're being too polite. The sales process doesn't just "highlight" core licensing, it's designed to bury everything else.

Your point about mandatory services for niche integrations is the standard playbook. They'll demo a perfect pipeline with Jenkins. Try to hook it into your homegrown artifact repository or an internal toolchain and suddenly you need a "partner integration specialist," billed hourly. That cost isn't hidden, it's just omitted until you're locked in.

And annual fees are only predictable until you need something. The contract will guarantee a response time. It won't guarantee a solution. If your issue requires them to actually fix something in their product, that becomes a "feature request." Getting it prioritized? That's a different conversation, usually with your account rep looking for a contract expansion.

Harry, you've hit on the absolute key question with total cost of ownership. In my team's rollout, the support model was the biggest predictable cost that became unpredictable in practice.

We had the standard annual support fee, but it only covered basic troubleshooting. When we needed to adjust scan policies for a specific compliance framework we follow, that was deemed a "configuration consultancy" and billed separately. It wasn't a bug, but it was essential for us to actually use the tool as sold. The line between included support and billable professional services felt incredibly blurry.

My advice would be to push for explicit examples in writing of what kind of configuration changes or integration guidance falls on which side of that line. And maybe budget 15-20% over the quoted license fee for the first year to cover these almost-mandatory extras.

> "the line between included support and billable professional services felt incredibly blurry"

This isn't unique to SCA tools, it's endemic in enterprise software where functionality depends on nuanced configuration. In experimentation platforms, for example, modifying sequential testing boundaries or aligning with GDPR consent mechanisms often triggers "premium support" fees, even though these are necessary for valid production use. The vendor's default stance is that any deviation from base setup constitutes customization.

Your contract strategy should reference the product's published data sheets or case studies. If they advertise compliance framework readiness, argue that essential policy tuning to achieve that readiness isn't consultancy, it's implementation of a core feature. Documenting this during procurement is more effective than disputing invoices later. Has your team tried anchoring these discussions to specific clauses in the SLA?

Harry, you're right to dig into the support and maintenance piece. That annual fee is predictable, but what it *buys* is not. We had a nearly identical experience to user1426's post about "configuration consultancy."

Our project needed to adjust the policy engine to match our internal risk matrix - a core reason we bought the tool. Standard support told us to read the admin guide. To actually implement the policies as sold, we were quoted for a "policy framework alignment workshop." It felt like paying extra to use the steering wheel.

My caveat would be to scrutinize their definition of "operational support" versus "strategic services" during negotiation. If it's not in the implementation scope document, it's probably a future charge.