Given the number of InfoSec incidents over the past few years, just about every enterprise that develops software has already put some kind of official security testing program in place. While this kind of application security assessment is a huge step forward, many programs have been built with the wrong priorities in mind. CISOs have to learn the misconceptions surrounding secure software development, then tailor their security testing programs based on the realities of their development environments.
Reviewing existing testing programs is the subject of a new webinar from Veracode, entitled "Reality Checking Your Security Testing Program." The webinar focuses on a number of misconceptions surrounding security testing and provides valuable insight into how CISOs and other IT executives can tailor their testing to ensure that software rolls into production as securely as possible and that it remains secure as the threat landscape changes. These misconceptions can be huge hurdles for enterprises to overcome, so CISOs should take the time to learn them in order to better understand the current conditions that their security testing programs are working under.
Misconception 1: QA Happens When Development Is Done
Too often, organizations confuse quality assurance (QA) with certification. They put testing rightly under the QA banner, but then only test the software after development is done with it — that's actually certification. And while certification is an integral part of the development process, it's usually too late at that point to make fundamental code changes to deal with security issues. Security testing has to be part of a continuous QA process, which includes testing throughout the development process and even self-testing by developers. QA security testing will also continue after the software goes into production, as even if the software itself isn't updated, the threat landscape can shift significantly.
Misconception 2: Third-Party Software Doesn't Need Rigorous Testing
Third-party code and libraries are now ways of life for many enterprises, especially given the recent interest and popularity of open-source software. The problem is that this code isn't usually put through the same security testing as the rest of the software, instead utilizing lower-level tests and vendor assessments to certify it. Even well-meaning organizations can overstate their abilities on assessments, resulting in third-party code that's full of vulnerabilities a simple scan won't catch. Third-party code has to go through just as rigorous a testing process as in-house code, and enterprises need to find a security solution that can ensure protection even in cases where the source code won't be available, such as a static binary scan.
Misconception 3: Developers Don't Care About Security
The consensus in the InfoSec world seems to be that software developers only see security as an obstacle to getting their code out on time, but in reality this just isn't true. The events over the past decade have led developers to care about security, but only up to a point. Developers also have to worry about scalability, adaptability, usability, deadlines and a host of other concerns. The goal of all CISOs should be to create a security testing program that takes the concerns of developers into account by including them in program creation. When people provide input into a process, they become more adaptable to the change that process brings. Developer input will also ensure the testing program fits in with the overall software development life cycle and doesn't put undue pressure on the development team.
These misconceptions are just three of the numerous examples covered in the webinar. The full webinar provides insight into how different projects have different security needs, how to make people more amenable to changes to the testing regimen and, most importantly, how testing needs to change with the advent of Agile methodology.
Agile, DevOps and other subparadigms such as Scrum are vastly different from more traditional waterfall development cycles and have unique testing needs. Even if a CISO makes testing a continuous process, failing to understand exactly how the organization utilizes Agile methodology can leave gaping holes in the overall life cycle where untested code can pass through into production with significant vulnerabilities.
Overall, the realities of a modern development environment mean that all CISOs have to take a look at their application security programs and ensure they do more than just pass a years-old compliance report. A true application security assessment will include considering all the variables that aren't obvious and then tailoring the program to ensure released software is as secure as possible. The "Reality Checking Your Security Testing Program" webinar is an excellent starting point for this assessment.
Photo Source: Flickr