April 29, 2020
Helen: Is security a functional or non-functional requirement and why?
Brittany: Without a doubt, security is a functional requirement. However, it should not be seen as a separate line item, but rather integrated into all components from epics, stories, and tasks, to story points and tech debt. It is just one more component of making sure a feature or product does what it is supposed to do, and the backlog is managed in line with business priorities. For example, if an ignored policy or vulnerability puts an online trading platform at risk for a DDOS attack, why would that be different than a design flaw or a bug that could cause availability issues?
Helen: What’s your favourite SecDevOps fail story?
Brittany: I wish it was just a story that happened one-time, but unfortunately, it’s the same story that I hear again and again. I call it ‘AppSec Roulette’: a development team starts a project and has read all the policies, so they make their architecture decisions without consulting security. Fast forward two months and they’re ready to ship and finally engage security. They assume they’ll move to GA as 5 out of 6 times they can either quickly mitigate the issues or override any objections to fix later, but the sixth time…
“Policies have gotten a bad rap. Development teams hear the term and think “compliance” which has become shorthand for “things I have to do so I don’t get into trouble (or spend 3 hours with an auditor).” However, the reality is that AppSec policies are not about compliance, but are actually a common development practice, just recognized by a different name: ‘design & coding standards.’ ”