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”: “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:
I have shared my thoughts about the Three Ss in recent articles 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. 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.
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 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, visit our website and follow us on Twitter, LinkedIn, Discord, YouTube, Twitch and GitHub.
The same mandate for sharing is even more important within organizations. As reported by SDxCentral, 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:
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, and contact us 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 or LinkedIn.
We're excited to share some big news from Slim.AI. We're taking a bold new direction, focusing all our energy on software supply chain security, now under our new name root.io. To meet this opportunity head-on, we’re building a solution focused on transparency, trust, and collaboration between software producers and consumers.
When we started Slim.AI, our goal was to help developers make secure containers. But as we dug deeper with our early adopters and key customers, we realized a bigger challenge exists within software supply chain security — namely, fostering collaboration and transparency between software producers and consumers. The positive feedback and strong demand we've seen from our early customers made it crystal clear: This is where we need to focus.
This new opportunity demands a company and brand that meet the moment. To that end, we’re momentarily stepping back into stealth mode, only to emerge with a vibrant new identity, and a groundbreaking product very soon at root.io. Over the next few months, we'll be laser-focused on working with design partners and building up the product, making sure we're right on the mark with what our customers need.
Stay informed and up-to-date with our latest developments at root.io. Discover the details about the end of life for Slim services, effective March 31, 2024, by clicking here.
We're excited to share some big news from Slim.AI. We're taking a bold new direction, focusing all our energy on software supply chain security, now under our new name root.io. To meet this opportunity head-on, we’re building a solution focused on transparency, trust, and collaboration between software producers and consumers.
When we started Slim.AI, our goal was to help developers make secure containers. But as we dug deeper with our early adopters and key customers, we realized a bigger challenge exists within software supply chain security — namely, fostering collaboration and transparency between software producers and consumers. The positive feedback and strong demand we've seen from our early customers made it crystal clear: This is where we need to focus.
This new opportunity demands a company and brand that meet the moment. To that end, we’re momentarily stepping back into stealth mode, only to emerge with a vibrant new identity, and a groundbreaking product very soon at root.io. Over the next few months, we'll be laser-focused on working with design partners and building up the product, making sure we're right on the mark with what our customers need.
Stay informed and up-to-date with our latest developments at root.io. Discover the details about the end of life for Slim services, effective March 31, 2024, by clicking here.
