Delve - Fake Compliance as a Service - Part I

How Delve managed to falsely convince hundreds of customers they were compliant and then lied about it when exposed and called out

DeepDelver

80% of Compliance has always been a performative box checking exercise.

They delivered the product that every company wanted - make the box checking faster.

There is a legal liability that comes with the bow checking. Nobody cares about box checking. Everyone cares about legal liability.

Nah. I’m gonna name some names.

I had a client in the compliance space - they handle detailed product information for Apple, Boeing, BAE systems, Philips, Siemens - you know, nothing important, just literally classified material and incredibly sensitive corporate material.

Anyway. We did ISO27001. We did it well, audited by Lloyds register, reputable stuff all the way down. Built actual meaningful processes.

Anyway, a massive PE entity bought them in a hostile takeover, fired everybody, binned the ISMS, moved to some “compliance” goons.

I saw the box ticking chicanery as it happened - as after firing everyone they of course didn’t follow the off boarding process, so I retained full access to their JIRA. I only lost access a year later when atlassian terminated the account for non-payment.

Nobody actually gives a shit, about anything.

Until someone rich and powerful gets ripped off -- then, suddenly, lots of people care a lot.

Yeah - probably. Didn’t Microsoft have Chinese engineers work classified government stuff?

I guess if you have the muscle to brush off legal action from the govt you’re ok. If you’re an unsuspecting startup - that could be a problem.

> I’m gonna name some names.

*Doesn’t name any names.*

Not that I want you to, I feel it would open you up to libel exposure. But can we both acknowledge that you didn’t name the entity that coasted through their audit?

I did, and then I thought twice. Let’s say it’s a synonym for a piece of non-reflective geology.
He didn't say when he was gonna name some names.
He technically did name many names:
> Apple, Boeing, BAE systems, Philips, Siemens

>Nobody actually gives a shit, about anything.

That's the case until there is the threat of discovery. The real issue is if the PE firm bought the company for the value of the IP and any damages awarded was included in the 'cost of business', which is why liability needs to be extended to those persons who make that decision, not just the corporate entity.

These days, nobody cares about legal liability, which is the likelihood of losing a lawsuit if there's a lawsuit, either. They only care about actual lawsuits against their company. They have noticed they're pretty rare and if the company's going to go under it's going to go under anyway, so might as well take the extra profits from not worrying about it

If someone checked one box, and the company goes under because of a lawsuit linked to not doing what this box said, then the individual who checked that box becomes personally liable of the damages done to the shareholders asset (the value of the company).

You don't want to be in this position, really. And that's the whole point of compliance.

Maybe. If their boss told them to do it and their boss is the CEO, probably not. It's on the prosecutor to prove the individual employee committed a crime worthy of piercing the corporate veil.

> If their boss told them to do it and their boss is the CEO, probably not

Then it becomes the CEO who's responsible. “Compliance” is there to protect the shareholders!

In practice the only liability you might wind up with is whether you technically met the conditions for checking the box (instead of just checking falsely). But the liability for the overall consequences of not doing the actual job the checklist sets out to do tends to stay where it is.
That’s a separate excercise in most cases. Obtaining the cert is it’s in excercise and not sticky a security excercise
Small businesses very much like to gamble with the box checking.
Okay, so who are we supposed to go to for SOC 2 compliance now if any number of the compliance automation companies might be charging 5 figures to do it fradulently?
If you want to do it right, hire a CPA who takes it seriously and spend the time to complete it in-house and fully understand it. Then engage one of the big 4 to sign off on it. The big 4 don’t offer much for SOC2 above what Delve does, it’s all smoke and mirrors unless you personally take it seriously.

Pay to play and keep selling. Understand the liabilities and cover your ass, address the biggest risks.

The point of SOC2 is really demonstrate that you have controls. The other fake compliance areas are scarier for sure. You used to see really blatant issues — I recall early SaaS companies pitching to my enterprise with sales engineers showing me customer data.

Microsoft refused to provide diagrams to the Feds detailing how Azure works. They got the FedRAMP High stamp anyway, because they already sold it to half the Fed. That’s more real… as a situation where a Chinese hacker could compromise data in a dedicated “government cloud” by compromising a certificate in an onprem dev environment should be impossible… yet it happened.

Big four have been caught approving fraudulent accounts too, so why not SOC? :)
Last time I went through SOC 2 we talked to our auditor about this. His view was that there are and basically always have been auditors/companies that will sign off on anything without verifying it if you're paying them. The rest of the industry knows who they are though. If you are taking things seriously and hire an auditor who does, that's one of the things that they look at when you're reviewing the reports from the services/subprocessors that you use. Ie, you can get a SOC 2 that doesn't mean anything but then any of your customers who know/care will flag it and it won't be worth anything.

From the article, OP dealt with this.

> But what do you do when the enterprise you are selling to asks you to show that pen-test report (which you never did despite paying for it, because Delve told you a pentest-tools.com vulnerability scan sufficed)? When they ask for your most recent risk assessment, do you just screenshot Delve’s pre-fabricated assessment and pray nobody will pay attention?

> It was that point where the realization sank in. We knew we messed up. We were unable to answer most questions honestly without jeopardizing the deals we were trying to land. We scrambled to get things done the proper way outside of Delve, in an effort to pretend to know what we were doing, but it ended up simply being too much work to get done quickly enough to save things.

> 80% of Compliance has always been a performative box checking exercise.

You're making the same mistake as most people do: it's 80% box checking but that doesn't make it performative, the box checking is here so that the dude who checked the box become legally responsible for what's happening if they haven't done what they said they did.

If you didn't check that box you could always claim you didn't know you weren't supposed to do what you did. As soon as you've checked “yes, I'm doing things in the approved way”, this excuse disappears.

> the box checking is here so that the dude who checked the box become legally responsible for what's happening if they haven't done what they said they did.

Maybe so, but how often are small companies actually sued for compliance survey misrepresentations? My most positive look at such surveys, after filtering out all the nonsense, is sometimes they flag something we've missed in our self-directed efforts.

Not really, and I kinda envy you that you haven't really worked up close with compliance-related people.

A lot of compliance is basically corruption - while in country A, you might fall out of a window if you don't buy from the right people at 10x prices, but in 'civilized' country B, you have to buy from vendor X (who has the necessary paperwork), at 10x prices, or you wont be able to sell the product - and there are a million ways that they can turn the levers to kick you out of their markets, or at least make you pay protection money to these compliance organizations.

The systems of grift are very sophisticated, and very obvious to anyone but the people perpetuating and participating in them. As they say,iyt is difficult to get a man to understand something, when his salary depends upon his not understanding it.

A lot of compliance software is griftware - Sonarqube is a prime example - most engineers don't think it adds value, and the 'analysis' it produces is incredibly shoddy, but like a lot of cybersecurity products, it relies on a authoritarian company culture, certification TP conditional on using the software and achieving a good score etc and alarmist language with nice dashboards. A classic example, is it tags public fields in Java as a security issue. And then the management see that you are writing 'insecure code'.

And literal mouthbreathing idiots in upper management eat this shit up, or use it as a punitive measure against the devs who by their very nature do all the meaningful work.

I'm not saying all compliance is worthless, but if you approach quality from first principles, a 'compliant' product usually has to clear a very low bar of quality. And compliance usually keeps the quality low, and prices high, by forcing potential competitors out of the market.

And compliance can keep quality low in other ways, I've seen firsthand - by making devs work on BS tasks, or preventing improvements and fixes to codebases, because they're not tracked appropriately by whatever change management system.

I was incredibly wary of doing hacky solutions in these places, not out of a sense of commitment to quality, but the fact that once management sees your hacks WORK (kinda), all requests to clean up the garbage will be stonewalled.

Thankfully LLMs make this busywork very easy, through making this papermill garbage, and nitpicking busywork very easy, which I feel will bring at least some positive change in the world (at least to those who do meaningful work)

Sonarqube did not flag public fields as a security issue by default the last time I used it — however it has found several real vulnerabilities for me before.

It did by default for me, and there are a bunch of other poorly implemented analyses, such as it incorrectly flagging Dictionary keys in C# as mutable, or opinionated stuff like it disliking certain names and patterns, forcing me to make arbitrary changes that often cost performance, readability or API cleanliness.

Or insane stuff like it doing a blanket-ban on security related code in the app (but importing a third party lib that does the same is fine).

The analyses in general are low quality and you can see not a lot of effort or thought went into them.

They are not the product - compliance, and dashboards for boomers is.

I'm curious about what did it detect for you? In my experience it stops very obvious bad patterns like using string manipulation to submit SQL (which in certain circumstances might even be fine, even necessary), but it can't really trace non-obvious security issues (like tracing a value through the code, making sure its valid on every codepath), it just doesn't have the compiler machinery to do that.

There is no relation between checking a box and becoming legally responsible for the vast majority of certifications.

The company may be legally in troble if the planets are aligned but that's all.

Compliance is crazy sucky - I remember there being a case when one of our vendors was harvesting data like crazy, and we went after them. It was grossly in violation of GDPR, like as bad as it could get.

When we reached out to them, they showed us a cert about how they were GDPR compliant, issued by a huge brand-name consulting firm.

In the paper they said they implemented certain standard-mandated cryptographic measures to 'anonymize' the data. Thing is, they implemented them wrong on purpose, so that they could actually identify users by inverting hashes with a rainbow table.

There was a lot of BS legal reasoning in there but the bigname firm signed off on it. Oh and at the bottom, it had a provision, that if the company were to be sued for breach of GDPR, the consluting firm would not be liable any way.

But this was good enough for tons of companies and govt agencies to just use that software.

So that's what compliance certs get you.

Yes, I know it first-hand.

At least in cybersecurity, there are no certifications that "certify" that you are secure. There are plenty of them that will assess your processes, their execution, etc., but the reality of the risk is next door. This is typically the case for ISO 27001, which has ISO 27002 (the ex British Standard from the 90s) that theoretically governs the controls you should have in place. But it simply does not work.

When you have a major leak, this is usually a company with half a page of certifications, but, hey, mistakes happen. The key problem that these mistakes come from is a fundamentally wrong approach to cybersecurity, but nobody cares.

Maybe like 40%, but also just check if they got a manual pentest.

That’s the only actual audit on “security”.

AI pentesting is just another SaaS.

Delve tried to automate the CPA, you can’t automate the audit. Same goes for the penetration test.

I’d be amazed if the companies were entirely oblivious to this.

In my experience it’s we know that they know that we know that they know …..