Security in software as an afterthought

Software development often uses agile development processes to see the project through from start to finish. Despite the processes being used on network and web applications with high security risks, most agile methods does not have features that specifically targets security concerns. (Siponen, Baskerville and Kuivalainen, 2005) Checklists, management standards, risk evaluations can all support agile methods but they are not seamlessly woven in with IT security in mind. (Othmane et al., 2014) Nor are they cost-effective; should a serious problem be discovered late, it might require repeat coding. (Baca et al., 2015)

Traditionally a security manager will be an advisor and perform audits, but in agile processes, some of the many steps are small and independent. It might not be successful to include a security manager in every small step and he/she might not see the whole perspective when given chunks of a larger puzzle.

Problems with security as an afterthought:

  • Cost, should a large portion of code need to be redone.
  • Security manager only seeing the whole picture at the end, might be missing important details of underlying algorithms.
  • Similarly, it would take time to get familiar with the software and to look for all the details an experienced user might see easily.
  • Software quality will improve if security is considered in what-if scenarios from the start.
  • Risk estimation might not be tailored to IT security, but rather a general estimation for all software – not giving a proper picture of the security risk.

Suggestion for solution:

Baca et al (2015) describes how Ericsson AB has tested an agile software development process when creating a money transfer system; Security-Enhanced Agile Process (SEAP).

  • SEAP has a specific characteristic in that it involves a group of 4 security specialists with different competences. This could for example be Security manager, security architect, security master and penetration tester.
  • There is an integrated risk analysis process performed per Business Use Case, compared to the standard approach at the beginning of every major software release.
  • The risk estimations were ranked on a range from 1 to 5 on the likelihood of successful attacks. This was multiplied by the estimated impact should it happen, which together gave a value which would indicate the severity. Above a certain threshold, the threat would be corrected immediately.

Image: The model of SEAP. The padlock indicates a security review. Source: (Baca et al., 2015)

Agile methods are in the software industry used mainly in place of the old waterfall method, and so it covers discovering and documenting use cases and needs, design, development and testing. In other words, SEAP uses a classic type of Agile development but implements the security aspect on every sprint and every use case too. So, in short, SEAP is used in the Agile methods of development and design as it covers all the aspects of the software creation.

Image source: (Joel, 2015)

Findings with SEAP process’ solutions:

  • SEAP solved risks previously postponed for later versions – from 38% to 11%.
  • On average, security risks demanded 1.5 hours of employee time with SEAP compared to 2.7 in previous processes.
  • SEAP decreased the number of unhandled risks from about 50% to 21%.
  • SEAP increased fixings of risks from 12,5% to 67,1% (more than 5x increment).
  • Severe risks were found because of a more detailed risk analysis, a deeper understanding gained.

SEAPs personnel cost for security was 5% compared to 1% in the previous process. However, particularly the 5x increment in security fixings were certainly beneficial as early correcting might hinder serious attacks. This could in other words save Ericsson any large blunders in the future. (Baca et al., 2015) I would say this sounds like a good approach to consider for software with high security risks.

I think it might be slightly overkill to include so much security and so many security professionals in developing a new app for collecting knitting recipes or a software, which will help you arrange the furniture in your living room. Security, as I am sure we all agree, is very important and often overlooked – but it should be considered in correlation to the factual need of it.

Saying that, Mayer-Stabley (2014) doesn’t fancy the slogan about “security cannot be an afterthought” in Agile processes. He believes it to be as incorrect as the reverse view, which would be “don’t think about security until the very end”. Both the fact that you can’t consider it at the end and that you should only think about it at the beginning is wrong in his opinion. I think the SEAP method demonstrates his take on what he believes any security expert will tell us: “include security concerns upfront AND keep them on the agenda throughout.”

Therefore, every software development project should consider security all through the development and design I believe – but in a way that makes sense in terms of what the software’s market and users are. Backup, password-recovery, not storing even the fly-fishing app-password in free text – these things are all important to consider all through the development. After all, if the CEO of Important Company Inc. loves to fly-fish and is not careful about passwords, this could be an entry point to one account, to another and finally some secret information from Important Company Inc. is leaked..!

(Strava, anyone? ) 





Baca, D., Boldt, M., Carlsson, B. and Jacobsson, A. (2015) ‘A Novel Security-Enhanced Agile Software Development Process Applied in an Industrial Setting’, O’Conner, L. ARES Conference International Conference on Availability, Reliability and Security 2015: 11-19, ARES Conference International Conference on Availability, Reliability and Security 2015, SwePub. IEEE: IEEE. pp.11.


Joel. (2015) A Designer’s Introduction to “Agile” Methodology [Online] Available from:–cms-23349 (Accessed: 16.01.2018).

Meyer-Stabley, B. (2014) Agile! The good, the hype and the ugly. SpringerLink [Online]: Switzerland : Springer, 2014. SpringerLink [Online] [EBSCO].

Othmane, L. B., Angin, P., Weffers, H. and Bhargava, B. (2014) ‘Extending the Agile Development Process to Develop Acceptably Secure Software’, IEEE Transactions on Dependable and Secure Computing, 11 (6), pp.497-509.

Siponen, M., Baskerville, R. and Kuivalainen, T. (2005) ‘Integrating Security into Agile Development Methods’, Anonymous Proceedings of the 38th Annual Hawaii International Conference on System Sciences, Proceedings of the 38th Annual Hawaii International Conference on System Sciences,

Image: Copyright Alexas_Fotos,, published under CC0 Creative Commons