Patch Management: Software Composition Analysis
Some more specific thoughts on patching open source software libraries
I recently wrote about patch management and my overarching philosophy to this problem. In this essay, we’ll cover more specific thoughts on patching open source software dependencies.
Software composition analysis (SCA) is the capability we’re talking about here. It’s about looking at the open source components used in your application, and analyzing them for security flaws.
Specifically, in this post we’re going to focus on open source libraries, not operating system packages.
In most modern startups, open source libraries are a good place to start your patch management program. You can reliably check compliance boxes using software composition analysis1. Bugs in open source libraries are also more likely to affect your product than bugs in operating system packages running on servers or outdated software running locally on employee workstations.
Identify
The first goal of our software composition analysis program is to inventory all of the open source libraries used in our product development. We want our inventory to include the following context, or have it readily available:
Packages
Versions
Call sites
Known vulnerabilities
Available updates
Dependency hierarchy
Development or Production
In practice, this is a wishlist and not a checklist. The tools I’ll mention later implement some of these, but aren’t perfect and the relative lift of building something with all of my desired attributes probably just isn’t worth the lift for most companies.
Protect
Let’s now assume that we have a list of potential updates that we could make. This is where reasonable people can decide to take very different paths.
If we automatically update all of these libraries to their latest release, we can declare “Mission Accomplished” on software composition analysis and move on. The reason I’ve never heard of a company doing this is that updates are often liable to introduce breaking changes, leading to severe bugs in your application.
In order to automatically apply updates, we need robust detection of breakage. Strong unit test coverage, integration tests, canary deployments, and automated rollbacks could give us the confidence we need to move forward with this solution. When breakage is detected, an engineer can step in to investigate the cause and remediate.
I suspect that very soon AI tooling will be available to preemptively detect breaking changes and modify our code to prevent issues.
If you think the automated approach might be feasible for your company, I encourage you to try it. I can’t say that I have personal experience with it, and it will almost certainly lead to surprising edge case problems that will require creative solutions. Please do it, solve those problems, and share what you learn. The industry would be much better off if we could just update all of our software without fear.
If you can carve-out a portion of your application dependencies where updates can be safely automated, that will reduce the load on the rest of this program and is still worthwhile. It can be expanded over time and lead you to gradually solve for edge cases instead of taking them on all at once. Start with one package and go from there.
Solving for automated library patching all at once may be too risky, and too much of an investment to be feasible. No problem! We just need a way to prioritize and address our list of available updates.
The following attributes are worth considering in a hypothetical prioritization algorithm:
Number and severity of known vulnerabilities
Reachability of known vulnerabilities
Number of versions between current and latest
Second-order dependencies updated in recent versions
Use in development versus production
Processing of untrusted input
Exploit prediction score of known vulnerabilities (EPSS)
Likelihood of breaking changes
Level of maintainer activity
Features and improvements added in newer versions
I don’t know of any products on the market that use all of these inputs to help you make decisions. There are a handful that use some of them, and they’re worth looking at to implement your program.
I recommend using a product for both building your inventory and prioritizing updates. Manually implementing this stuff would be a significant lift. Even a product that doesn’t cover everything I’ve mentioned can be great for starting your program.
Note: I don’t have a financial interest in any of these companies, or any hidden economic incentive to recommend them over other tools
I recommend several of them to Observa clients, and want to maintain positive working relationships with these companies, so I won’t share pricing information here. In my experience, none of these are significantly out of sync with the others on pricing, though some may be less expensive for a given customer than the others depending on specifics.
Coana and Semgrep Supply Chain both use static analysis to determine if a known vulnerability is reachable from your application2.
EdgeBit uses runtime analysis to determine reachability. An agent checks to see if specific files are loaded when the application is actually running and uses this context for vulnerability prioritization or suppression. They’re also experimenting with EPSS to include exploit prediction scores as an input to prioritization.
Socket.dev is focused on a slightly different problem3. They do list vulnerabilities, but their primary value proposition is looking for malware in these open source libraries. Takeovers, troll packages, typosquatting, etc. I like this product and it’s a great complement to an SCA tool with reachability analysis and other prioritization features.
A shortcoming of all of these tools is that they are solely focused on the security aspects of patch management. I’d like for a tool to consider other factors, like maintainability and improvements to make this program more holistic.
Bringing this back around to practical advice for your program:
Consider how much of this you can automate.
Choose an SCA tool that you like, implement it, and check-in on it regularly to apply the highest priority updates.
From there you can work with your engineering team to decide what other factors you’d like to prompt package updates. This will give you a strong foundation and let you move on to other aspects of your patch management program.
SOC 2 Common Criteria: 3.2, 3.4, 4.1, 7.1, 7.2, 7.4
CC 3.2
COSO Principle 7: The entity identifies risks to the achievement of its objectives across the entity and analyzes risks as a basis for determining how the risks should be managed.
Point of Focus: Identifies Vulnerability of System Components — The entity identifies the vulnerabilities of system components, including system processes, infrastructure, software, and other information assets.
Point of Focus: Assesses the Significance of the Risks — The entity assesses the significance of the identified risks, including (1) determining the criticality of system components, including information assets, in achieving the objectives; (2) assessing the susceptibility of the identified vulnerabilities to the identified threats (3) assessing the likelihood of the identified risks (4) assessing the magnitude of the effect of potential risks to the achievement of the objectives; (5) considering the potential effects of unidentified threats and vulnerabilities on the assessed risks; (6) developing risk mitigation strategies to address the assessed risks; and (7) evaluating the appropriateness of residual risk (including whether to accept, reduce, or share such risks).
CC 3.4
COSO Principle 9: The entity identifies and assesses changes that could significantly impact the system of internal control.
Point of Focus: Assesses Changes in Threats and Vulnerabilities — The risk identification process assesses changes in (1) internal and external threats to and vulnerabilities of the components of the entity’s systems and (2) the likelihood and magnitude of the resultant risks to the achievement of the entity’s objectives.
CC 4.1
COSO Principle 16: The entity selects, develops, and performs ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning.
Point of Focus: Considers Different Types of Ongoing and Separate Evaluations — Management uses a variety of ongoing and separate risk and control evaluations to determine whether internal controls are present and functioning. Depending on the entity’s objectives, such risk and control evaluations may include first- and second-line monitoring and control testing, internal audit assessments, compliance assessments, resilience assessments, vulnerability scans, security assessment, penetration testing, and third-party assessments.
CC 7.1
To meet its objectives, the entity uses detection and monitoring procedures to identify (1) changes to configurations that result in the introduction of new vulnerabilities, and (2) susceptibilities to newly discovered vulnerabilities.
Point of Focus: Conducts Vulnerability Scans — The entity conducts infrastructure and software vulnerability scans designed to identify potential vulnerabilities or misconfigurations on a periodic basis and after significant changes are made to the environment. Action is taken to remediate identified deficiencies in a timely manner to support the achievement of the entity’s objectives.
CC 7.2
The entity monitors system components and the operation of those components for anomalies that are indicative of malicious acts, natural disasters, and errors affecting the entity's ability to meet its objectives; anomalies are analyzed to determine whether they represent security events.
Point of Focus: Implements Detection Policies, Procedures, and Tools — Detection policies, procedures, and tools are defined and implemented on infrastructure and software to identify potential intrusions, inappropriate access, and anomalies in the operation of or unusual activity on systems. Procedures may include (1) a defined governance process for security event detection and management; (2) use of intelligence sources to identify newly discovered threats and vulnerabilities; and (3) logging of unusual system activities.
CC 7.4
The entity responds to identified security incidents by executing a defined incident-response program to understand, contain, remediate, and communicate security incidents, as appropriate.
Point of Focus: Remediates Identified Vulnerabilities — Identified vulnerabilities are remediated through the development and execution of remediation activities.
Here’s a blurb Coana was kind enough to share with me:
Coana uses reachability analysis to gain a contextual understanding of the vulnerabilities in your open source components. This allows the tool to remove the approx. 90% of the vulnerabilities that a traditional SCA tool reports, since they are irrelevant false positive alerts that present no actual security risk. Coana has been built by members of a leading academic research group, and our reachability analysis technique is among the most sophisticated on the market. This blog post explains how it works.
— Anders Søndergaard, Co-founder and CEO at Coana
Socket kindly shared this blurb with me:
In addition to catching known vulnerabilities, Socket uses LLMs to detect zero-day open source supply chain risks like malware, typosquatting, hijacked packages, obfuscated code, privileged APIs, and more. The GitHub app (which you can trial for free) enables protection on all updates and new dependencies added in PRs, blocking these risks before they land in your projects. Socket can be a full replacement to traditional SCA, or a compliment to existing tools.
— Sarah Gooding, Head of Content Marketing at Socket