A detailed investigation published on Substack has alleged that Delve, a compliance automation platform, systematically manufactured false SOC 2 and ISO 27001 certifications for its clients. If the allegations hold up, it represents one of the largest compliance fraud operations in the startup ecosystem.
For developers and engineering teams that rely on compliance certifications when evaluating tools, this is a wake-up call.
What Happened with Delve
According to the investigation, Delve operated by pre-populating audit evidence, generating test procedures and conclusions internally, and then routing the finished package to auditing firms that would rubber-stamp the results without conducting independent verification.
The key allegations include:
- Fabricated audit evidence - Delve's platform allegedly generated compliance artifacts and pre-filled audit conclusions rather than requiring clients to demonstrate actual security controls
- Non-independent auditors - The auditing firms used were reportedly Indian certification mills operating through US shell entities, violating AICPA independence requirements
- Misleading marketing - Claims about "US-based auditors" allegedly masked the actual audit process, and trust pages displayed security badges before any compliance work had begun
- Wide impact - Multiple companies including venture-backed startups and at least one NASDAQ-listed firm reportedly received these certifications, collectively handling millions of customer records
The auditing firms named in the investigation include Accorp, Gradient Certification, Glocert, and DKPC - described as accepting pre-written conclusions rather than performing genuine independent audits.
Why This Matters for Developer Tools
If you evaluate code review tools, security scanners, or any SaaS platform, you have probably looked at compliance certifications as a trust signal. SOC 2 and ISO 27001 badges appear on nearly every tool's security page.
Here is the problem: a badge is not proof of anything.
A legitimate SOC 2 Type II report means an independent auditor observed a company's security controls operating effectively over 6 to 12 months. It covers access controls, encryption, incident response, change management, and more. When done properly, it is a meaningful signal.
But when the audit process itself is compromised, the certification becomes theater. A tool could display a SOC 2 badge while having:
- No real access controls
- Unencrypted data at rest
- No incident response plan
- No change management process
- No employee security training
This is particularly dangerous for tools that touch your source code. Code review platforms, static analysis tools, and AI coding assistants often require read access to your repositories. If their security posture is fabricated, your code is exposed.
The Compliance Automation Problem
Delve is not the only compliance automation platform. The market includes Vanta, Drata, Secureframe, Thoropass, and others. These tools promise to streamline compliance by automating evidence collection, monitoring controls, and connecting companies with auditors.
The legitimate ones add real value. Automating evidence collection for a team that actually has security controls in place saves hundreds of hours.
The risk emerges when automation replaces implementation. When a platform generates the evidence itself rather than collecting evidence of real controls, the entire audit becomes a fiction. The company gets a certificate. The auditor gets paid. The customers get nothing.
This is not a problem with compliance automation as a concept. It is a problem with specific actors exploiting the gap between what a certification implies and what it actually verifies.
How to Actually Verify a Tool's Security Posture
If you are evaluating developer tools - especially ones that access your code - here is how to go beyond the badge:
1. Request the Full SOC 2 Type II Report
Any legitimate vendor will share their SOC 2 report under NDA. If they refuse or only offer a "summary," that is a red flag. The full report should include:
- The auditor's opinion letter
- A description of the system and its boundaries
- The specific controls tested
- The test results, including any exceptions or failures
- The observation period (should be at least 6 months for Type II)
2. Verify the Auditing Firm
Check if the auditing firm is a licensed CPA firm registered with the AICPA. Look them up on the AICPA's firm directory. A legitimate SOC 2 audit must be performed by a CPA firm. If you have never heard of the firm and cannot find them in the directory, investigate further.
3. Look for Type II Over Type I
SOC 2 Type I is a point-in-time snapshot - it says "the controls were designed properly on this date." Type II says "the controls operated effectively over this period." Type II is significantly more meaningful because it requires sustained compliance, not just a one-day performance.
4. Check for Exceptions in the Report
A clean SOC 2 report with zero exceptions across every control is actually somewhat unusual and could indicate a superficial audit. Real audits often find minor exceptions that the company has remediated. The presence of exceptions (with remediations) can actually indicate a more thorough audit.
5. Evaluate Security Independently
Compliance certifications should be one data point, not the entire evaluation. Also consider:
- Security documentation - Does the vendor publish a security whitepaper or maintain a detailed security page with specifics, not just badges?
- Vulnerability disclosure program - Do they have a responsible disclosure policy or bug bounty program?
- Incident history - How have they handled past security incidents? Transparency matters more than a clean record.
- Data handling - Where is your code processed and stored? Is it used for training? What is the retention policy?
- Access controls - What permissions does the tool actually need? Does it follow least-privilege principles?
What This Means for the Dev Tools Ecosystem
The Delve allegations highlight a systemic vulnerability in how the software industry evaluates trust. We have collectively outsourced security evaluation to certifications, and those certifications are only as good as the audit behind them.
For dev tool vendors, the lesson is straightforward: invest in actual security, not just the appearance of security. A compromised certification is a ticking time bomb - when it unravels, the reputational damage is catastrophic.
For developers and engineering leads evaluating tools:
- Do not treat compliance badges as proof. They are a starting point for investigation, not a conclusion.
- Read the actual reports. SOC 2 reports exist to be read, not just referenced.
- Verify the auditor. Five minutes of checking the auditing firm's credentials can save you from trusting a rubber-stamped report.
- Evaluate security holistically. How a company responds to security questions tells you more than what badges they display.
The tools that handle your source code deserve the same scrutiny you would give to any critical infrastructure dependency. A compliance badge should open the conversation, not close it.
The Bigger Picture
This is not just about Delve. The compliance automation industry has grown rapidly, and the incentive structure is fragile. Companies want certifications fast and cheap. Platforms compete on speed and price. Auditors face pressure to approve.
When the incentives all point toward faster and cheaper certifications, corners get cut. The Delve investigation may be the first major public exposure, but it is unlikely to be the last.
As developers, we are in a unique position. We understand systems, trust boundaries, and the difference between security theater and actual security. Apply that same rigor to the tools you choose to trust with your code.
Frequently Asked Questions
What is SOC 2 compliance?
SOC 2 is a security framework developed by the AICPA that evaluates how a company handles customer data across five trust principles - security, availability, processing integrity, confidentiality, and privacy. An independent auditor must verify controls before issuing a SOC 2 report.
Can a SOC 2 report be faked?
Yes. As the Delve investigation shows, some compliance automation platforms allegedly pre-populate audit evidence, use non-independent auditors, and generate rubber-stamped reports. Without proper verification, a SOC 2 badge on a website can be meaningless.
How can I verify if a tool's SOC 2 certification is real?
Ask the vendor for their full SOC 2 Type II report (not just a badge). Check the auditing firm's credentials on the AICPA website. Look for a Type II report that covers at least 6 months of observation, and verify the auditor is a licensed CPA firm with no conflicts of interest.
What is the difference between SOC 2 Type I and Type II?
Type I evaluates whether security controls are properly designed at a single point in time. Type II tests whether those controls actually operated effectively over a period of 6 to 12 months. Type II is significantly more rigorous and trustworthy.
Should I stop trusting compliance certifications entirely?
No. Legitimate SOC 2 and ISO 27001 certifications remain valuable signals. But they should be one input among many. Verify the auditor, read the actual report, and evaluate the vendor's security practices independently rather than relying on a badge alone.
Originally published at aicodereview.cc
Top comments (0)