The 3 S’s of Software Supply Chain Security: SBOMs, Signing, Slimming
One of the more infamous trends of 2021 was the exponential growth of software supply chain attacks, starting with Solar Winds and culminating with Log4j, with thousands upon thousands of lesser-known but similarly disruptive attacks in between. Needless to say, software supply chain security has been elevated to the list of top concerns of enterprise leaders today, as CTOs and CISOs the world over seek strategies and solutions to secure their infrastructure and software.
Kelsey Hightower, in his satirical GitHub Repo “No Code”, jokingly wrote that the safest way to ship code is to “write nothing; deploy nowhere.” While said in jest, he’s not entirely wrong: The safest software is the software you never ship.
Anyone who’s been anywhere near a gathering of tech leads has heard the phrases “ship more” and “ship faster” chanted repeatedly like a mythical incantation — so how can less be more when it comes to software development? After all, the world runs on software. It’s been 10 years since Marc Andreessen’s prescient article, “Why Software Is Eating the World,” gave us a prophetic view of digital disruption. Software-based and software-defined technologies are now saving the world, as Andreessen describes in his June 2021 follow-up article.
So, given the critical role software plays in sustaining humanity, what can we do today to address Software Supply Chain Security (SSCS)? At Slim.AI, the cloud native startup I founded with my longtime colleague and creator of the DockerSlim open source project Kyle Quest, we believe we must address the problem of WHAT gets shipped to production, not just how fast or how frequently teams can deploy. Addressing the problem of software supply chain vulnerability starts by building better software, and the people best able to secure the software supply chain are developers.
Thus far, three developer-driven approaches to SSCS have risen to prominence. As we call them at Slim.AI, the “Three S’s”: SBOMs (Software Bill of Materials), Signing, and Slimming.
Let’s take a quick look at the three S’s…
An SBOM, or software bill 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. U.S. President Biden’s Executive Order of May 12, 2021, requires any vendor selling software to the U.S. government to include an SBOM for each product. It won’t be long before other governments and enterprises around the world adopt the same requirement. Already, the Cloud Native Computing Foundation 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 is a way of digitally attaching a verified, immutable identity of a developer to a piece of code. 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. Similarly, if a piece of code is changed, the change is signed and the author of the change known. The intent of signing is to provide blockchain-like security and to verify an integrity path so that we know who changed what. Signing is not new, but anyone paying attention to the cloud native space has heard of the work the team at Project Sigstore (and the associated startup, ChainGuard) is doing in this space, and in 2022 we’ll see advancements in this area from several different technology perspectives.
Slimming is identifying what is in your software containers and minimizing the content to only that which is required to run in production, thereby minimizing attack surface. While this process is often manual, labor-intensive, and requires specialized knowledge, currently, we’re working hard at Slim.AI to automate these processes.
Slimming Is a Powerful Weapon in the Software Security Fight
SBOMs and signing are valuable and worthwhile security endeavors, and I believe they are critical pieces of the overall solution. Without slimming, the solution is incomplete. Whereas SBOMs focus on cataloging dependencies and signing focuses on verification, slimming focuses on reducing the attack surface, which helps with both known and unknown vulnerabilities (zero-day attacks). Slimming is the only technique that meets Kelsey’s tongue-in-cheek admonition that the safest software is the software you never ship.
In a recent article, John Carrier and Retsef Levi of MIT Sloan discussed systems thinking that seemed quite pertinent to the importance of reducing complexity to reduce risk.
Carrier pointed out, “Despite the sophisticated risk frameworks we’ve developed for handling large-scale projects, even in operations, we’re still suffering from the consequences of preventable incidents.” Doesn’t that describe the state of software supply chain security today?
Levi then advises, “Complex systems are inherently riskier; with that in mind, leverage technology to simplify a scenario rather than overcomplicate it.” (Emphasis added.)
That’s precisely what slimming is all about.
Ship Slimmer to Ship Safer
One of the core tenets of the physical supply chain can be paraphrased as: “The number of products you have on the shelf exponentially increases the complexity of your supply chain.” The same applies to the software supply chain. The more parts and pieces you incorporate into your software, the more complex your supply chain, and the more difficult it is to secure. That’s why reducing complexity should be a primary focus for today’s development, operations and security professionals.
That’s where slimming and Container Best Practices (CBP) come into play. The first CBP is to know or identify what’s in your containers. The next steps are to minimize image sizes, control vulnerabilities and secure services. (A great way to accomplish this is to use the free and open source tool DockerSlim.) Slimming not only removes the pieces you’re not using but also removes the vulnerabilities you don’t know about. The ultimate goal of container slimming is to create the minimum viable footprint (attack surface) to get the job done: less risk, better software.
my entrypoint calls “sh” btw … it hasn’t left sh arbitrarily , atho sh is the defacto entrypoint to many images
— Jeronimooo 🇦🇷 (@Whiletruedotrue) December 11, 2021
In 2022, we’ll see advancement in slimming technology, too. Within 18 months, developers will have access to automated tooling for container best practices. Developer teams will be able to summon their complete container inventory on demand; know what is in every container, always; and have immediate, team-wide access to vulnerability scans. More importantly, this automated tooling will live in an integrated system of change and integrate with container repos and CI/CD systems through APIs and built-in connectors.
It All Comes Down to Building Better Software
2021 gave us a shrill wake-up call on the importance of software supply chain security, and as a result, many brilliant minds are honed in on improving security processes and creating tools that developers can use to reduce risk within the software that runs our world. What inspires me most about these efforts is that there is no better way to reduce risk than to build better software from the very start — software that observes container best practices. By reducing complexity (shipping slimmer) developers can rest knowing their software not only is running better with lower overhead and operational burden but is also more secure.
