Secure Code Development: A Casualty With Agile?

Surely this is the case with any non functional requirement and Agile. This is where you need an architect (by role if not by job title) to make sure that non functional requirements are included in the user stories and acceptance criteria and to negotiate their priority so that they don't drop off the bottom of the backlog.

Ideally this should be non-functional requirements you can either inherit the implementation from another project or tweak it a bit. With some care should be able to come up with an efficient identity and domain based declarative non-intrusive business security. Point is you should have this in place and keep refining it. Sometimes you can postpone it for a few sprints consciously if there are limitations and constraints. Projects will aways need expertise, direction and more importantly smart motivated people.

Jim Bird shows nicely how teams can build in security requirements.

I also agree with the principle that Steve Wink states, that this is about missing requirements or functionality, thought I do not agree with his choice of wording nor with assertion that you need an architect to soleve this problem. I want to go further and state that what is missing from the discussions is a recognition of the limits of what a software development methodology can address and what it cannot address.

I assert that there is no development methodology that will solve the missing requirement problem as it is a knowledge problem. Since it is a knowledge problem, we do not know how to ensure that all the inherent unknowns are discovered and dealt with. The best we can achieve is to identify major areas, usually through personal experience and/or through the use of the experience of others, using checklists for example, and then come up with suitable requirements, but this does not ensure that we will discover an unknown major area. Even when we have correctly identified a major area, there is no methodology or practice that will ensure or guarantee that we will not have missed significant or important issues within the area. These two levels of uncertainty are inherent in knowledge work and berating any methodology as not addressing them is to misdirect one's criticism.

On page 19, of Klaus Pohl's excellent textbook, Requirements Engineering: Fundamentals, Principles, and Techniques, he points out that there is no such thing as 'non-functional requirements', there are underspecified requirements and missing quality requirements. For those who use user stories what this tells us is that if a product is missing security requirements it is because security was not identified as a user and thus no stories from this user's perspective were written. Given this, an architect may in fact be the wrong person to work with the team to specify these stories. A better candidate to work with the team would be a person who has worked in the area of software security. However, if this person does not have extensive experience in the problem domain that the product being built is addressing, then the team would also need to find an expert in the security issues of that domain. An example of this would be a team who is designing the software to operated the doors of a prison and they only consulted with prison guards and a software security expert who has no experience with ensuring security in a prison and not also consulting with an expert on prison door systems. No offense to prison guards, but it has been my experience and in the reports in the literature, users of systems often have not thought through the issues inherent in the systems they are using, hence the need to consult with those who have, i.e. experts.

Going back to the study that started this discussion, as I do not want to pay $30 to read the report, does anyone know if the authors contrast their survey information with information about comparable products, both in size and in the problem domain being addressed, built by similar size companies who work in the same business domains using non-Agile development techniques. If they did and those projects did include better consideration of security issues then the Agile methodology projects then they can rightly fault Agile, otherwise I assert that that they have mis-directed their criticism. It has been my experience and I have also seen a number of anecdotal reports that robustness, fault-tolerance and scalability are also not well addressed by companies building software systems and products, independent of whether they use Agile Methodologies or not. I assert that this is yet another manifestation of the inherent knowledge problem I asserted earlier. Given this does the two extensions they propose address these underspecified requirements and any others that I have not thought of, read about or observed? If not, are we to just keep adding extensions to Agile Methodologies whenever we discover something that is not being covered? If we did, would we still have Agile Methodologies?

I believe secure code development is a casualty in general, not just with agile - at least in small and medium sized businesses.

I believe that agile is highly amenable to tweaking to make development more secure. I wrote a blog post with further details and some examples: www.jemurai.com/2012/03/agile-insecurity/

I applaud making this topic a top level infoq item and would love to see more discussion about application security in a developer forum.

Why would this exact same problem not be apparent in a "non agile" environment? And has Agile ever claimed to magically deal with security without the presence of a security stakeholder?