Why DevOps Teams Need Security Skills and How Shift Left Tools Help

By Trisha Paine

Trisha Paine

The pace of new technology has accelerated with the introduction of public clouds. Modern application architectures are cloud-native and built based on microservice architectures. The adoption of containers, serverless functions and microservices is increasing rapidly, rendering traditional security approaches obsolete. Furthermore, with the advent of continuous integration and continuous delivery (CI/CD) pipelines, the volume of deployments is rising exponentially.

With this momentum, it’s becoming more difficult for your clients to detect and manage software vulnerabilities. To compound this, companies are adding more and more DevOps teams, CI/CD pipelines, and microservices with various permissions and capabilities just to keep up with their business demands. This only increases the attack surface, making security know-how a crucial skill for every developer today.

This article explores why you should encourage your clients to provide their developers who work in the cloud with sufficient cloud-native security skills, and gives recommendations on tooling to make it seamless and streamlined.

The Dangers of Native Cloud Computing

Not surprisingly, granting inexperienced people access to cloud resources is dangerous. Without proper tools and training, developers simply don’t have the skills or time to check for vulnerabilities. In addition, developers are primarily concerned with writing code and achieving deadlines — with security often an afterthought or something they think can be plugged in at a later stage.

Friction on both development and security sides is often an issue. The DevOps team is frustrated by the friction added by invasive security tools, so it will turn off security checks and scans in the name of productivity. The security team, meanwhile, is frustrated because it depends on the DevOps team to leave the security mechanisms intact. Striking a balance between delivery speed and security is a delicate process.

Real-World Security Breaches Impacting Your Clients

There are genuine security risks your clients face in the context of developers experimenting in the cloud, even in sandboxed environments.

For example, it’s tempting to use HTTP instead of HTTPS to “just quickly try something out” without the hassle of managing SSL certificates. Doing this leaves network traffic unencrypted and vulnerable to eavesdropping.

Also, when developing a web application, scanning for vulnerable packages is usually an afterthought for developers, who are often under pressure to deliver a new feature or bug fix in a minimal time frame. If such an app is ever exposed on the internet, there’s a risk that an attacker could exploit this vulnerability.

Having an attacker break into a development environment opens it to even greater exposure once they break in. For instance, there have been cases where developers use staging data that is a copy of actual past data. Even if such data isn’t available on a live production site, it might still contain sensitive, personally identifiable information.

A final scenario would be proprietary code that is considered a business advantage; if an attacker or competitor gains knowledge of such code, it could lead to a significant loss for the business. Alternatively, citing back to Log4j, using vulnerable code from third-party repositories could open the environment to even more security incidents.

The ‘Shift Left’ Paradigm

Shift left is a nascent term for what DevSecOps is primarily concerned with and can be summarized using the medical maxim: “Prevention is better than cure.”

In other words: Preventing security threats before and during the development phase is a lot cheaper than detecting and fixing them later in production.

This idea has two goals:

How to Encourage DevOps to Innovate Safely in the Cloud

When consulting with your clients, encourage them to …

… enforce security early in the development process. They will need to ensure that automated and imperceptible security tools are deployed before the DevOps team writes the first line of business logic.

Developers should have sandboxed environments available to safely experiment. For your clients using AWS environments, this could take the form of separate accounts that are part of one AWS Organization; this way, they can just delete the account if things get out of control.

But even sandbox environments can work with actual data, and this data can still travel through the internet, between the developer’s machine and the cloud provider, so these environments just fit half the bill. Security tooling needs to be applied to all environments. Most cloud vendors will allow clients to restrict what developers can do in their accounts. Again on AWS, this would take the form of service control policies (SCPs) that define what the account itself can and can’t do.

Virtually all cloud vendors allow you to set limits on costs or will send alerts if costs go above a certain threshold. Clients should use these features to keep costs under control for all their cloud accounts.

Most importantly, leverage cloud-native application protection platform (CNAPP) tools that can integrate into their development and production environments to scan for vulnerabilities and quickly prioritize security risks without causing friction for developers.

Don’t Let Deadlines KO Security

Cloud application development will continue to accelerate and requires the developer and security teams to work in tandem to mitigate risks. SecOps needs to make it easy to ensure the DevOps teams don’t get out of control, as even seasoned developers will eventually cut corners when faced with looming deadlines.

Automated security tooling that follows the shift left paradigm can help your clients mitigate these risks. This will allow both teams to leverage the cloud while monitoring the code early in the development cycle, keeping it free from vulnerabilities and secret leakage while not delaying development.

Trisha Paine is the head of global cloud security marketing for Check Point Software Technologies. With 20-plus years of experience in cloud, security and technology companies, Paine focuses on developing go-to-market strategies and addressing complex cloud security use cases. Paine holds her M.B.A. and J.D. degree focusing on business and intellectual property law from the University of Toledo. You may follow her on LinkedIn or @CheckPointSW on Twitter.