DevOps rules web application development

Any sizable company is now a software company that builds and runs many of its own websites and applications. This means that you have the same company (and often many of the same people) working on every step of the software development lifecycle (SDLC), from design and development right through to operations and maintenance. In such environments, merging all the separate stages into a single unified workflow can greatly increase efficiency and agility while also reducing costs.

In web application development, where agile methodologies with continuous integration and continuous deployment (or continuous delivery) are the order of the day, DevOps is the only practical way to keep business-critical applications running smoothly across frequent updates. The entire development process is heavily automated to minimize manual steps and communication overhead, with companies using a wide array of tools combined into multiple toolchains (10 toolchains on average, according to the 2020 Atlassian DevOps Trends Survey). Automation allows small development teams to deliver projects on scales and schedules that would be way beyond their reach with more manual methods.

The benefits of agile DevOps are well-documented: faster development, lower costs, shorter times to fix, and rapid response to changing business requirements. Yet there is one crucial aspect of application development that is missing from many DevOps workflows: application security. Perhaps due to lingering pre-web misconceptions that software security is not a big deal, many organizations still treat it as an afterthought and try to bolt a security testing silo onto an agile and highly automated DevOps process. As we’ve written before, this can’t possibly work and only serves to reinforce the myth that cybersecurity and automation don’t mix.

5 reasons to build security into your DevOps workflows

CI/CD pipelines can pump out application updates on a weekly or even daily basis, so application security testing must be automated if it is to keep up with agile development and operations. But with surprisingly many organizations still treating software security as a nice-to-have rather than a necessity, let’s quickly run through 5 good reasons why you need to include application security testing in your DevOps practices:

• Reduce the risk of data breaches: Web applications are a major vector for cyberattacks, so following security best practices from the earliest stages of development is vital for reducing security risk, especially considering the far-reaching consequences of a data breach.
• Fix security defects faster: Whatever AppSec tools and processes you use will uncover security issues that you need to fix – and having an efficient workflow can make the difference between quickly implementing a routine bug fix and halting the entire pipeline.
• Automate security to keep up with DevOps: Automated toolchains are the heart of DevOps, so having a separate security team doing security testing inevitably creates a bottleneck in the development pipeline.
• Maintain the pace of software innovation: The drive to quickly get business-critical features into production doesn’t mean that you can’t deliver secure software – you can, but only if security is an integral and predictable part of the process.
• Do more with your existing resources: A software development organization can have hundreds of developers but only a handful of security professionals, so starting security testing early in the development cycle helps to minimize security risks.

The bottom line is that DevOps organizations can’t afford not to do application security testing, and the only realistic way to build secure products in agile environments is through security integration and automation.

Different approaches to building secure DevOps

Time to address the headline question: does it really matter where you add the Sec into DevOps, or is it yet more marketing alphabet soup? The answer really depends on how deep you want to go. If we’re talking about building secure software quickly and efficiently, the exact term doesn’t matter as long as everyone knows that security practices must be an integral part of the development and operations pipeline. DevSecOps is by far the most popular way to describe this, but putting the security part elsewhere can be useful to show which stages are emphasized in different workflows. Let’s have a shot at deciphering it all:

• DevSecOps: This industry-standard term plugs security right into the middle of the DevOps pipeline and suggests that while the whole process is still primarily about development (because Dev comes first), software must be secure before it gets to the operations team. Considering that most existing DevOps organizations don’t have a security focus, the DevSecOps approach is the most practical way of integrating security testing into the software development process.
• SecDevOps (a.k.a. rugged DevOps): Quite literally putting security first, this approach requires DevOps teams to factor security considerations into all their decisions, from secure design choices and secure coding practices to hardened deployments. While this is definitely the way of the future from a security standpoint, SecDevOps needs a security-first mindset (along with suitable skills and education) across all teams and processes, which can take time to build.
• DevOpsSec: Probably the least popular term of the three, this combination suggests that security is bolted onto an existing DevOps process, for example by doing security testing only after the application is deployed. While better than nothing, such late-stage testing negates many of the benefits of DevOps, forcing the agile pipeline to halt and backtrack whenever a vulnerability is found.

Keep in mind that DevOps itself is a very general concept, not a hard-and-fast model. Depending on your organization, adding security to DevOps could be as simple as plugging the right automated tool into your development and deployment processes or as complex as combining separate teams to grow a security-infused DevOps culture from scratch. Luckily, there is an easy way to build AppSec into an agile development process.

Automated development needs automated AppSec

Application security testing covers a wide variety of methods: manual penetration testing, static code analysis (SAST), vulnerability scanning, software composition analysis, and more. Each has its merits, and a mature application security program should incorporate multiple approaches to maximize testing coverage. At Invicti, we firmly believe that the foundation of this program should be an accurate, integrated, and automated solution for dynamic application security testing (DAST, also called dynamic analysis) that is easy to deploy regardless of the existing workflows and underlying technologies.

A modern DAST product such as Invicti gives you visibility into the real-life security of your application in its current environment, whether development, staging, or production (or any combination thereof). Most importantly for building DevSecOps, you can integrate testing into your existing build process and have tests triggered and results reported fully automatically – see our white paper on building dynamic security testing into the SDLC to learn how this is done. With a wide array of built-in integrations, Invicti is ready to work with popular issue trackers and CI/CD platforms straight out of the box.

The vulnerability testing process itself is also automated, as Invicti features Proof-Based Scanning to automatically confirm over 94% of direct-impact security vulnerabilities. You can set up issue tracker integration to send these verified and actionable reports (complete with remediation guidance) directly to the developers to fix, with no risk of false positives. With this security testing automation in place, security issues are addressed like any other software bug – and all without leaving the optimized tools and workflows that your DevOps professionals rely on.