As the Product
I’d like to be secure
To avoid hackers exploiting me and having fun at my expense
One of the things that I’ve been working on during the last time is about how to ensure that the security of the product is correctly managed through the agile lifecycle. And it’s not an easy topic since we don’t have a big up-front planning were we can expend the needed time to analyze the risks and set up the security requirements. In fact is the opposite, we are not sure of what we will be building some weeks after so planning security can be a really painful activity or even worst, we can decide to forget about security in our product or do it as “best effort”. But after consider it carefully, I really think it’s a good opportunity to increase security efficiency since we can also be agile on security; reassessing the risks with a higher frequency and being able to better adapt the countermeasures to the dynamic context where the product will be leaving.






But to be able to exploit this opportunity we will need a “security champion” collaborating with the DevOps team to guarantee the security risks are detected and managed on time. I don’t mean having a dedicated security architect by team but he should have some dedication at least once per sprint to ensure that no new risks are being introduced while the team develop the new stories.
This security specialist must work closely with the Product manager and the Product owner to understand what is the long and mid-term vision and roadmap for the product, so he can forecast what will be the risks and define the security requirements that would be taken in consideration by the scrum teams in the implementation.

He also need to have close interaction with the scrum members to understand how they will implement each story in order to be able to detect security risks coming from the implementation strategy selected in each case.
He’s also the one that should maintain up to date the risk register agreeing with the risk board the strategy to manage the identified risks and work with the Product owner to translate these risks management strategies into user stories to inject in the teams backlog.

On the other hand, as part of the continuous integration process,  the static code should be checked with a tool to detect any security vulnerability being introduced on the product, as well as vulnerability scans for the infrastructure and application vulnerability scan before to consider a release prepared to be deployed in production. Beside of that, periodically and always for each major release, it must be done a complete security audit before deploying the code into production, as well as a Pentest exercise over the infrastructure hosting the product.

Sometime I've heard also people afraid by the fact of the same team developing and operating the solution. Since it can be a risk on some cases, there is plenty of ways to mitigate it: peer programming, peer reviews, external audits, role segregation, etc...

Lastly but not least it will be fundamental to deliver proper training to the scrum team about secure code techniques since as in all the cases, the human factor is always the weakest link of the chain.

In conclusion, contrary to what is commonly believed, agility does not have to mean lack of security. In fact, as we have seen, it could become an opportunity to improve better security processes being smarter and more effective on the efforts that we dedicate to protect our product.