Software Integrity Blog


Software security myth #4: Software security is a cryptography problem

Software security isn’t the same thing as security software. You can use a crypto library to add a security feature to an application, but that’s not the same thing as making an application secure. The liberal application of magic crypto fairy dust to your code will provide no security by magic. (In fact, the same myth applies to any particular security feature, not just crypto.) Software security needs to be built in from the ground up. As such, cryptography makes the list of software security myths at number four.

The seven software security myths are common misconceptions about software security best practices. These myths explore how software security initiatives should work, and aren’t simply about how to secure a particular application.

Learn more about all seven software security myths.

Cryptography can be a useful tool when it comes to securing data, communications and code globs (among other things), but it’s no silver bullet. Why, you ask?

Magic crypto fairy dust

The idea that you can sprinkle magic crypto fairy dust all over a piece of software and it will then be secure is wrong. First off, security is a system property, not a thing. Simply adding crypto measures to your code is unlikely to make it secure. Additionally, cryptography is astonishingly complex to get right. Not only is the math difficult, applied cryptography is filled with sneaky pitfalls that are easy to get wrong.

Cryptography can’t find or eradicate bugs and flaws, but sometimes it can temporarily obscure them and make life that much more difficult for debuggers and architects. Crypto can’t train your developers. And crypto even falls prey to penetration testing from time to time. To give you an example: if a SQL injection is found in your app that talks to an encrypted database, do you think encrypted data or plain text data will be returned?

Just as we’ve already discussed with perimeter security, security tools and penetration testing, crypto alone is not the answer.  (Or more generally, any particular security feature alone is not the answer.)

There are two reasons for this.

  • Most attacks against applications do not target security features specifically (and crypto is just another security feature). Most instead target defects in other parts of the application (bugs and flaws) in any part of the reachable code. Using however much crypto does nothing to fix these defects or to protect them from exploit.

All SSL does is protect an exploit from prying eyes as it whizzes by. It might even allow an attack to sneak right by some firewalls.

  • Applied crypto is designed to protect data, not the application that processes data. Data in motion between machines can be protected. Data at rest on a disk can be protected. But data being manipulated in real time by a running application is a sitting duck, or a running duck—well, you get the picture.

Is security a feature or a function? No.

Developers and software architects have been trained for years to piece out their work in terms of features and functions and often think by default that security is one of the two. The most common security feature in a developer’s mind is cryptography. That is, when you ask a developer to make their code secure, often the first thing they think of is crypto.

Software security is about integrating security practices into the way you build software, not simply integrating security features into your code. The integration of identity management features, multi-factor authentication or PCI compliance measures are all very useful and meaningful tools that shouldn’t be discounted. But at the end of the day, simply adding security properties such as these won’t magically secure the software.

There is no single ‘fix’ to guarantee security. Achieving the most secure software requires carefully administered, step-by-step measures that take place strategically throughout the SDLC.

Want to see what organizations throughout a variety of industries are doing to implement software security initiatives?

Learn about the Building Security In Maturity Model (BSIMM). 

See Myth #5


Myth #4: Software Security Is a Cryptography Problem
Myth #4: Software Security Is a Cryptography Problem

More by this author