DevOps.com

  • Latest
    • Articles
    • Features
    • Most Read
    • News
    • News Releases
  • Topics
    • AI
    • Continuous Delivery
    • Continuous Testing
    • Cloud
    • Culture
    • DevSecOps
    • Enterprise DevOps
    • Leadership Suite
    • DevOps Practice
    • ROELBOB
    • DevOps Toolbox
    • IT as Code
  • Videos/Podcasts
    • DevOps Chats
    • DevOps Unbound
  • Webinars
    • Upcoming
    • On-Demand Webinars
  • Library
  • Events
    • Upcoming Events
    • On-Demand Events
  • Sponsored Communities
    • AWS Community Hub
    • CloudBees
    • IT as Code
    • Rocket on DevOps.com
    • Traceable on DevOps.com
    • Quali on DevOps.com
  • Related Sites
    • Techstrong Group
    • Container Journal
    • Security Boulevard
    • Techstrong Research
    • DevOps Chat
    • DevOps Dozen
    • DevOps TV
    • Digital Anarchist
  • Media Kit
  • About
  • AI
  • Cloud
  • Continuous Delivery
  • Continuous Testing
  • DevSecOps
  • DevOps Onramp
  • Practices
  • ROELBOB
  • Low-Code/No-Code
  • IT as Code
  • More
    • Application Performance Management/Monitoring
    • Culture
    • Enterprise DevOps

Home » Sponsored Content » Symantec » Why Workload Security Is Not Just for IT Anymore

Why Workload Security Is Not Just for IT Anymore

Why Workload Security Is Not Just for IT Anymore

By: Chris Riley on June 6, 2019 Leave a Comment

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.

Recent Posts By Chris Riley
  • Using Incident Response for Continuous Testing
  • What Is Resilience Engineering?
  • Moving from NOC to the SRE Model
More from Chris Riley
Related Posts
  • Why Workload Security Is Not Just for IT Anymore
  • Why is Security Still in the Way? A Look at DevSecOps Right Now
  • How to Securely Manage Secrets Within Jenkins
    Related Categories
  • Sponsored Content
  • Symantec
    Related Topics
  • developers
  • devops
  • it
  • security
  • Symantec
  • testing
  • workload protection
Show more
Show less

That’s no longer the case. Today, workload protection is the responsibility of the entire DevOps team, not just IT engineers.

Let’s explore why, and what this change means for developers.

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.

Sign up for a free trial of Symantec CWP.

— Chris Riley

Filed Under: Sponsored Content, Symantec Tagged With: developers, devops, it, security, Symantec, testing, workload protection

Sponsored Content
Featured eBook
The 101 of Continuous Software Delivery

The 101 of Continuous Software Delivery

Now, more than ever, companies who rapidly react to changing market conditions and customer behavior will have a competitive edge.  Innovation-driven response is successful not only when a company has new ideas, but also when the software needed to implement them is delivered quickly. Companies who have weathered recent events ... Read More
« Pre-Commit Job Workflow in Azure DevOps
Getting the Enterprise Digital Core in Shape »

TechStrong TV – Live

Click full-screen to enable volume control
Watch latest episodes and shows

Upcoming Webinars

10 steps to continuous performance testing in DevOps
Thursday, August 11, 2022 - 3:00 pm EDT
Bring Your Mission-Critical Data to Your Cloud Apps and Analytics
Tuesday, August 16, 2022 - 11:00 am EDT
Mistakes You Are Probably Making in Kubernetes
Tuesday, August 16, 2022 - 1:00 pm EDT

Latest from DevOps.com

CloudNativeDay: WASM to Drive Next IT Epoch
August 10, 2022 | Mike Vizard
MLOps Vs. DevOps: What’s the Difference?
August 10, 2022 | Gilad David Maayan
GitHub Brings 2FA to JavaScript Package Manager
August 9, 2022 | Mike Vizard
CREST Defines Quality Verification Standard for AppSec Testing
August 9, 2022 | Mike Vizard
IBM Unveils Simulation Tool for Attacking SCM Platforms
August 9, 2022 | Mike Vizard

Get The Top Stories of the Week

  • View DevOps.com Privacy Policy
  • This field is for validation purposes and should be left unchanged.

Download Free eBook

The State of the CI/CD/ARA Market: Convergence
https://library.devops.com/the-state-of-the-ci/cd/ara-market

Most Read on DevOps.com

Recession! DevOps Hiring Freeze | Data Centers Suck (Power) ...
August 4, 2022 | Richi Jennings
Orgs Struggle to Get App Modernization Right
August 4, 2022 | Mike Vizard
GitHub Adds Tools to Simplify Management of Software Develop...
August 4, 2022 | Mike Vizard
The Everything-As-Code Revolution and the OWASP Top 10
August 4, 2022 | Aakash Shah
Putting the Security Into DevSecOps
August 5, 2022 | Ross Moore

On-Demand Webinars

DevOps.com Webinar ReplaysDevOps.com Webinar Replays
  • Home
  • About DevOps.com
  • Meet our Authors
  • Write for DevOps.com
  • Media Kit
  • Sponsor Info
  • Copyright
  • TOS
  • Privacy Policy

Powered by Techstrong Group, Inc.

© 2022 ·Techstrong Group, Inc.All rights reserved.