Software Quality Insights

Apr 17 2009   6:36PM GMT

Software security threats: Changing QA a must

Jan Stafford Jan Stafford Profile: Jan Stafford

Software quality assurance (QA) and software security teams have long been separate islands within development organizations. That division is giving data pirates carte blanche to compromise software, cyber-security industry veteran Barmak Meftah told me recently.

“Today, we are witnessing the greatest increase in cybercrime,” said Meftah, Fortify Software’s technology senior vice president. “Yet most organizations continue to bolt security on after the fact. Organizations need to build in security first, not layer it on later.”

Hackers have always exploited security vulnerabilities missed during development, but security experts worry the scope of attacks will increase. For instance, they think hackers will increase SQL injection attacks on Flash, JavaScript errors. Another unchecked threat is cross-site scripting, which is still rampant in the Web 2.0 world. “It’s literally on every site I view,” Web security consultant Kevin Beaver told me in another conversation.

Mehta and I talked about how this code-red software environment has pushed software security assurance to the forefront in 2009. He listed these reasons:

  • Heightened executive pressure for software security: As
    software’s critical role in running business operations becomes apparent, non-technical executives have become increasingly interested in understanding broader approaches that manage risk, not technology.
  • The need for a holistic platform for software security: Traditionally, companies have only been able to buy point products to secure applications during development, QA or in production. That doesn’t work now that data predators, who are continually becoming more sophisticated, use multiple methods to leverage software vulnerabilities to attack organizations. Reacting to this pressure, companies have been forced to adopt multi-prong approaches that include pen testing, static analysis, web application firewalls and so on.
  • A business-driven focus on more security from development to production: Eliminating risk leads to preventative, not reactive, security testing. There’s a move from SDLC only to security teams are attempting to bring about significant cultural and process changes to elevate security awareness and governance across an organization.

Today, Mehta said, QA teams must pick up responsibility for security and work with development to make fixes. This is a marked change from the recent past, when QA and security managers have rarely crossed paths. “They have been different organizations with different objectives,” Meftah said. QA has focused on common use cases to uncover problems that typical users may encounter. Security has focused on abuse cases, hoping to uncover a corner case that could allow an adversary to penetrate and exploit a system.

Now, Mehta told me, QA and security teams have to cross the chasm to work on these issues and more together. QA involvement is key way to shift from a reactive security approach — such as patching and firewalls — towards a preventative approach that builds security in from the beginning.
This conversation left me wondering how many companies are pairing or have paired their QA and security teams and to what extent. Or, perhaps some QA and security managers believe they should continue as separate entities. I’d like to hear from you on this subject, either in comments below, or via email at editor@searchsoftwarequality.com.

 Comment on this Post

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: