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.
Top comments (0)