The UK government recently announced a public consultation on software resilience. Julia Lopez, the UK’s Minister of State for Media, Data and Digital Infrastructure called for views in a recent statement, noting that events like Log4Shell or the 2020 SolarWinds attack have “demonstrated the widespread impact which insecure software can have on businesses, charities, educational institutions and other organisations operating across the UK – and globally.”
Over the next few months, the consultation will call for views from experts, companies, professionals in the field, academics and others to offer guidance on how to move forward. It couldn’t come at a better time. Software security – and the security of the software supply chain – is now an issue of public safety.
How small vulnerabilities become big problems
Risks around software no longer just endanger one business but exist within a complex environment in which vulnerabilities in one piece of code can spread – often undetected throughout an entire supply chain.
There are two forces here which have made software development a real issue for public safety. The first is the ever-increasing demand for new applications and services. For many companies, meeting that demand is a crucial way to stay competitive. As such, there is tremendous pressure on developers to build new software quickly and for security teams to approve it for release without taking all the necessary steps to ensure vulnerabilities don’t slip through the cracks.
Our 2022 Fall AppSec Indicator revealed the grievous problem that emerges from the overbearing market demands and internal pressure that these professionals face. Of 500 DevSecOps professionals, nearly half (45 percent) said that they skip crucial security steps because of this pressure. On top of that, 74 percent admitted that they regularly release insecure applications, and that 1 in 3 issues under remediation go to production without ever being caught.
The second is the ever-deepening interconnection of software systems. Developers regularly reuse software components – it’s a widespread practice and one that developers rely on to build software, pulling code from any number of open-source platforms such as GitHub. In fact, 70 percent of the average application’s code is open source. Unfortunately, much of that code might be old, out of date, or exploitable with emerging vulnerabilities.
If this was just one line of code in one piece of software, it might not be such a problem. However, code is often used multiple times and can easily spread throughout the software supply chain. As that code spreads, so will its inherent vulnerabilities.
Destructive tremors in the software supply chain
This can have destructive effects which rip through the software supply chains on which we all now rely. We’ve seen this multiple times in the last few years.
You might also like
Take Log4Shell, which continues to cause havoc. Log4Shell affects Log4j, an immensely popular open-source logging framework. This particular vulnerability allowed malicious parties to easily carry out attacks on vulnerable entities. When it was finally discovered toward the end of 2021, Log4Shell was given the highest possible CVSS severity rating. To make matters worse, researchers discovered that it had been actively exploited since 2013.
Log4j is so popular that the vulnerability affected hundreds of millions of systems and according to research from EY, 93 percent of cloud enterprise environments were vulnerable. Jen Easterly, director of the US Cybersecurity and Infrastructure Security Agency (CISA) described the vulnerability as “one of the most serious I’ve seen in my entire career, if not the most serious.”
While some widely-used open-source components contain serious vulnerabilities such as Log4Shell, malicious actors are also actively trying to exploit the open-source software ecosystem. Cybercriminals recently attempted to disguise their malicious code as NPM packages for the Material Tailwind CSS framework.
The problems and solutions lie in software development
Attackers will, as it is often said, always choose the path of least resistance. Unfortunately, many of the oversights made in software development provide such a path. This can come from the simple mistakes that developers often make when pushed to release, or it can come from reused code and open-source assets hiding undiscovered vulnerabilities. However, even those small errors in code, can echo out to cause far-reaching problems.
Still, these are fixable problems. Security is not developers’ primary concern, and yet they’re often expected to write secure code and fix existing flaws without the education to do so. Similarly, they often don’t have the right tools to assess the security of their code or review the risk profile of open-source components they might be relying on. Significant support from management is required to provide the necessary tools, training, and time.
All too often, security is still siloed at the end of development – but if we want to mitigate the risks that emerge during application development, it has to be woven into the process. Security testing and scanning has to be continuous throughout development to identify and mitigate any risks that emerge, whether due to insecure open-source components or security flaws introduced by developers. To support developers on their way to creating more secure code, application security tools should also be automated and accurate to help them keep up with today’s agile development processes.
The UK government’s public consultation on software security is a good sign. Businesses, governments and broader society rely on the security of the software supply chain and this public consultation is right to recognise the risks involved. We don’t yet know what the conclusions of the Government’s consultation will be; however, our experience shows that making continuous web application security a management priority within application development ultimately leads to a more secure software supply chain.