An easier road to SOC 2 begins with the right approach — and the right technology

I like to think about SOC 2 as a beneficial network effect.

‍

There’s a viral element to it, which is key to its success: A company has to review its vendors and collect their SOC 2 certification information, so if one company is certified, there’s more pressure on their partners to be certified, too. Becoming SOC 2 compliant requires a company to think deeply about their commitment to their security posture and prove that commitment over time. The in-depth process leads a company to take those with SOC 2 more seriously.

‍

Released by the American Institute of Certified Public Accountants (AICPA) in 2010, SOC 2 certifies an organization’s Trust Services Criteria (TSC): security, availability, processing integrity, confidentiality, and privacy. An independent auditor assesses the organization’s processes against a set of requirements, and since every business is unique, every audit will also be unique.

‍

There used to be very little standardization around security protocols, but we’ve all seen how a security breach can break a company. In 2022, the average cost of a data breach was $4.83 million, not to mention the loss of trust among customers and partners. That reality led to a slew of security questionnaires, with every company having their own priorities. But in the past couple of years, the landscape quickly shifted from having no standardization to rallying around SOC 2. Suddenly, there was something that made sense. Instead of filling out yet another 200-question form about your security protocols, you can just say, “We’re SOC 2 certified,” and everyone knows what that means.

‍

How Do You Become a Company That Other Companies Can Trust?

SOC 2 covers more than just the InfoSec policies. It’s an indication of overall trustworthiness. Questions like, “Do you conduct performance reviews?” aren’t typically a part of other InfoSec certification processes, nor do they usually require board meeting minutes. The idea is to establish whether a company is secure in its organizational processes and information handling. In that way, SOC 2 certification reveals more about a company than just its security posture — it’s an indication of a company’s overall strength. A company that can’t provide satisfactory answers to the audit probably isn’t thinking hard about their security, is more vulnerable to security breaches, and could, therefore, go under easily.

‍

SOC 2 compliance reveals more about a company than just its security posture — it’s an indication of overall trustworthiness and strength.

‍

That said, there’s a right way and a wrong way to do SOC 2. The wrong approach is to treat it like a checklist, going through the motions of ticking all the boxes to make the auditor happy. The right way is to look at the SOC 2 guidelines and understand the intent behind each requirement. There’s a requirement to implement a screensaver password, for example, but the policy doesn’t say anything about automatically logging into a computer once it’s turned on. If we understand the intent behind the policy, it’s clear you should always have a password to access a machine.

‍

Driving compliance is like having a big sledgehammer in your hands: You can get anyone to do anything in the name of compliance. Ask yourself: Are we just checking boxes, or can we seize the opportunity to get the most out of this?

For any company our size or larger, it’s clear: SOC 2 is the modern standard. Becoming certified is time-consuming, but if you don’t have it, potential customers will back off because of the increased risk on their end — it’s just getting too hard to sign deals without it.

‍

Chainguard’s Journey to SOC 2

We work in fortified software delivery and were eyeing SOC 2 compliance in its early days. Within a few weeks after I joined Chainguard, we knew we wanted to become SOC 2 compliant.

‍

You can get anyone to do anything in the name of compliance. But ask yourself: What can we do to get the

‍

I came to Chainguard after having worked at Google for 15 years. At Google, people had great ideas around open source and security, but there was never a consistency of effort to bring those ideas out into the world. At Chainguard, I saw the opportunity to take these ideas and run with them. Chainguard’s mission is to be the safe source for open source, bringing together open source software, supply chain security, and cloud-native development. I joined Chainguard to work on open source security, but it quickly became apparent that we needed someone to focus on InfoSec and compliance. I became that person, and SOC 2 became my primary project.

‍

There are two levels of SOC 2 certification:

• Type I evaluates a company’s controls at a single point in time, establishing that the company met all the requirements on a single day. It’s pretty lightweight from an auditing perspective, so few companies put a lot of trust in it.

• Type II requires a company to demonstrate those controls over time, typically three months to a year, with six months being the standard recommended period.

‍

Chainguard was already engaging in most of the correct security practices, and the compliance process required us to improve our policy and documentation, outlining our approach to matters like encryption, incident response, and remote work. I didn’t want those to be cut-and-paste policy documents, but assets that reflect our perspective as seasoned security engineers.

We received our Type I certification in about five months and launched into Type II shortly after. Demonstrating our adherence to these rules for six months meant tracking things like who had access to various company systems, what vulnerabilities we saw, and how we addressed those vulnerabilities. It was a lot of effort, but Chainguard Images made it much easier.

‍

Our Own Technology Eases the Lift

I’m a one-person InfoSec and compliance team, which means I have to be ruthless against sources of toil. One of the greatest sources of toil in InfoSec is reviewing common vulnerabilities and exposures (CVEs) and alerts, but using Changuard products means I have very few CVEs to manage in our production fleet.

‍

One of the greatest sources of toil in InfoSec is reviewing CVEs and alerts.

‍

Chainguard’s approach to vulnerability management and our development philosophy made our SOC 2 certification process a lighter lift. Even before we announced Wolfi, our own Linux (un)distro - we deployed all of our production apps using distroless images with the help of amazing open-source tools like ko.

‍

The idea around distroless images is simple: rather than including an entire Linux distribution in each container, only include the files necessary to run your application. Adopting a distroless philosophy reduces vulnerabilities by at least 99% — in both numbers and effort. Chainguard today has 66 applications deployed in production using container images. The average container image contains around 311 CVEs. With 66 applications, that’s roughly 20,500 vulnerabilities to track actively. That would take a massive effort to triage, research, and resolve — enough that it would require additional staff to manage. Most container image vulnerabilities are in unnecessary components, so the distroless approach helps massively. Instead of tracking 20,500 vulnerabilities, I'm only tracking 180 CVEs: that's more than a 99% reduction in scope and effort. None of these vulnerabilities originated from the base image.

‍

Another reason we have so few vulnerabilities is we are constantly rebuilding and pushing out the latest version of our software. Many companies have much slower software development iteration cycles, which causes vulnerability creep. Chainguard Images are rebuilt nightly, so it’s always built on top of the latest, most secure software. The process is made easier by Chainguard’s practice of reproducible builds. All the software we build is reproducible: If nothing changes between what we built today and what we build tomorrow, it will be bit-for-bit identical. That reproducibility creates a lot more trust in our systems because we can easily trace our component changes, and it helps us move faster.

‍

When undergoing the compliance process, these approaches allowed us to go above and beyond the expectations for SOC 2. You have to keep track of all the vulnerabilities and what you did about those vulnerabilities for several months. Because we were big believers in distroless, we had very few vulnerabilities, which made tracking much easier.

Another example of going above and beyond the SOC 2 requirements is around two-factor authentication. Requiring two-factor authentication seems reasonable, but some methods are better than others. We asked ourselves, “What is the strongest two-factor authentication?” Like other high-security organizations, we've rolled out phishing-resistant FIDO2 security keys, but unlike many of them, we require these keys to be used by all employees for all applications. There’s no known way to steal or spoof this authentication mechanism — and it’s just one of the ways Chainguard aims for the best in security.

‍

Recommendations for a Smooth SOC 2 Certification Process

Getting SOC 2 certified can be daunting, but there are some things to know at the beginning of the journey that should make the path smoother.

‍

• The most difficult part of SOC 2 is consistency. It’s one thing to define a process, but it’s tough to consistently follow that process and be accountable for making a paper trail. Chainguard uses Secureframe to help us track our compliance, but be aware that software packages such as this inject their own interpretation of SOC 2 requirements. Sometimes, their language can be oversimplified; other times, overcomplicated. Don’t be afraid to refer back to the AICPA’s Trust Services Criteria for clarity and intent. Despite what you might expect of a text written by accountants, it’s all in plain English.

• Don’t underestimate the importance of tracking user access across all your systems, not just the ones you know about. If you’re like me, you work in a company of bright, independent engineers who may adopt a system you’ve never heard of. If the auditor catches wind of such a system, they will ask you to produce the access record for that service. Talk to your colleagues about all the services they use and track them. That will save you any nasty surprises at audit time.

• Get everyone in your company on board. If you try to do everything yourself, you will fail. Open a dialogue across your organization and get your colleagues to share any security shortcomings with you. One of our biggest wins came when I started talking at company all-hands meetings about the SOC 2 certification process. I asked people to let me know if they saw anything I should know about. Sure enough, people would message me afterward on Slack and say, “Hey, did you know about this thing? I thought you might think this is important.” Making the process collaborative was a big key to our success.

• Pay attention to what motivates people to collaborate in this process. Put SOC 2 in purely technical terms, and people will question it or, worse, not pay attention. Explain SOC 2 in business terms that people can relate to, like the sales opportunities it unlocks, and you will get much better buy-in.

‍

Put SOC 2 in purely technical terms, and people will question it or, worse, not pay attention. Explain SOC 2 in terms people can relate to, and you will get buy-in.

‍

Honestly, SOC 2 may not be worth it for every company. Sometimes the effort is too great for the organization’s size, or they might just be finding their feet and it’s not on their radar yet. And maybe the system is biased toward those companies that have the resources to throw at certification.

‍

But I admit, I’m developing some biases, too. While I don’t immediately write off a company that isn’t SOC 2 compliant, I’m increasingly noticing that they haven’t thought through security as deeply as those who are. It’s a lot of work, but Chainguard is SOC 2 compliant, and we’re a stronger company for it.