Don’t Play the AppSec Blame Game: Positive Interactions Between the Security and Development Teams


App_security_RGB_blue_NT.pngMark Twain said, “If you hold a cat by the tail you learn things you cannot learn any other way.” Now substitute “hold a cat by the tail” with “tell a developer their code stinks." Either scenario will teach you valuable lessons, and both will give you scratches. But why would you get scratches from the developer? One simple reason: the approach. Telling anyone their product has issues when they have put their blood, sweat, and tears into it, will cause them to take it personally. The key to getting over that speed bump and moving towards improvement is coming at it from a positive and non-judgmental angle.

 

As I was thinking through this issue, I came across an older blog post by a gentleman named Tim Kulp. In his postTim was talking from the point of view of a development manager who has to deal with developers who have had their code picked apart by HP Fortify SCA (Static Code Analyzer). He listed three great points on how to deal with pissed off developers, and I liked his approach. But I also think his advice is good for security folks who are responsible for testing applications and must work with developers to try to fix the vulnerabilities they find. Let’s go through these and see how they apply to the security managers, application testers, and other security folks out there.

 

Focus on the code, not the developer

 

Tim Kulp says, “Accept one cold hard fact, you are where you are and it really does not matter how you got there.” This is great advice for the development manager who needs to keep the team focused so the developers will begin to improve their skills over time. But what about the security tester who tests an application, turns in the results to the dev shop to get the problems fixed, and then finds 3 different vulnerabilities when the code comes back? This is a facepalm moment if there ever was one (and it is fine to indulge in that facepalm), but the overarching attitude should be one of assistance and learning. How can the new issues be fixed? Did the previous fixes cause the new vulnerabilities? If so, how can that be avoided in the future? Where can the development team go to get some education about those vulnerabilities? All of these are cooperative ways of focusing on the goal of improvement instead of beating up a developer.

 

Make it about learning, not about fixing

 

This is a particularly difficult piece of advice for folks who have an engineering mindset. The goal should be to fix the flaws, right? Well, that is ONE of the goals, but it is not the only goal. Training developers to reduce flaws is more important in the long run.  As Tim says in his post, you need to remediate as soon as possible. But he also makes the excellent point that you should “make sure the team has a firm grasp on the security issue and how to ensure it does not creep in to future builds.” He says to stay away from terms like:

 

  • We need to fix this issue
  • People are going to use this to hack our app
  • The world is going to end because your app is insecure

 

All of these lead to stress and pressure that are not conducive to getting the problem fixed and learning how not to do it in the future. Landing blows about the head and shoulders of the development team is NOT going to make them want to secure the application, and it will likely lead to them looking for some place else to sling code.

 

Reward success, support those who need it

 

Tim starts out this section with this bit of wisdom:

 

Let's face it, in the software world business sponsors want product fast, cheap and do not care about security until it bites them. Developers feed off this behavior by focusing on features, schedule and sometimes chose the quick solution over the best solution.

 

We all know this is a pervasive issue, and Tim is right when he says that this behavior has to be unlearned. As a development manager, Tim is pointing out how to bring in positive reinforcement and celebrating releases with few or no vulnerabilities. If the development manager is not offering any type of reward system for secure code, then suggest it to him.  This could be in the form of bonuses or other incentives. If a coder knows she will benefit from consistently producing secure code, then she has a motivation to get security integrated with her regular process. She learns to code more securely, and you get more secure apps. It’s a win-win.

 

Summary

 

In the end, all of this advice boils down to staying positive in your interactions with developers. As the security person, you can contribute to a positive atmosphere by helping get security ingrained in the development lifecycle. You can create a feeling of ownership in the security process for the developers, which will lead to a good relationship with the development team. This will all take time to accomplish, but don’t give up on it. In the end, the entire organization will benefit from your efforts.

 

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
US Army veteran. IT and infoSec professional since 1994. Founder of HouSecCon. aka m1a1vet


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation