The toxic-combo time bomb ticking in your software development lifecycle

In cloud security, the concept of "toxic combinations" has taken center stage, thanks to the pioneering work of Wiz Security. These arise when multiple issues interact in unintended ways, creating opportunities for attackers to exploit.

However, while the security industry focuses on scrutinizing infrastructure-level toxic combinations, a whole new set of threats is brewing in the shadows of the Software Development Lifecycle (SDLC): “toxic interactions”. These threats exploit the complex interplay of human and machine developer activities, misconfigurations in tools such as Source Code Management platforms (like GitHub and GitLab), and a wide range of vulnerabilities in proprietary and open-source code.

The recent EmeraldWhale breach highlights the consequences and nuance of these threats. Attackers didn’t brute-force their way into a production application. Instead, they exploited a combination of SDLC weaknesses: excessive developer permissions, exposed GitHub configurations, and hardcoded credentials. It was like leaving the blueprints, the keys, and the alarm codes all in plain sight. The result? Over 15,000 stolen cloud service credentials and a compromised development pipeline.

The problem is that traditional approaches to addressing toxic combinations in cloud security often focus narrowly on standalone misconfigurations, but this is just one piece of the puzzle. Combined with access controls, developer entitlements, developer activity, and code vulnerabilities, they create larger, more complex threats within the SDLC that organizations can no longer afford to overlook.

Recognizing unique toxic combinations is important, but describing and addressing them as toxic interactions offers a clearer, more effective way for organizations to achieve true SDLC security and governance.

The rise of “toxic interactions” in the SDLC

Toxic interactions start with an identity—this could be an internal or external developer, a service account, or even a third-party application. When an overly entitled developer identity engages in risky activities by leveraging misconfigurations to introduce code vulnerabilities, it creates a chain of risks that can quickly escalate into threats, jeopardizing the entire SDLC.

Here are just a few examples of these interactions:

The "Ghost in the Machine" Combo: An inactive user account with excessive permissions is a prime target for credential theft. Pair this with unrestricted access to critical repositories, and a malicious actor can wreak havoc.
The "Wolf in Sheep's Clothing" Combo: A developer bypasses branch protection rules and exhibits suspicious commit activity, such as large code dumps, late-night commits or changes to sensitive files, potentially injecting malicious code.
The "False Approver" Combo: A pull request from an unknown source gets approved by someone with no prior commit history, potentially allowing an attacker to slip malicious code into your project.
The "Open Door" Combo: A repository grants unrestricted direct access to everyone, coupled with pull requests approved by users with no prior commit history, creating a backdoor for malicious code.
The "Insider Threat" Combo: An identity bypasses branch protection rules and combines this with suspicious commit activity, potentially indicating an insider threat attempting to compromise the codebase.

These are not just theoretical threats; they’re the reality of today’s sophisticated attacks. Addressing them requires a deeper understanding of how risks emerge within the SDLC.

Secure the SDLC from the inside out by addressing gaps in traditional security

While organizations have implemented various security tools and practices, most struggle to detect and prevent these toxic interactions effectively. Traditional security solutions often operate in silos – scanning code, monitoring access, or checking configurations independently. This fragmented approach creates dangerous blind spots where critical security areas overlap.

To close these gaps, organizations need a unified approach that can identify and neutralize toxic interactions across the entire SDLC ecosystem.

Securing the SDLC starts with addressing the multitude of risks that arise from developer identities, misconfigured tools, and vulnerable code. When these attack vectors intersect, they amplify risk, creating toxic interactions that current approaches fail to address.

A multi-layered defense that combines identity governance, secure tool configurations, and code security ensures security is seamlessly embedded into every stage of the SDLC. By reducing the attack surface through preventive measures, rapidly detecting issues, and remediating risks—whether guided or automated—organizations can close these gaps and stop toxic interactions before they compromise the development pipeline.

By treating the SDLC as an interconnected system, organizations can address risks where they converge and amplify. This unified approach focuses on the interplay of risks across developer identities, tools, and code, ensuring security measures work together to neutralize threats before they escalate. By seamlessly embedding security into every stage of development, organizations can build secure and resilient software without slowing innovation and ensure their defenses stay ahead of today’s evolving and increasingly sophisticated SDLC threats.