Introduction to inner-loop security. Shifting left, but better.

The talk traces "shift left" back to a 2001 article about bringing QA into development, then argues that the idea has drifted into tooling pushed onto developers with little regard for their workload. Examples include IDE plugins nobody uses, training that does not stick, and performance reviews that ignore security.

To offer an alternative, the talk adapts the inner and outer loop model from software delivery. The inner loop covers coding, building, testing and committing on a developer's machine, while the outer loop starts at the pull request and holds pipelines, scanners and vulnerability management. Each common AppSec activity is judged by the friction it adds to developer flow. Static analysis, DAST, manual pen testing and software composition analysis mostly land in the outer loop because they are slow, need a running application, or generate noise. Lightweight dependency checks, fast control tests and pre-commit hooks are presented as better inner-loop candidates.

The conclusion is that no universal balance of friction exists, so teams should weigh each control's cost to developers. Reporting should focus on validating security controls rather than chasing long vulnerability lists, with the aim of making the secure option the easy one.