SECURITY 101
The Criticality of Context for Addressing Software Supply Chain Risk
June 19, 2023
Understanding the context of detected risks is a critical requirement for efficiently addressing software supply chain threats. The relevance of a threat and its remediation priority depend on its actual impact on your products and services. A vulnerability in a package that’s only used in specific development scenarios has a different criticality to one that exposes customer data in a production environment, for example. In this article, you’ll learn how to utilize context to inform efforts to prioritize and mitigate supply chain threats.
Software supply chain risks such as vulnerable dependencies and improper git controls substantially affect your product's overall security. Each component that's exposed to a risk inherits that weakness, giving attackers an additional entry point into your system.
Estimates call for the global cost of supply chain attacks to reach $45.8 billion in 2023 and climb to more than $80.6 billion by 2026. It’s thus crucial that organizations prepare themselves to properly deal with supply chain issues.
However, not all risks are equal. It's critical to consider the context around each threat to prioritize the remediation of the most relevant issues, instead of spending resources on ones that aren't immediately significant. In this article, we'll examine how to understand and utilize threat context to increase the efficiency of your application security process.
A threat's "context" determines whether a threat is currently relevant and the extent to which it should be prioritized for remediation. The context varies depending on where and when the threat is detected.
But what does it mean for a threat to be relevant? Put simply, not all detected supply chain threats pose a credible risk. The criticality of the risk created by a vulnerability is dependent on factors such as the system it occurs in, the purpose of that system, the software involved, and the ability of response teams to effectively address the threat.
For example, container vulnerability scanners often report CVEs in low-level packages that aren't leveraged in production code. They're still technically vulnerabilities, but they're innocuous within the context of your application. It would be unwise to resolve them ahead of other immediate supply chain risks, such as incorrect access control on a source code repository that publicly exposes your IP.
It's therefore vital that you use your knowledge of your application and security environment to assess the context around supply chain threats. To do this, you'll need to start by establishing a baseline for your development ecosystem.
The baseline threat context encapsulates the normal operating state for your development ecosystem, developers, and organization. It gives you the tools required to accurately determine the risk criticality of new threats.
Effective baselines should cover the following three components:
Let's explore each of these in turn.
The ability to make precise context assessments depends on having full visibility into your supply chain and its existing risks. To make a balanced assessment of risk, you need to know which packages you're using, where they're deployed, and the types of vulnerabilities they could contain.
A software bill of materials (SBOM) is an essential tool for gaining this visibility. An index of the packages and repositories within your stack, the SBOM allows you to clearly see which services use a particular dependency.
You should augment SBOMs with your own awareness of the environments in which dependencies are used. For example, a package exclusively used as a developer tool may present a less critical risk than one shipped to production. By gaining visibility into the supply chain, you can quickly assess the threat that new zero-day vulnerabilities pose to your project.
One challenge with visibility is how to minimize coverage gaps and prevent data from becoming outdated over time. You can mitigate this concern by selecting tools that are integrated with your source code management system, allowing you to detect vulnerable dependencies the moment they're added to your repository. This is more robust than IDE plugins, which developers can disable, or pipeline-based detection, which won’t run until the threat is already established in your production code.
Once you've obtained visibility into your supply chain, you should supplement it with detailed knowledge of how each supply chain component relates to your projects, repositories, and products. This step should filter the SBOM output to produce a tagged index of packages, including the critical data likely to affect the context of new threats.
For each identified component, note which of your assets it applies to, the criticality (importance) of the component and that asset, and any relevant information that would assist with incident response. This last can include details such as the product manager or responsible code owner to ensure the correct people are notified of new vulnerabilities.
Similarly, you should also index your asset inventory so you can quickly identify which repositories exist in particular environments, who can access them, and the time they were last pushed or updated. For instance, a project that hasn't received dependency updates over an extended period may be more contextually relevant because it's likely to rely on outdated package versions.
Threat contexts should form the basis of how you manage and respond to risks. This means you need to create a framework for classifying and prioritizing threats based on the risk severity and business importance of the asset’s you have inventoried. This framework will provide the definitive answer to questions such as whether a threat is relevant, how urgently it should be remediated, and who is responsible for the work.
Here are a few guidelines on how to use threat contexts to prioritize supply chain risks:
Risk management is also intrinsically connected to your strategy for communicating new threats. Make sure to have dedicated communication channels so that DevOps teams can liaise with security experts and product leads to accurately assess the criticality of risks. It's vital to know who to contact when a threat is found.
Regularly monitor and review risks and responses to fine-tune your context baseline and management approach. The relative priorities of assets and supply chain components can rapidly evolve, as packages are updated, products are added and deprecated, and your development environments are hardened. All of this means a proactive approach to reevaluation is required.
Threat contexts allow you to address supply chain risks throughout the software development lifecycle. The ability to accurately analyze risk contexts will enable you to effectively target the most important risks with precision while simplifying ownership or resolution efforts.
Understanding threat contexts facilitates rapid resolution by ensuring the most relevant risks rise to the top automatically and by defining who should be acting on the risk. This expedited remediation, limiting the exposure of a vulnerability, and ultimately reducing the likelihood of exploitation.
The context of a risk reveals a true depiction of the threat severity, the person or people most apt to help mitigate the risk, and those responsible for introducing it. Scanners can find an overwhelmingly large number of vulnerabilities, spanning from innocuous package vulnerabilities that have spent years in the backlog to newly published hardcoded secrets used to access PII data. A context-based risk management framework is capable of handling all of these situations, accurately prioritizing the risk, and assigning ownership automatically.
By cataloging your assets and supply chain components alongside critical contextual data, the framework informs what you should do to mitigate risks while powering actionable protection measures. Use the information from your framework to implement systems that automatically find and block the highest-priority threats for the given context.
Context-based risk management can be adopted by any DevSecOps team to secure your software development lifecycle against high-severity vulnerabilities. Here are a few best practices to gain the greatest protection.
Pipelineless security provides fast, frictionless, and private feedback with 100% coverage from day one. As opposed to traditional CI/CD pipeline-led approaches, the pipelineless model offers real-time detection that communicates directly with developers to minimize exposure.
Pipelineless security helps contextualize the risk for developers and offers instant fixes for high-priority vulnerabilities. It ensures the context you've identified is enforced, without making developers wait for build pipelines to complete. Scans are triggered by automated webhooks fired for events such as Git pushes, ensuring no extra configuration is required.
Identify all your assets, their responsible owners, and their relative importance to your organization. The urgency of this step cannot be underestimated: Vulnerabilities alone don't create a threat; threats arise due to the combination of a vulnerability and the asset it presents within.
Larger organizations can have hundreds or thousands of projects, and a low risk in one project could present a critical risk when found in another. This makes it challenging to determine which ones need the most urgent attention when a new zero-day vulnerability is reported. Analyzing each asset's threat context ahead of time—such as whether it's customer-facing, outdated, or abandoned— allows you to make informed classification decisions when threats appear.
Proactively assessing supply chain risks is another essential task that helps you understand where threats could arise and what their impact would be. Part of this can involve regularly looking at the vulnerability histories of the packages you depend on.
For example, if a project is outdated or has reported CVEs in the past, it might be more likely to cause further problems in the future. In this scenario, completing a risk assessment would reveal an opportunity to implement preventative mitigation, such as by replacing the package with a better-supported alternative.
As we've discussed in this article, a framework-driven method is the best way to utilize context in risk management. Combining automated detection tools with relevant classification procedures and communication strategies enables you to consistently prioritize risks according to their context. To take this framework to its most logical end employ the use of a tool that allows you to set policies that match your framework’s guidance, and automate the process steps that are most critical such as notifications and SLA timing.
Software supply chain risks such as vulnerable dependencies, hardcoded secrets, and ineffective source-repository access controls have the potential to cause security incidents. Yet in practice, many of these issues aren't immediate threats, such as when a vulnerability is found in a package that is only used by a specific internal tool.
Understanding the context around each threat is key to ensuring efficient detection and mitigation. DevSecOps teams don't have limitless resources, so it is critical that you focus on the most relevant risks that have immediate consequences for your product, customers, and business. Establishing your baseline context by achieving supply chain visibility and defining a consistent prioritization framework is the first step in this process.
