Once upon a time, workload security (which means making sure an application and its environment are configured and deployed securely) was something that developers didn’t have to think much about. Developers’ only real security responsibility was to write secure code. After they passed the code off for building, testing and deploying, it was someone else’s job (specifically, the IT department) to secure the workload of which the code was a part.

How Security Problems Flow Down the CI/CD Pipeline

To understand why workload protection has become everyone’s responsibility, you have to understand how DevOps and CI/CD have given rise to new types of security challenges.

In an organization that has embraced DevOps, code is intended to flow continuously, in a so-called CI/CD pipeline, from development to testing, to building and, finally, to deployment. To keep the CI/CD pipeline flowing smoothly, DevOps teams typically strive to standardize and automate as many processes as possible.

From the perspective of efficiency and reliability, standardization and automation are great. They are key to enabling continuous software releases.

When it comes to security, however, standardization and automation have a downside, which is that a configuration problem introduced at one stage of the pipeline can flow down the pipe and reach production environments easily without anyone noticing.

This is true for two main reasons. First, standardization and automation minimize the amount of human intervention and oversight that go into the CI/CD process. Again, that’s exactly the point, and it’s a benefit in most respects. But when it comes to security, less human intervention means a greater chance that a security problem will go undetected (particularly if you don’t have automated security tests or audits in place to catch the issue).

The second major risk associated with standardization and automation within a CI/CD pipeline is that sometimes, developers might set a configuration that they don’t intend to be used in production, but is pushed into production nonetheless by the automated pipeline.

For example, developers might place code inside a container to help with testing or staging, without intending for that same container to be used in production (instead, they assume the code will be repackaged before being deployed). Because they don’t intend for the container to be used in production, they don’t use a secure configuration for it. Maybe they let it run as root, for example. Then, if communication breaks down and a release automation tool pushes that container into production without changing the configuration, a container with a security flaw will end up being deployed.

To learn more about security and compliance for DevOps, check out our recent webinar.

Extending Workload Protection Beyond IT

In a perfect world, the IT team would be able to catch these flaws. But the reality is that in a fast-moving CI/CD environment, it’s not realistic (or fair) to expect IT alone to make sure that workloads are configured securely before they are deployed.

Instead, the entire DevOps team needs to take responsibility for workload security.

What that means specifically will vary from organization to organization, but in general, extending workload protection beyond IT means the following:

Making sure that developers (and not just IT engineers) understand workload security best practices and why they are important to follow at every stage of the CI/CD process.
Establishing and enforcing (via automated audits) policies for how workloads can be configured at any stage of the CI/CD pipeline. For example, the DevOps team as a whole might agree not to run containers as root, even if it’s only in pre-deployment.
Enabling runtime protection by scanning for vulnerabilities that appear within applications and environments once they are live.
Securing data at all stages of the CI/CD pipeline and scanning data for signs of intrusion or malicious code.
Performing continuous security monitoring and vulnerability detection (both pre-deployment and post-deployment) to catch issues as quickly as possible, even if they have slipped through the cracks of earlier security tests.

Conclusion

It would be nice for developers if workload security was not their responsibility. But in the age of CI/CD and DevOps, they no longer can hand off that burden to the IT team. The IT team still has an important role to play in making sure workloads are deployed securely, but effective workload security for DevOps starts early in the CI/CD pipeline—with developers. Code moves too quickly down the pipeline for developers to assume that they can safely do one thing with a workload and have the IT team change it before the workload is deployed.

Symantec Cloud Workload Protection (CWP) helps organizations monitor and protect their workloads, no matter where they reside. With CWP, organizations don’t have to look for multiple products to meet their many security needs. CWP offers a single console to monitor and manage security across various platforms. It offers automatic discovery of workloads across AWS, Azure and Google Cloud, and visibility into security postures and software, which enables automatic workload monitoring and protection. With continuous delivery workflows and malware prevention, CWP is essential for modern software development.

— Chris Riley