Moving from DevOps to DevSecOps
Moving from DevOps to DevSecOps – DevOps has become a popular practice. Software teams can greatly increase their speed of delivery for applications and services, by adopting DevOps practices such as:
Infrastructure as code, containerization, and orchestration
Continuous integration and delivery
Metrics and monitoring
Note that security is not on this list.
Because of this, DevSecOps – a combination of DevOps and security practices – is growing popular today. The two are intimately related: DevOps uses automation to increase the speed and consistency of software delivery, while DevSecOps uses automation to increase the security of the software that is delivered.
However, DevSecOps is far less widely used than DevOps. In this article, we’ll discuss the benefits of adopting it, and some tips on doing so.
What is DevSecOps?
As with DevOps, there is no official definition of DevSecOps. However, it generally means the integration of security into the SDLC (software development lifecycle). It can be categorized as building security into your infrastructure, applications, CI/CD pipeline, and even compliance management. Let’s discuss each one.
Building security into infrastructure: A DevSecOps shop usually leverages IaC (Infrastructure as Code) and manages its infrastructure through a code revision process. This provides the ability to harden the infrastructure automatically via state configuration, closing unused ports, disabling unused protocols, setting network boundary security via NACLs, and so on.
Building security into applications: Application security is a broad subject, but much of it can be automated via DevSecOps. This includes code that ensures only cipher suites, protocols, and hashes are used in the application stack, code that disables insecure methods at the OS, code that installs framework updates (Java and NodeJS) as part of an agent-based desired state configuration management, and so on.
Building security into the CI/CD pipeline: Most DevOps shops perform application testing within the pipeline, but security testing should be performed too. A Nessus vulnerability scan can be performed on the deployment stack before it’s promoted into production. If open vulnerabilities are found, this will provide the opportunity to write hardening code to fix them. And API testing can verify that attacks trigger alerts based on exception handling/monitoring tools. Other practices include container hardening, OS network hardening (such as implementing host-based firewalls, data loss prevention agents, etc.), and so on.
Building security into compliance management: For many organizations, compliance with one or more regulatory standards is a mandatory, time-consuming burden. Although you can’t change the mandate, you can make it much less burdensome.
By integrating security auditing, continuous compliance monitoring, and TVM alerts into your pipelines, you significantly increase the quantity and quality of compliance-related feedback, ideally while automating some of the compliance-related work as well.
Preventing compliance missteps earlier in the SDLC will increase development velocity; it will also eliminate time-consuming incidents when development work is submitted for approval, but then rejected on the grounds of non-compliance.
Integrating a continuous auditing tool into your SDLC can create logs of all audit trails relating to compliance tasks, thus reducing the time required for the periodic audits from outside assessors (because much of the work will already be done).
Benefits of DevSecOps
As we’ll discuss below, adopting DevSecOps requires some cultural changes, and these aren’t necessarily easy. So why do it?
First, it can significantly improve the security of the delivered software. As discussed in great detail in OWASP’s report “Securing Enterprise Web Applications at the Source: An Application Security Perspective,” secure software is a result of keeping security in mind throughout the development process.
Unfortunately, many software organizations tend to emphasize the development of new features, rather than security. New features drive sales, while better security is difficult to quantify (and frankly, is not highly sought after by potential customers anyway). Nevertheless, even though better security might not initially increase the bottom line, it will do so eventually. This occurs in two ways: by reducing expenses, and increasing sales.
Expenses are reduced because DevSecOps prevents some security defects from occurring, and reveals others earlier in the SDLC. According to research by Blaze Information Security, fixing a defect during a shipment phase is 160 times more expensive than fixing it during the development phase. Compare the cost of upgrading a dependency library to include the latest security checks—which costs almost nothing, probably a few hours spent by a single engineer—to the potential damage of shipping a release that contains a security hole.
As for increasing sales, this is a longer-term effect. Although an application’s quality is not always visible to customers, inadequate security will eventually become apparent. Having a stronger security posture than your competitors—i.e., providing secure services when others fail—is how you gain trust and grow your customer base.
Moving from DevOps to DevSecOps
Adopting DevSecOps can be challenging. The good news is that if you already use DevOps, you’re most of the way there already. Here are some general principles to follow.
First, the basics of application and system security should always be maintained. For example, system design should follow the principle of minimal privilege; no user should have more access than needed to perform necessary tasks.
The codebase should be covered with static code analysis and unit and integration tests. A lot of security problems are caused by coding errors which could have been caught by automated tools.
Dependencies are also a significant source of potential vulnerabilities. There are a variety of good tools available for keeping them updated, automatically. It’s also a good idea to regularly check the Common Vulnerabilities and Exposures (CVE) index, in case vulnerabilities are found within the tools, libraries, and frameworks that you use.
As discussed above, there are many opportunities for improving security in the infrastructure, applications, CI/CD pipeline, and compliance management. Once these are implemented, it’s important to not be complacent. Regular security reviews should be conducted on every phase of your SDLC, with the goal of continually improving your hardening measures.
Lastly, perhaps the most challenging part of adopting DevSecOps is not technical – it is cultural. It’s important to foster collaboration and reduce friction during security reviews and other activities. Sometimes teams treat each other as enemies; obviously, it’s important that they work together instead.
A common source of friction is between development and operations/security teams. Developers want to introduce new features quickly, and often are not well-versed in security issues (many aren’t even familiar with the OWASP Top 10).
Meanwhile, security teams want to be more careful and prevent potential vulnerabilities from being introduced; to make matters worse, they are frequently understaffed, and all too often, ignored or overridden. The most successful organizations manage to surmount all these challenges, and they construct SDLC processes that are both productive and secure.
Although adopting DevSecOps is not necessarily easy, it’s important to remember that the challenges are temporary, while the benefits are long-lasting.
Moving from DevOps to DevSecOps