In tech culture today, DevOps has become well-established. Many organizations have embraced it, and they now enjoy its numerous benefits: shorter release cycles, better software quality, faster time to market, and so on.
The next logical step is to adopt DevSecOps as well. As its name implies, DevSecOps adds security to DevOps. This sounds simple, but the changes that it introduces—and the additional benefits that it provides—are substantial.
DevSecOps can provide significant competitive advantages to those organizations which implement it. Despite this, many organizations have not (yet) committed to it.
There are three primary reasons for this:
- Executives don’t understand the benefits of DevSecOps.
- They think they don’t need it.
- They think they can’t use it.
In this article, we’ll discuss all three of these issues. We’ll see that most DevOps shops can, and should, embrace DevSecOps as well.
The Benefits of DevSecOps
You probably are already familiar with DevOps, which:
- Integrates operations into the develop/release cycle.
- Increases the speed at which software is developed and delivered.
- Automates much of the software lifecycle.
Now compare this to DevSecOps, which:
- Integrates security into the develop/release cycle.
- Increases the security with which software is developed and delivered.
- Automates many of the traditional practices of security engineers, operations teams, and development teams.
In a nutshell, DevSecOps uses automation to increase security throughout development and production.
Why It Is Needed
DevSecOps provides tremendous pay-outs to organizations that use it. For example, the overall speed of software development and delivery can increase, because many tasks and processes which were formerly done manually can now be done quickly and automatically.
However, its most important benefit is the greatly enhanced security posture that it provides. At all steps of the software cycle, DevSecOps requires security to be “baked in”—to be inherent and automated throughout the process. Doing this correctly means that security is built into:
- The infrastructure.
- The applications.
- The CI/CD pipeline.
- The network’s borders.
Let’s discuss each of these.
Securing the Infrastructure
Obviously, it’s vital to secure infrastructure components such as networks, services, and databases. Traditionally, infrastructure hardening has been done manually. This is labor-intensive, tedious, and error-prone, and potentially has severe consequences if not done regularly and correctly.
IaC (Infrastructure as Code) allows infrastructure to be managed via software. Among other benefits, IaC is very useful for DevSecOps, and IaC frameworks and tools can be leveraged to keep infrastructure secure. Here are some examples:
- As new components are added or swapped into the infrastructure, they can be configured and hardened automatically.
- Ports and protocols can be tightly controlled. With well-designed security groups, trusted connections can be narrowly defined and consistently enforced.
- Infrastructure can be regularly monitored. When configuration drift is detected, it can be corrected immediately.
- Encryption can be applied and maintained everywhere it’s needed. (One of the largest sources of cloud-related security problems is the failure to properly encrypt data storage.)
- Credentials can be generated, rotated, and managed.
Securing the Applications
By automating security-related procedures, DevSecOps can prevent many common application-related vulnerabilities from occurring. This can be done throughout your environments, from dev all the way through to production. Examples include:
- Installing applications automatically and requesting/applying trusted certificates for web endpoints, app-to-app communication, and app-to-database communication.
- Installing framework updates as part of an agent-based desired state configuration management.
- Creating auditable exceptions in applications that show security attacks, then alerting when those exceptions are raised.
- Ensuring only strong cipher suites, protocols, and hashes are used in the application stack, and that all insecure methods are disabled at the OS whenever possible.
- Ensuring that your containers are configured properly, deployed from an immutable source, and regularly scanned for vulnerabilities.
Securing the CI/CD Pipeline
When anticipating potential security concerns, it’s easy to overlook the delivery process itself. DevSecOps can help to ensure that secure software is delivered into secure environments. Best practices include:
- Running a full vulnerability scan on the deployment stack before it’s promoted into production. (A negative result gives you peace of mind. A positive result gives you the opportunity to fix the open vulnerabilities. Either way, it’s helpful.)
- Fuzzing your APIs to test their exception handling.
- Hardening containers.
- Hardening environments by ensuring proper configuration of firewalls, data loss prevention (DLP) agents, and so on.
Securing the Borders
Just like the other tasks described above, DevSecOps can greatly increase the ease, consistency, and speed with which your network borders are protected. However, unlike the other tasks described above, the application of DevSecOps to border protection isn’t as clear.
In fact, many executives think that the need for web security prevents them from using DevSecOps. This point deserves further discussion.
“We can’t use DevSecOps here.”
The border is the most critical point for defending against external threats. All other hardening can be made irrelevant if the border isn’t properly secured.
And this is why many executives believe that DevSecOps is not an option for them. They understand that robust web security is critical, and they also (correctly!) understand that their current security measures are incompatible with DevSecOps practices.
Many organizations are still using security appliances as their primary protection against external threats. A decade ago, these appliances were good enough. Today, they’re a competitive disadvantage.
Traditional security devices (whether physical or virtual) hinder the agility and security of organizations which still use them. A few examples:
- Many appliances do not provide an API. Others offer only limited programmatic control. In most cases, changing their configuration requires manual intervention, which is time-consuming and error prone.
- Maintaining consistent configurations and settings across devices can be very challenging.
- External-facing applications cannot be scaled beyond a certain point.
- The appliances are not designed for ephemeral workflows.
- They are not designed to support IaC modeling.
Security appliances represent a decades-old approach to security, so it’s not surprising that they don’t support modern practices. What is surprising is that even many “cloud-native” appliances aren’t built for DevSecOps either.
For example, some require multiple instances to be launched into your environments. Some require additional layers of management just to maintain consistent configuration among them. Many do not provide good support for evolving architectures and expanding deployments. In general, these security products tend to require significant intervention and management, while lacking automated control capability. This all severely limits the use of DevSecOps.
This is why many executives believe that DevSecOps isn’t an option for their organizations. And to be clear, these executives are correct—for as long as they continue to use previous-generation approaches to web security.
Solving the challenge
Achieving the full benefits of DevSecOps requires a web security solution that fully supports its practices.
As with any new trend, there are many vendors claiming that their products support DevSecOps. In practice, the actual amount of support varies widely.
When evaluating a web security solution, you should ensure it has these features and capabilities:
- Full programmatic control via a comprehensive API.
- Dynamic recognition and protection of assets deployed through CI/CD.
- A secure isolated environment, i.e. a VPC (Virtual Private Cloud) where traffic is filtered and threats are blocked before they reach your network.
- A dedicated VPC for each account. (There should be no multi-tenancy, as this can lead to spillover attacks.)
- Fully managed security infrastructure. The provider should provide immediate, automatic updates whenever new threats become known.
- Continual threat analysis based on Machine Learning, to adapt to new web threats as they arise.
- Deep log analysis and intelligence reporting through dashboards.
- A cloud-native solution that runs natively on your preferred cloud platform (e.g., AWS, GCP, and Azure).
Today, security is not simply an “add-on” to modern infrastructure and application management, but a crucial part of it. That’s why DevSecOps is especially important; it’s needed to ensure that security provisioning, patching, hardening, and configuration is applied through code.
Furthermore, since the border is the most susceptible to attack, it’s paramount that it receives the strongest protection possible, and that it too enjoys the automation and hardening that DevSecOps can provide. That’s why it’s important to choose a web security solution that fully supports it.
By securing your border with a platform that enables your DevSecOps practices, you’ll be able to keep threats out of your network, out of your APIs, and out of your applications and services.
About Tzury Bar Yochay
Tzury Bar Yochay is the CTO and co-founder of Reblaze. Having served in technical leadership in several software companies, Tzury founded Reblaze to pioneer an innovative new approach to cyber security. Tzury has more than 20 years of experience in the software industry, holding R&D and senior technical roles in various companies.
Prior to founding Reblaze, he also founded Regulus Labs, a network software company. As a thought leader in security technologies, Tzury is frequently invited to present at industry conferences around the globe.