DevSecOps Challenge #1: How to approach DevSecOps security automation

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

DevSecOps encourages security tasks to be wrapped and enabled with software development and operations tasks. The aim is to make them as seamless as possible while adding security value - and not more work.

Identifying vulnerabilities is essential but it’s also time-consuming and often costly. Staples like CI/CD tools have seen widespread adoption, serving as a wake-up call for development teams about the genuine need for secure code at speed. How do companies and teams answer that call? 

  • Find your stride with security automation 
  • Aim for a centralised security space
  • Give your team their valuable time back
  • Consider the longevity of your security solutions 

Find your stride with security automation

Many companies are working to achieve automation that works and adds value - all without adding more tasks to the security personnel to run it. 

When you move to security automation, you’ll find some security tasks that can be automated and others that are much harder to fit in. Architecture reviews and threat modelling can be challenging to automate and their heavily manual nature doesn’t allow for much labour saving. 

Although a core tool for analysing security and identifying potential vulnerabilities, penetration testing has long suffered from the restraints of manual processes. Nobody wants to be shackled to this mundane yearly testing that doesn’t always give you the insights you need to move forward. 

DevOps teams need the right software stack to fully realise DevSecOps or security by design. To be an effective addition, security tools must smoothly integrate with existing workflows. 

This typically comes down to the following five categories of security checks or tools:

  1. Static application security testing (SAST): Analysing an application from within, taking a closer look at the source code, byte code and binaries rife with typical security vulnerabilities.
  2. Dynamic application security testing (DAST): Mostly used to detect security vulnerability for exposed HTTP and API interface of web-enabled applications.

Working similarly to IAST, RASP and similar tools, they all have their strengths when it comes to false positive rates, deployment and feedback. 

  1. Software composition analysis: An important offshoot of SAST which focuses on 3rd party components of code for known vulnerabilities and licensing issues.
  2. Container analysis: These are your dockers, Kubernetes, etc. and they’re full of known holes. They can be used to harm you or just get flagged to give the dev team something to occupy themselves. 
  3. Infrastructure: The beloved cloud and on-premise solution; who doesn’t miss the days of needing to put a jumper on to go into the machine room? 

Depending on what you’ll do with your DevSecOps program, you’ll likely need a combination of the above tools to give yourself adequate coverage. When you then examine the gaps you have in security testing and correlate against the types of issues you find in your processes, you can then add further security tools to your DevSecOps to increase failsafe. 

Aim for a centralised security space

Are you currently working with a range of tools with unique outputs and triggers in each environment? See how unproductive that sounds? 

Often the data generated from siloed tools has entirely different outputs, files, terms and even how the data is formatted. This can be a nightmare to make sense of. 

Making it easier to see what’s going on and where your current risk lies by consolidating security tools in a central platform is the way to go. This lowers the exposed vulnerabilities, ensuring it all runs smoothly and you can rely on visibility when developing. 

Give your team their valuable time back

Everyone generally agrees that DevOps teams must adopt cybersecurity best practices, but everyone has different ideas of what that exactly means. With a well recognised skills gap in cybersecurity, security experts are in short supply. Often vastly outnumbered by developers too, they’re responsible for the security of code they played no part in writing. 

Even when they can carry out the testing, they’re seen as a bottleneck that slows down the whole process. 

Issues found manually by skilled penetration testers can be scripted up and added to your DevSecOps tech, facilitating all-important continuous improvements with time and each interaction.

We’ve seen this numerous times: an issue is found in one project, a script is created and run against other projects where the same issue exists. Think of the time saved in discovery and remediation tracking of that issue, not to mention the DevSecOps program has further reduced the risk for the company.

There are automated market-leading solutions that are happy just to get to work without any real need for maintenance or management. They can trigger tools to work at the right time depending on the outcome it finds - again, without any manual input needed. 

This gives you and your team valuable time back to focus on what’s important.


Consider the longevity of your security solution 

If we go back a few years, container and Kubernetes security were nowhere to be found in a standard security program, yet they’re now commonplace. Go back further and cloud security would have been a specialism to only a few. But like the business needs of today, the landscape has changed. 

What hasn’t changed is security requirements. The automation opportunities, infrastructure and integrations available certainly have.  

DevSecOps programs need flexibility built-in as standard to accommodate different types of security tools and allow security programs to mature without needing to be reinvented. There’s no use employing a system that doesn’t fill all the gaps. 

Let the security processes and tech drive the security tooling used, rather than letting your security tool limitations affect your security processes. The first step is understanding what guardrails you’re looking for and work towards making that a success. Avoid setting yourself up for security failure by being aware of the challenges you’ll encounter.

Overcoming the security automation challenges you’ll face

It’s no surprise that when you strive for security automation, you’ll find some tasks can be automated and others that are harder to accomplish.

That’s why we’ve provided practical guidance for software security teams looking to save time when scanning and testing software - all without slowing 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 #2: 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...

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