The Slim.AI Blog

The 4th S of Software Supply Chain Security

An approach to Front Line Software Supply Chain Security (SSCS).

John Amaral

Photo by Towfiqu barbhuiya (opens new window) on Unsplash (opens new window)

This past year we learned the hard way that your software supply chain is only as secure as its weakest link. A number of high-profile attacks, breaches, and exploits directed at the global software supply chain made headlines due to their massive impact. The much-publicized Solar Winds attack and the Log4J vulnerability are prime examples. These attacks shined a spotlight on the risk of future attacks and raised serious questions about how we secure the vastly complex global software supply chain that underpins all software.

The Good News/Bad News of the Software Supply Chain

The software supply chain is a modern marvel. Free and Open Source software has proliferated and is easily used and applied by millions of developers. The speed of digital transformation and software innovation continues to increase exponentially as a result. Likewise, software supply chain complexity, scale, and risk increase proportionately. Today, it's really easy for developers to incorporate vast libraries of code into applications, package that into containers, and ship to production with the click of a button. The code running in production is the child of the massive supply chain that birthed it. It bears the benefits and risks of all the decisions, contributions, features, and flaws manifested by its creators in aggregate.

Kelsey Hightower said in his popular parody GitHub project “No Code” (opens new window): “No code is the best way to write secure and reliable applications. Write nothing; deploy nowhere.” This idea is so relevant today, in an age where it's common to ship so much code to production, so fast, and with apparently so much risk. It begs the questions: Do we really know our software? Do we know how it was produced, secured, and handled? Can we trust the authors? Can we trust that the software is authentic? Is all the software we run in our production applications really needed to do the job?

In an age when every company is a software company, this is a risk far too great. Software developers, security practitioners, open-source foundations, government, and industry leading companies have scrambled to create solutions and approaches to addressing this risk. But we are in the very early phases of realizing and implementing these solutions widely and effectively.

So what can we do to build a first line of defense?

If you want to manage software supply chain risk in your organization, I’d like to suggest an approach you can use to build a comprehensive, automated software supply chain security (SSCS) program and ship more secure, less risky applications to your production environments and consumers. It’s an approach I call “the Four Ss,” and it comprises these elements:

  1. Software Bill of Materials (SBOM): A “software bills of materials” is a list of all the components in a piece of software, with a special focus on open source and third-party components. SBOMS are a necessary tool in the quest to “know your software.”
  2. Signing: Signing is a way of digitally attaching a verified, immutable developer identity to a piece of code. Coupled with other tools, it allows for creating a transparent, cryptographically secure record of software changes and manifests a permanent, and reliable digital chain of custody for software and related artifacts.
  3. Slimming: Slimming is the process of minimizing the code footprint you ship to production in containers. This inherently reduces software supply chain complexity, software attack surface, and aggregate risk.
  4. Sharing: No one person and no one organization can provide a comprehensive SSCS solution. Communication about SSCS and collaborating on solutions both within and among organizations is essential to advancing the industry and protecting our software-reliant global ecosystem.

I have shared my thoughts about the Three Ss in recent articles (opens new window) and presentations, but I’m convinced that the fourth S—sharing—is just as important to building a first-line defense, so I’ve added it to the model.

Let’s look at each of these Four S's in more detail.

SBOMS

SBOMs are an important basic tool used for describing a body of software dependencies. They are produced using software tools that inspect software repositories and containers to produce a digital record of the packages and components they comprise. SBOMs can be aggregated to represent an arbitrarily large collection of software dependencies. They are the definitive software recipe. SBOMs are machine-readable in any of several standard formats. Once your software is described by SBOMs and stored, you can continuously monitor the dependencies for emerging vulnerabilities, patch levels, and other supply chain-related risks. SBOMs are required for any vendor selling software to the U.S. government by Executive Order (opens new window). The CNCF is teaming up with industry to bring more standardization to SBOMs. In 2022 and beyond, we’ll see advancement in the tooling and standards for SBOM development and for dynamic management of SBOMs as well.

SIGNING

The purpose of signing is to provide cryptographic proof that the author is who they say they are and that the code has not been changed or corrupted since it was signed. If a piece of code is changed, the change is signed and the author of the change known. This concept extends to automata that build and process software. In an end-to-end system, signed code and artifacts are recorded along the supply chain in a transparent record. Downstream systems that build from signed software programmatically interact with this record to ascertain the integrity and provenance of the software. This pertains to the full extent of the contributing upstream dependency chain assuming the record is complete and intact. In the future, we will rely on signing (and related systems ) as a root of trust for all software dependencies. No software will be consumed, deployed, or run where provenance is ambiguous or unknown. Significant adoption of such technology will be required to reach this reality. Today, the adoption of such systems as described is low and the components are nascent. But momentum is building. Two primary signing systems you may want to explore are Sigstore and Notary.

SLIMMING

As I mentioned earlier, the safest software is the software you never ship. It's important to be sure you are only running code in production that is required for your app or service to function properly, and no more. Organizations today typically deploy containerized software to production containing significant amounts of unnecessary software waste in the form of libraries, OS binaries, tools, package managers, and more. Shipping and running unnecessary code is costly, less secure, and increases the operational complexity to maintain your production software footprint. The more code you ship, the larger and more complex your “effective” supply chain.

Removing software from container images has historically been manual, labor-intensive work that requires specialized, expert knowledge. By contrast, slimming programmatically and automatically removes unnecessary code from production images during the CI/CD build phase of production image creation. Slimming containers has multiple significant benefits that include reduced vulnerabilities, faster CI/CD cycle times, runtime efficiency, lower deployment times, operational costs, and reduced software risk surface. There is a significant developer experience benefit from slimming as well. Since slimming occurs in the production build phase of the container lifecycle, developers are free to use images locally that best suit their experience, velocity, and productivity. These development images may contain libraries, test suites, tools, package managers, etc. The slimming process will remove these artifacts later to produce a minimal, production-ready image.

SHARING

What do we do with all of this security knowledge? Although it may seem counterintuitive to our natural inclinations, we need to openly share our security findings and preventative measures. Keeping SSCS knowledge and expertise to ourselves is not doing any favors for the development and broader security ecosystem. To keep the industry moving forward and to avoid major attacks, we cannot keep this information gated.

We need more sharing between organizations, CISO to CISO, open source software author to software developer consumers, container maintainer to container user, and so forth. That’s why I’m writing this blog and speaking about this topic in conferences (opens new window) as often as I can. As mentioned above, I recently changed the “Three Ss” to “Four Ss” to underscore how important it is that we engage in discussion and collaboration about SSCS issues across organizations, industries, and geographies. At Slim.AI, we’ll be sharing our learnings every step of the way. I invite you to read our blog (opens new window), visit our website (opens new window) and follow us on Twitter (opens new window), LinkedIn (opens new window), Discord (opens new window), YouTube (opens new window), Twitch (opens new window) and GitHub (opens new window).

The same mandate for sharing is even more important within organizations. As reported by SDxCentral (opens new window), Gartner research suggests that there's increasing awareness of the importance of communicating cross functionally about security:

…Gartner urges CTOs to work closely with CISOs, CIOs, or chief data officers (CDOs) to make sure they pursue “the right specific technologies in those areas to further the strategies for cybersecurity and data analytics,” [said Gartner analyst Samantha Searle.] However, Gartner data shows only 52% of CTOs regularly engage with their organization’s CISO, and only 29% regularly engage with their CDO. “There’s a clear call to action. If you’re going to be involved in investing in cybersecurity and data analytics technologies, you need to be engaging with these kinds of dialogues,” she said.

In summary, the lesson to take away from Solarwinds, CodeCov and Log4j is that your third-party and open source packages and imports are only one zero-day exploit away from compromising your entire production operation. But you can set up a first line of defense by implementing the Four Ss:

  1. Software Bill of Materials (SBOM): Identify your inventory and know what you need to secure
  2. Signing: Verify your packages and build an immutable identity
  3. Slimming: Slim your containers and minimize the attack surface
  4. Sharing: Communicate and collaborate cross functionally about SSCS within your organization and share your learnings with the ecosystem

We’re trying to make it easier for companies to apply and automate these practices in their workflows. At Slim we offer solutions and tools to help you better understand your software, remove vulnerabilities, and ship only what's needed to production. The current Slim.AI container profiles give information about the containers’ file system, metadata, attack surface, and history. This means less risk of shipping unneeded software — software that may contain vulnerabilities or compliance issues.

Slim.AI is seeking to democratize information about containers and make it easy for developers to know what’s in their software. We invite and encourage developers to use and contribute to the DockerSlim open source project (opens new window), and contact us (opens new window) to get access to our software supply chain security early access program where you can see the 4S's in action.

If you’re interested in learning more, drop me a line on Twitter (opens new window) or LinkedIn (opens new window).

Related Articles

See All Articles