Securing agile

Long ago, we thought quality should be controlled at the end of a process. Then agile came along and showed us quality needs to be assured at every step we take in the way to reach a goal. Today security, as it faces the same challenges, will try to follow the same path.

Following this path means a couple of things. First, security is one of the forces, together with user design, systems design, evolutive architecture, quality assurance and more, that pushes the agile process to achieve business value for our customers that will perdure.

Second, as a consequence of the first, security should be part of every part of the value delivery process. Inceptions should identify security concerns which might be threatening what the stakeholders have agreed on as business value. Iteration planning and “tres amigos” sessions should identify the stories and points in the stories where we might be dealing with sensitive information and include acceptance criteria accordingly. Developers should use a minimum of techniques to make sure code does not have naive cracks which could have been caught with static analyzes tools, and, implement security measures to validate back doors have not been planted by other developers. Tests to automate what’s possible should be mostly welcome.

Learning objectives
Security basics.
Threat model.
Apply a threat model to the agile process.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s