 Hi everyone. Thanks for joining. I'm John Amaral, co-founder and CEO of Slim.ai. Today I'll discuss an approach to frontline software supply chain security. This material is pretty high level and a conceptual overview intended for organizations, security practitioners, and software developers that want to manage software supply chain risk in their organizations, build a comprehensive automated software supply chain security program, and ship more secure, less risky applications to their production environments and consumers. I refer to this approach as the three S's of software supply chain security. The concepts are based on a blog post I published a while back. I've extended the agenda for this talk to include a bonus S, the fourth S of software supply chain security, just to keep things fresh and bring some newer observations on the topic to light. Software supply chain security has become a top of mind concern over the past year plus. There have been a number of high profile attacks, breaches and exploits directed at the global supply chain that made headlines due to their massive impact. The highly publicized SolarWinds attack and the log4j vulnerability are prime examples. These occurrences dramatically strained our ability to respond and they shine 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 the software we use today. In an age when every company is a software company, this is a risk 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 all in a very early phase of realizing implementing such solutions widely and effectively. The software supply chain is a truly modern marvel. Free and open source software is prolific, easily used and applied by millions of developers. As a result, speed of digital transformation and software innovation continues to increase exponentially. At the same time, software supply chain complexity, scale and risk increases proportionately. Today, it's really easy for a developer to incorporate vast libraries of code into applications, package it into containers and ship it to production with the click of a button. The code running in production is the child of a massive supply chain and 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 secure and make applications reliable. Write nothing, deploy nowhere. This idea is very 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 question, do we really know our software? Do we know how it was produced, secured and handled? Can we trust its authors? Can we trust the software is authentic? Is all the software rerun and production applications really needed to do the job? 3S's approach addresses these important questions about software supply chain security and the integrity of the software rerun. 3S's are S-bombs, signing and slimming and they represent key concepts in managing software supply chain risk. The first S is for S-bombs or a software bill of materials. S-bombs are lists of all the components in a piece of software with a special focus on open source and third party components. S-bombs are a necessary tool in the quest to know your software. The second S is for signing. Signing is a way to digitally attach a verified stable developer identity to a piece of code. Coupled with other tools, signing allows for creating a transparent, cryptographically secure record of software changes and it manifests a permanent reliable digital chain of custody for software and related artifacts. The third S is for slimming. Slimming is the process of minimizing the code footprint you ship to production in the form of containers and inherently reduces software supply chain complexity, software attack surface and aggregate risk. Let's dive into S-bombs. If you've been in the security or dev sec ops space in the past few years, you've probably heard the term S-bomb. Since S-bombs are the inventory of all the software components used across your organization, this enables security teams and developers to understand what third party resources and imports they're using. To protect your organization from threats, you have to know what's in your stack. Additionally, by providing all historical information that's managed by Git, S-bombs give you critical retrospective knowledge of what's running in your container in any given build. This allows you to take action when a vulnerability is discovered and understand how exposed your production systems were at any point in time. For example, in the log4j attack, companies that had S-bombs in place could much more easily take a complete inventory of their potential exposure. Further, S-bombs are an important basic tool used for describing a body of software dependencies. To produce an S-bomb, there are software tools that inspect software repositories and containers to create a digital record of all the packages and components they comprise. S-bombs can be aggregated to represent an arbitrarily large collection of software dependencies. In summary, S-bombs are the definitive software recipe for the software you ship and build. They're machine readable in any of several standard formats. Once your software is described by S-bombs and stored, you can continuously monitor the dependencies for emerging vulnerabilities, patch levels, and other supply chain-related risks. You'll often find S-bombs stored in an artifact repository, backed up to an S3 bucket, or hosted with a provider for quick access when the knowledge of what's in your container becomes mission critical. S-bombs are even required for any vendor selling software to the U.S. government by executive order. Even utilizing S-bombs has its shortcomings, though, which is why my approach is multi-pronged. To make sure you're covered from all angles, S-bombs can be considered a reactive approach to software supply chain security. Looking back at a nutrition label of what's in your container is more commonly done after attack and not a means to prevent them. From a well-rounded approach to security, we have to move on to the second S approach. Now, reviewing the pros and cons of S-bombs, the pros, it helps you know what's in your containers. It's like a nutritional label that gives you a historical record of all the composition, provides inventory for continuous assessment and improvement, and it is machine-readable. The cons are it's reactive. It can't predict what's coming down the road for changes. Maintaining it can be difficult over time because you build older versions and you get to manage revision histories and this large, ever-growing set of compositions, and there can be inconsistency between various tools that you'll have to reconcile. There's no one good answer yet, but for sure, incorporating S-bombs into your software life cycle security regime is an important first step. 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 is 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 software 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'll 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 technologies will be required to reach this reality. Today, the adoption of these systems is pretty low and the components are in their infancy, but strong momentum is building, including key vendors and organizations that govern and control large bodies of software. We have a lot of hope that this will become a pervasive system in our industry. One notable system that exists now is SigStore. There's a historical system called Notary, which is also used in certain places, but SigStore is gaining a lot of momentum for this area. Because this area of the industry is emerging, it's still uncertain which standard will prevail and a major downfall to relying solely on signing for software supply chain security. But, for example, we don't know how the public keys used to sign containers will be managed and distributed yet. There's universal consensus is that the signature will live as an artifact in a registry, but there's still debate over what format the artifact should take and how it should exist and be queried. So there's still a lot of work going on in understanding exactly how we'll interact with signatures, whether they be stored and in what form. And despite this and systems like SigStore that make signing easier, it's still a complex process to make changes to or revoke a signature. This coupled with the fact that it can't prevent vulnerabilities, makes it necessary to include the third S in the approach in your frontline software security, excuse me, software supply chain security plan. Again, pros and cons around signing. Pros, signing is a great trust foundation for the software supply chain. It helps you establish provenance of containers in your system, and new tools make it easier like SigStore. But it is also gaining support for a lot of major platforms including GitHub and AWS and others. Cons, trust doesn't imply need for software. So just because you can trust it doesn't mean you should use it. Alone, it doesn't prevent vulnerabilities like Log4j or even bad actor risk, where an actor would sabotage the supply chain, maybe even a malintended previously trusted author could inject some sort of software into the supply chain that causes a risk. And revocation and changes to this record can be complex. It's still uncertain which standard will prevail but there are some leaders in the clubhouse. As I mentioned initially, the safest software is the software you never ship. It's important to be sure that you're only running code or production that is absolutely required for your app or service to function properly and no more. It's typical today for organizations to deploy containerized software production with significant amounts of unnecessary software waste in the form of libraries, OS binaries, tools, package managers and more. Shipping any and running unnecessary code is costly, less secure and increases the operational complexity of maintaining your production software footprint. The more code you ship, the larger and more complex your effective supply chain is and this is why slimming is so important in managing your supply chain. Removing software from container images and from your supply chain in general is 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 including reduced vulnerabilities, faster CI CD cycle times, higher runtime efficiency, lower deployment and lower operational costs and reduced software risk service. Their 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 might contain libraries, test suites, tools, package managers, etc. The slimming process will remove these artifacts later to produce a minimal production ready image but developers get to use the images they want while they're building which makes them go faster. The pros to slimming reduced size and attack surface for containerized software which means less vulnerabilities and overall lower supply chain complexity and risk. There are added benefits to performance and even cloud costs. Smaller containers run faster and smaller footprints and your Amazon bills can actually go down because of it. The cons, slimming can be a complex expert process and can often add work for developers and it requires good test infrastructure to be able to automate this and get slimming to work automatically. The lesson to take away from SolarWinds and Log4J is that your third party and open source packages and imports are only one zero day exploit away from comprising, from compromising your entire production operation. Utilizing the 3S's approach where the whole is greater than the sum of the parts will help your organization achieve best practices for your shipped containers. But before we wrap up, I'd like to talk about that bonus S that I promised in the beginning. The bonus S is sharing. What do we do with all this security knowledge? Although it may seem counterintuitive to our natural inclinations, we must share our security findings and preventative measures openly across our industry. Keeping commonly accessible but difficult to reproduce security information, knowledge, and expertise concealed or unshared is counterproductive to our broader industry. To keep the industry moving forward and to avoid major attacks, we must share security information and approaches broadly. We need more sharing between organizations from CISO to CISO, open source software authored open source developer consumers, container maintainer to container user, and so on. That's why I'm speaking about this topic as often as possible. I recently added the bonus S to my 3S's approach to underscore how important it is that we engage in discussion and collaboration about software supply chain security issues across organizations, industries, and geographies. Sharing is even more important within organizations. As reported by SDX Central, Gardner research suggests that there's increasing awareness of the importance of communicating cross-functionally about security. In a recent Gardner report, it urges CTOs to work closely with CISOs, CIOs, or chief data officers to ensure they pursue the right specific technologies in those areas to further the strategies for cybersecurity and data analytics. They make it clear as a call to action. If you're going to be involved in cybersecurity and data analytics technologies, you need to engage in these kinds of dialogues. Gardner shows that only 52% of CTOs regularly engage with their organization CISO and only 29% regularly engage with their CTO. At my company, slim.ai will be sharing our learnings every step of the way. We seek to democratize container security information, make it easy for developers and container consumers to know what's in their public images they use. We invite and encourage developers to use and contribute to the Docker Slim open source project. At slim.ai, we also offer a solution to apply and automate the 3S's approach to help make it easier for companies to set up a first line of defense by implementing all of these S's including the 4th S. This includes software bill of materials that help you identify an inventory of what you know, help you have the ability to verify the packages and build immutable source code and containers, help you slim your containers and minimize the attack surface and be able to easily communicate and collaborate cross-functionally about software supply chain security within your organization and share your learnings within an ecosystem. We're trying to make it easier for companies to apply and automate these practices and their workflows. 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 container's file system, metadata, attack surface and history. This means less risk of shipping unneeded software, software that may contain vulnerabilities or compliance issues. Feel free to follow us and use our tools. They're free today. You can find us on Twitter, LinkedIn, through our Docker Slim GitHub repository, Discord and YouTube for our latest research, documents and resources. And you can certainly sign up and use our platform at portal.slim.dev. Thanks for joining me to learn about the 3S's plus the bonus S approach today. I know your time's valuable. I'd like to open it up for questions or comments as necessary. Thanks again.