Tech Insight: 5 Myths Of Software Security

Why do vulnerabilities keep cropping up in software? Here are five reasons -- and what developers can do about them

[Jason Sachowski is a security professional at ScotiaBank. His content is contributed through the auspices of the (ISC)2 Executive Writers Bureau.]
Todays businesses rely heavily on software -- and increasingly, so do individuals. Yet with so much riding on our applications, we continue to see new vulnerabilities crop up every day -- and major data breaches as a result.
Why isnt software more secure? Some of the problem has to do with the development process, and some of it has to do with the need to better integrate software security with business needs. Lets look at some of the myths that continue to surround the software development process -- and how these myths contribute to the continuing vulnerability problem.
Myth #1: Software Security Is An Information Security Problem
Its a common misperception that anything related to security should be the responsibility of the IT security department. In fact, security best practices should be instilled as subfunctions of the overall business. In its 2009 article,
Security Is Not Just a Technical Issue
, the U.S. Department of Homeland Security said it best: Senior management must set the direction for how enterprisewide security practices are perceived, prioritized, managed, and implemented.
The Microsoft Application Architecture Guide
makes another important point: Security must be viewed as just another attribute of software, much like usability, performance, reliability, and scalability. Security controls should be a critical element in the software development life cycle (SDLC), from the definition of requirements to the retirement of the application.
Myth #2: Developers Are Solely Responsible For Application Security
When vulnerabilities are found in software, developers are usually on the front line of the finger pointing. Yet while developers are the primary creators that make software work, a secure SDLC process requires involvement from many other stakeholders, including analysts, architects, testers, auditors, and management.
With full participation of multiple stakeholders in a secure SDLC process, potential flaws can be identified both before deployment and during implementation, reducing the attack surface and strengthening defense-in-depth strategies. A team approach to secure software development will improve the software release, change, and configuration management processes, improving software deployment standards.
Myth #3: No Problem, The Code Was Scanned
Programmatic source code scanners provide a reasonable level of assurance that software was created without structural issues, but this is only one side of the coin. Humans are prone to error; there is no way of mitigating this. There will always be logical source code errors -- such as data validation or race-conditions -- that programmatic scanners may not detect.
Even if scanners could pick up logical source code errors, we still rely on humans to update new vectors as the threat landscape evolves. Again, having extra sets of eyes reviewing source code -- including analysts, testers, and auditors -- can help reduce the attack surface for each new application.
Myth #4: Security Is Software-Centric
The software development, deployment, and usage chain is only as strong as its weakest link. Developing and implementing secure software means taking a holistic view of how software will be implemented, including business use, architectural considerations, and logical access controls.
A commonly overlooked aspect of security -- and this is not software-specific -- is the relationship between physical and logical security. No matter how much effort is placed on implementing a repeatable secure SDLC process, a physical security failure can spell disaster. Encryption is the best possible solution to physical vulnerabilities.
Myth #5: Educate Once, Implement Many
All of the stakeholders involved in the secure SDLC process hold some degree of experience, but they may not all have the training they need to spot potential security problems in a developing applications. Even if those stakeholders are not IT security professionals, education and training in the field of software security are essential to the secure SDLC process.
A good approach to achieving current and relevant knowledge of the secure SDLC process is to explore industry-recognized professional certification programs. Through certifications, stakeholders are required to complete a minimal level of recognized training and education that helps ensure they are current on key aspects of secure software development.
Its important to remember that a secure SDLC process does not guarantee that software will be implemented free from vulnerabilities; all software is susceptible to attack in todays rapidly evolving threat landscape. The secure SDLC process is a holistic methodology that emphasizes security by design; in other words, its not about developing perfect software, but about controlling the risks associated with software.
Software security -- and the secure SDLC process -- is essential to business. But its important to remember that it is a process and requires a team effort. If all of the stakeholders participate, theres a much better chance of avoiding vulnerabilities -- and subsequent breaches.
Have a comment on this story? Please click Add a Comment below. If youd like to contact
Dark Readings
editors directly,
send us a message
.

Last News
▸ ArcSight prepares for future at user conference post HP acquisition. ◂ Discovered: 07/01/2025 Category: security	▸ Samsung Epic 4G: First To Use Media Hub ◂ Discovered: 07/01/2025 Category: security	▸ Many third-party software fails security tests ◂ Discovered: 07/01/2025 Category: security

**Cyber Security Categories**
Google Dorks Database	Exploits Vulnerability	Exploit Shellcodes

CVE List

Tools/Apps

News/Aarticles

Phishing Database

Deepfake Detection

Trends/Statistics & Live Infos

Tags:
Tech Insight: 5 Myths Of Software Security