Secure Code Development: A Casualty With Agile?

| by Vikas Hazrati Follow 0 Followers on Mar 11, 2012. Estimated reading time: 2 minutes |

Agile teams are known to produce reliable and high quality code quickly. However, it is observed that the pressure to deliver quickly might result in short cut reviews, curtailed testing and lack of attention to secure code. Is secure development as good as wishful thinking with Agile?

A study based on small and medium enterprises suggested that, Agile teams do not take security seriously even when building systems which are accessible over the web. The study quotes,

The interviews indicate that small and medium-sized agile software development organizations do not use any particular methodology to achieve security goals, even when their software is web-facing and potential targets of attack. This case study confirms that even in cases where security is an articulated requirement, and where security design is fed as input to the implementation team, there is no guarantee that the end result meets the security objectives.

Adrian Lane too looked at the risk of developing software with Agile methodologies in terms software security. According to Adrian,

Focusing on the efficient delivery of features, textbook implementations of Agile come at the expense of secure software development, and push security verification and services outside of the software.

Rocky Heckman suggested that with techniques like TDD and pair programming in place, most of the focus continues to be on functionality.

The tests focus on high quality code from the perspective of the features and reliable repeatability of operations. There is little or no mention of penetration style testing or threat modeling.

Does Agile development mean a total disregard for security? There seems to be a way out.

Jim Bird suggested that with a little caution it is possible to deal with risks in an incremental way.

According to Jim, the security practices have to be burnt into the teams just like other quality practices. Teams could use incremental Attack Surface Analysis to watch for changes in system's security risk profile which might occur as a result of changed architecture of interfaces.

Threat modeling doesn't have to be a big deal for teams that are building software incrementally and that know the code well. Most changes that can be done in a 1-week or 2-week sprint are small and incremental, and shouldn't take a lot of time to review even when you have changed the attack surface.

Jim also mentioned the use of security sprint, which Microsoft calls a security spike or a “mini security push” where the team looks for security bugs in existing code before making any further major changes. Jim quoted Adrian Lane when he mentioned that security is primarily a development team concern than the customer. The development team should take responsibility of giving adequate attention to security in their development process.

Even a strong and well-intentioned Customer can't be expected to understand application security issues or how to build secure software. They already have too much on their plate.

Thus with the right measures and mindset it is possible to weave in security as a part of the development process.

As Jim put it,

There's no reason that Agile Development has to = Security Fail. The technical work, the commitment to quality and detail that is required to build secure software is the same, regardless of what development approach a team follows.

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Secure Code Development: A Casualty With Agile? by Steve Wink

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.

Secure Code Development: A Casualty With Agile? by Raghuraman ramaswamy

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.

Look at it from what is in scope for software development methodology. by Norbert Winklareth

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?

Secure Code Development: A casualty period. by Matt Konda

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:

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

Does this article have anything to do with Agile? by Jeff Santini

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?

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

5 Discuss