Do you believe the 7 myths of software security?

Feb 04, 2016 / 2 min read

Table of Contents

7 Myths of Software Security Best Practices

Software security best practices are meant to improve security initiatives, not secure single applications. Let’s debunk 7 common software security myths.

Software Security Myths Debunked - Understanding Best Practices in Cybersecurity

New technologies move at incredible speeds today, and more software means more vulnerabilities. And the more vulnerabilities (a.k.a. the broken stuff), the better chance attackers have of finding and exploiting them to penetrate your system—cracking into software full of sensitive data for malicious purposes. That’s why building secure software should be a top priority in your organization.

In the beginning, perimeter security was invented to protect this broken stuff from bad people. But more importantly, why is the stuff broken in the first place?

The seven software security myths discussed here are common misconceptions about software security best practices. These practices aren’t meant to to secure particular applications. Instead, they should be part of a robust software security initiative.

7 Myths of Software Security Best Practices

Learn the reality about the many elements involved in securing software.

Myth 1: Perimeter security can secure your applications

Perimeter security is a worthy investment and can effectively shield the hustle and bustle of creativity and innovation within your network, but it does nothing to secure the actual software you rely on.

Myth 2: A tool is all you need for software security

When it comes to security, what you don’t know could very likely hurt you. Integrate software security tools and automation into your software security initiative (SSI) for reasons of efficiency and scale. But do not confuse tool use with an SSI.

Myth 3: Penetration testing solves everything

Any kind of “penetrate and patch” mentality is insufficient as a stand-alone security approach. It is much more powerful in tandem with training, design review, code review, and security testing. A well-structured SSI does all those things and uses penetration testing to demonstrate that all those other things generated the expected level of quality.

Myth 4: Software security is a cryptography problem

You can use a cryptography 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 won’t magically provide security.

Myth 5: Software security is only about finding bugs in your code

Implementation bugs in code account for only half of the overall software security problem. (The other half involves a software defect that occurs at the design level: flaws.) Additionally, while finding bugs in code is great, unless you fix what you find, security doesn’t improve.

Myth 6: Software security should be solved by developers

Solving software security is not as easy as picking a single population (software developers) to assign the security problem to. Ultimately, it must be coordinated by a central software security group (SSG). Creating an SSG is the first step when your firm is ready to tackle software security.

Myth 7: Only high-risk applications need to be secured

Today it’s about securing the entire portfolio—the overall attack surface, not just high-risk applications. No matter whether you’re working on a small project or a huge corporate application strategy, the key to reasonable risk management is to identify and keep track of risks over time as a software project unfolds.

There is no single silver bullet that will solve the security problem. Software security needs to be built in from the ground up. The Black Duck application security portfolio can help you create more secure software.