Over the past several years, there has been a notable surge both in the frequency and severity of Software Supply Chain attacks, with high-profile incidents such as SolarWinds and log4j capturing widespread attention. The repercussions of such attacks have prompted a proactive response from the U.S. government, including the issuance of Executive Order 14028, mandating Federal Agencies to enhance threat sharing capabilities, uphold up-to-date provenance, and fortify supply chain security. The executive order goes further by requiring federal agencies to request Software Bills of Material (SBOMs) and other attestations from vendors who sell to the government.
Expanding beyond federal agencies, certain utilities fall under federal government ownership and, therefore, must also adhere to these regulations. These mandates have had a ripple effect as regulators within the electric power sector subsequently issued supply chain guidelines recommending solicitation of SBOMs for critical software or the collection of attestations affirming adherence to secure development practices. The overarching objective is to uphold the security of critical assets within the electric power space and ensure a robust and resilient supply chain.
The landscape of software supply chain security is undergoing a paradigm shift, driven by the dual urgency of persistent attacks and a proactive governmental response. The collaborative efforts of entities like NIST, OMB, and sector-specific regulators underscore a commitment to fortifying the software supply chain and, by extension, safeguarding critical infrastructure and assets.
Transparency for Software Suppliers
Regulators are increasingly advocating for transparency in the software ecosystem, recognizing that both software producers and consumers, despite having distinct use cases, stand to benefit from improved visibility. A fundamental step towards achieving this transparency is the adoption of a Software Bill of Materials (SBOM).
An SBOM serves as a machine-readable inventory detailing the components within a piece of software, encompassing crucial information such as supplier names, component names, and versions. Beyond these basics, SBOMs can provide insights into relationships between components, licensing details, and the origins of each element.
During the software development lifecycle, SBOMs offer indispensable advantages for software producers. Particularly for those managing a plethora of products or engaged in large software projects, tracking the components which make up their products is a challenge. This is especially relevant in scenarios where a producer integrates proprietary code, open-source code, and third-party commercial code to craft their end product.
For example, software producers want to avoid incorporating components that are no longer supported by their maintainers. The consequences of relying on unsupported components are significant — they may cease to receive essential security fixes and updates. If a producer inadvertently includes such components in their software, it could lead to operational challenges. Addressing the situation is time-consuming and costly to pull out and replace the outdated elements and related components which depend on it. Furthermore, for supplier’s clients a vulnerability in the software that cannot be effectively mitigated may necessitate removing the product or device entirely, incurring substantial financial losses.
Forward-thinking software producers are already leveraging SBOMs internally as a proactive measure for tracking the components used to ensure compliance with licensing requirements. Additionally, these producers extend their reliance on SBOMs to interactions with their own vendors. By requesting SBOMs from suppliers, they gain a comprehensive understanding of the components being passed along to their clients. This practice not only aids in maintaining a clear inventory but also supports due diligence in terms of security, compliance, and overall software integrity.
Best Practices for Software Producers to Secure their Software Supply Chains
- Universal Adoption of SBOM
- Make Cybersecurity a Key Procurement Criteria
- Evaluate Open-Source Code and Product Risk
- Adoption of Secure by Design
Universal Adoption of SBOM: Effectively identify and mitigate risks
Modern development is characterized by the integration of components from diverse sources rather than relying solely on internally written code. Developers often pull in components from various origins, customize them, and combine them to create the final product.
Many developers, including ourselves, heavily depend on open-source communities where components are constructed through collaborative contributions from developers who may never have met. This distributed development model is instrumental in producing high-functioning software and expediting the development process.
However, a potential downside emerges when considering the sources of these contributions. Developers are integrating code from various origins, sometimes unknown, and subsequently passing along these contributions without rigorous security assessments. This increases the likelihood of building software that may be vulnerable and insecure.
Herein lies the significance of Software Bills of Materials (SBOMs). SBOMs play a pivotal role in promoting transparency into the components that drive your business operations. By providing a comprehensive list of components used in the software, SBOMs empower developers and organizations to gain insights into the origins and dependencies of their code. This transparency is essential for ensuring the security and integrity of the software being developed and deployed.
Make Cybersecurity a Key Procurement Criteria
This concept is centered around the necessity of acquiring transparency data to comprehend your organization's risk posture effectively. An opportune moment to request this critical information is during the presales cycle. This stage proves advantageous as vendors are typically more motivated when a potential sale is on the line. Seeking transparency data at this juncture not only assists you in making an informed decision about which product to choose but also signifies the vendor's willingness to share crucial insights.
When a vendor willingly provides transparency data, it serves as a positive indicator. This signifies a commitment to a new level of transparency and maturity in their Software Development Life Cycle (SDLC). By gaining access to this information, you can conduct a firsthand assessment of their software components. This includes identifying outdated elements and assessing the presence of high-risk vulnerabilities, among other factors.
It allows you to evaluate the vendor's commitment to security, the robustness of their development processes, and the overall health of the software they are offering. The transparency data obtained during the presales cycle becomes a valuable resource for aligning your organization with secure and reliable software solutions.
Evaluate Open-Source Code and Product Risk
Before pulling open-source software (OSS) dependencies or tools, you should first identify candidates and evaluate them against your needs and for security and sustainability.
For example, determining the maintenance status of the software. Actively maintained projects are essential, as they are more likely to receive regular updates and patches, reducing the risk of security vulnerabilities. Evaluating the history of the project provides insights into its stability – a well-established project with numerous releases may be more reliable than a brand new one.
Another consideration involves minimizing the addition of new components to your project. Each new package introduces dependencies, potential support challenges, and expands the attack surface. Exploring the feasibility of utilizing existing components, rather than adding new ones, can mitigate these concerns.
Additionally, assessing the project's code review practices is essential. While automated tests are valuable, human code review before merging pull requests enhances code quality and helps detect unintentional issues, reducing the likelihood of vulnerabilities caused by mistakes.
Understanding the project's contributors is equally important. Projects with diverse contributors from multiple organizations are often more robust and resilient. Examining the maintenance structure, including the number of maintainers and their workload, can provide insights into potential security risks. Changes in ownership also warrant attention, as a recent transfer may introduce uncertainties about future maintenance practices.
Adoption of Secure by Design
Implementing secure practices involves three core principles, each emphasizing the importance of integrating security into the fabric of product design and development. Recognizing that security is an ongoing journey, these principles encourage a proactive approach to security rather than reactive fixes after product release.
The first principle is taking ownership of customer security outcomes. This involves building products with security in mind, making security an integral part of the product's functionality, and adopting choices that lead to better outcomes for users. Emphasizing defaults based on the current threat landscape, like requiring multi-factor authentication for admin accounts, further enhances the product's security.
The second principle is embracing radical transparency and accountability. Transparency serves as a means of accountability and an incentive for improvement. For example, having Common Vulnerabilities and Exposures (CVEs) associated with your product can seem like bad thing. In reality, it indicates a robust testing community. Various avenues for transparency include publishing data on patching and update processes and maintaining accurate CVE entries. Additionally, having a vulnerability disclosure policy that allows testing against products promotes accountability.
Lastly, building the structure and leadership necessary to achieve security goals. Security initiatives must be integrated throughout the organization, with incentives aligning with security objectives. Incorporating secure-by-design efforts into annual financial reporting demonstrates a link between customer security and corporate financial outcomes. Boards play a pivotal role by seeking information on product security and its impact on customer security, emphasizing the importance of security beyond the realm of the Chief Information Security Officer (CISO). These three principles collectively form a comprehensive approach to fostering secure practices from product inception to organizational leadership.
Conclusion
The increasing importance of transparency in the software ecosystem, particularly through the adoption and use of Software Bills of Materials (SBOMs). Both software producers and consumers can benefit from SBOMs, as they enable more rigorous tracking and assessment of software components for security, compliance, and overall integrity.
Open-source coding has become an integral part of modern development, and the adoption of SBOMs is instrumental in safe guarding against the integration of insecure or vulnerable code within software products.
Furthermore, it's becoming increasingly important for software producers to make cybersecurity a key procurement criterion, ensure thorough evaluation of open-source code and product risk, and apply the principle of 'secure by design'. This approach stresses the importance of considering customer security outcomes in product development, fostering radical transparency and accountability, and integrating well-founded cybersecure practices from product inception to organizational leadership. By embracing these practices, software producers can not only mitigate potential risks but also align themselves with secure and reliable software solutions.
