Alexandru Bolboaca and Adrian Bolboaca’s article about Architecture, Extreme Programming and Security testing was published in the Agile Record, a free-to-download magazine published quarterly in Germany. You can read a fragment of the article here.
Briefly on Architecture, Extreme Programming and Security testing
Agile
Agile has become more and more well known into the software development world today. And this happens because it offers more benefits to the businesses that consider becoming agile. But some topics are not discussed as often as they should. One of them is how to handle security in the new agile context. Of course, the consultant answer would be “the team will decide the best solution possible”. We want to offer our view from experience on this topic. We will introduce the concept of security testing, then we will speak a bit about agile and how it can deal with security testing, then we will offer some tooling and a conclusion for best practices.
Security testing
First of all let us understand what security testing is. A fast definition would be: “Security testing is a process to determine that an information system protects data and maintains functionality as intended.” [http://en.wikipedia.org/wiki/Security_testing]. This is quite a generic definition, so going more into detail the same resource tells us that when we speak about security testing we are dealing with: confidentiality, integrity, authentication, authorization and non-repudiation. These are the areas that need covered when performing security testing for a software product. But how do they relate to agile? The answer to this question would be how to put these theoretical concerns into practice as early and often as possible.
Thinking up front as risk management
Agile software development is based on the concepts of iterative and incremental development. This is often interpreted as starting building a software product without any actions beforehand. This view is incomplete, as we often need some thinking and planning before writing the first line of code. We should think about defining a minimal architecture and communicating it well to all the stakeholders, including the non-technical ones. A very important part of architecture is security. We should think about our product, how sensitive the data is and how the security risks can be minimized. This analysis is very difficult because each application has its own needs and concerns. This is why we need to take the time to find out the best approaches for our situation.
Read more on http://www.agilerecord.com issue 17/2014
