It’s hard to pinpoint when the concept of DevOps entered the mainstream. As late as 2017, implementation was still relatively sparse, with many skeptics questioning the approach or simply wondering what the fuss was all about. Today, DevSecOps is following that upward curve, with adopters trying to educate mainstreamers on the benefits, while the yet-to-be convinced often struggle to make sense of common misconceptions.
Like DevOps, DevSecOps comprises equal parts culture, process, and tooling. DevSecOps is founded on the idea that security is a shared responsibility across the engineering and security teams, which can be a cultural barrier in organizations that are more accustomed to treating security as a last step in the development process. But as more organizations adopt cloud and container technology, they can’t afford to leave security to the last minute.
Outdated security practices can undo even the most efficient DevOps initiatives. Some would say that security should have been more tightly integrated into DevOps in the first place.
“Security was always intended to be part of that melding between development and operations, but it got overlooked in many cases when teams started doing DevOps,” Kirsten Newcomer, director, hybrid platforms security product management at Red Hat, said in a recent interview. “And even today, in some cases, DevOps is seen as something that belongs more to the application team, even though it’s intended to include Ops.”
The tools and processes teams use to protect containerized applications must embody DevSecOps principles by implementing security earlier in the application life cycle, integrating and automating security into existing developer workflows, and empowering developers as security users.
Best practices
Teams need to integrate security throughout the layers of the solution stack before deploying and running a containerized application. Security must be a continuous process throughout the application and IT operations life cycles, responding to new threats and solutions as they emerge.
Red Hat’s recommendation for a DevSecOps framework includes nine security categories and 32 methods and technologies that address the entire application life cycle. This recommended framework places Red Hat’s built-in capabilities, DevOps toolchains, and security partner solutions at key integration points in the application lifecycle.
Securing the Kubernetes platform to support business-critical containerized applications in a secure, reliable, and scalable manner is essential. This recommended framework provides foundational platform security features for securing the underlying container host—Red Hat Enterprise Linux® and Red Hat Enterprise Linux CoreOS—as well the container platform.
In addition, vulnerability and configuration management helps improve, identify, classify, and resolve application, configuration, and container image security defects. These methods help to incorporate security into the DevOps lifecycle early, which saves time and money.
Identity and access management (IAM) methods control access to on-premises and cloud assets, applications, and data based on user or application identity and administratively defined policies.
Automated compliance validation and reporting throughout the DevOps pipeline helps you simplify audits and avoid costly regulatory fines and lawsuits.
A best practice for application security is to integrate automated security testing into your pipeline, including the registry, the integrated development environment (IDE), and the continuous improvement (CI) and continuous delivery (CD) tools.
Container images can and should be scanned in your private container registry. Scanners can be integrated with CI for real-time assessments—cataloging the open source packages in a container, notifying you of any known vulnerabilities, and updating you when new vulnerabilities are discovered in previously scanned packages.
Scanning at the registry level is crucial in hardening pipelines and catching vulnerabilities as early as possible. Later in the life cycle, vulnerability scanning in the build, deploy, and runtime stages should be employed to discover and address issues as soon as possible.
It’s also highly recommended to sign custom-built container images to ensure they are not tampered with between build and deployment. At the deployment stage, integrating security testing should consider policies that trigger automated rebuilds, versus trying to patch running containers.
Red Hat’s recommended DevSecOps framework lays a reliable and scalable foundation to help you expand DevOps security and reduce risk. To learn more visit us here.