DevSecOps Challenge #2: Fitting DevSecOps into CI/CD pipelines

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

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. 

  • How not to incorporate DevSecOps
  • Implementation of effective security guardrails
  • Embracing the agile approach 

How not to incorporate DevSecOps

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: 

  1. Ran all the relevant security tools against the relevant assets
  2. Collected all the issues together from each individual tool 
  3. Triaged the issues to understand any new risks introduced 
  4. Prioritised the new highlighted issues 
  5. Communicated the issues, stats and data back to the CI/CD process and to any other messaging systems

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. 

Implementation of effective security guardrails

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.

Embracing the agile approach 

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.

Pipelines and problems: employing DevSecOps successfully

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.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
Managing Risk

Speed up Pipelines Using Automated Risk-Based Decisions

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...


DevSecOps Challenge #10: Communication between teams

Adding automation to one part of a process can then flood another part of a process. With DevSecOps, we’re allowing more security tools to find more...


DevSecOps Challenge #9: Security metrics, insights and continuous improvement

Many security departments and management teams want to improve their processes. DevSecOps introduces the ability for much more granular measurements...


AppSec ❤️ DevOps: Bridging the DevSecOps Disconnect

It’s a tale as old as time: developers want to ship an app but are lambasted with security requests, and security teams want to secure an app but are...

Managing Risk

DevSecOps Challenge #8: Adding risk prioritisation to your pipeline security

DevSecOps increases the number of issues found and the speed at which they’re to be dealt with. In reality, only a small number of issues will pose a...


DevSecOps Challenge #7: Mapping security automation to how development works

All teams present in the app development process have pressures on them to get work done fast and efficiently.  With DevOps processes and CI/CD...


DevSecOps Challenge #6: The all-important triaging of security issues

Security tools can be noisy. In 20 years, we haven’t seen a single security tool return a set of issues that are 100% what needs to be worked on....


DevSecOps Challenge #5: Running too many security tools in CI/CD

DevSecOps involves setting up many different automated security tools to cover all bases. It’s not uncommon for organisations to run tons of security...


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

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


DevSecOps Challenge #3: Doing DevSecOps without constant CI/CD changes

Better collaboration between teams, faster time to market, improved overall productivity and enhanced customer satisfaction are just some of the...


DevSecOps Challenge #1: How to approach DevSecOps security automation

DevSecOps encourages security tasks to be wrapped and enabled with software development and operations tasks. The aim is to make them as seamless as...

Company News

Introducing Uleska: The Future of DevSecOps Automation Tools

Few industries have seen such scrutiny and shifts in recent years as cybersecurity. In an increasingly connected world, speed and agility throughout...