Security while scaling Agile - lessons learned

Karen, a principal security architect, describes what happened when a product group moved from waterfall to Agile and then to the Scaled Agile Framework (SAFe). Her security plan of roughly fifty activities per lifecycle stage no longer fit short sprints run by many small teams, and security activities had stopped being scheduled. The talk covers how the security team adapted, the obstacles it met, and what remains unfinished.

The first fix was to regroup the activities into about a dozen backlog stories and build a guided tool that asks teams a series of questions, so each team generates only the security work its change needs. Security requirements were reframed as enablers so product owners could prioritize them, and risk assessment moved to the earliest stages, such as research spikes and program increment planning. Pipeline scanning was pushed toward trunk-based development, though templates for the varied languages and CI systems were still in progress, and threat modeling and risk decisions stayed manual.

The main takeaways are to work directly with engineers, managers and product owners, automate wherever possible, and rely on a champion network, since full-time security staff amounted to about one percent of the engineering population. An audience member from a much larger organization described a similar menu of non-functional requirements, which reinforced the approach.