DevOps Practices Primed to Combat Threats | Fastly

There’s a regular misconception among those implementing DevOps practices that adhering to security best practices will slow them down, so security teams are often left out of the loop. Only a quarter of organizations surveyed for “Reaching the Tipping Point of Web Application and API Security,” a report we conducted in partnership with Enterprise Strategy Group (ESG) Research, said they have centralized security responsibility across all applications and aspects of their environment. 

The reality though is that DevOps practices are actually already primed for security inclusion. Here are a few ways you can make the most of DevOps practices by including security, rather than treating it as a roadblock. 

Continuous deployment requires visibility into potential threats 

Key to DevOps is a continuous deployment model that increases the pace of releases so your teams can innovate faster and deliver better products and experiences to your customers. 

However, the adoption of open source or cloud-native components and frameworks exacerbates the lack of visibility in critical areas of application security. The average application codebase, for example, consists of 70% open-source code, and in almost 90% of cases the software had a component more than four years out of date or with no development activity in the past two years. That invites the obvious possibility of being blind to potential threats.

 You should leverage tools that both secure systems and provide your security, DevOps, and dev teams insight into threats and vulnerabilities. Enhanced visibility means getting security telemetry to your teams so they can access that data in the DevOps and security tools they already use (such as Jira, PagerDuty, Slack, and Splunk), and not force them to log into yet another management console.    

Consolidation ensures proper security environments and quick fixes

Certain security tools like static application security testing (SAST) or dynamic application security testing (DAST) test a snapshot of the codebase in dev environments — and the codebase can change by the time the code is released to production, resulting in false positives if WAF rules were written for the older codebase snapshot. This is even more problematic given rapid DevOps software cycles. 

According to the ESG report referenced above, organizations reported an average of 53 alerts per day from their web application and API security tools, with 45% of these determined to be false positives. Ultimately, 75% of organizations spend equal or more time on false positives as on actual attacks. 

When you’re inundated with all these false alerts, it’s tempting to ignore most alerts and resist investigating them, creating friction between dev and security functions. To reduce this friction and avoid piling on more security debt, it’s important that your developers trust your security tools and integrate those they engage with into the DevOps pipeline.

Dev teams often settle on their own application stack. Unfortunately, that leads to a proliferation of dev and operational environments, often hosted across multiple cloud providers. Ensuring that security tools work effectively to provide visibility in any environment your apps operate in, as well as your developers’ chosen pipeline, is critical.

For companies that focus on edge-based DevOps services, implementing security controls as code offers developers the ability to implement security at every step of the DevOps pipeline. 

Look for edge services with extensive APIs and support for a variety of dev languages, as well as solid integration into the current DevOps pipeline and toolchains. Not only does this allow developers to establish the proper security environments for different application targets — development, staging, or production — but it also lets them quickly push fixes and patches through to in-production applications, without worrying about time-consuming false positives. 

DevOps-native security tools enable automation

Detection and testing are not the only security processes that should be driven by automation. Automation needs to extend from testing to deployment to attack detection, and finally to response. 

When it comes to data exfiltration, 1 minute versus 10 to 20 minutes is a big deal. By automating, you can take action at machine speeds. In today’s world, attacks are often automated, so automation on the defensive side helps level the playing field. 

DevOps-native security tools — such as next-gen web application firewalls or test automation — that integrate with dev infrastructure as well as cloud-native components, like Kubernetes and Envoy, without requiring that the codebase or instrumenting be changed for each deployment help make this level of automation possible. Once deployed, you can automate monitoring of traffic and application performance speeds as well as detection and response to attacks and anomalies. 

Integrated solutions empower developers to focus on their work without sacrificing performance 

With multiple smaller dev teams taking responsibility for their own code, deployment, and environments, large companies often face situations where every team has its own version of toolsets, using different software components and establishing different processes. 

The added complexity of managing distinct dev environments makes securing those environments and the resultant software that much harder. Simplifying the dev environment and consolidating well-used DevOps processes into common services reduces redundancy, minimizes complexity, and allows security tests and configuration changes to more completely cover a company's application portfolio.

Your developers need a platform where reliability, performance, and security are all baked in, so they can just focus on developing apps. Developers who have to constantly maintain their infrastructure may sacrifice security for the sake of getting things done.

While flexibility should be supported, having common infrastructure to handle the hard tasks, such as authentication, data encryption, and managing roles, removes any worries developers might have about getting security right — because it’s already baked into the environment.

Takeaway: integrate secure DevOps practices into your digital transformation strategy

Yes, business teams, developers, and application security professionals all have their own problems, incentives, and priorities. But if you’re going to build an efficient DevOps organization, these groups need to overcome the differences in culture and work to incorporate security into DevOps in a way that supports the business.

Historically, security teams have mandated certain security policies without allowing for significant input from the dev teams. Meanwhile, developers' incentives are designed to create functional code quickly, but often do not incorporate security milestones. Both groups need to work with the other to create a culture that fosters attainable security, so the focus remains on delivering better products and experiences for your customers — and secure DevOps is a great place to start.

Download the full ESG report to learn more about modern security trends and the challenges organizations are facing today.