״Software vendors must be held liable when they fail to live up to the duty of care they owe consumers, businesses, or critical infrastructure providers ״(the White House).
Today, any software provider is expected to assume greater responsibility for ensuring the integrity and security of software through contractual agreements, software releases and updates, notifications, and the mitigation of vulnerabilities. Recently, the ESF (Enduring Security Framework), a cross-sector working group, issued guidance that includes recommended best practices and standards to assist customers in implementing security measures within the software supply chain. In this article, I will delve further into the practical recommendation of utilizing SBOM-driven risk scoring as an effective mechanism for triage and prioritization.
Common methods of compromising software supply chains persist, including exploiting software design flaws, incorporating vulnerable third-party components into a software product, infiltrating the supplier’s network with malicious code before the final delivery of the software product, and injecting malicious software into the software deployed in the customer environment.
A Software Bill of Materials (SBOM) has emerged as a crucial element in software security and software supply chain risk management. An SBOM serves as a nested inventory, providing a list of ingredients that constitute software components.
The operationalization of SBOMs at scale requires tool automation and standardization in system deployments, product development, and data exchange between software vendors and consumers.
There are a few important machine-readable SBOM standard formats supported by the industry. CycloneDX and SPDX define the way SBOMs are created, analyzed and shared. VEX is a complementary form of a security advisory that indicates whether a product or products are affected by a known vulnerability or vulnerabilities. Thus, it offers the benefit of showing that a product is not affected by a specific vulnerability, even if this vulnerability exists in its SBOM.
Correlating SBOM content across software products deployed within the enterprise can provide powerful insights to the application security, incident response and forensics teams, risk management, and procurement. Organizations are expected to generate and manage a large amount of SBOM data for internal products as well as consume external data that needs to be managed in an effective manner. Therefore, there is a need to support process automation of SBOM-driven risk management at scale.
Using SBOMs and Risk Scoring
Risk scoring can serve as a means to generate a condensed overview derived from SBOM content, enabling swift comparisons with external data sources and facilitating prompt decision-making based on received SBOMs and prioritization.
- The SBOM enhances transparency, thereby improving software asset management, patch management, identification of technical debt gaps, and vulnerability management for customer organizations. It also holds the potential to extract the provenance of components to validate integrity and trust.
- Analyzing SBOM content alignment across software products implemented in the enterprise yields valuable insights for incident response teams, risk management, and procurement process validation.
Turning SBOM into Risk Information at Scale – Rationale for Risk Scoring
A key challenge for every AppSec professional and CISO is managing the alert fatigue across your products and services. Including evaluating external risks coming from third party software components.
The key barriers to implementation are out-of-date contractual or license-based support that may impact the availability of downstream patches and product updates and exponential growth in the complexity of dependencies within software products, whether open-source or closed-source.
A risk score is a metric used to predict aspects of the software and its components’ current and future risk that can effectively support prioritization at scale.
Risk Score = probability x Impact
Risk Scoring allows organizations to understand their software supply chain risk based on defined risk factors and anticipate the potential future risk of a given software product in the enterprise.
An effective risk score could be on a scale from 1 to 10 (such as CVSS and Scorecard), so we can align every risk component to the 1 to 10 scale for ease of reference.
An aggregated risk score: In many complex systems and systems of systems, there may be multiple SBOMs as a part of the collective solution and, therefore, a collection of Risk Scores.
Risk Scoring Components:
1.Vulnerabilities: Mapping known vulnerabilities using CVE enumeration and CVSS score from available feeds such as NVD, OSV, and Github Advisories.
2. Context from vendors: VEX and advisory context from vendors that may change the decision of vulnerability scoring in the context of usage. Linking SBOMs to vulnerabilities enables risk flags, while VEX documents allow a consumer to prioritize vulnerabilities.
3. EPSS 3.0: Exploitability metric by FIRST, which predicts the probability (between 0 to 1.0) for exploitation in the next 30 days. This is an effective additional likelihood layer to the CVSS score that can help to prioritize the most important CVEs to handle first.
4. KEV: CISA also created a publicly available threat intelligence feed that is known today as the CISA KEV (Known Exploitable Vulnerabilities) Catalog. This catalog contains about 5% of all identified CVEs that are confirmed by CISA as having been or actively exploited. Therefore, this is a good starting point to prioritize high-impact vulnerabilities to address. In addition, this is part of the checklist you would validate before final approval of the new version release.
5. Threat intelligence – Add additional sources of threat and vulnerability feeds known malicious packages (Examples: private feeds from Snyk, Sonatype, Graynoise, etc.)
6. OSS Reputation: The open SSF scorecard evaluates independently for performance measures metrics affecting different parts of the software supply chain including source code, build, dependencies, testing, and project maintenance reputation of open source projects (1-10 rating).
7. Performance over time: MTTR ( Mean Time To Repair) critical vulnerabilities of a product/package version could give a relevant metric of security risk performance.
8. Impact and context. In this aspect, prioritization based on the business context of the software product would help prioritize and triage the vulnerability forest.
A few examples are
- Criticality of the module/product: Is this mission-critical ( sensitivity or criticality)
- In how many products do I have the specific vulnerability?
- Externality exposure of a service/component
9. Compliance exposure – Licenses: Both proprietary and open-source software licenses are important to validate the compliance of the organization’s legal policy.
Risk Scoring Layers Concept – Adding Risk Metrics to SBOMs:
- Start with CVE enumeration and CVSS score based on the SBOM data.
- Consume and add VEX context to reprioritize criticality
- Evaluate CVEs with a high EPSS score (i.e. 0.6-1.0)
- Prioritize KEV list – to address first.
- Evaluate by OpenSSF reputation score (1-10) – identify risky dependencies.
- Analyze exposure to the external network (using CVSS vector)
- Evaluate accumulates risk by the amount of product count per vulnerability.
- Evaluate by the label of the criticality of specific container SBOM to the business.
- Identify compliance violation risks in using the SBOM dependencies analysis according to the company license policy.
- Share and manage the data as attestations in a collaborative platform with workflows to other systems such as Jira and others through API and machine-readable.
Leveraging SBOMs With Risk Scoring for Practical Use Cases:
- Continuous vulnerability triage for products by using risk metrics to prioritize a patching work plan across products.
- Compare products side by side based on risk metrics.
- Compare and approve new version updates before deployment/release.
- Track the technical debt gap using the risk-scoring thresholds for product versions.
- Create a quick report of the top 50 risks across my most critical products.
- Impact analysis to accelerate an incident response – in case of an actively exploited vulnerability is found in the wild. In this case, time matters to quickly identify how I am impacted and what would be a blast radius of the heat map of this exposure.
How To Use Scribe Hub Platform for Effective Risk Management:
- Centralized SBOM Management Platform – Create, manage, and share SBOMs along with their security aspects: vulnerabilities, VEX advisories, licenses, reputation, exploitability, scorecards, etc.
- Build and deploy secure software – Detect tampering by continuously signing and verifying source code, container images, and artifacts throughout every stage of your CI/CD pipelines.
- Automate and simplify SDLC security – Control the risk in your software factory and ensure code trustworthiness by translating security and business logic into automated policy, enforced by guardrails
- Enable transparency. Improve delivery speed – Empower security teams with the capabilities to exercise their responsibility, streamlining security control without impeding dev team deliverables.
- Enforce policies. Demonstrate compliance – Monitor and enforce SDLC policies and governance to enhance software risk posture and demonstrate the compliance necessary for your business.
Two examples of Scribe Hub risk analytics capabilities are presented:
Vulnerabilities mapped per SBOMs, risk scoring by CVSS ,VEX, EPSS and KEV data.
Time series of SBOM version performance over time indicating MTTR the mean time to repair critical identified vulnerabilities.
Summary
SBOM-driven risk scoring empowers organizations to assess supply chain risk by evaluating predefined risk factors and foreseeing potential future risks associated with a specific software product within the enterprise. The risk score serves as a quantitative measure to anticipate both current and prospective risks related to the software and its components.
This scoring metric is derived from indicators sourced from the SBOM, VEX, among other feeds, and aligns with the content supporting Supply Chain Risk Management (SCRM). When applying or evaluating a risk score, factors such as the software’s usage context, how it is accessed or isolated, and the processes and systems it supports should be taken into consideration.
Scribe Hub serves as a collaborative platform designed for the extraction, management, attestation collection, and risk-scoring analysis of SBOMs at scale. This platform efficiently processes multiple external data feeds to handle the intricacies of complex systems and software products.
This content is brought to you by Scribe Security, a leading end-to-end software supply chain security solution provider – delivering state-of-the-art security to code artifacts and code development and delivery processes throughout the software supply chains. Learn more.
Related posts
