Security is not a nice to have feature

Security is a big part of our daily conversations specially when we design or architect new applications. In our architecture artifacts, we have a section for non-functional requirements which has the security highlighted in the first place. Although, we understand the importance of security, it always gets in the way of other tasks that we have to concentrate on. We put the security related stories in our backlog, but we keep pushing them down with lower priority compared to stories that bring business value. Sometimes, our applications live behind the firewall which make the security lower in the priority from the product owners’ point of view.

Some developers feel the security is not their responsibility. They are expert in designing and writing codes. They think the company should hire security experts who can handle all of the security matters.

In reality, the security is the whole team responsibility. As leader, architect or manager, you need to make it a culture. Security for you and your team should not be add-on or nice to have feature that we can keep lower it in the backlog. We should introduce security to our teams and product owners as it is a concern that is mandatory to cover before being live in production.

You need to create your story in a way that concern the team on the system confidentiality, integrity, availability and traceability. For example, instead of creating a user story to encrypt your database or to enable SSL to encrypt data in rest and in travel. You need to create the user story in a way that concern the team about the data integrity and confidentiality and explain how this can impact the users, company’s reputation and revenue.

At the end I recommend reading “Secure by Design” book by Daniel Sawano, Dan Bergh Johnssona and Daniel Deogun. It is a great book that can help you change your way of thinking about how you change the security from add-ons to be a daily concern that you always trying to solve.