Skip to content

The Dirty Little Secret Everyone in Application Security Knows But Few Actually Talk About: Until You Actually Fix Your Code, You're Not Actually More Secure

    
The Dirty Little Secret Everyone in Application Security Knows But Few Actually Talk About: Until You Actually Fix Your Code, You're Not Actually More Secure
Woman_Saying_SHh

Here's the dirty little secret everybody in application security knows but few are willing to say out loud: Until you actually fix your code, you haven't actually improved your application security.

It sounds like a no-brainer. Really it does. But with traditional tools you might be working really hard just to generate a large pile of risks that you will triage, rank, sort, graph, and report. But after all this work, your code is just as insecure as before because at the end of the day, nothing really matters until you fix the code. You can run all the tools you want, but they don't change code. Humans change code. And changing the code is what matters most.

Why Don't Application Vulnerabilities Get Fixed in the Code?

Some organizations are currently tracking thousands of risks in their software portfolio.  Why aren't they just fixing them?

  1. Strike While the Iron Is Hot.  By the time traditional tools have identified a risk, the window for fixing the code quickly and easily has long past --particularly if the software project is practicing Agile or DevOps methods. Developers need information about vulnerabilities in real time, as they are coding.

    They don't need a PDF full of mistakes made by other developers. And they don't need single-file "spell-check" type analysis. They need the full power of a real vulnerability detection engine.  Incidentally, this is the best way to teach secure coding as well, so developers get instant feedback about real security flaws.

  2. Jack and Jill Went Up the Mountain. Wait. What? That should have read 'Hill'. Jack and Jill went up the hill. When you saw something different, it seemed weird to you. News Flash: You've been conditioned. And that happens every time you start a new process. It likely happened when you started using your current application security tool. Don't be afraid. You may be able to dramatically simplify your existing security processes by adopting Contrast. 

    Contrast works differently from your current security tools.  It's passive, easy to deploy, runs continuously, and provides real time feedback. Don't be afraid to give up on some of those old processes - like scheduling scans, arranging credentials, training the tool, and triaging false positives.

  3. The Devil You Know Beats The Devil You Don't. We adapt to the tool we have. Do you have someone on staff who handles all of the filtering for false-positive results? What would you do with them if you didn't have any false-positive results? Questions and uncertainties are bound to exist, especially when you are dealing with something you just don't know that much about. 

    The concept isn't new. Dan Arielly has made a career talking about behavioral economics and writing about irrationality. We grow accustomed to the tools we use. We get good at using them. We hesitate to try something new. Fear, uncertainty, and doubt cloud our judgment. And because of that, we too often stick with the mediocre because it's more comfortable...for now.

So you know the problems. And the irrationalities behind them. The question remains: What will you do with the knowledge you now have. Our Solution? Just Do It. Just make the change. And get focused on fixing code, not just finding problems.

You knew that was coming. For it's the same advice everyone gets when they are hemming and hawing between two decisions. It's the iconic advice Nike gives: "Just Do It". 

Give Contrast a try.

  • Read a whitepaper on IAST solutions and how they use advanced data tagging and modern instrumentation to analyze code on a deeper level producing results that matter.
  • Watch a quick demonstration showing how to install the Contrast engine on your code so you can analyze results from runtime to infinity and beyond (thanks, Toy Story).
  • Send us a note so you can schedule your personalized demo at your convenience.

So go ahead. Break free. Blaze new trails. Be original. And help your code and your business be more secure. Because until you actually fix your code, you haven't actually improved your application security. 

false-sense-of-application-security

 

Jeff Williams, Co-Founder, Chief Technology Officer

Jeff Williams, Co-Founder, Chief Technology Officer

Jeff brings more than 20 years of security leadership experience as co-founder and Chief Technology Officer of Contrast Security. He recently authored the DZone DevSecOps, IAST, and RASP refcards and speaks frequently at conferences including JavaOne (Java Rockstar), BlackHat, QCon, RSA, OWASP, Velocity, and PivotalOne. Jeff is also a founder and major contributor to OWASP, where he served as Global Chairman for 9 years, and created the OWASP Top 10, OWASP Enterprise Security API, OWASP Application Security Verification Standard, XSS Prevention Cheat Sheet, and many more popular open source projects. Jeff has a BA from Virginia, an MA from George Mason, and a JD from Georgetown.