Ship software to Uncle Sam faster with zero-known vulnerability containers

TL;DR: Using zero-known vulnerability containers could dramatically increase the speed at which software producers deliver software to the government, helping those companies make more money faster while enabling the digital capabilities for government agencies.

‍

If you and your company have been slowed down by onerous vulnerability management checklists while trying to deliver software to a government, you and your company are not alone. I know this because I previously worked at In-Q-Tel, an investor that aids startups breaking into the military, intelligence, and government market, and I observed that the software security process, better known as the “Authority to Operate” or ATO process, was a source of delay, anguish, and foregone dollars for many companies. A former In-Q-Tel colleague and I recently explored this in an article titled “Avoiding the Military’s Software Security Black Hole” that calls for systematic investigation into what can be done to make the ATO process both secure and fast.

‍

As part of that systematic investigation, here’s a thought experiment I would like to propose: have 100 companies going through the ATO process use Chainguard Images, container images designed to have zero-known or low vulnerability counts, and compare the known vulnerability counts, timelines and staff time cost of those 100 ATOs to 100 other randomly chosen ATO processes.

‍

My hypothesis: dramatically reduced software delivery timelines and staff time costs due to a radically lower count of known vulnerabilities.

‍

Let me explain.

‍

Onerous security process + vulnerability-ridden software = bad day

‍

It’s a common refrain that there are numerous causes for the slow timelines and heavy staff costs associated with government software security processes. Some parties finger too few staff performing too many software security reviews. Others point to a lack of automation. Still others argue that the security checklists are simply long. Some even point to a belief that security always beats out new technologies in government agencies and the slow ATO timelines are a result. These arguments are sensible, though it would be worthwhile to analyze them in depth. The article I mentioned earlier, for instance, calls for “ATO observatories” to analyze what the true causes of slow ATO processes are.

‍

But let me offer a complementary theory: the ATO process is slow when the government must comply with onerous security processes and when the software it intends to consume is riddled with known vulnerabilities. In other words, it’s not the process itself that is the problem. It’s that the process slows down dramatically and becomes more expensive when the software to be reviewed is overflowing with known software vulnerabilities. And this is the current case, especially with popular container images, a common way to ship and deliver software.

‍

Academic software engineering research finds that popular container images often have hundreds of known vulnerabilities. For instance, take NGINX, a popular web server container image. The latest Docker Hub version of that container image, as of June 9, 2023 (and using Grype, a popular open source container scanning tool) has 144 vulnerabilities.

‍

Using container images with hundreds of known vulnerabilities is a surefire method for slowing down the ATO process. Each known vulnerability must be documented. Each must be assessed in order to determine if the vulnerability is a true positive or a false positive. For those that are a false positive, the security officials must examine if the risk of exploitation is acceptable and if there are potential mitigations. If that sounds terrible, it’s because it is. This is why those 100 randomly selected ATO processes are going to be slow, staff intensive and involve lots of software vulnerabilities.

‍

Onerous security process + zero vulnerability software = much better day

‍

Admittedly, software providers can’t change the government’s software security process. It’s out of their control. But they can change the software they provide the government. In particular, software providers can use Chainguard Images, hardened container images with a minimal attack surface built by Chainguard.

‍

For instance, the same NGINX software mentioned earlier has a version available via Chainguard Images. As of June 9, 2023 (again, using Grype, the same scanner) there were zero vulnerabilities in the latest version of the Chainguard Images NGINX image. And Chainguard Images, which includes a public tier that enables free and open source use, cover many different programming languages, middleware, databases and other needs, too.

‍

Now, replay the security process, but with zero-known vulnerability containers. There’s no need to document vulnerabilities. There are significantly fewer or no known-vulnerabilities. There’s no need to determine if vulnerabilities are true positives or false positives. There is no need to assess risk and consider mitigations. For those 100 companies in this hypothetical experiment, zero-known vulnerability containers means radically faster security processes with far less staff time.

‍

Who’s afraid of a zero-known vulnerability container ATO (thought) experiment?

‍

Not us. If you or your company (or government agency) is interested in trying out Chainguard Images as part of accelerating software delivery to the government or to other regulated environments, please contact us. Software delivery to Uncle Sam doesn’t have to be so slow and painful.