DevSecOps Is Having Its ‘OK Boomer’ Moment – InApps 2022

Rezilion sponsored this post.

DevOps veterans already know that legacy approaches to software compliance and security do more harm than good, often involving preventive controls that are time-consuming and require manual processes and workflows. Things like access policies, procedures, standards and network firewalls are antiquated; they were designed for waterfall development methodologies and relied on long time cycles, which are incompatible with DevOps.

The debate these days is over how to apply the cattle vs. pets principles of DevOps, that enable immutable infrastructure, to compliance and security. I’ve been a big advocate of Gartner’s recommendations for using its continuous adaptive risk and trust assessment (CARTA) methodology for supporting DevOps, because in cloud workloads risk is fluid, not static. It needs to be discovered, continuously assessed, and mitigated.

What Is Your Desired State?

Here’s the elephant in the security room: Resilience is baked into every immutable application or service. That is, in the event of a component or code update, if your best practice is to create a new container with the updated version of your application and delete the old one, then you will have a fresh instance after each update. Should a vulnerability exit or an injection attempted, they will be cleaned during the update.

For most, achieving an operational model in which no configuration changes, patches or software updates are allowed on production systems, is not quite a reality yet. There will be a day where all patches and updates are applied to “golden” images and layers, and then production workloads will universally be built fresh from these images and replaced, rather than serviced. In such a world of immutable infrastructure, cloud workload protection strategies will shift to a focus on application control and desired state enforcement at runtime.

Today, we’re already seeing the world of patch and vulnerability management fall into chaos because the rate of code change and dependency on third party or open source components is greater than most security and compliance teams can keep up with.

Desired state enforcement solutions analyze the CI/CD pipeline and turn code into a whitelist, establishing an automatic policy that enforces developer intent or desired state. The key with desired state enforcement is to rely on the declarative nature of code to drive policy, rather than attempting to establish a heuristic analysis or attempt to learn good from bad using machine learning — because those methodologies can’t keep up with the rate of change and pace of scale in modern DevOps environments. Baselines are a thing of the past.

The declarative nature of modern development languages, modern frameworks and modern architectures inherently creates a whitelist for each service. A recipe or cookbook is basically a policy — it’s an architecture policy that tells code what it can and can’t do. Why shouldn’t we apply the same principles to protection? Cookbooks and recipes are a perfect profile of the desired state — why not use those to populate and build a whitelist, or if you prefer a policy that is enforced at runtime using your existing immutability mechanisms?

Cloud Workload Protection Is Already in Your Code

There are two fundamental benefits of cloud workload protection:

1. Desired State Governance

Understanding what should and shouldn’t be running in production environments help create a better model for architectural hygiene. Containers ship with lots of unnecessary glut that often gets deployed in production. This “inherited” code often suffers from bloat (more code than is needed or is useful). Old code tends to stay around because it’s hard to tell if anything or anyone needs it. Safer to leave it in, right? In addition to the problems of identifying who wrote it and when, bloated services have a direct security impact because more code = greater attack surface.

Older code usually has vulnerabilities, in part due to the evolving nature of the security environment and that new attacks targeting old code appear on a regular basis. Also, the security context of old code can change as applications evolve or code gets moved. Because declarative architecture can be unraveled into relationships, dependencies and actions, desired state enforcement can reliably identify which artifacts are actually needed in production and which components are merely operational bloat.

2. Desired State Enforcement

In today’s development environment, we can take advantage of the declarative nature of modern development languages, modern frameworks, modern architectures, and cloud-native architectures based on microservices, APIs and containers. There’s a lot of declarative information there. We can take all of that declarative intent and use it to build the whitelist that we are talking about — it can be our policy.

In a recent webinar I did with Neil MacDonald, Distinguished Vice President Analyst at Gartner, we talked about using desired state enforcement to bring security seamlessly and transparently into DevOps workflows. The idea is: Let developers do their thing. The onus on the security team is to integrate protection into the developers’ world — rather than complicate it. As Neil says, “We’re not going to go ask the developer to go to some security console or to go write a manifest of all of the applications that are supposed to be on this server. They want to write code, they want to do it quickly, and they want to get it into the hands of your customers. We can’t slow them down, and that needs to be a guiding principle.”

Feature image via Pixabay.

At this time, InApps does not allow comments directly on this website. We invite all readers who wish to discuss a story to visit us on Twitter or Facebook. We also welcome your news tips and feedback via email: [email protected].