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

DevSecOps tool examples that will alleviate your workload

Nowhere is this more apparent than in DevSecOps where developers and releases outnumber security experts by thousands to one. It’s simply not...


What is CI/CD? A Complete Guide to CI/CD

Software development cycles have changed immensely in the last ten years. New practices and design philosophies are being tried every day. One of...


How to source the right tools to scale an AppSec programme

Everyone’s development is different, it stands to reason everyone’s perfect security toolkit will also be different. But finding the right tools to...


What is Penetration Testing (Pen Testing)?

Penetration testing (also known as pen testing) is the process of checking if your infrastructure and applications are robust enough to protect...


What is Dynamic Application Security Testing (DAST)?

DAST, meaning Dynamic Application Security Testing, is a form of black-box security testing. It simulates external attacks on a live application,...


Ultimate Guide to DevSecOps

What is DevSecOps?  DevSecOps meaning (Development, Security, and Operations) primarily aims to automate security in each part of the software...

Company News, Security

Uleska and Log4Shell

Summary TL;DR: If you are a cloud customer of Uleska, you are not vulnerable to log4shell. If you are an on-premise customer of Uleska and are using...


The Top Application Security Tools in 2021

In modern businesses, applications have assumed a pivotal role. And while applications help with operational processes, the majority of cyber-attacks...


The Ultimate Guide to Application Security Tools

With the emergence of new software security threats, businesses need robust, flexible and affordable methods to ensure their applications are...


Introducing the DevSecOps Toolkit: A guide to scaling an AppSec programme

Imagine you’ve been asked to build a house from scratch. You don’t have any tools. You don’t have any experience. In fact, all you have is an empty...


What is Static Application Security Testing (SAST) and how does it work?

What is SAST? Static Application Security Testing (SAST), or static analysis, is a method of testing and analysing source code. This method allows...

Tools, Featured

Choosing the Best AppSec Tools: Advice from Experienced Engineers

In our latest webinar Gary Robinson and Martin Hewitt from Uleska gave us a fascinating and comprehensive look into how experienced security teams...

Managing Risk

How to Use Risk Based Security Testing [With Video]

Last week we discussed how using risk-based decisions can help speed up pipelines. You can watch the webinar on demand and read a summary of the...


Can DevSecOps Tools Open Security Testing To Everyone?

At Uleska, we focus on moving security testing away from experts running manual tests and move it to automating security checks into existing...

Company News

Start your DevSecOps journey with the Uleska free plan

Companies are developing and shipping software faster than ever before. The very nature of DevOps means that developers can work in an always-on...