Facing the Shift-Left Security Conundrum. A True Story

Shift left security is hot — until it's not. Dynamic business requirements and cloud complexity pose major least privilege challenges.

There was a time when developers and security teams did not, er, get along. Friction reigned as each struggled to meet its own needs. Security teams forewarned of data breaches, DevOps forewarned of development slowdowns and access denials from curtailing privilege.

The dark days are over — everyone gets it now: security is about the business. High profile breaches like Capital One, the US president’s executive order on national cybersecurity and new technologies are putting stakeholders on the same page in which organizations understand that prioritizing security is essential to reducing their cloud’s attack surface. Developers want to cooperate and bake fine-grained access control into their security practices. Shift-left security is hot and even has its own culture of technical communities, conferences, buzzwords and personas.

That is, shift left is hot… until it’s not. Dynamic business requirements and cloud complexity make managing least privilege — whether you’re on the security or DevOps side of the house — a huge challenge.

Security and DevOps: Still at odds

Developers want broad privileges to perform the actions needed for the service or application being developed. From a security perspective, full admin privileges are excessive — the very security weaknesses known to lead to data breaches — so need curtailing.

In a well-known scenario that plays out in organizations everywhere, the security team sends a developer seeking broad privileges back to their desk to figure out manually — and justify — which permissions they truly need. The cloud’s promise of agile work gives way to an endless ping-pong — the well known friction — in which security and developers negotiate over access.

For developers and DevOps deep in the trenches, a big part of the problem lies in being able to understand what entitlements they rightfully need. The bottom line is that development work is slowed by security requirements that are best practice on paper, but difficult to implement in real life.

“Shift-left security” methodology — fact or fiction?

Shift-left security means incorporating security earlier in the development process so developers don’t find themselves coming up against security teams demanding they refactor their code just when they’re ready to push to production.

What does shifting left involve for the developer? Here are some elements of shift-left practice:

• Embedding least privilege in infrastructure as code (IaC) - Configuring policies and adding automated guardrails in the cloud by DevOps as part of their ongoing and day-to-day work to protect the infrastructure and prevent excess permissions to cloud workloads.
• Managing role-based access control (RBAC) on Kubernetes - Setting up RBAC on Kubernetes to enforce the least privilege model on Kubernetes clusters, to avoid excess permissions and to enable required permissions only.
• Enforcing least-privilege policies on CI/CD pipelines - Removing developer admin credentials from CI/CD workstations and adopting adaptive permissions to prevent exposure or a widespread breach through CI/CD pipelines.

As a developer or DevOps professional, these actions may leave you feeling fettered. They seemingly tip the balance toward security at the expense of quick and agile development. This is because many of these security requirements aren’t accompanied by automated tools that easily integrate into the software development cycle to become part of the daily work.

Other actions, such as security teams evaluating OSS libraries or requiring a risk assessment for new features, are high maintenance and go against performance SLAs, which is what you as a developer are really measured on rather than security efforts toward preventing a data breach.

With so many tasks and pressure from engineering leadership, support, product, customer success and marketing — what’s a developer to do?

Crossing the chasm: DevSecOps

Decisions regarding the security practices that development should be implementing don’t need to fall to the developer. An organizational solution exists: DevSecOps. We explore the DevSecOps role in a separate article — simply put, DevSecOps professionals are responsible for bringing the right security processes to developers in a way that’s easy to apply and with a focus on the business value of the security requirement.

Detect risks in IaC and harden the cloud infrastructure environment for least privilege as part of the CI/CD pipeline

Image created August 2022

DevSecOps is the closest thing to an organizational fix to bring a security focus into the development sphere and help organizations shift left. Even so, it’s not a magic bullet and is hard work. DevSecOps professionals are still people relying on others and themselves to share info, align on what's most important vs noise and figure out who does what to fix issues. And not every organization is able to dedicate security roles within their DevOps team.

In an era in which security requires attention, multiple steps can be taken to make shift left happen.

What it takes to make the shift-left shift

It’s time to acknowledge that security activities and management are taking up the time of your development teams whether or not your organization is consciously prioritizing security and has allocated adequate cloud security resources.

Detect gaps in policy guardrails as part of the IaC process, minimizing compliance risk

With the security best practices of least privilege and zero trust widely recognized as the only way to secure the cloud environment effectively, and compliance a regulatory must, organizations are left to choose one of two paths:

A never-ending struggle - Let developers continue daily negotiations with security, wasting their time and venting their frustration at the water cooler. Or:

Shift left - Make a conscious choice to advance shift-left security, adding DevSecOps roles if possible — but even if not — introducing tools that will streamline, automate and remove friction from security processes and educating DevOps about the insight they can gain from automated security tools.

What does this mean? In short, shifting left involves three key dimensions:

• A mindset shift - Understand that security is not a side task but a core part of the development day to day. Security doesn’t take away from development time; rather, it is an essential part of development time. Leadership should trust that their DevOps are doing the right thing when working on security.
• The right tools - Find security platforms that help developers fill real performance-related security gaps and make security easy to implement and incorporate. Such tools can help bring together the different goals of CISOs (security) and DevOps teams. CISOs can use them to gain visibility and greater control over what the infrastructure looks like and what DevOps is doing. DevOps teams can use them for insights previously unavailable to them, learning from the tools’ findings and risk by severity. The tools should leverage workflows to help get risk remediated, offer automation guardrails and empower scrum masters, PMs or POs to add security to their sprints. They can, for example, integrate generated access policy recommendations with Slack, Jira, ServiceNow or Terraform for automatically granting and revoking entitlements. In short, the right tools can help break down the organizational silos that de facto prevent willingness to shift left on security.
• The right training - Conduct repeatable training with development teams about security, while automating and integrating training processes into cloud infrastructure processes. Training is essential to achieving greater cloud security maturity and a key part of any cloud security strategy.

Shifting left isn’t a luxury

Least privilege driven by shift left isn’t a luxury, it’s a necessity. Cyberthreats are increasing and costing more.

In its recent report [IBM Cost of a Data Breach, 2022], IBM found that 83% of organizations had more than one data breach — and that 45% of the breaches were cloud based. They also found the average cost of a data breach to be USD 4.35 million, up 13% over the past two years.

Verizon, in its annual data breach investigations report [Verizon DBIR, 2022], reported that “82% of breaches involved the human element” — be it stolen credentials, phishing, misuse or simply an error.

Organizations need to crack the least privilege nut. And yet, IBM reported that 79% of critical infrastructure organizations (finance, healthcare and others) — and 59% of industries overall — don't even deploy zero-trust architecture.

The bottom line: Can we really shift left?

The right tools coupled with a strategic approach to cloud security maturity across tools, people and processes, are the answer to the “shift left” conundrum and ending the vicious cycle of dev-security friction. A comprehensive cloud security platform to support all security stakeholders — DevOps, DevSecOps, IAM and security — can help remove organizational friction and finally let DevOps and security work together.

Learn more about the DevSecOps definition and how a DevSecOps role can contribute to your organization's security here.