New guidance released by CISA, NSA, partners on securing software supply chain
The U.S. Cybersecurity and Infrastructure Security Agency (CISA), the National Security Agency (NSA), and partners published new guidance on securing the software supply chain. Developed through the Enduring Security Framework (ESF), this guidance provides software developers and suppliers with industry best practices and principles, including managing open source software and software bills of materials (SBOM), to maintain and provide awareness about the security of software.
Titled, ‘Securing the Software Supply Chain: Recommended Practices for Software Bill of Materials Consumption,’ 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. The document evaluates that unmitigated vulnerabilities in the software supply chain pose a significant risk to organizations.
“Fundamentally, SBOM provides critical software transparency for improved patch and vulnerability management for customers as well as potentially mitigate supply chain risks,” Jorge Laurel, chief of the ESF, said in a media statement. “The newest ESF release provides best practices for SBOM consumptions with the goal of increasing cybersecurity within organizations as well as the supply chain at large.”
The cybersecurity technical report builds on the September 2002 release of Recommend Practices for a software supply chain’s development, production, distribution, and management processes, to increase the resiliency of these processes against compromise. It also builds upon and supports the Office of Management and Budget (OMB) memorandum on Enhancing the Security of the Software Supply Chain through Secure Software Development Practices (M-22-18).
“Because the considerations for securing the software supply chain vary, this follow-on guidance focuses on Software Bill of Material (SBOM) Consumption and open source software (OSS),” according to the cybersecurity technical report. “This information 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. All organizations are encouraged to proactively manage and mitigate risks as a part of evolving secure software development practices. An organization’s role as a developer, supplier, or customer of software in the software supply chain lifecycle will continue to determine the shape and scope of this responsibility.”
Additionally, it is recommended that acquisition organizations assign supply chain risk assessments to their buying decisions given the recent high-profile software supply chain incidents. “Software developers and suppliers should improve their software development processes and reduce the risk of harm to not just employees and shareholders, but also to their users.”
When it comes to SBOMs consumption, organizations need to focus on the consumption of SBOMs received by various customer organizations and provide guidance for the use of SBOMs that will be consumed by customers. An SBOM primarily conveys information about what is in the software.
“The mere act of knowing that a supplier can provide a quality SBOM offers benefits to the software user since it offers a certain level of confidence that the software supplier is more likely to be able to respond to supply chain concerns,” the cybersecurity technical report detailed. “However, full leverage of the power of SBOM requires the capabilities to turn the SBOM data into security intelligence, which can then drive security actions. From a security perspective, SBOMs are valuable because they ensure that the software is up-to-date and patched against known security vulnerabilities.”
There are other risks that transparency through SBOM can address, such as licensing information derived from SBOMs, which can help businesses ensure that they comply with licensing requirements when using open-source and third-party licensed software.
An organization that uses the application could also gain attribution information if the information is provided by the SBOM. The greater visibility provides another potential avenue for license compliance. SBOM data can also provide insight into how up-to-date the components in an application are, and the corresponding risk of technical debt when components have not been kept up-to-date. This might, in turn, offer some insights into the cost of maintenance and the potential cost of ownership or future contracts.
The cybersecurity technical report also prescribes workflows for the acquisition, management, and use of SBOMs by software consumers, which is broadly defined to include commercial and non-commercial entities acquiring third-party software capabilities from a supplier, developer, or open source. SBOMs can inform the risk decision associated with acquiring a product if the actual acquisition occurs soon after the evaluation of the SBOM, which may evolve. Initially, risk can be assessed based on the content of the SBOM including known vulnerabilities associated with SBOM components, but over time risk can be re-assessed due to changes in the environment or newly discovered ‘zero-day’ vulnerabilities.
It further detailed that a new SBOM for an existing software product should be provided/acquired for software updates, software upgrades, or for augmenting the completeness of a prior SBOM for an existing software product. The new/updated SBOM should be compared to the last SBOM to identify new components /dependencies that have been introduced or removed since the last version. These changes should be validated against current threat information (ex. CVEs and/or VEX) to ascertain, inform, and update the current risk posture and risk scoring.
The guidance also provides information on how to quantify the risk of a software product or component based on an SBOM. Beyond tracking well-defined, known risks, such as checking against lists of known vulnerabilities, SBOM data can be used as a starting point for more context-specific risk analysis. Components mentioned in an SBOM can be further investigated to understand details about the source of the components, for example, jurisdiction, maturity (e.g., an open source project with only one maintainer), or the financial stability of the supplier. While this data may not be directly available in the SBOM, it can be used as the starting point for this type of enrichment that can feed into more enhanced risk analysis.
Risk Scoring allows organizations to understand their supply chain risk based on defined risk factors and anticipate the potential future risk of a given software product in the enterprise. A risk score is a metric used to predict aspects of the software and/or its component’s current and future risk. This metric is developed using indicators from the SBOM, Vulnerability Exploitability eXchange (VEX), etc. as well as other feeds and content in support of SCRM (Supply Chain Risk Management).
The technical report added that risk analysis and the criteria that will be utilized to assess the scoring of the product and/or software components will include a rubric with categorical definitions to encourage the transparency of assessment results. “When applying or assessing a risk score the context of where the software is being used, how the software is accessed or isolated, or what processes and systems it is supporting should be a factor in considering the associated risk. The risk score informs the overall risk determination for a software product or software component,” it added.
To fully maximize the value of SBOM requires organizational cyber policies and procedures that allow for the successful agile automated implementation of SBOM consumption for all software in the enterprise. This is not dissimilar to other types of security data. Threat intelligence data, for example, has gone through a similar evolution and has a similar diversity of maturity. Implementing appropriate operational processes will be a prerequisite to enabling decisions to minimize the risk made visible by SBOM content.
Some of the mitigation measures to reduce the risk associated with the software are:
- Identify vulnerable and/or exploitable versions of software and prioritize patching accordingly. Monitor those systems/software for malicious or anomalous behavior, determine a risk associated with these observations, and implement corrective behavior automatically. AI/ML models can help automatically detect malicious or anomalous behavior.
- Use data collected from the SBOM and its analysis and incorporate it directly into the risk management processes to determine the organization’s software supply risks and risk tolerance. This means also tying in mechanisms for applying countermeasures, mitigations, or other risk control activities.
- Use of SBOM and SCRM processes works in concert with a ‘zero trust’ architectural approach.
The document identified that the four-quadrant approach is one effective way to evaluate open-source vulnerabilities found in COTS software. “For example, software with some vulnerabilities–where the vulnerabilities are considered to have low impact and are unlikely to be exploited –could be approved for purchase, renewal, or maintenance contract by simply accepting the low-risk level. Obviously, software with a high impact, high likelihood of attack vulnerabilities may need to be rejected.”
However, it is often not possible to reject any software critical to the business. While using SBOM data in the COTS procurement process is a relatively new discipline, the assumption here is that both the customer and the vendor will act in good faith to improve the security of the product and reduce security risk over time. This assessment process can be applied to all deployed software.
In conclusion, the guidance assesses that SBOM consumption is new and will evolve and scale, and emerging tools will help automate and scale. Understandably, tools are not here yet—until recently, SBOM data was quite scarce, so there wasn’t much need for open-source software or proprietary SBOM consumption tools. Different organizations will focus on different risks that they can better manage with software transparency.
Furthermore, the industry is still imagining use cases and expects more to emerge as SBOM becomes more common. There is still value in just asking for SBOMs, and just keeping SBOM data on hand to respond to emergency advisories. SBOM is just one part of software supply chain security—basic hygiene and paying attention to other C-SCRM guidance are still important.
Earlier this week, the CISA released a document that provides insights into the circumstances and events that may prompt an organization to issue VEX information. It also outlines the entities involved in creating or using VEX information. The decision to issue VEX information is primarily a business decision for most suppliers, while independent open-source developers may have more individual considerations. The document also highlights the factors that can influence this decision-making process.
The CISA also in September published its Hardware Bill of Materials (HBOM) framework for Supply Chain Risk Management. This document introduces an HBOM framework that creates a consistent, replicable avenue for vendors to engage with purchasers about hardware components in their current or prospective product acquisitions. This framework equips purchasers with the means to thoroughly evaluate and mitigate risks within their supply chains.
Related
