The Software Supply Chain

"Supply chain risk" overall is a huge and complicated bucket for businesses – environmental, reputational, ethical and continuity concerns can be overwhelming enough.  Even limiting consideration to cyber security risk, it's still a massive challenge.

It's easy to hark on about the pandemic changing the working world forever, but it's certainly accelerated the adoption of remote working and cloud technologies (SaaS / PaaS platforms) across the globe.  Companies have outsourced functions that always used to be in-house.  They've purchased tools and products for remote working productivity.  They have a workforce who are increasingly demanding better productivity tools and more specific toolkits – integrating small, specific applications into their departmental workflows to boost efficiency and engagement.

Anecdotally, we've seen customers over the last two years increasing their pool of third-party service providers and vendors to meet the needs of a changing workforce and changing working patterns, and it's been a rapid process.

There are many different ways in which supply chain attacks can impact your cyber security resilience.  We all appreciate that third-party service providers may have access to physical premises, or to technical infrastructure, and that a compromise of these providers can grant that access to an attacker.  If you have smaller, or less-mature, suppliers in your supply chain, we know that they may have immature information security practices.  Because we think about these areas a lot, most businesses have pretty mature processes aimed at managing these risks in their supply chains.  

One area where we often see weakness in our customers, however, is in management of the software inventory and their software supply chain.

You can't fix what you don't know about.  

When a vulnerability is released, your first task is work out whether you're impacted, and what you need to do to manage that impact - if you want to understand the impact to your business of a vulnerability in a piece of software, you need a full understanding of the components in use across all your systems. 

That's a complicated problem to solve - even a relatively simple piece of software may use hundreds of different libraries and components maintained by different parties, all of which may rely on other libraries.  When an exploitable vulnerability exists, you want to be able to identify affected systems and mitigate the issue as quickly as possible. 

Log4JShell was a prime example of a vulnerability within the software supply chain causing havoc - it's a popular component and its use was widespread, so when it came to addressing the risk the first step for most businesses was trying to find out whether it was used, and where it was used.  For many, this involved asking questions of suppliers and software maintainers, reaching out to internal stakeholders and doing research - that's time-consuming, and in the case of Log4JShell (a high-impact vulnerability with exploit code circulating in the wild), it was time that would have been better spent applying the patch.  

Businesses with a comprehensive list of components and libraries in use cut out that time in their response, and were able to move straight into mitigation.  

Log4JShell is a high-profile example as it was a very high impact issue in a common library, but it's worth noting that modern adversaries actively target open source libraries to embed malicious code in the supply chain.  In October 2021, for example, we saw an npm package with more than 7 million weekly downloads being compromised via an account takeover.  For an adversary, planting malware into common packages is a technique which potentially gives access to thousands of victims in a single attack – that's a great return on investment!

Software inventory management

This type of remediation pattern - working out which libraries and components are used where - will become a more common problem for businesses to solve.  If you want to be proactive about preparation for a security incident, you should be thinking about how you inventory software assets and what level of detail you have available to you about the components in use.

Comprehensive asset management, done well, cuts down on time to mitigation significantly - meaning your window of exposure is reduced.  
It's worth noting that 'garbage in, garbage out' applies to cyber security asset management as much as it does to any other control measure - if you get comprehensive asset coverage to a decent depth, it can be extremely helpful.  If you don't get the right coverage or depth, you may find that you have a false sense of security and still need to scramble to identify your exposure when a vulnerability comes to light.