DevSecOps Challenge #4: Using DevSecOps to reduce and focus issues raised

  • Share on Twitter
  • Share on LinkedIn
  • Share on Instagram

One of the biggest challenges when rolling out a DevSecOps process is the volume of issues it can bring to light. 

From a development point of view, we don’t want the implementation of security in DevOps to give the dev team massive lists of vulnerabilities to check over on every build or release. We want to avoid anything that might cause unforeseen delays to keep everything on track - but we also want the application to be secure. 

For that to happen smoothly, security needs to be snug in the process. So, how can we turn the hundreds of issues these DevSecOps tools are going to spit back at us every pipeline, into succinct and important issues that we can fix quickly whilst working on the code in tangent?

  • Brave the first issue triaging  
  • Managing historical lists
  • Better understanding the risk of issues
  • Further reducing false positives

Brave the first issue triaging 

Assuming you’re not starting the project from scratch, running a bunch of security tools is going to result in a decent sized initial set of issues. With so many hoops that devs already have to drop through, they’re likely to be ignored. Or worse, it blocks the build or release and lets non-important security issues you’re already aware of get in the way.

All the AI/ML in the world isn’t going to remove non-issues better than a manual step, so here we recommend getting stuck in. Treat this first run as a normal security test. Expect 100s of issues and be prepared to go through them and mark the false positives, duplicates and issues that just aren’t important right now.   

To make this easier on future you, do this in a way that means these marked issues are programmatically recorded, regardless of the tools or scripts you're running. This means the next time you run the security tools through the DevSecOps process, they’re remembered and not flagged. Winner. By keeping them in an ‘invalid issue’ list, this means that instead of having a wealth of vulnerabilities reported, you’re only working with the small percentage of issues that are essential to resolve.

Manage historical lists 

Agile development is all about incremental changes. DevSecOps should be set up to work in the same way.

From above, we now know the (smaller) list of real issues currently existing in the project. Do we need to be alerted to those same issues in every pipeline run?  No, instead what we’re interested in is any changes - has our change introduced any new issues? Has it fixed any issues we expected to be fixed?

By automatically managing and recording the lists of real issues existing in every pipeline DevSecOps run, we can then concentrate on the differences. For example, say last run we had 100 issues. This is fine, it’s our security backlog, we know about it and have plans to burn it down. Now, in our new pipeline run, we’ve identified 102. 

This needs to be flagged up to make those new issues easily visible and actionable for all teams, regardless of the tools or script that flagged them. Enter DevSecOps issue tracking - matching previous issues consolidated from all the tools, with the current run, so differences can be easily flagged and handled. This is much better than trying to manually find the two new issues among the haystack of issues and tools. 

Better understanding the risk of issues

Even with new issues being worked out and reported, the step where we need to look at those issues often breaks the automation workflow. Do we focus on every new vulnerability? 

Ultimately, it depends. If they’re very low-risk issues that can wait until later, your team can prioritise big-ticket items instead. On the other hand, if these new issues are pressing and cause great risk for the app release, we really need to resolve them before going live.

Pioneering DevSecOps and security tools like Uleska, come with the ability to automatically determine the risk level of security issues. Going beyond CVSS, this takes all the laborious guesswork out of deciphering the major from the minor issues.  

Calculating this risk inline with the CI/CD pipeline means that we can further reduce the issues we’re alerted to in real-time. You can decide on a certain threshold of issue risk that triggers an alert or holds the build.

This further reduces that abundance of issues being reported by the security tools, keeping only the very few that we actually care about. If these issues were to be raised weeks later when the feature is released, you’d be back at square one and go through the workflow of coding, testing and releasing again. 

Getting alerted to these issues early on saves all teams valuable time. Time that can be put towards impactful app improvements.

This has been evidenced by Facebook, where a near 0% fix rate was seen when automated security checks were applied after release, compared to a 70% fix rate for the same automated security checks applied before release.

Further reducing false positives

When you delve further into security tools, there’s often a pattern in the issues raised - false positives.

What if there was a way you could setup your DevSecOps to implicitly identify these for what they are - potential false positives - and not flag them during the DevSecOps process? This would mean the relevant security personnel or developer could look at them later and raise an issue if they’re real.  

Think of those common header issues that are flagged or that issue type from that tool you often ignore because it’s most likely a false positive. Pre-empting them as likely non-issues means they still get addressed, but don’t hold up the pace of the development cycles.

The Uleska Platform implements many of the above concepts to effectively reduce the scale of issues raised during DevSecOps. It ensures development teams are alerted to the important issues and other, low priority items are handled in the background. Dev cycles are frictionless, unless there’s a major issue.  

The best part? This also helps combat the dreaded misalignment of dev and security teams, allowing them to work together since all the issues from each tool are captured and triaged in one, centralised place. 

Taking hundreds of issues and automatically filtering them down also saves a lot of time, for everyone involved. With the added advantage that when issues are fixed, they’re automatically removed from the list when the DevSecOps tools stop reporting them.


App security issues can be funneled real time during the CI/CD pipeline to make the number of issues significantly more manageable. Preempting any challenges you might come up against when implementing DevSecOps is essential. 

That’s why we’ve provided practical guidance for software security teams looking to save time when scanning and testing - all with as little friction as possible. Download your guide today to prepare for the security challenges your team might come up against. overcome the challenge of devsecops

Subscribe to the Uleska blog

You may unsubscribe at any time using the unsubscribe link in the newsletter.

Popular Articles
Visit the Blog

Open Source Security Testing Tools

Security tools are an essential part of software development today, especially with the ever-increasing number of attacks we see every year....


Security Orchestration Automation and Response (SOAR)

Security teams frequently struggle with the volume of alerts and issues they are tasked with daily. On average, most enterprises receive between...


Secure Software Development Life Cycle

Software development has evolved into an incredibly complex machine, with several moving parts to keep track of. Teams get more extensive, and...


Application Security Orchestration & Correlation

Application Security is a constantly evolving industry, with new threats and methods to combat them appearing regularly. One of the more recent...


Top 5 AppSec Productivity Hacks 2022

The application security (AppSec) industry moves fast. Development, security and operations (DevSecOps) practitioners are having to find creative...


How to improve security tool selection and customisation with Uleska Toolkits

We know starting your application security (AppSec) journey can be a little overwhelming. After all, choosing your tools from scratch and setting...

Application Security

What is Application Security? A Beginner’s Guide

What is Application Security? Application Security is defined by developing, adding, and testing security features in an application or website....


Vulnerability Assessments in Application Security

Did you know that over 79% of developers surveyed in 2020 stated their applications had 20 or more vulnerabilities on average? As the digital world...


Defining and breaking down Vulnerability Management

No system is perfectly secure, as proven by software analysis firm CAST, which reviewed 278 million lines of code and discovered more than 1.3...

Company News, Featured

Toolkits: Taking the guesswork out of security tool selection and customisation

There are thousands of amazing AppSec tools out there, but this can be both a blessing and a curse. While the headway and innovation we are seeing...


How to eliminate risk when scaling application security

Building robust application security is a lot like building a house—you want it done thoroughly, without any missing parts. However, there is a...


What is the OWASP Top 10 and how to use it?

Cybersecurity has been a rising concern in the last decade. In 2021, researchers have seen 50% more attacks per week on corporate networks compared...


What is Shift Left? Ultimate Guide to Shift Left Security

With today’s fast development speeds, it’s hard to keep up with security practices for some organisations. This is especially true in the last few...


What is Software Composition Analysis?

Open-source software has become a vital part of development in the last decade. However, utilising these components often comes with several caveats,...


DevSecOps tool examples that will alleviate your workload

The saying goes: “Many hands make light work.” Nowhere is this more apparent than in DevSecOps where developers and releases outnumber security...