Compliance as a runtime problem

Let’s try a thought experiment: I’m a customer who has been burned by a bad vendor, and you’re a competing vendor trying to sell me your service.

My previous vendor had all the required certifications and claimed my data was encrypted before being stored.

It wasn’t, and it leaked.

Overnight, my competitors became more capable. I was humiliated in the press. Lawsuits are ongoing.

With that in mind, what can you give me to back up the claim that your service is doing “the right thing”?

• Policy and audit documents? That’s what I got from my previous vendor. How do I know your system hasn’t changed its security posture since the last audit?
• Source code? How will I know it matches what is deployed in production? A git hash or version tag isn’t going to cut it.
• Logs? How do I know they haven’t been tampered with?

I won’t fault you if you don’t have a concrete answer, the problem cuts across a lot of layers.

But what intrigues me is that as developers, we know exactly what our programs should be doing and we have a ton of tools to make sure they do. Type systems, test suites, build pipelines etc.

We know technical guarantees are valuable. Yet, we don’t provide many of them to our end-users. As soon as a system is in production, we ask users to take our word for it that a system behaves like it should.

Every organization that handles sensitive data will have a stack of compliance documents describing their systems and processes.

Privacy policies, data processing agreements (DPAs) with vendors, internal security policies, SOC2 reports, pentest reports. In regulated industries you’ll find a dozen more.

You’ll likely have seen some of these claims in marketing material as well.

Even if we assume trustworthy authors, such documents suffer from the same issue that all documentation suffers from: the actual system can silently drift from what’s described.

For example, during a busy period, a last-minute decision is made to integrate with a third-party API. The development team fails to notify the document owners, and now the privacy policy is missing a subprocessor.

Periodic reviews and audits might catch some of these issues, but they’ll often miss things and are inherently after-the-fact.

This is a less-than-perfect situation and it’s easy to dismiss the entire thing as “compliance theater” or “a legal concern, not a developer concern”.

It’s very much our concern though, we’re the ones building the systems that adhere to these claims.

So, let’s view this problem through developer goggles and see where we end up.

Enforcing policy at runtime

Many of the system-related claims are code-shaped: They describe how, why and when data flows through the system.

What if we could take these claims and:

• Put them in a structured policy document that describes the claims that apply to a system.
• Enforce them at runtime, such that violations are impossible.
• Externally verify them by ensuring a system is built with a particular policy and enforcement-runtime.

If the runtime is implemented correctly, the policy describes the maximum the system can actually do, not just the minimum it promises. Going back to our earlier example, the system can’t send data to the third-party API unless it’s listed in the policy.

This would give much stronger guarantees than the current “take our word for it” approach.

I’ll go into more detail in the next post, but using commodity Confidential Computing hardware and an attestation process potentially anyone can verify that a node is running expected software and policy before they exchange any sensitive data with that system.

This same tech could be used by auditors and system operators to cryptographically link documents, reports and logs to the systems that produce them. Essentially forming a verifiable historical record of the system over time.

In future posts we’ll see how this works in more detail.

I’ll go over (in no particular order):

• What kind of claims can be verified this way.
• How hardware and a small runtime can give us a verifiable foundation.
• How verification works.
• What a policy document would look like.

More information soon :)