Across the globe, healthcare has seen the largest year-on-year rise in cyberattacks (74 per cent).
Hospitals are at risk of heavy disruption to patient care, a mounting backlog of paperwork, and cancellations of thousands of appointments. And patient data is more sensitive than ever.
The surge of ransomware attacks against U.S hospitals during Covid, and the potential role a misdirected ransomware attack played in a German hospital patient’s death, have triggered warnings and discussions about the threat cyber attacks pose to real human lives.
We’ve already seen the havoc and disruption that cyberattacks can wreak to healthcare operations on a logistical level.
The infamous WannaCry attack in 2017 infected nearly 600 GP practices in the UK. Since then, the NHS has invested heavily in security – but is that enough to address new vulnerabilities?
Open source is everywhere – including the UK’s hospitals
One of the biggest cybersecurity challenges facing not just healthcare but all industries is open source software resiliency against malicious actors.
To put things into perspective, open source comprises 80-90 per cent of code in all modern applications.
There are lots of great reasons to use open source like the associated cost savings of open source software.
It avoids cumbersome licensing fees, and allows the developer community to collaborate on innovations for its applications.
The NHS itself has committed to adopting more open source software within its IT infrastructure, with an Open Source Guidance document for developers on GitHub, and a policy paper on its commitment to openness.
Even with these documents in place, though, the NHS could still be at risk if it doesn’t have full visibility of the risky components deliberately or accidentally containing vulnerabilities that malicious actors could exploit.
Cross-industry, many commercial consumers of open source are not managing their software supply chain in any centralised fashion.
Of the open source components being downloaded that are known to be vulnerable, 96 per cent of the time, there’s been a better, non-vulnerable version available.
The most glaring example of this is the log4j vulnerability discovered in December 2021, which cyber criminals ruthlessly exploited, leaving many organisations open to attack.
Since then, despite the high level of publicity surrounding the exploit, 40 per cent of organisations across the globe are downloading the vulnerable versions of the logging component to this day.
With cyberattacks in the healthcare sector rising at pace, this is a worrying figure and stems from a lack of incentive to act and a lack of visibility within organisations concerning the open source components in their applications.
But why is this relevant to the NHS?
There’s cause for concern given that the NHS’s digital transformation remains an underfunded initiative according to research from the British Medical Association.
Such under-resourcing has led to inadequate infrastructure and interoperable systems; IT specialists are struggling to gain a comprehensive overview of the disparate software and IT processes across hospitals.
When the fog is this thick, the risk of blind spots, particularly for open source software, becomes immeasurable.
Healthcare must invest in software hygiene
Now is the time for the NHS to invest in funding for tools that improve its visibility over the components being used in its software.
The first step is to make use of a Software Bill of Materials – a recipe-like list of ingredients that make up the software, not too different from what car manufacturers use.
When a car breaks down, mechanics need that bill of materials to identify and replace a damaged component. We should expect the same from software in healthcare organisations to identify vulnerabilities.
Log4j wasn’t an esoteric IT issue endemic within niche technology sectors.
Its impact was global and its mitigation proved a massive undertaking – especially in healthcare, where many security professionals lamented the difficulty of hunting down the component because of a complete lack of visibility into their software.
The use of SBOMs would have been hugely beneficial here.
To be clear, SBOMs are just the first step.
While SBOM use is starting to pick up – especially in the US, this will be a major transition period and a much heavier lift than many realise.
Security professionals in healthcare will stumble along the way, and open source projects would do well to adopt complementary security tools alongside SBOMs to reassure developers of their components’ security profile.
As part of this, IT professionals should make use of free certified tools like those outlined by the Open Source Security Foundations in its Concise Guides for Developing More Secure Software and Evaluating Open Source Software.
The healthcare sector will also need to invest in intelligence tools that allow it to detect and manage vulnerabilities – artificial intelligence will no doubt play a major role here.
The UK Government can – and should – help enforce best software practice
The UK Government has an opportunity to play a bigger role here in producing prescriptive guidance and clear standards that will benefit the NHS’s cyber resilience.
While the UK government has tried to recognise the importance of digital supply chain security, current policy doesn’t consider open source as part of that supply chain.
Instead, regulation or proposed policies focus only on third-party software vendors in the traditional sense but fail to recognise the building blocks of all software today and the supply chain behind it.
Until significant emphasis is put on improving open source practices on a national level, the government is unlikely to deliver on its objectives to improve cyber resilience.
In a time when the NHS has been besieged by under-resourcing challenges, security must not fall by the wayside.
The consequences of inaction could lead to an even greater burden for practitioners to deal with as service becomes disrupted by bad actors exploiting vulnerable software.
By Brian Fox – Co-Founder and CTO at Sonatype
Brian has extensive open source experience as a member of the Apache Software Foundation and former Chair of the Apache Maven project. Brian was a direct contributor to the Maven ecosystem, including the maven-dependency-plugin and maven-enforcer-plugin.
He has over 20 years of experience driving the vision behind, as well as developing and leading the development of software for organisations ranging from startups to large enterprises.