Understanding ShiftLeft

Thinking of "shift left" as a waterfall model is a common misconception. Many assume that shift left simply means moving security tasks to the beginning of the development lifecycle, rather than performing them until the end.

Shift Left Refutes the Pentest Methodology

A decade ago, when security was still gaining ground in the industry, testing typically happened only after all requirements were gathered and development was completed. Reporting security issues after everything is built yields little value and slows down production deployment.

This is a major downside of the waterfall methodology—a linear, stage-wise approach where each stage is completed before moving to the next, with no turning back. You complete the entire pipeline and only then receive feedback—too late and too rigid. The waterfall model focuses on process rather than value delivery. Even if you try to apply shift-left principles within a waterfall approach, staying rigid and not focusing on value means you're doing it wrong.

Iterative Model

The iterative model offers flexibility for feedback. There is no fixed start or end—you can begin at any point in the development lifecycle and still aim to secure the product. The goal of shift left should be interpreted as enabling early security feedback for developers, so security isn’t an afterthought.

Many people mistake threat modeling for a process-oriented approach, similar to waterfall methods. However, true threat modeling is iterative. It doesn’t focus on the entire system upfront but rather on what’s currently being developed. It helps identify risks iteratively instead of trying to capture everything at once. Some methodologies that attempt to enumerate every possible threat are not really threat modeling—they are risk assessments.

At the End of the Day, What Matters Is:

1. Providing visibility to developers into the security process.

2. Offering early feedback—such as running SAST, SCA, and secret detection scans in the CI pipeline—so developers can fix issues while they’re still in context.

3. Avoiding rigid thinking about where to start or end—just start.

4. Choosing methods with low coupling, high cohesion, and minimal dependencies. Rigid, tightly coupled systems hinder agility and slow down progress.

The Philosophy of Start and End

A line has a clear start and a definitive end. It has a destination to reach. A circle or sphere, on the other hand, gives the illusion of infinity. It has no defined start or end. Wherever you begin, the end leads you back to the beginning. You can enter the sphere from any point and still navigate meaningfully, without ever truly reaching a conclusion.

Iterative methods embrace this circular philosophy. You can start anywhere in the cycle and still progress toward the goal. This way of thinking reminds us that the world and the universe is not linear, but rather composed of interconnected spheres within spheres.

Similarly, understanding the security domain requires a thoughtful, adaptable mindset. Avoid blindly applying principles. Instead, choose what works best based on context and continuous learning, not rigid, narrow thinking.