Article: Secure agile software development an oxymoron?

Discussions

News: Article: Secure agile software development an oxymoron?

  1. Can you be agile and secure? That's the dilemma agile software developers face as they build flexible, responsive applications. But it is possible, according to Dan Cornell, principal at the Denim Group. Some compromises just need to be made. In this SearchAppSecurity.com article, "Secure agile software development an oxymoron?," Cornell goes through each phase of the agile development method and explains how and where security can be included. Of course, there are some trade-offs for including security. One of the big ones is that more documentation is required. You need security coding standards, threat modeling standards such as STRIDE and DREAD, and user story threat models. Cornell says no one is inventing new security things to be done, but existing techniques have been made to fit into the agile development life cycle. "Security is not something typically taken into account from people talking about and writing about agile development," he said. "What we need to do is bring back some of the security things." Do you agree? Can you be both agile and secure?
  2. I posed a similar question[ Go to top ]

    I quite agree, and it's a good shot at working security into the process, but I think it's an attitude adjustment too. An adjustement that isn't too disimilar to thinking about security in the first place, agile or not. I posed a similar question a while ago. I think this is a specialization around a (not entirely) non functional requirement along the lines of performance and scalability commonly discussed in agile development circles. Do *some* things need to be done upfront or can everything be done in a paritioned and sometimes reactionary fashion? Regards, Max
  3. Given that the vast majority of software today is *not* developed using agile methods, and is notoriously defective from a security standpoint, shouldn't the question be: "Can you use a predictive, forecast-driven method, e.g. waterfall, and still be secure?" I simply don't see how using agile methods can be any worse. Seriously, if security is important to the customer, it should be accounted for in the product backlog. No non-functional requirement comes for free, and the customer must understand that there's a cost associated with developing secure software. This expense may come at the price of a few other features. Mark
  4. This is completely ridiculous. The fact that your software process is agile or not has nothing to do with developing secure applications. Security is about requirements. If your customer does not care about security, then (beside obvious things like preventing SQL injection and sanitizing your user inputs) you should not care about it. If the customer has security requirements, then you will care about them. That you have an Agile process or not, you implement your user requirements. If your user does not care about security, he may need some education. And you have a responsibility to at least try to educate him. But in the end, he tells you the requirements and you implement them with ow without an Agile process. Emmanuel
  5. WAC. That's pretty much the same as asking "Agile software development with Java an oxymoron?". The fact that you can right doesn't mean that you have to... Regards, Slava Imeshev
  6. WAC. That's pretty much the same as asking "Agile software development with Java an oxymoron?".

    The fact that you can write doesn't mean that you have to...

    Regards,

    Slava Imeshev
    Sorry for the typo. Regards, Slava Imeshev
  7. I do not agree at all that agile developpers are not "taking security into account". and that we have to "bring back some of the security thing". I don't believe this kind of generalization. It may be true that security is a poor parent in many development projects but certainly not more in agile environments than others. One problem with security is that it is lateral concern like transaction management, logging, caching, and other systemic requirements. Traditionnally, these concerns are addressed programatically and this code is blended with the code that addresses business concerns. OO only offers intrusive and inelegant capacity to establish a clean separation between these concerns and the business itself: it's either deep class hierarchy or lots of object composition. This approach does not ease an agile development process where unit testing among other things is crucial. I think that one solution is AOP: it greatly helps to produce code with clean separation of concerns thus a lot easier to test. Using creative technologies like AOP will help developpers to ease the systemic concerns development in any development environment. JL
  8. oxymoron[ Go to top ]

    Anything described as a "moron", oxy or otherwise, has to be treated with suspicion. :-) Cheers, Marc