What is DevSecOps?

DevSecOps integrates security practices into every phase of development, ensuring vulnerabilities are addressed early without slowing down your CI/CD pipeline.

DevSecOps highlights the importance of incorporating security testing and practices into the software development process. Shifting security to the left helps to ensure rapid delivery is not at the expense of security vulnerabilities.

Why use a CI server?

DevSecOps is an approach to software development based on the DevOps methodology. Just as “DevOps” merges “development” and “operations,” the term “DevSecOps” combines development, security, and operations. The addition of “security” emphasizes the importance of integrating security considerations into every stage of the software development lifecycle.

The triad of DevSecOps

The aim of DevSecOps is to enable teams to deliver software more quickly and efficiently while keeping the codebase free of security vulnerabilities. This strategy protects both your organization and your users from cyberattacks.

DevSecOps vs. DevOps

The DevOps methodology is designed to accelerate software delivery while improving quality and reducing bugs. With roots in the Agile movement, DevOps was developed to address issues with the traditional waterfall approach to software development and delivery.

Rather than a linear process of design, development, integration, testing, and release that can last several years, DevOps encourages teams to move their work through those cycles rapidly and frequently. To achieve this, DevOps advocates for robust, automated CI/CD processes that shorten delivery times and provide rapid feedback, creating a virtuous cycle of continuous improvement.

How is DevSecOps different from DevOps? In fact, DevOps was never intended to exclude security. However, while the DevOps movement helped to break down boundaries between development and operations teams, information security teams typically remained siloed. The term DevSecOps – together with several other versions, such as SecDevOps, DevOpsSec, and Rugged DevOps – was coined in an effort to address this.

Using the term “DevSecOps” reminds teams to factor security into the software development and deployment process. This includes:

  • Extending the culture of shared understanding and responsibility to security concerns.
  • Building security checks into the automated testing regime of a CI/CD pipeline.
  • Securing the software supply chain, including all dependencies and the CI/CD pipeline itself.
DevSecOps practices

In the same way that “shift-left” testing makes finding and fixing bugs easier and quicker, security practices are easier to incorporate and more effective when addressed earlier in the development process.

Why is DevSecOps important?

The potential impact of security vulnerabilities in your software cannot be overstated.

As well as financial and reputational damage, software security breaches have resulted in vast amounts of sensitive data being leaked, including internal documents and customers’ personal information. Depending on the applicable jurisdiction, leaking user data can result in severe financial penalties as well as legal liability.

Despite all this, the traditional approach to software security can make it feel like an encumbrance rather than an asset. Security audits and reports slow down progress and prevent you from getting your latest features into the hands of your users. However, choosing to ignore the importance of security in the software development lifecycle (SDLC) risks enabling the next cyber attack to make mainstream news.

While those exploits became headline news, their origins were far more pedestrian. Vulnerabilities exist because humans write code and humans make mistakes. Sometimes, those mistakes have been made by others before and are easier to recognize (if you know where to look). Sometimes, however, they are novel, perhaps resulting from a combination of factors that have not previously come together in that way.

To complicate things further, almost all software incorporates dependencies – whether open-source or proprietary – and there is no guarantee that third-party code is free of vulnerabilities. As such, securing your software supply chain is just as important as assessing the security of your own source code.

So, how should security be brought into the SDLC? The DevSecOps approach applies the same principles that have enabled faster, more stable releases: Shift security to the left so that it is addressed early and often.

Shift-left testing

On the face of it, shifting security to the left might sound like you just need to add a stage to your CI/CD process to make your software available for testing and review by the security team.

Although there is a place for manual security testing (as we’ll discuss), limiting your engagement with security requirements to a step at the end of the CI/CD process means you miss out on the benefits of rapid, regular feedback for several reasons:

  • Manual testing is time-consuming to perform, meaning you either have to slow down deployments or limit security testing to a subset of releases.
  • By the time any security issues are identified, the individual who wrote the relevant code will have moved on to something else, making the fix or recommendation harder to implement.
  • Finally, limiting security testing to a single step in the process engenders an “us and them” mentality between security and the rest of the organization. This doesn’t help either side get what they want: the release of useful, secure software.
How should security testing be integrated into the CI/CD process?

How to implement shift-left security testing

So what does a shift-left approach to security mean in practice? While there’s no one-size-fits-all solution, the following tools and techniques can help to integrate security throughout the SDLC.

Appoint security champions

While a culture of shared responsibility is important, it’s not enough to tell your development teams that they’re all responsible for software security. Keeping up with the latest attack vectors and malware developments is a full-time job, and you can’t expect everyone to maintain the same level of expertise.

Bringing a security champion into a multidisciplinary team to coach others and share best practices can help build understanding and promote a culture of collaboration among security professionals.

Make security a design constraint

Ideally, security needs to be considered before any code is written. It should be woven into user stories, raised during backlog review meetings, and discussed when planning each sprint. When working out how to tackle a new feature, take the time to discuss the risks it might present and how to mitigate them.

Adopting a threat modeling strategy, such as STRIDE, or using a tool, such as the OWASP cheat sheet, can help you stay on track while you learn these new skills. While considering security at the design stage won’t catch everything, it’s a good start and helps promote a DevSecOps culture.

STRIDE Threat Modelling

Include security in automated tests

Automation is a central tenet of DevOps. It speeds up tasks and ensures they are performed consistently, freeing people up to do more creative work. If you want to deliver software to users regularly and frequently, adding automated security tests to your pipeline is essential.

When writing automated unit, integration, and end-to-end tests, security features should be considered as relevant as any other functionality. If your team has been incorporating security requirements into user stories and discussing threat models as part of the design process, adding tests that cover security functions is a natural extension of that work.

Add security testing tools to your CI/CD process

In addition to the tests you write yourself, various security testing tools can help build confidence in the quality of your code. While traditional security scanning tools were not well suited to an automated CI/CD pipeline, CI/CD security testing tools designed for automation are now available. These integrate into your CI/CD pipeline and can report results via the dashboard or feed them straight into bug-tracking tools. As with all automated tests, it pays to structure your testing to provide feedback as quickly as possible.

Static application security testing (SAST) tools perform static code analysis to check your source code for known security flaws, such as buffer overflows and SQL injection opportunities. Because static analysis is run on the source code, it can be run early in the CI/CD pipeline as soon as changes have been committed.

SAST tools are language-specific, and some integrate into the IDE to provide continuous feedback as you write or the option to run tests on demand. By directing developers to the specific line of code containing the vulnerability, SAST tools offer targeted guidance, making fixing the issue quicker. However, false positives can be an issue, so being able to mute or dismiss particular alerts is essential if you want to avoid the risk of all SAST results becoming background noise.

Using SAST tools in CI/CD

Dynamic application security resting (DAST) is the corollary to SAST. This takes a black box testing approach on the running application, checking for known vulnerabilities such as cross-site scripting, command and SQL injection, and insecure server configuration. Because DAST tools require the application to be built and deployed to a test environment, they are typically used later in the CI/CD pipeline.

Secure your software supply chain

The potential for cyber attacks is vast. Bad actors can often find a security flaw in a widely used piece of software. These attacks – and others like them – have served as an essential reminder of the importance of securing your software supply chain.

What do we mean by the “software supply chain”? Put simply, it’s everything that is involved in the development and delivery of your software. All software development requires other software, from reusable components and libraries to IDEs, frameworks, and build tools. Software supply chain security involves assessing the security of the software you rely on and securing your development processes.

You can assess the former using software composition or component analysis (SCA) tools. SCA tools should crawl not just the dependencies you’ve dropped in but also their dependencies recursively up the supply chain – a perfect example of a job best left to computers, particularly when you consider how often new dependencies are added to a project.

Software Supply Chain

As well as being run automatically as part of the CI/CD pipeline, some SCA tools are available as IDE plugins to provide feedback on the fly. As with static and dynamic security tests, SCA testing is limited by the vulnerabilities the tools are aware of, so ensure the tools you choose are regularly updated with new exploits and cover areas relevant to your product and organization.

Bring in the red team

The concept of a red team originates from war games, where members of your own side are asked to play the role of the enemy in a simulated attack to identify weaknesses in your defenses and strategies. The same approach has been used to great effect in software development – sometimes in the guise of penetration testing or ethical hacking – to find new and unexpected exploits.

For a red team to work effectively, they cannot be involved in developing the system under test. Similar to exploratory testing, red teaming requires testers to think outside the box and use the software in ways other than was intended.

A red team can work in a staging environment (ideally as similar to production as possible) or on a live production system. If you choose the latter, you’ll need confidence in your software’s failure modes or very tolerant users (and C-level execs).

Treat all vulnerabilities as bugs

A DevSecOps approach involves everyone taking responsibility for the security of your software. Therefore, it’s time to stop thinking of security issues as somehow separate from “regular” bugs. Any failures or vulnerabilities discovered in your system belong in the same backlog as all the other issues and should be prioritized alongside them.

The whole team, not just the security champion, should be responsible for fixing vulnerabilities. This will help everyone build their security knowledge and expertise so they can use those skills on the current codebase and future projects.

Monitor production

Despite all your efforts in the previous stages of the SDLC, there is still a risk that a hacker will find a weakness in your live system. Firewalls and monitoring tools are still worth investing in to protect your organization and users. Runtime application self-protection (RASP) tools are the latest addition to these defenses, automatically detecting and blocking suspicious behavior.

Wrapping up

  • The DevOps approach involves regular feedback loops designed to help you improve what you’re building and release changes faster.
  • Shifting security to the left means considering security for the whole team at every stage of the SDLC.
  • Baking security into your CI/CD pipeline means you get regular feedback on the security of your application and can improve it in the same way as the rest of your functionality.
  • Securing your software supply chain is as important as securing your application code. Checking for and protecting against known vulnerabilities will at least ensure your software keeps pace with attackers rather than leaving you undefended from known exploits.
  • Treating every new vulnerability as a bug to be triaged, fixed, and tested for in the future will make your software more robust over time.
  • DevOps and DevSecOps are as much about culture as they are about tools and processes. Embedding security into the software development process requires a culture of shared responsibility.