3 ms·

Many devs I speak and work with are either ambivalent or disillusioned about agile. In my circles this article keeps coming up in discussions about agile - http

Many devs I speak and work with are either ambivalent or disillusioned about agile. In my circles this article keeps coming up in discussions about agile - https://securosis.com/blog/agile-development-and-security/ https://securosis.com/blog/agile-development-and-security/.

jerf 12y ago
Errr, while I agree that Agile has a hard time producing secure code, I see little evidence that non-Agile has any easier of a time. Sure, in theory Agile under some interpretations [1] precludes the sort of thoughtful design that security requires, but it's not as if very many projects are getting it right without Agile either. To a first approximation, everybody does security this way: 1. Some developer who thinks they understand security, but really doesn't, make some vague sketches on a napkin that describe how one particular attack, which isn't even that big a threat in the first place, could conceivably be prevented, if the attacker cooperates well enough. 2. Development happens without regard to the napkin. 3. Flaws are fixed one-by-one as they are reported with little thought given to whether the reported flaws reveal a systematic problem. The most common alternatives to 1 are "Everybody on this project is just so awesome that they would never make mistakes so we don't even have to think about security", "Oh, security, pshaw, 'just' sanitize user inputs and you're done" (though press them on what "sanitizing" is and you'll find it generally borders on meaningless) and "________." (no thoughts given at all). [1]: That caveat is important, please do not reply as if it is not there.
- Spearchucker 12y ago
  I agree with you. Security takes discipline, regardless of methodology. Interestingly, the only freely-available security-focused method I've seen is Microsoft's SDL (waterfall)[1]. The article does spark some interesting debate though, also about TDD. [1] http://www.microsoft.com/security/sdl/default.aspx http://www.microsoft.com/security/sdl/default.aspx

jerf 12y ago

Errr, while I agree that Agile has a hard time producing secure code, I see little evidence that non-Agile has any easier of a time. Sure, in theory Agile under some interpretations [1] precludes the sort of thoughtful design that security requires, but it's not as if very many projects are getting it right without Agile either. To a first approximation, everybody does security this way: 1. Some developer who thinks they understand security, but really doesn't, make some vague sketches on a napkin that describe how one particular attack, which isn't even that big a threat in the first place, could conceivably be prevented, if the attacker cooperates well enough. 2. Development happens without regard to the napkin. 3. Flaws are fixed one-by-one as they are reported with little thought given to whether the reported flaws reveal a systematic problem. The most common alternatives to 1 are "Everybody on this project is just so awesome that they would never make mistakes so we don't even have to think about security", "Oh, security, pshaw, 'just' sanitize user inputs and you're done" (though press them on what "sanitizing" is and you'll find it generally borders on meaningless) and "________." (no thoughts given at all). [1]: That caveat is important, please do not reply as if it is not there.

Spearchucker 12y ago
I agree with you. Security takes discipline, regardless of methodology. Interestingly, the only freely-available security-focused method I've seen is Microsoft's SDL (waterfall)[1]. The article does spark some interesting debate though, also about TDD. [1] http://www.microsoft.com/security/sdl/default.aspx http://www.microsoft.com/security/sdl/default.aspx