A version of this article appeared in SC Magazine. It has been updated and syndicated here.

‍

One of the many conundrums faced by today’s security specialists is figuring out the balance of solutions they will use to handle the cyber risks they face. How should the budget be split between tools and people? What suite of tools will work best for the existing tech stack? With so many options out there, there are no easy answers, and choosing the wrong options will cost time and money later.

A recent report revealed that the application security tools market is tracking for ‘explosive’ growth between now and 2025, a strong indication of their undisputed role in successful DevSecOps practices, and increasing industry relevance in the face of growing volumes of code with potential security vulnerabilities.

There is a somewhat curious problem, however. Nearly half of all organizations knowingly ship vulnerable code, despite using an array of AppSec tools designed to stop just that. For products with an undeniable market demand gaining rapid traction, it makes little sense. Why would so many buy into sophisticated security tools, only to ignore their findings or not use them at all? It’s a little bit like buying a beachfront home, only to sleep in a tent in the woods.

There are a few reasons why AppSec tools are not being utilized as we might have come to expect, and it’s less about the tools and their functionality, and more about how they integrate with a security program as a whole.

More tools do not equate to fewer problems.

As companies evolve their software development processes, moving from Agile, to DevOps, to the holy nirvana that is DevSecOps (hey, for now, it’s the best we’ve got), it is inevitable that multiple scanners, monitors, firewalls, and all manner of AppSec tools get purchased along the way. Though it may seem like it’s a case of ‘the more, the merrier’, very often this leads to a tech stack that resembles Frankenstein’s Monster, with all the unpredictability that this implies.

With budgets and expert resources that are increasingly limited for the scope of work required, trying to undo the mess and find the best tooling path forward is a daunting task, and the code needing scanning and remediation just keeps on coming. It’s little wonder that many organizations have had to keep shipping code, though it’s rather alarming, and still poses an immense risk to our data and privacy.

Scanning tools are slow, and this impacts release agility.

Achieving security at speed is something of a white whale in software development, and the truth is, we’re still trying to get that right even as we usher organizations into adopting a DevSecOps-oriented approach. Meticulous, manual code review might have worked as the security failsafe in the 90s, but in a time where we’re churning out lines of code in the hundreds of billions, it’s a plan that is about as effective as preparing a football pitch with a pair of nail scissors.

Scanning tools automate the process of finding potential issues, doing that meticulous code review part for us. The problem is that they are still slow in the context of a CI/CD pipeline firing on all cylinders, and no one tool finds every vulnerability. There’s also a couple of glaring issues with the results that are spat out at the security team following a scan:

1. There are a lot of false positives (and negatives)
2. Some poor security expert still has to sit there and do a manual review to sort the real bugs from the phantom bugs
3. Quite often, far too many common vulnerabilities are revealed that should have been picked up before the code was deployed. Do you really want your very expensive security experts distracted from the big, hairy security problems with the small stuff?
4. Scanners find, they don’t fix.

Even in an organization that is doing its level best to work to cybersecurity best practice, and move with the times to include security in every stage of the process, the above process is still a showstopper if scanners are the main protective measure, and too many common bugs trip up the team in deploying safe code. It stands to reason that corners may be cut here, and that usually comes in the form of relying on the bare minimum of tools that cannot possibly cover every potential risk, even if a suite of solutions have been purchased.

Some tech-lead automation can lead to diminished code quality

Scanning and testing bear the load of automated processes in AppSec tooling, along with essentials like firewalls and monitoring, but other common tools can inadvertently erode the hands-on security foundations over time.

For example, RASP (runtime application self-protection) technology is often applied to harden security posture without sacrificing coding speed. It operates in the runtime environment of an application, protecting against malicious code input, real-time attacks, and flagging any odd execution behavior.

It’s certainly a layer of additional protection, but if thought of as a failsafe against any potential weaknesses in the codebase, developers can become complacent, especially when faced with increasingly impossible go-to-market deadlines in pushing out new features. Secure coding practices may not be followed, with the assumption that self-protection in runtime will detect any mistakes. Developers don’t go out of their way to create insecure coding patterns, but security will often be deprioritized in favor of feature delivery, especially with the assumption of an automated safeguard.

Tools can fail (and in the case of RASP, often run in monitoring mode to avoid false positives, which in turn only provides visibility – not protection – against an attack), and when that happens, it is high-quality, secure code that can be relied upon every time. Security awareness in every role that touches code is fundamental to DevSecOps, and developers not training in or producing secure code is a mistake. Secure and insecure code requires the same effort to write; it’s gaining the knowledge to code securely that takes the real energy. Time spent implementing and optimizing RASP can be much better utilized in upskilling developers to not make the mistake in the first place.

Balancing tools and people: it’s not a silver bullet, but it’s the closest we’ve got (for now).

The main ethos of DevSecOps is making security a shared responsibility, and for organizations that are creating the software that powers our lives -- everything from the electrical grid, to our doorbells -- they need to bring everyone on the journey to ensure a higher level of safety.

Tools won’t do it all, and it’s not even the cheapest way. By far the best results are achieved by prioritising relevant security training for everyone touching code, actively working to keep security front-of-mind for the development team, and building a positive security culture that is human-led, with a tooling suite that plays a supporting role.

Even in the face of time constraints, cut corners, and other things that make security experts lose sleep at night, if developers don’t introduce common security defects in the first place, then those tools (and whether they are used or not) represent far less of a risk factor.

‍