Five reasons why your DevSecOps fails and how to tackle them

Your expensive scanners might be producing reports that nobody cares to read. Maybe you didn't even install the tools in the first place. At Nixu's Cyber Coffee webinar on DevSecOps, our cybersecurity gurus Ari Kesäniemi and Matti Suominen revealed five typical reasons why organizations fail at DevSecOps and how to solve these problems.

Reason 1: Security tools are just gathering dust

“But those tools are not finding anything useful.”

One of the typical reasons why DevSecOps fails is that the organization is lacking the time and expertise to configure their code scanners and dynamic application testing tools and tweak them to suit their environment. The first run of a new scanning tool will more than probably produce a lot of false positives and meaningless results. If you take the time to tag the false positives and reassess the rest of the findings, it will pay off later with sharp results.

Especially in large organizations, it can also be a good idea to dedicate a team that helps everyone out with the security tools. They can compare different products and see which tool works best with a particular technology stack, so you're not wasting your efforts. Remember to share your experiences with the tools to other teams, so they don't have to learn the hard way.

Reason 2: Nobody reviews the scanner results

OK, now you've bought that a state-of-the-art security tool that has cost you half of your security budget. Having it check every build creates that warm fuzzy feeling. Don't get too excited. Even if you had the tools configured to scan the right things, but don't have extra time in your development process to check the results, you are on the wrong track.

If you don't check the reports, you don't know what your security posture is. Even if the findings looked OK last week, the situation might be very different today. New vulnerabilities are published daily, or someone could have made a configuration mistake, leaving a gaping hole in your defenses. Historical returns are no guarantee of future returns, as they say in the financing business.

Reason 3: You’re drowning in reports

“The newest results are in your email, please check the report version 1.2.17a_MHa.”

Reviewing the reports, comments about fixes, and updated documents from retest rounds… times the number of security tools used by the teams. It can be pretty hard to keep up, especially if you're trying to see the big picture of what multiple product teams are doing. Instead of driving people mad by making them dig reports from the scanning instance filesystem or fishing out files from the ever-expanding inbox, you might want to consider an Application Vulnerability Correlation (AVC) tool. These tools that are sometimes also referred to as Application Security Orchestration and Correlation (ASOC) integrate testing results from multiple sources, help you remove duplicate findings, and provide a unified view to the vulnerability status of all teams. 

Reason 4: Nobody fixes the findings

"I don't know how to fix this nonsense about poisoned web caches and three-letter acronyms."

Let's face it, the descriptions of some security vulnerabilities are plain horrible, and depending on the tool, the remediation instructions may or may not be useful. Sometimes you need to dig deep to find and fix the actual root cause of the issue without breaking something else and still complying with all security and privacy requirements.

Anyway, it's the backlog that defines which tasks get done. If improving security is not on the backlog, it won't get done. Integrate the scanning tools or the AVC tool into your issue tracking system or backlog tool to get things rolling.

Reason 5: You forgot the human part of DevSecOps

"Can we now fire all the penetration testers and the security team and let the machine do the job?"

Automatic security testing tools are getting better all the time, and you can have them scan each build. Still, you cannot beat the human brain when it comes to misusing logic flaws. Let the machine do what the machine is good at – speedily and tirelessly reporting all the reoccurring simple mistakes – and let the human penetration tester focus on the more complicated problems. This way, your penetration testing efforts are better spent.

Besides, you'll still need people to run a vulnerability management process: estimate the severity of vulnerabilities, prioritize them on the backlog, and fix the issues – we don't have a tool for that yet. It's also good to remember that on top of all the testing, it's good to use threat modeling to identify potential weaknesses from the processes behind the system.