5 Common Mistakes in DevSecOps

Lately, DevSecOps has been an indispensable part of corporate AppSec programs. The rise of digital transformation and the increasing speed of software development processes has mandated the security to be more agile as well and the solution has presented itself in embedding security tests right into the SDLC.

However, we have been witnessing some common mistakes when companies try to architect their DevSecOps processes which might lead to unexpected complexities down the road.

Let’s dive into 5 most common mistakes that we have been observing these days.

1. Unplanned Automation

Let’s start with the most common mistake which is the easiest one to fix as well.

Even though automation is essential for successful DevSecOps adoption, we see a somewhat flawed approach in practice.

Kicking off scans within pipelines is no longer an issue as almost all security vendors now offer native integrations with the pipelines.

Still, merely triggering scans within pipelines in an automated fashion is considered as achieving DevSecOps whereas very little attention is paid to the optimal stage of SDLC where the scans will be kicked off.

In many cases, the intuitive go-to solution is automatically kicking off scans and checking for vulnerabilities in each code push to repository without thinking much about the sustainability of this approach.

With this approach, it does not take long before developers start to feel restricted and frustrated and start a riot. This quickly takes its toll on DevSecOps adoption since it is impossible to get to the point without having developers on your side.

The right approach is to automate security tests only after carefully examining the needs of applications and agreeing on the right approach with the development teams.

Keeping development teams out of the loop while designing automation is a bad idea and impedes the success of DevSecOps adoption in the long run.

2. Inaccurate Tooling

Under the management pressure of jump-starting an AppSec program, AppSec teams tend to pour significant money into expensive tools without carrying out proper PoV processes to understand how the tool fits with their needs hoping that the tools will point them in the right direction.

At the end of the day, instead of selecting the right tools that play well with the processes the organization has, the processes are decided based on the capabilities of the selected tools which is far from being the vendor-agnostic approach that is required in DevSecOps.

Do not forget that tools might and do change over time. So, instead of creating new processes every time a new tool is adopted, it is much better to select the right tools based on the agreed-upon processes.

The stellar performance of open source security tools in certain programming languages and environments has made them reliable options to mitigate the sense of urgency before bringing in a commercial tool and to start building processes without having to spend a fortune.

One-tool-fits-all approach simply does not work in DevSecOps and you need to understand your own technology stack and the way your development teams work for a healthy tooling for your DevSecOps processes.

3. Misconfiguration of Scanners

Once a deal is closed, most security vendors take a reactive customer support approach and focus on answering the questions of customers instead of proactively working on configuring the tool to maximize its performance in the customer’s environment.

Most of the time, it is mind boggling to see how much the quality of findings can improve with better configuration. A significant reduction in the number of false positives is a very likely outcome which is key to reducing the friction with the development teams.

So, instead of focusing on scans being automatically kicked off within pipelines, the first step should always be configuring the scanners which pays dividends in the long run by reducing the number of vulnerabilities to deal with.

Without proper configuration, having to eliminate hundreds if not thousands of irrelevant vulnerabilities becomes overwhelming and discouraging both for security and development teams.

4. Lack of Metrics

Due to the lack of metrics, “How secure are we?” is the most difficult question to answer in the IT space. For the same reason, it is hard to showcase the ROI of AppSec pograms while there is almost always organizational pressure to measure the success.

While it is not easy to gauge the level of your security posture, without well-thought metrics, it is also impossible to measure the effectiveness of your overall security program.

Creating metrics like time to respond or remediate a vulnerability and defining KPI’s for each metric shed light on how seriously the process is taken across the entire organization.

DevSecOps is a marathon rather than a sprint and you need to know what you are doing well and what needs improvement to get to the desired state over time.

5. Ignoring The Cultural Aspect

As much as a technical topic, DevSecOps is also a cultural concept that requires a collaborative effort and buy-in from all security, development and DevOps teams. Otherwise, it is only destined to fail.

In the real world, it is extremely common to see conflicts arising between development and security teams that resemble a tug of war where each team tries to hold its line and blame the other team for either bringing false positive vulnerabilities to their attention or not fixing the vulnerabilities in a timely manner.

This is especially the case when the security team works in a silo and makes decisions without convening with development or DevOps teams to brief them on the benefits of DevSecOps for higher quality applications and the potential risks of not doing it.

It is always a good idea to hold planning sessions where all stakeholders are involved where processes, metrics and KPI’s are mutually decided. Only after then the parties can be held responsible for not complying with the ground rules decided together.