Most organizations still think open-source risk is a dependency problem, but I’m here to show you that it’s not. The real problem is all the code entering your environment outside the normal validation model. This come in as AI-generated snippets or copied functions from Stack Overflow. They could also be internal reuse, refactored fragments or even random utility classes that nobody tracks because “it’s just a few lines.” That’s where teams get exposed.
Traditional SCA platforms were built around declared packages and manifests. That worked when developers pulled dependencies in predictable ways. Modern development doesn’t work like that anymore. Especially with AI coding assistants now generating code faster than most organizations can review it, and that is exactly why snippet-level detection matters. This is all baked into our AI Development offering framework but read on to understand the interworkings.
The Hidden Risks Nobody Is Operationalizing
Open-source and AI-assisted development absolutely accelerate delivery. They also quietly create licensing, provenance, and security problems most teams are not actually measuring or even thinking to measure.
The common failure patterns usually look like this:
- AI-generated code introducing GPL or AGPL licensed snippets into proprietary applications
- Developers copying “small harmless functions” without attribution or provenance tracking
- Vulnerable code fragments bypassing traditional dependency scanning entirely
- No ability to trace where code originated during audits, M&A reviews, or customer security assessments
- Security teams relying on happy-path SCA validation while snippet reuse remains completely reachable
Because once snippet reuse bypasses visibility, you no longer have enforceable governance. You just have assumptions and assumptions are not controls.
Traditional SCA Wasn’t Built for This
Most SCA tooling still focuses heavily on:
- Package manifests
- Dependency trees
- Known components
- Version tracking
Is this still useful? Absolutely. Is it enough? It used to be, but not anymore. Modern risk increasingly lives in smaller fragments of reused code that never appear in package manifests at all. AI coding assistants made this dramatically worse almost overnight. Now organizations have code entering production where nobody can confidently answer:
- Where did this come from?
- What license obligations exist?
- Was this modified?
- Does this introduce inherited CVEs?
- Is this legally safe to ship?
That becomes a business problem very quickly especially during audits, customer due diligence, acquisitions, or legal reviews.
Why Black Duck’s Snippet Detection Changes the Conversation
Black Duck has moved beyond simple dependency visibility. Their snippet and code similarity capabilities help organizations identify reused open-source code fragments, partial matches, and inherited licensing exposure that traditional package-based scanning often misses. This has to be top of mind because modern AppSec programs need to validate code provenance, not just dependency declarations.
Some of the capabilities that actually “move the needle”
- Snippet-level and code similarity detection
- Open-source provenance tracking
- License risk identification at fragment level
- AI-assisted code governance support
- CI/CD and developer workflow integrations
- Policy enforcement during pull requests and build stages
- SBOM generation with deeper code intelligence
This is where we see SCA starting to become operational instead of just informational and why you go with a household name like Black Duck, with licenses and implementation running through Merito. This would be a good time to mention there is a follow up blog on why this model makes more sense than just buying licenses from vendors themselves, click the "Ask an Expert" modal in your lower right corner and I'll personally send it to you.
The Real Business Impact
The technical story is only half the issue, the bigger problem is operational exposure, which for those of you who know me personally and professionally, this is my world at Merito. When organizations can’t validate reused code properly, they create all sorts of issues. A short list that we've seen are customers are:
- Legal exposure from untracked licensing obligations
- Security blind spots hidden inside modified snippets
- Delayed releases during customer security reviews
- Audit failures and weak SBOM confidence
- Increased remediation costs after production deployment
- Compliance gaps across distributed engineering teams
And yes… AI code generation is accelerating all of it. Faster delivery pipelines without stronger validation gates just increase blast radius. Our very own Claud Certified Architects (CCA-F) can help with framework and get you on the right path.
What Should Be Stopping This
As much as I love them, most organizations do not need more dashboards. They just need better enforcement points. I wanted to make sure you walk away with as many check lists as I can give you without doing a mini-assessment (by the way, I'd love to meet with anybody on the topic, so please do reach out to hear more). A strong and mature snippet governance model should include:
- Snippet-level scanning integrated directly into CI/CD
- Policy enforcement before merge approval
- AI-generated code validation workflows
- License exception handling and approval gates
- Continuous SBOM validation
- Developer-facing remediation guidance
- Ongoing negative testing against policy bypass attempts
Security controls should be tested for exploit resistance, not just functionality. If developers can accidentally bypass your governance model, they eventually will. Usually under delivery pressure, trying to get that feature out or user story closed and usually right before a release freeze. Candidly, I’ve done this myself.
How Merito Operationalizes Black Duck
Tools alone won’t and don’t fix this problem. It's the execution that does. Merito helps organizations operationalize Black Duck inside real enterprise delivery pipelines without turning AppSec into a release bottleneck. An à la carte list usually includes:
- Pipeline integration and rollout strategy
- Policy and governance design
- AI-generated code governance models
- SBOM operationalization
- Developer enablement
- Exception workflow design
- Release gate enforcement
- Audit readiness support
- Continuous validation and reporting
The important part is making the controls usable by engineering teams instead of creating another disconnected security process everyone works around. Because developers will absolutely route around painful controls. Every time. And non-developers…who now have access to repos and coding assistants because the barrier to entry is getting lower and lower with Claude, Codex, Windsurf etc... they will do it every time because they don’t know any better.
Internal Black Duck Resources Your Team Should Be Using
Your teams should have centralized internal guidance for:
- Approved license policies
- Snippet detection thresholds
- AI-generated code governance
- SBOM ownership responsibilities
- Pull request enforcement standards
- Exception approval workflows
- Remediation SLAs
- Secure reuse guidelines
If those resources don’t exist yet, that’s usually the first operational gap to fix we like to fix. Its not the scanner but more so the governance model around it.
One more checklist Before You Scale AI-Assisted Development
Since I love checklists, I’ll leave you with this. If your organization is heavily using GitHub Copilot, Cursor, Windsurf, or other AI coding tools, ask these questions now:
Governance Checklist
- Do we validate snippet-level code reuse?
- Can we identify copied or AI-generated open-source fragments?
- Are license obligations enforced before release?
- Do developers receive feedback early in the pipeline?
- Can we trace code provenance during audits?
- Are SBOMs continuously updated?
- Do we test policy enforcement failures intentionally?
- Are exception approvals documented and auditable?
- Can teams bypass scanning through alternate workflows?
- Do we validate exploit resistance of our release gates?
If you answered “no” or “not sure” to several of those, the problem is not AI coding. The problem is the control model surrounding it and I’m seeing that gap getting expensive fast.
Final Thought
Snippet-level detection should not be thought of as compliance tooling. I want you to think of it as maintaining control over what enters your software supply chain before it becomes a legal issue, production incident, or customer escalation. Organizations that operationalize this early will move faster, safely and at a lower cost. Organizations that don’t will eventually discover their governance model was built entirely around happy-path assumptions and this usually happens during an audit. Or after a release….or both.
