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

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

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 pipelines humming, the last thing you want is for security to slow things down or complicate the existing workflows.

We’re taking a look at secure SDLCs and the CI/CD pipeline - and how security tech and processes can better fit into the current development way of working. Ultimately, making things simpler and better for developers.

How current security testing causes further work for teams

The way security testing is conducted and modern software development is handled aren’t perfectly aligned. This clash of approaches can cause further work and delay between security and dev teams. 

For example, when it comes to container security, there are lots of good commercial and open source security tools that can take a container or a registry and examine them for known security vulnerabilities.

Typically, security tools approach this task on an image level. They take the image, find the vulnerabilities, return a list of them and the job is done. If you update the image or wish to check the image again after a period of time to know if any new vulnerabilities have been detected by the industry on this image, you can run the image through again. 

If you have a registry, the security tool can look at all the images and tags and report on all of them. This can result in a large list of vulnerabilities - issues that were unforeseen and now have to be addressed.

Developers will work with container images differently. Each image is a resource and that image may be used on one project, many or it may not be used at all. But how do you know if a particular image is used in a project? 

While members of the development team may not be keeping track of all the images they use, it’s likely in the logic of the projects’ CI/CD pipeline, where the image names/tags are specified during the build/release.

So, on one hand, we have reams of security issues reported against images or the registry. On the other hand, we have development projects that use some subset of those images.

Challenges faced

This poses a few challenges:

  1. Simply looking at the lists of issues from the security tools doesn’t give the right, holistic picture. Many of those issues will never come to light due to the images not being used. This time wasted on fixing issues for containers that aren’t used is time that could be spent on further development.   
  2. Not knowing how many times a container is actually used in projects can hide the effect any issues would have. Remember, you’ll have lists and lists of issues to work through and simply working down through the individual risk or CVSS of each issue is the wrong approach. It could well be that an issue that’s not top of this list exists in a container that’s used by 50 projects, which should be prioritised to be fixed first. 
  3. The real risk of a security vulnerability isn’t just based on the technical bug but includes the sensitivity of the data processed (PII, financial, healthcare) and the scope of the project. For example, is it used by five internal people or 50 million people around the world?

How to effectively work through the issues

For each of the issues found, knowing where - or if - the affected component is used, what it’s used to process and the scope of each project using it, is the best way to effectively work through the issues from top priority to bottom.

This disconnect is exacerbated by codeline versions - with libraries and containers that are likely to change often. If we’re adding extra steps in our processes to onboard new codelines or containers into lots of security tools on every change, then that’s quickly going to become an impossible task.

Dealing with a security check on the image/tag

Let’s look at another aspect. Let’s assume we’ve set up our pipeline to security check the image/tag when doing the build. In this case, we have a good chance of finding issues early, but we’re going to waste a lot of cycles checking the same image over and over again. This poses a few issues.

1. Checking the image again and again

If this image is used by 20 projects and we do a release a day, we’re going to check that same image 20 times each day. This not only delays the security results in real-time but likely costs more due to security tools charging for the time they’ve analysed the containers they’re given.

It can be difficult to align these. Most security products ask you to onboard items to be tested (such as containers, repos, URLs and EC2s, for example) so they can test and report on them. However, doing this initial onboarding can be difficult, especially if the dev team doesn’t have a full understanding of what codelines and images they’re using. 

Even if they do, it’ll quickly get out of sync when someone updates the project codeline or image in CI/CD and doesn't update the onboarded profile in the security tool - you’ll now be reporting security against the wrong thing.

More regularly, we see the truth of what assets are used in a software project that is held in the pipeline, that’s where the codelines, URLs, images and boxes that are actually used are configured. Configuring security tools outside of this will lead to misalignment and reporting on issues/risk that doesn’t match up to the reality of the software project. 

2. Extra work for the Dev team

Checking this security and dev context also adds extra tasks onto the development teams who are making these changes, frustrating people further.

Things change. Teams introduce new technologies, frameworks and libraries. New teams start using other coding languages. The business buys another company that develops in ways no one else has used before.

Typically, the security tooling is tied to the tech being tested. Tools that check AWS for security don’t tend to work on GCP or Azure. Tools that check Python code won’t find anything in C++. Even commercial tools that cover many languages will have differing levels of coverage for each language they handle.

More recent technologies like Dockers and Kubernetes have made some of the infrastructure easier. This then introduces new tech that needs to be secured.

That’s why when you’re faced with the need for a consistent security policy to be driven by your DevSecOps tech, there can be a battle with security tooling. The short answer is the development pipelines and configuration needs to be the driver. This contains the truth of what’s being built and means development can configure this once, as well as enable DevSecOps tools to work out how to run the necessary security testing.

How the Uleska Platform works through the issues

The Uleska Platform is set up to allow development and CI/CD configuration to drive security testing without adding additional work. Using a simple CLI (and APIs), the Uleska Platform can be updated in real-time with the codelines, images and boxes that are being used in different stages of the SDLC, so that it can then orchestrate the correct tooling to implement the security guardrails.

Ultimately, the Uleska Platform reports security information back to the CI/CD pipeline, as well as ticketing systems like Jira and Slack.

This not only saves time, since neither development nor security needs to onboard or configure the elements of the project, but it means issues being returned are real and not a legacy of an old component of the project.

To discover more about the challenges of automating DevSecOps and how to overcome them, check out our playbook. 

Learn more about the challenges of DevSecOps

One of the challenges with DevSecOps is incorporating many layers of security tasks into the fast-paced software development cycle. This slows down the pace and causes a variety of problems. Luckily, there are a variety of things you can do to overcome the challenges faced. In our playbook, we cover the top 10 challenges of automating DevSecOps, while also delivering actionable advice on how to overcome them.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

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 AppSec testing

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

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 and DevOps: How to bridge 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 #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.