Australian inaction keeps software supply chain security risks alive

After the SolarWinds breach unfolded, the prevailing attitude was one of “we need to talk” about the security of our software supply chains.

It’s remained a consistent discussion topic in the years since. The problem is, we’ve kept talking about it, and talking about it, but too many organisations seem to have placed it into a ‘too-hard basket’ and deferred meaningful action.

And so two years later, the same threat still exists, and is largely unaddressed.

A recent US study by Vanson Bourne found only 37-38 per cent of critical infrastructure and government agencies had fully developed and implemented “software supply chain risk management policies and processes”. The same study found implementation of such policies and processes difficult for 82 per cent of agencies and 62 per cent of infrastructure firms.

Narrowing the focus to Australia, research by PwC indicates only one-third of Australian organisations “have assessed exposure to risk of attacks on the software supply chain”, and “more than half have not taken any actions for lasting impact on their third-party risk management”.

As a result, attackers are honing their focus and attention on identifying and exploiting vulnerable software supply chains. It is estimated the number of software supply chain attacks quadrupled in 2021 compared to the year before, and unfortunately that growth will continue as long as supply chain security risks remain under-addressed.

The vendor vector

While there are several ways that security risks can manifest in supply chains and “n-th” party relationships, the one we intend to focus on is the SolarWinds archetype: the risk of an attacker inserting malicious code into a genuine software update to propagate the malware.

VIEW ALL

One reason to focus on this avenue is that it’s the most common of all supply chain threats; according to EU cyber security agency ENISA, “attackers focused on the suppliers’ code in about 66 per cent of reported incidents”.

This, ENISA said, “shows that organisations should focus their efforts on validating third-party code and software before using them to ensure these were not tampered with or manipulated”.

For vendor-sourced products, customers must either rely on the vendors’ own assurances that all the code they use is secure, or have some way to validate the vendor’s supply chain security independently.

There is evidence that some larger Australian organisations are going down the latter path. CBA, for example, has noted publicly the “need to take a broad view when assessing the risk vendors pose”, and to go beyond vendors’ assurances by running independent due diligence on claimed protections and controls.

Risk assessments are critical because if you use software from a vendor that has security problems, you will inherit them into your ecosystem and bear the consequences. Any assessments undertaken should include assurances and detailed plans about how those in the software supply chain plan to release secure program updates with verified certificate signatures, and how they will help to manage the identities of all of their software and devices. It should also demonstrate a clear path for cryptographic upgrades and updates for their products.

An initiative of the US government may, in future, also assist in this regard; responsible vendors (and indeed organisations as well) may increasingly publish a list of all the coded “ingredients” that make up their products. The format for this, the software bill of materials or SBOM, is still a work-in-progress, but promises to bring additional transparency to the area.

Getting developers to secure code

A different approach to tackling the problem – and indeed, one we think constitutes the next big step in really improving the software supply chain – is for vendors themselves to implement secure coding certifications for developers that create and update their products.

The impact of software developers, and the need for them to have verified security skills and awareness, tends to be forgotten in an industry that is tools-obsessed, rather than focused on people-led defence through key security skills.

In recognition of the role of developers as a critical component of software supply chain security, vendors should assess how they can encourage secure coding and continuous improvement within their development community, and ideally create ways to benchmark skills and current training.

We know that emphasis on developer upskilling is improving, but according to a research report conducted by ESG, 48 per cent of developers have admitted to knowingly shipping vulnerable code. Factors such as time constraints, and the reality that security simply isn’t a top priority (nor a measure of success) in their world, contribute to an environment where code-level vulnerabilities are not addressed as early as they should be.

If we’re to stop them from infecting the software supply chain, every organisation needs to commit to a more developer-friendly security program. Until we reach a point where developer enablement in secure coding is the norm, we’ll always be behind in closing windows of opportunity before threat actors can peer in.

Matias Madou is the co-founder and CTO of Secure Code Warrior.