How DevOps Can Use Quality Gates for Security Checks

Last updated at Wed, 03 Jan 2024 19:26:06 GMT

Your team has been working at all hours to put the final touches on code for a new big feature release. All the specs are in, the feature works as expected, and the code is pushed to production. A few hours later, the daily security scan runs and the alerts start piling in. What went wrong? And what do you do now?

Typically when this happens, it means rolling back the entire deployment, retroactively fixing the bugs and vulnerabilities in the code, and a week or two later, re-deploying. If you’ve ever been in this situation, you’re familiar with how costly and frustrating it can be. Or, if you haven’t, now is the time to get ahead and prevent it from occurring.

This is where quality gates come in. Traditionally, quality gates have been used to check the quality of the code itself, but did you know they can also be used to check for security issues within the code? In this post, we’ll explain what quality gates are, how they can be used for security, and ways to implement them so you can experience less downtime and build more secure products—faster.

What is a quality gate and how is it used for security?

A quality gate is most often created by DevOps teams to halt or fail a build if a certain threshold of issues is detected. By predetermining what constitutes good code from poor or subpar code, you can have a continuous integration tool such as Jenkins detect if code doesn’t meet your criteria. This PASS/FAIL criterion for software quality keeps your developers on their toes, mitigates issues in the software itself, and minimizes issues post-production.

To date, quality gates have only really been used to evaluate the quality of the code, not the security of the code. But as you probably know, quality code doesn’t always equal secure code, so if code isn’t given a full security scan before going into production, you risk facing the same exact issues and having to roll it back in order to fix it.

Instead, you can add security to the mix to ensure that you can build good code quickly and securely. In practice, this means that quality gates can be configured to stop or fail a build if the code doesn’t meet certain security standards. With security issues being detected alongside everyday code issues, they can be addressed at the same time so that when code is ready to deployed, you know it’s been given the green light on all ends. This allows security to be built into the product rather than as an add-on.

When is it appropriate to set up a quality gate?

It’s never too early to start using quality gates—especially if security is a priority for your customers yet viewed as a blocker to your developers. Bringing it into the fold is a smarter long-term move.

For companies who practice continuous development and release code often, quality gates are a good way to keep code honest and of a certain quality. This way, no matter how fast you’re running or how large your team grows, you can maintain code quality expectations from your developers. And if you’ve experienced quality issues in the past, quality gates can help to monitor for improvements.

If your company is looking to adopt DevSecOps, or shift security left into the software development lifecycle (SDLC), a quality gate is one way to do it. As we explain in this whitepaper), bringing security into the development cycle is a good idea for a number of reasons. Just to start, products become secure by default, issues are easier and faster to fix, and you can greatly reduce the chances that you’ll have to roll back a deployment. Quality gates not only make security easier for DevOps to implement, they also provide an efficient feedback loop by automating critical checks that would have to otherwise be done manually.

How to create a quality gate for security

If you’re using a continuous integration tool such as Jenkins, it’s easy to set up a quality gate of any kind. For example, you could set a policy that halts a build if more than 5 high severity issues are detected. To layer on the security component of this, you can configure the policy directly in Jenkins, then use a dynamic application security testing (DAST) solution like AppSpider to execute a scan of your application as a post-build action and report on the results. AppSpider is designed to integrate with this Jenkins plugin and AppSpider’s REST API, making it easy for developers to set up and for security to be integrated into the process.

AppSpider also provides powerful scan scoping configuration and support for multiple scan engines to balance test coverage and time it takes to complete the scan. This way, you can be sure security assessment of your application doesn’t unnecessarily delay the build pipeline.

AppSpider is also designed to hook into issue tracking tools like Jira so that if and when an issue is found, it can be submitted directly to a developer. The notification will indicate that there is a serious security issue which needs to be fixed before the build can be completed. This is a powerful way to get the attention of your developers and provide built-in motivation to fix it so that the product can go out in time.

Shifting Left with Quality Gates

Leveraging quality gates are a key way companies can shift left and build more secure products. The sooner security can be built into the SDLC, the more time development can save and the more commonplace security will become. Considering today’s volatile threat landscape, no company can afford to release code with potential vulnerabilities in it.