I really enjoy having Gunnar Peterson on the team. Seems like every time we talk in our staff meeting I laugh and learn something – two rare outcomes in this profession. We were having a laugh Friday morning about the tendencies of software development organizations to trip over themselves in order to improve. Several different clients were having the same problem in understanding how to apply security to code development. Part of our discussion:

Gunnar: There are no marketing requirements, so no code, right?
Adrian: I’ll bet the developers are furiously coding as we speak. No MRD, no problem.
Gunnar: The Product Manager said “You start coding, I’ll go find out what the customer wants.”
Adrian: Ironic that what they’re doing is technically Agile. Maybe if it’s a Rapid Prototyping team I’d have some sympathy, but someone’s expecting production code.
Gunnar: I wonder what they think they are building?

Don’t talk to me about improving Waterfall or Agile when you can’t get your organizational $&!% together. What do I mean by that? Here is an example of something I witnessed:

  • Phase 1: Development VP, during an employee review, says, “What the heck have you been doing the last six months?” In a panic, developer mentions a half-baked idea he had, and a prototype widget he’s been working on. An informal demo is scheduled.
  • Phase 2: VP says “I love that! That is the coolest thing I have seen in a long time”. The developer’s chest swells with pride.
  • Phase 3: VP says “Let’s put that in the next release”. The developer’s brain freezes, thinking about the engineering challenges of turing a half-baked widget into production code, suddenly realizing there is no time to do any other sprint tasks. The VP takes the developer’s stunned silence as a commitment and walks away.
  • Phase 4: Developer says to product manager “Yeah, we’re including XYZ widget. The VP asked for it so I checked it into the code base”. Product Manager says “Are you effing crazy? We don’t even have tests for it”. And they make it happen because, after all, it’s employee review time.

It’s not news to many of you, but that’s how features get put in, and then you ‘fix’ the feature. Security plays catch-up somewhere down the road because the feature is too awesome to not put in, and to wait until it’s fully sussed out. I used to think this was a process issue, but now I believe it’s a byproduct of human nature. Managers don’t realize the subtle ways they change others’ behavior, and their own excitement over new technology pushes rules right out the window. It’s less about changing the process than not blowing up the one you have.

Gunnar’s take is a little different: If you’re in security, don’t assume that you can change process and don’t assume your job is to make process more formal. Instead look at concrete ways to reduce vulnerabilities in the context of the existing process. As any teenage girl knows, don’t listen to a word the boy says – watch what he actually does. Likewise, security people working on SDLC, don’t believe the process documents! Instead observe developers in the wild – sit in their cubes and watch what they actually do. If you strip away the PowerPoints, process documents, and grand unified dreams of software development (be they Agile, Scrum, or Rational) this is how real world software development occurs. It’s a chaotic and messy process. This assumption leads you in a different direction – not formalism, but winning the hearts and minds of developers who will deliver on building the security mechanisms, and finding quick and dirty ways to improve security.

Share: