Software development always ignores security. This must change soon

If any event has demonstrated how vulnerable organizations and infrastructures around the world are to software vulnerabilities, it’s Log4j.

The critical zero-day vulnerability in the Java Apache Log4j logging library allowed attackers to execute code remotely to gain access to devices and networks. And because open source software was embedded in a wide range of enterprise software applications, services, and tools, it had the potential for widespread, long-term disruption.

No wonder the director of the US cybersecurity and infrastructure agency CISA Jen Easterly described the vulnerability as “one of the most serious I’ve seen in my entire career, if not the most serious”.

Security patches were quickly rolled out and organizations quickly decided to apply them, although the ubiquitous nature of Log4j’s open source code means that there will be software and applications that will not receive the update, especially if no one realizes that Log4j was part of the development. process.

Log4j is just one example of serious security vulnerabilities discovered in software that’s been in use for years – and it happened 20 years after Microsoft boss Bill Gates released his Trustworthy Computing memo. , which urged Microsoft developers to produce more secure software after various bugs and security flaws were discovered in its operating systems and products.

“Ultimately, our software should be so fundamentally secure that customers don’t even care,” Gates wrote.

Two decades later, and although Microsoft Windows is generally considered a fairly secure operating system, when used properly and security updates are applied, even Microsoft cannot escape critical code vulnerabilities. . And more broadly, there is still far too much insecure software.

Software has always shipped with bugs, but software and services have become increasingly important in our daily lives, making the potential impact of security vulnerabilities even more damaging.

In many ways, software development has not evolved to cope with this new reality: products are still being deployed, only for vulnerabilities – sometimes major ones – to be discovered much later. And when it comes to a somewhat obscure component like Log4j, organizations may not even be sure if they are affected or not.

“Intrinsically, the way we develop software lends itself to bugs and defects,” says Rob Juncker, CTO and head of software development teams at Code42, a software security company.

“The accelerated work pace we live in contradicts the best practices of most security teams.”

Cybersecurity wants to secure software, a process that requires investment, personnel and time. This often goes against the requirements of companies that create software: they want to make sure the code is working and release it as soon as possible, especially if new products or features depend on it.

TO SEE: A winning strategy for cybersecurity (ZDNet special report)

The state of security is wildly uneven across the industry, with pretty good security at some of the top vendors, but the vast majority – even the very well-funded ones – lack basic security investments, says Katie Moussouris , CEO of Luta Security .

“Unfortunately, we have seen an underinvestment in cybersecurity over the past 20 to 30 years,” she says.

What companies need to do is ensure that cybersecurity is built in from the start and is the building blocks of a software development program at every step of the process – that way all risks and potential risks can be considered and dealt with before they become problems down the line.

“If you think about how software is created, deployed and maintained, it’s a whole supply chain. And it starts when you’re designing software or thinking about new features,” says Jonathan Knudsen, strategist principal in security at Synopsys. , a software security company.

“In the design phase you have to think about security, you have to do threat modeling or architectural risk assessments, so before you write any code you just think about how it’s going to work and what what he’s going to do – – and how he might be attacked,” he added.

TO SEE: Cybersecurity: let’s get tactical (ZDNet special report)

Bosses may be reluctant to spend the extra time and resources ensuring code is delivered safely, but in the long run this should be the most efficient approach, both in terms of cost and reputation.

It’s safer to make sure the code is secure before it’s released, rather than having to deliver a critical update later, which might not even be applied by users.

The problem is that many organizations are so used to a development model where speed is key, and the risks for them to produce poor code are considered relatively low.

This could mean that more hands-on intervention is needed to encourage secure code – and penalize those who deliberately ignore security issues.

“In other industries where we have such a critical dependency, we have regulated those industries, but software has remained largely unregulated, so there are no software liability laws,” says Moussouris.

There has been some movement in this area: for example, the UK government has proposed legislation that will require manufacturers of Internet of Things devices to follow a set of software security rules before products can be sold.

However, government is changing at a slower pace than industry and even if the rules are enforced, there is already plenty of IoT software that would not meet the requirements.

But as organizations and individuals become more aware of cybersecurity issues, the market may force organizations to take software more seriously, leaving software developers who don’t think about security left behind.

“Globally, we’re becoming more aware of software security, so I think that’s going to translate to buyers asking their builders harder questions,” Knudsen says.

It is therefore vital for software developers, their customers and even society as a whole that software security is taken seriously. Perhaps “act fast and fix problems” could be a new motto for developers to aspire to.


Gordon K. Morehouse