Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


10:25 AM
Connect Directly

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.]

Today's 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 isn't 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. Let's 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
It's 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 Guidemakes 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.

It's 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 today's rapidly evolving threat landscape. The secure SDLC process is a holistic methodology that emphasizes "security by design;" in other words, it's 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 it's important to remember that it is a process and requires a team effort. If all of the stakeholders participate, there's a much better chance of avoiding vulnerabilities -- and subsequent breaches.

Have a comment on this story? Please click "Add a Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.

Jason is an Information Security professional with over 10 years of experience. He is currently the Director of Security Forensics & Civil Investigations within the Scotiabank group. Throughout his career at Scotiabank, he has been responsible for digital investigations, ... View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
User Rank: Strategist
12/12/2012 | 3:56:11 AM
re: Tech Insight: 5 Myths Of Software Security
This is an interesting look at the whole scope of software development -- not just what the programmers do, but all of the stakeholders involved in software security.
--Tim Wilson, editor, Dark Reading
User Rank: Strategist
12/7/2012 | 9:09:56 PM
re: Tech Insight: 5 Myths Of Software Security
Are there any editors there?
COVID-19: Latest Security News & Commentary
Dark Reading Staff 7/9/2020
Russian Cyber Gang 'Cosmic Lynx' Focuses on Email Fraud
Kelly Sheridan, Staff Editor, Dark Reading,  7/7/2020
Why Cybersecurity's Silence Matters to Black Lives
Tiffany Ricks, CEO, HacWare,  7/8/2020
Register for Dark Reading Newsletters
White Papers
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
The Threat from the Internetand What Your Organization Can Do About It
The Threat from the Internetand What Your Organization Can Do About It
This report describes some of the latest attacks and threats emanating from the Internet, as well as advice and tips on how your organization can mitigate those threats before they affect your business. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-07-10
osquery before version 4.4.0 enables a priviledge escalation vulnerability. If a Window system is configured with a PATH that contains a user-writable directory then a local user may write a zlib1.dll DLL, which osquery will attempt to load. Since osquery runs with elevated privileges this enables l...
PUBLISHED: 2020-07-10
An exploitable SQL injection vulnerability exists in the Admin Reports functionality of Glacies IceHRM v26.6.0.OS (Commit bb274de1751ffb9d09482fd2538f9950a94c510a) . A specially crafted HTTP request can cause SQL injection. An attacker can make an authenticated HTTP request to trigger this vulnerabi...
PUBLISHED: 2020-07-10
A SQL injection vulnerability in the user and admin web interfaces of Sophos XG Firewall v18.0 MR1 and older potentially allows an attacker to run arbitrary code remotely. The fix is built into the re-release of XG Firewall v18 MR-1 (named MR-1-Build396) and the v17.5 MR13 release. All other version...
PUBLISHED: 2020-07-10
Incorrect file permissions in Citrix ADC and Citrix Gateway before versions 13.0-58.30, 12.1-57.18, 12.0-63.21, 11.1-64.14 and 10.5-70.18 allows privilege escalation.
PUBLISHED: 2020-07-10
Improper input validation in Citrix ADC and Citrix Gateway versions before 13.0-58.30, 12.1-57.18, 12.0-63.21, 11.1-64.14 and 10.5-70.18 and Citrix SDWAN WAN-OP versions before 11.1.1a, 11.0.3d and 10.2.7 allows reflected Cross Site Scripting (XSS).