US addresses securing software supply chain for managing open-source software, SBOM
U.S. security agencies published a cybersecurity technical report (CTR) that expands on a June 2023 memo from the Office of Management and Budget (OMB). The memo focuses on strengthening the security of the software supply chain, including open-source software (OSS) and software bills of materials (SBOM), by promoting secure software development practices. The report guides both individual developers and large industry companies, helping them adopt and maintain secure software supply chain practices to mitigate potential risks.
Titled ‘Securing the Software Supply Chain: Recommended Practices for Managing Open Source Software and Software Bill of Materials’ and developed by the Enduring Security Framework (ESF) Software Supply Chain Working Group, the National Security Agency (NSA), Office of the Director of National Intelligence (ODNI), the Cybersecurity and Infrastructure Security Agency (CISA)-led a public-private cross-sector group. The document aims to provide comprehensive guidance on recommended practices for describing, assessing, and measuring security practices throughout the software lifecycle.
“Open source software is an essential and valuable component in many commercial and public-sector products and services, and collaboration on open source software often enables great cost-savings for participants,” Aeva Black, CISA open source software security lead, said in a statement. “However, organizations that do not follow a consistent and secure-by-design management practice for the open source software they utilize are more likely to become vulnerable to known exploits in open source packages and encounter more difficulty when reacting to an incident.”
For this reason, “CISA is very pleased to have co-produced this guide with NSA, ODNI, and industry partners, which can be used by organizations of all sizes to improve the safety and security of their open-source software management practices,” Black added.
The guidance will help continue to foster communication between the different roles and among cybersecurity professionals that may facilitate increased resiliency and security in the software supply chain process. It may be used to describe, assess, and measure security practices relative to the software lifecycle. Additionally, the suggested practices listed herein may be applied across a software supply chain’s acquisition, deployment, and operational phases.
The software supplier is responsible for liaising between the customer and software developers. Accordingly, vendor responsibilities include ensuring the integrity and security of software through contractual agreements, software releases and updates, notifications, and the mitigation of vulnerabilities.
The guidance contains recommended best practices and standards to aid customers in these tasks. This document aligns with industry best practices and principles that software developers and software suppliers can reference. These principles include managing open-source software (OSS) and SBOMs to maintain and provide awareness about software security.
Recommended activities for open-source adoption by developers include identifying potential OSS solutions for consideration, creating an internal secure repository, and integrating OSS into the secure build process of the product using the same guidelines as with the in-house developed components. It also helps track updates to OSS or third-party components and produce updates of the product to specifically address changes to the OSS.
When it comes to the suppliers, the guidance prescribes monitoring for license change issues and vulnerabilities of the OSS included in any third-party software; and managing updates of the product that specifically address changes to the OSS. The use of an SBOM tracking mechanism is strongly recommended to aid in ensuring the ongoing integrity of the product.
Organizations may need to select, acquire, and deploy package repository software or services to host their internal secure open-source package repository. They may already have one if they are building and publishing packages internally, and if so, they should evaluate whether this existing software or service can also meet their needs for OSS.
The main factors in selecting a package repository may support the types of open-source packages used by the organization, such as Maven, Node Package Manager (npm), or Docker images, as well as specific features desired by the organization, such as integration with the organization’s Identity and Access Management (IAM) systems.
When implementing a package repository solution for an organization to use in open-source management, it is critical to properly define and enforce the process for adding packages and consuming them. For organizations with extensive open-source use, these processes can have a significant impact on agility and developer satisfaction. Choosing the appropriate level of assessment for each stage of development and automating these processes can minimize this impact.
To ensure that developers can confidently consume open-source from the package repositories, appropriate controls should be put in place so packages cannot be added outside of the approved processes. These controls may include access control restrictions or policies that prevent the consumption of packages that don’t meet certain criteria.
The guidance said that organizations may use multiple package repositories with differing policies to balance developer agility with risk. For example, one can be used from developer local workstations and continuous integration (CI) systems with fewer restrictions, and another used for more restrictive build systems used for product release with more restrictions.
These mitigations are in line with industry frameworks like the Secure Supply Chain Consumption Framework (S2C2F). The S2C2F offers best practices and specific requirements to enhance the secure consumption of open-source components by developers. It also organizes these practices into a maturity model, enabling development teams and organizations to implement them.
The guidance also outlines the process for maintaining, monitoring and updating approved OSS that has been integrated into a company’s product delivery. It also addresses the mechanisms for receiving vulnerability and threat reports related to third-party components, evaluating the risk of these vulnerabilities, and defining the necessary actions for crisis management to mitigate the threat.
The ESF document also provides a synopsis of the SBOM creation process and its relation to the Open-Source Review Board (OSRB) activities. It details information, tools, processes used, and considerations required for creating an SBOM. Also included are the means to update and distribute secure SBOMs due to software updates and changes, which may result from responding to vulnerabilities in third-party components.
Additionally, SBOMs use information produced during the acquisition and review of open-source components and can be used as part of vulnerability management.
U.S. President Joe Biden released in May 2021 an Executive Order (EO) 14028 that directed guidance in support of software security. Government and industry are collaboratively writing this guidance as a result of the EO. Highlights from the EO state that organizations may be requested to provide an SBOM directly to the purchaser or publish it on a public website and that both government and non-government parties may be required to review the SBOM to ensure that software products comply with the minimum elements for an SBOM.
Also, the EO directed the Department of Commerce and NTIA to publish the ‘Minimum Elements For a Software Bill of Materials (SBOM),’ which outlines activities and data required for an SBOM as well as example formats that fulfill SBOM requirements.
The guidance describes a VEX document as one that provides a method to provide clarifying security information for components in a specific software package’s SBOM that are marked as vulnerable. For example, if the vulnerable part of an open-source component is inaccessible to attackers or removed and therefore cannot be exploited, this could be listed in the VEX document that accompanies an SBOM.
In this manner, VEX provides additional context which may reduce the number of ‘false positive’ vulnerabilities that a vulnerability scanning tool would report against an SBOM due to the specific package instance. Furthermore, a vendor could provide a package’s SBOM and VEX document online to support customer requests.
Last month, the agencies published guidance that provides software developers and suppliers with industry best practices and principles, including managing OSS and SBOM, to maintain and provide awareness about the security of software. Organizations can use the guide to assess and measure their security practices relative to the software lifecycle; the suggested practices may be applied across the acquisition, deployment, and operational phases of a software supply chain.
A complimentary guide to the who`s who in industrial cybersecurity tech & solutions
Free DownloadRelated
