Security pros face great challenges in managing all the products and tools they use to handle the cyber risks they face. How should they split the budget between tools and people? What suite of tools will work best for the existing technology stack? With so many options, there are no easy answers, and choosing the wrong options can cost time and money later.
A recent report found that the application security tools market will experience explosive growth between now and 2025, a strong indication of its undisputed role in successful DevSecOps practices and increasing industry relevance in the face of growing volumes of code with potential security vulnerabilities.
Unfortunately, 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 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 DevSecOps, it’s inevitable that multiple scanners, monitors, firewalls, and all manner of AppSec tools get purchased along the way. Although 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 it implies.
With budgets and expert resources increasingly limited for the scope of work required, trying to undo the mess and find the best tooling path forward has become 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. The bottom line is that an unruly toolset, no matter how new and shiny, doesn’t allow an organization to ‘plug and play’ into a functional DevSecOps process.
- Scanning tools are slow, which impacts release agility.
Achieving security while coding at speed has become very challenging for many organizations, and we’re still trying to get that right even as we urge a DevSecOps approach. Meticulous, manual code review might have worked as the security failsafe in the 1990s, but at a time where we’re churning out lines of code in the hundreds of billions, it’s too slow and not very effective.
No singular tool finds every vulnerability, and there are a few glaring issues with the results a security team typically receives following a scan:
- There are too many false positives (and negatives), ensuring a security expert still has to sit there and do a manual review to sort the real bugs from the phantom bugs.
- Far too many common vulnerabilities are revealed that should have been picked up before the code was deployed. Do companies really want their very expensive security experts distracted from big, complex security problems with the small stuff?
- Scanners find issues, they don’t fix them.
Even in an organization that’s doing its level best to meet cybersecurity best practices and include security in every stage of the process, if their dependence is on scanners they will fall short of true DevSecOps success. It stands to reason that corners are cut, and that usually comes in the form of relying on the bare minimum of tools that cannot possibly cover every potential risk.
- 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.
- It’s hard to strike a balance between tools and people.
Companies embracing DevSecOps strive to make security a shared responsibility, and for organizations that create 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. The best results are achieved by working to keep security front-of-mind for the development team, upskilling them, and building a positive security culture that’s human-led, with a tooling suite that works to complement their efforts.
Matias Madou, co-founder and CTO, Secure Code Warrior
