This week, a widely-shared Substack post accused compliance startup Delve of helping hundreds of companies achieve security certifications without the underlying security work. The allegations are serious: pre-filled evidence, rubber-stamp auditors, and trust pages listing controls that were never implemented.
Delve has disputed the claims. The truth is still playing out.
But regardless of how this particular story resolves, it surfaces a tension that exists across the compliance-as-a-service industry and touches every company that has gone through a SOC 2, ISO 27001, or similar certification process.
The difference between certified and secure
Compliance frameworks like SOC 2 were designed to give buyers a standardized way to evaluate a vendor's security posture. The intention is sound. But the execution often translates into a race to certification, where speed and cost become the primary variables and the actual state of a company's security becomes secondary.
This isn't unique to any one vendor. It's structural. An audit is a point-in-time assessment, conducted by a third party, based on evidence a company provides or makes available. The quality of that process depends entirely on the rigor of the auditor, the honesty of the evidence, and the depth of the controls actually in place.
When that system works well, certification is a meaningful signal. When it doesn't, you get a report that says a company is compliant while their software is running three-year-old versions of libraries with known critical vulnerabilities.
What templates can't tell you
One of the specific charges against Delve is that they provided pre-populated board meeting minutes, risk assessments, and policies. Customers were allegedly led to adopt these as-is rather than treating them as starting points for documenting their actual practices.
Delve's position is that templates are standard industry practice. They're not wrong that templates exist everywhere in compliance tooling. The question is what they represent.
A policy template is a document. A policy is a practice your organization actually follows. Those are different things. An auditor working quickly, with shallow scrutiny, may not distinguish between them. An attacker scanning your environment certainly won't.
The same distinction applies to your software supply chain. You can adopt a template that says you have a vulnerability management process. You can check a box that says you conduct dependency scanning. Or you can actually know what libraries are running in your production environment, what versions they're on, and whether any of them carry active vulnerabilities.
One of these is a document. The other is real visibility.
The dependency problem doesn't wait for your audit cycle
Your reliance on open source software is a living, continuously changing attack surface. The average software project pulls in hundreds of direct and third-party dependencies. New vulnerabilities are discovered constantly. The timeline between disclosure and active exploitation has compressed significantly over the past several years.
SOC 2 is annual. Vulnerabilities don't wait around until your next annual audit.
The XZ Utils backdoor, disclosed in early 2024, demonstrated how deeply a malicious package could embed itself into the software supply chain before anyone noticed. The impact of Log4Shell in 2021 was amplified because most organizations had no clear picture of where Log4j lived in their dependency trees.
A compliance certification would not have caught either of these. Continuous software composition analysis would have.
What this story is actually about
The Delve controversy is generating attention because the allegations are specific and the stakes are real. Companies are potentially exposed to HIPAA liability and GDPR fines because they believed they were compliant when they weren't.
But the underlying issue is broader: the market has created strong incentives to look secure, and weaker incentives to be secure. Speed, cost, and the ability to show prospects a clean trust page are more immediately legible than the actual state of your security posture.
Risk lives in the gap between the appearance of security and security itself.
Compliance is not the enemy. Certifications serve a purpose, and a well-run SOC 2 process can meaningfully improve a company's security posture. But certification is a starting point, not a destination. And a certificate is not the same as visibility.
Knowing what's in your software — every dependency, every version, every known exposure, updated continuously — is the foundation that makes everything else meaningful.
That's not a trust page. That's a security practice.
See what’s running in your software. Start your free trial.
