Everyone (or almost everyone) in the DevOps world likes to talk about the importance of security. But too often, these DevOps security conversations end with generic recommendations such as, “Follow the OWASP Top 10.”
Don’t get me wrong—reference frameworks such as OWASP are great resources for helping to guide DevOps security. But it’s usually far from obvious to many DevOps teams how to bridge the gap between the abstract theory of these frameworks and actual practice. That’s especially true given that many DevOps teams spend their days putting out fires in fast-moving CI/CD environments and have little time to step back and operationalize security best practices, even if they know they should.
In this article, I’d like to present one real-world strategy for implementing the DevOps security best practices outlined by organizations such as OWASP. That strategy is what I call self-service workload protection. The term refers to making security not just something that DevOps teams recognize as important in the abstract but an easy-to-use service that anyone on the DevOps team can operationalize just like any other process within the CI/CD pipeline.
In other words, we need a self-service approach for offering workload protection through an accessible library of policies and tooling that DevOps teams can leverage on demand. Let’s take a look at how we can achieve that in practice.
Understanding Self-Service Workloads
To understand how self-service workloads work, we need to know the common parameters that define a secure and properly configured application deployment. With that information, security teams can automate the process and offer a complete set of reusable and adaptable tools for DevOps service teams to run.
The common parameters usually boil down to the following factors:
- Making sure that all required compliance and security scans run at least once for every deployment. Those scans need to use preventive actions and block insecure deployments.
- Making sure that for any new vulnerabilities found, we add them to the list of checks. (For example, we should be able to see updated reports for new issues as they’re discovered.)
- Performing audit reports and continuous security monitors over the development and production sites to capture security issues.
- Establishing sane and pragmatic secure default policies and authorization profiles.
The above parameters should be captured and packaged as a self-service solution and used during the normal flow of operations—for example, CI/CD pipelines, validation, and compliance checks creating and uploading a new image to a container registry, etc. This means the security team will have to spend some time to make sure the application of workload protection policies is a team effort.
How to Make Security Better Via Self-Service Workload Protection
From the perspective of the security team, the main goal is to make security accessible to everyone in the organization. Not only that, but the tooling and resources they offer need to be documented and easy to use. The DevOps team should be able to plug in security controls without knowing their ins and outs, though they need to have the means to let the security team know if something goes wrong. Let’s explore how we can make this process better.
Shift-Left Security Through CI/CD Pipelines
Shift-left security is the main focal point of the security team, and it’s also the most tricky to get right. By adding more security checks and audits earlier in the development process, there’s a risk of stepping into other people’s ponds (which may degrade their workflow experience).
A better approach is to give more responsibility to the DevOps team and let them determine the best possible integration point. Mistakes will be made, but important lessons will be learned. Gather feedback from the process and, if required, iterate over the agreeable. That way, everyone will benefit. If the appropriate steps are taken, the security team will have a way to apply its security checks during the development process, and the DevOps team will have its infrastructure protected (at least from known risks).
Test automation and continuous integration points are the most obvious solutions, as they are the most automated parts of the system. The security team can go the extra mile and offer reusable policies and deployment steps that can be added on each deployment type. For example, they could offer a container image that is bundled with security checks and frameworks that test common security issues. The DevOps team can simply enable the checks via the CI/CD dashboard and during the build stage, the check would act as a gateway if a security check fails.
In addition, the security team can share infrastructure policies and secure default configuration via infrastructure-as-code tools such as Terraform using remote state. This could be enabled during infrastructure provisioning by the DevOps team, without configuring anything. Sharing state this way often improves collaboration between departments.
Pre-Baked Secure Images
Developers use VMs and containers to package their apps for the DevOps team to deploy them to production. Usually, those images host crucial configuration and services that are specific to that application. What’s more ideal than to have the security team prepare a list of safe-to-use images that are preconfigured with secure defaults and scanned against vulnerabilities? Developers just have to specify the required image by ID so that the DevOps team can use it for all deployments.
Tip: Symantec’s CWP product is integrated with Jenkins to enable simple, automated vulnerability scanning during the CI/CD process.
For example, tools such as Packer are used to create identical images for AWS compute instances, and features such as seccomp profiles are enforced to Docker images. With Packer, you can deploy consistent images to the cloud and integrate vulnerability scanning into the process to ensure the deployed images meet GSO guidelines. There is a small caveat here, though: If developers decide to add an external library that needs more capabilities and they don’t inform the security team, then the application might misbehave in production and the DevOps team would be caught unaware. So, it’s important to have a good communication channel and do a security assessment for each new dependency or change introduced to the system. This keeps the self-service agreement working without interruptions or misunderstandings.
Conclusion
Letting the DevOps team manage its own self-service affairs when it comes to security controls and compliance requirements are the next major step toward a more productive business model. There are additional costs, but the end results have long-term advantages.
By having a preset repository of tooling, configuration policies and pre-baked images accessed from secure portals, teams can integrate security from the start while maintaining the benefits of accelerated development. And by doing that, security and DevOps teams can improve their collaboration.
That’s great news. What’s even better is that we can use a tool that is suited for all the above tasks—Workload Security Protection from Symantec. If you want to learn more about the platform, see how it can help secure your cloud with a free trial.
Disclaimer- This article was originally published on devops.com.
BDCC
Latest posts by BDCC (see all)
- Top Security Practices for DevOps Teams in 2025 - December 19, 2024
- Jenkins vs. GitLab vs. CircleCI: The Battle of CI/CD Tools - December 16, 2024
- Beyond the Pipeline: Redefining CI/CD Workflows for Modern Teams - December 13, 2024