29
Fitting DevSecOps into CI/CD Pipelines
Put simply, the goal of CI/CD pipelines is automation and a key goal of DevSecOps is to alert someone to a problem as early in the automated-delivery process as possible. It’s no wonder it’s a business priority, with many quickly realising DevSecOps is not just about plugging a few APIs into a CI/CD pipeline and calling it a success.
For those entangled in laboursome, traditional security measures, DevSecOps is a breath of fresh air. Security can no longer be secondary, here’s how to incorporate it into your pipeline.
Failure is part of the tech transformation process. Only through trial and error can you keep innovating. It’s a key part of the journey to DevSecOps.
Don’t let your vision be limited by a silo. We’ve seen so many companies that have automated a portion of the security process in a pipeline realise that other valuable parts of the security process were missed and have caused a failure to make the automation effective.
There’s a number of tasks that would need to be performed in any security testing. Between the time a developer pushes their code to the time it goes live you need to make sure you’ve successfully:
We’ve seen examples of DevSecOps pipelines that don’t make it as far as step two, by hooking in a number of security tool APIs. What this results in is a mass of issues sitting in a bunch of security tools that no-one is looking at.
If a security vulnerability comes to light and no-one is around to view it - does it even exist?
In effect, it doesn’t.
This is one of the reasons why the recent US Executive Order directly mentions the checking and remediation of security issues before release. See section 4 (e) (iv):
employing automated tools, or comparable processes, that check for known and potential vulnerabilities and remediate them, which shall operate regularly, or at a minimum prior to product, version, or update release;
Similarly, what can cause friction when shoehorning DevSecOps into your pipeline is completely automating vulnerability management, which comes only after security tools have been run manually by a separate security team.
With CI/CD pipelines running in minutes and the response time of overworked, understaffed, security teams being measured in weeks - you’ve guessed it, this tends to not work either.
To keep everything sweet between development and security teams, you need to implement effective security guardrails to provide low friction and low effort automation security checks.
During the CI/CD pipeline there are a few questions being asked of DevSecOps, which the process and tooling need to be able to answer.
Nearly every security tool out there is built with a different mindset from DevSecOps. They run, find a bunch of issues and return something convoluted back.
Okay, you’ve got some new issues being flagged up, what do you do with that?
Do you go to the security team for input?
No, because that’s a manual step and your aim here is to automate DevSecOps.
You need to develop solutions that don’t overwhelm CI/CD pipelines, yet allow flexibility for differing tech stack, security tools and environments. There’s a bunch of risk prioritization steps you can take to quickly and automatically determine if a new reported issue is a ‘must fix’ or a ‘who cares’.
“Yes, we already know there are already a few hundred issues in this project, we’ve accepted that and it’s in the backlog!“
What we’re asking in DevSecOps is, have the latest changes caused any new and important security issues that we should report and worry about before going live?
To answer this, not only do you need to collect lots of info from typically lots of tools (in whatever format they return their results in), but you also need to work out what the difference is from the last run.
To facilitate the automation of this prioritisation, the Uleska Platform includes cyber risk modules that assign effective risk against every issue returned. This risk prioritisation logic is then configured outside of the CI/CD pipeline logic, meaning it can be changed seamlessly.
The CI/CD pipeline logic can have easy and consistent logic applied to make decisions based on the information returned. It’s just one way we can secure your software at speed and scale.
Traditional security professionals operate in a silo, with capacity limited by the number of security personnel inside it. Scaling manual processes is already an uphill battle so embracing the agile nature of DevSecOps has never sounded so good.
The framework focuses on the leverage of automation throughout the process. Leveraging DevSecOps practices and CI/CD pipelines enables organisations to respond to security and reliability events quickly and efficiently. Producing resilient and secure software on a predictable schedule and budget is every dev's dream.
Always remember, no standard implementation of a DevSecOps environment or a CI/CD pipeline exists that works for everyone.
Automation, armed with security, ensures that the best days of software delivery are ahead of us. Overall, your security arsenal enhances your credibility in the market and builds trust with consumers. With that in mind, there’s no better time to start preempting any challenges you might come up against.
Devising a framework that supports the ultimate goal of adopting DevSecOps practices mature enough to support fully automated CI/CD pipelines is no easy feat on your own.
That’s why we’ve provided practical guidance for software security teams looking to save time when scanning and testing software - all without slowing down the delivery. Download your guide today to prepare for the security challenges your team might come up against.
Read the whole playbook here