Pedro Del Gallego- 01 Feb, 2023
Untangling Dependencies at Amazon
As companies scale, they slow down. Teams spend more time coordinating and less time building. Every new feature overlaps and intertwine with features … Read Article
Over the last decade, software developers have increasingly adopted open-source software to assemble their applications. Open software has become essential for teams to reduce time-to-value. Industry data suggests that between 85 to 97 percent of code in enterprise codebases comes from open-source packages and their nested dependencies. This network of software components and the tools used to build the software is what we call the software supply chain on an application.
Most companies have minimal visibility of the software they run in their environments due to the complexity of their software supply chains. Companies have solved a similar challenge in manufacturing using bills of materials (BoM). A bill of materials is a list of the items needed to create a product and the instructions for assembling it.
Imagine a LEGO boxset. Each box contains a booklet with the bill of materials for that set. A unique code identifies each brick type. The booklet also provides the instructions to build the model using the components from the list.
A software bill of materials (SBOM) is similar in nature. Essentially is a machine-readable inventory of all software components and dependencies utilized in an application. Software is becoming increasingly complex and increasingly composed. Without an SBOM, organizations lack visibility into the license and security risks associated with the software they are building or consuming.
Three benefits of software bill of materials
First, the primary purpose of using SBoMs is to identify vulnerabilities and license risks throughout the software supply chain. Software supply chain risks are inherited from the dependencies. If one of these dependencies has a vulnerability, the application will most likely have a vulnerability.
Second, a software bill of materials helps identify risks earlier in the software development process and improves the efficiency of developers.
Finally, a bill of materials adds another layer of depth for security. It provides records that track all software components that have been in production. SBOMs reduce the time needed to identify affected workloads and the mean time to recover from vulnerabilities.
Automating the software bill of materials validation is critical to detecting and remediating risks quickly
Organizations are adopting modern software delivery practices such as DevOps that help teams deploy frequently, some of them multiple times per day. Manual checks to discover vulnerabilities and license risks will not scale. Furthermore, manual auditing introduces friction in the delivery process and slows down teams. Generating and validating the software bill of materials on every software change as part of the CI/CD pipeline is crucial to keep up with rapid software development, in which components and their versions are swiftly changing.
BOMs are well-established in traditional manufacturing. Each production order creates a new bill of materials. A manufacturer uses a BOM to track the parts to create a product. If defects are later found in a specific component, the BOM makes it easy to locate all affected products. Organizations must treat their software environments with the same rigor. Each software release must create a new SBOM. If a vulnerability is found, the organizations must clearly understand what products were affected and for how long. Tracking and archiving all the changes in the software supply chain achieves this granularity level.
Updating the operating model is necessary to secure the software supply chain without affecting product teams
Securing the software supply chain is complex because it requires multiple parts of the organization to change how they work together. A cultural shift is needed in the security, compliance, and cyber functions. Instead of focusing on auditing, they should automate controls, provide policies as code, and self-service security products that integrate with the CI/CD pipeline, allowing product teams to ship software safely and independently.
| Security Roles | DevExp Roles | Product Teams |
|---|---|---|
| Understand the dependencies network and their risks, such as vulnerabilities and licensing restrictions. | Create a unified CI/CD pipeline to help product teams shift left security controls | Update to the latest functionality and security patches when a new security vulnerability is discovered |
| Determine external and internal security and compliance requirements | The CI/CD pipeline automatically generates, validates, and archives SBOMs for every software change | Use code and manifest files to define all the dependencies of the application (e.g., npm, maven, pip, terraform) |
| Implement as code the required controls to manage the dependencies risks | Provide reference artifacts and libraries that teams can utilize as the starting point | Each product team is responsible for ensuring that the SBOMs of their products are created |
Conclusion
Recent security events, including the Solarwind hack, the Log4Shell zero-day vulnerability, the publication of the Executive Order 14028 and the increasing adoption of OSS have brought the necessary attention to the security of the software supply chain.
(vii) providing a purchaser a Software Bill of Materials (SBOM) for each product directly or by publishing it on a public website;
Generating an SBOM is only one-half of the story. Organizations need to verify it against a list of known vulnerabilities to know which components could pose a threat, and it needs to happen for every software change as part of a CI/CD pipeline. Furthermore, when a vulnerability is discovered, companies need to be capable of understanding what components, when, and for how long they were affected.
Finally, organizations must establish a clear operating model that help teams working towards securing the software supply chain without affecting the velocity of product teams.
In future posts, I will continue exploring the necessary mechanisms and the operating model to secure the supply chain successfully.
