EXCLUSIVE: Software security – it’s time to rise to the occasion

Software security

Share this content

Amy Baker, Security Education Evangelist, Security Journey explains how to solve the software security problem for the whole SDLC.

When evaluating network security, application security also needs to be considered. Applications that are developed and sit on the network need to be secure – if they contain insecure code, vulnerabilities may be exploited, that then pose a risk to the network.

Often, individuals and teams in organisations oversee both network and application security. Therefore the solutions to solving the AppSec Dilemma are somewhat transferrable; continuous application security education and training that helps develop and cement secure habits can, in turn, help bolster network security.

Software security has been front and center of many discussions in the US recently. Alongside guidance from the NSA, CISA and OpenSSF on issues like typosquatting and SBOMs (Software Bills of Materials), the US government announced requirements for its software supply chain to attest to its compliance with NIST security standards. It was also a hot topic at this year’s Black Hat conference, with Chris Krebs stating in his opening keynote speech that he believes security is only going to get worse before it improves. He claims this heightened risk is a result of the benefits of insecure software far outweighing the negatives.

Krebs’ statement, unfortunately, accurately reflects the state of software security in today’s threat environment. Cyber-attacks are on the rise and the software supply chain is a common target for hackers. Yet instead of prioritizing security, the focus for many across the software development lifecycle (SDLC) is being the first to market.

Security is too often viewed as a roadblock to innovation, stifling quick moving application-development. However, this view is far outdated and it is crucial that innovation and security are viewed as synergistic. What’s more, it’s time for everyone across the SDLC to embrace a security-first mindset and see the value of ‘shifting left’.

Quantifying vulnerability risk

The software supply chain is an attractive target for cyber criminals. Take the Log4Shell vulnerability as a prime example; the open source Log4j is commonly used across the globe within applications and digital services. Yet exploiting the vulnerability was not a hard task. The compound risk of wide-spread damage and a relatively simple exploit put organizations around the world in a hugely vulnerable position.

And, we see this time and time again, like in the case of the 25,000 malicious plug-ins recently identified across WordPress sites. Many businesses think their applications are safe, almost completely unaware there is insecure code built into their services.

The good news is that the OWASP Top 10 provides a reliable breakdown of the vulnerabilities that pose the most significant risk. Yet some of these risks have been hugely prevalent for almost 15 years and organizations are still struggling to mitigate them.

Injection vulnerabilities, for example, held the top spot for over ten years and are still on the podium. This is far too long for a vulnerability that is relatively simple to avoid. It’s time the SDLC quantifies what this risk means and learns how it can be mitigated.

Speed vs. security

The AppSec Dilemma stems initially from a lack of investment. Software development is booming, while securing this software is rarely given the same importance. Instead, many enterprises focus on getting their product or application to market as soon as possible, in order to beat the competition and start serving customers.

However, this mindset of speed vs. security needs to be interrogated and corrected. It is simply not the case that to be first to market means to compromise security in the process, or vice versa. In reality, if security is considered from the beginning of the development lifecycle – as is the case with scalability and performance – organizations will avoid far more delays than if it is only considered last minute.

This is where the value of shifting left comes in. It ensures security is integrated from the earliest stages of the SDLC, avoiding time consuming vulnerability patching later down the line.

It is also more cost effective to shift left and integrate security from the get-go. According to Boehm’s law, the cost of finding and fixing a defect grows exponentially with time. Therefore, organizations that may be compromising security to cut costs will be doing themselves a disservice.

Overcoming the current AppSec Dilemma

Quantifying the risk from threat actors and correcting the speed vs. security debate are only two considerations for overcoming the ‘AppSec Dilemma’. There are also huge expectations put on developers today, yet very little secure coding training is available to them.

Over the last ten years, code demands on developers have increased 100x and 92% feel pressured to write code faster. Yet over half have zero professional training in how to code securely – and secure coding is not a requirement in the top 40 university coding programs in the US. The onus therefore cannot fall on the individual developer, who may never have come across the resources that help them learn to better their craft. Instead, organizations need to take responsibility for training their teams.

An integrated approach to secure coding education

The first step for enterprises looking to better educate the SDLC on secure coding is prioritizing a security-first mindset. This is not simply applicable for the development team but everyone that plays a role in getting software and applications to market. This includes DevOps professionals but also UX designers, product and project managers and those leading quality assurance (QA). Without everyone recognizing the value of ‘shifting left’, application security will come up against unnecessary roadblocks.

These teams not only need to know how, but why security-first is such a critical mindset. Therefore, integrated and continuous education on this topic is a must. While those creating code need foundational learning as well as hands-on exercises, everyone else should have access to basic application security education at the very minimum.

In other words, education needs to be tailored to each individual role and made relevant to the challenges they face in their day-to-day. There is nothing less engaging than a training program that is in an entirely different coding language, designed for someone with a lower experience level. Bespoke education initiatives can empower entire teams to think differently and make informed decisions that ensure security across every aspect of application development.

It is also key for this education to be a continuous and evolving program. The ‘one and done’ approach, where application security is merely a tick-box exercise, will fail to influence a security-first mindset. In order to ensure that secure coding is front of mind every day, all year round, repeating elements of training will help teams retain knowledge. This is particularly pertinent given that after 31 days, around 79% of learning is lost.

A great solution for guaranteeing engagement with ongoing education initiatives is by offering incentives and rewards for those ‘security champions’ within an organization. Recognizing the people that make a concerted effort to improve their security can be as simple as praise in management meetings.

It is also therefore key to measure results – like the number of vulnerabilities in a code before and after education programs – so that success can be highlighted. This evidencing has benefits twofold; it also makes justifying further education investment to the Board far easier once financial decision makers can see the business benefits of more secure coding knowledge.

Looking ahead

The AppSec Dilemma will continue to throw successful software development and secure applications into chaos if it’s not addressed soon. The mounting pressure on developers, alongside risk posed by issues like injection vulnerabilities and the lack of resource available to the SDLC for securing their code is at breaking point. It’s time to take action and make a security-first mindset a must.

Organizations need to see the value in shifting-left and educate their workforce appropriately – with continuous education that champions those driving changes. While the guidance and requirements we’ve seen recently from the likes of NSA and the US government is a great step in the right direction, now enterprises need to rise to the occasion and put the software security problem behind us.

This article was originally published in the December edition of Security Journal Americas. To read your FREE digital edition, click here.

Receive the latest breaking news straight to your inbox