Power to the People and the Coming AppSec Revolution

Thursday, January 24, 2013

Fergal Glynn

68b48711426f3b082ab24e5746a66b36

Article by Wendy Nather

This article is a guest post by Wendy Nather, Research Director of the Enterprise Security Practice, 451 Research. Veracode is a client of 451 Research.

When the revolution comes, the first up against the firewall will be your business partners – along with every other third-party that provides you with software.

It used to be that you could call for more secure software from individual vendors – and Microsoft heeded that call, for example with its push for trustworthy computing, starting in 2002 – but today we’re more dependent on software than ever, and more interconnected than ever; we rise and fall by the security of our associates. The sheer number and variety of third-party applications have exploded: with on-premise software, mobile devices, and cloud-based services, a large organization can have tens of thousands of applications in use.

So organizations can’t focus on one or two providers, or address software security only within their own development efforts; they need to do it across the board. Initiatives such as Build Security In are taking acquisition into account, and supply chain security is being discussed at all levels in both the public and private sectors.

Now, it’s not too practical to take some commercial software off the shelf at Best Buy and tell the cashier that you’re not going to buy it unless it’s secure. But you can certainly start fomenting revolution by including security requirements in every RFP, statement of work and other contracts that you sign with third parties. This means that you need to start out by deciding how secure you want your software to be, and how you’ll measure that security. Here are some things you’ll want to include in the contract language:

  • How you will measure the level of security you expect from the software you receive
  • Who will provide those measurements – in other words, who will do the testing, and how often
  • Who is responsible for fixing anything that doesn’t measure up to your requirements
  • Who will bear the cost of those fixes, and how quickly they’ll be done
  • What will happen if something isn’t fixed – whether you can reject a deliverable, terminate the contract, or choose to sign off on the risk

I am not a lawyer, so I’m not about to give you legal language to use. But I can tell you that organizations have successfully included these issues in contracts – and as noted in Veracode’s latest State of Software Security Report, those that had a formal process for requiring software testing across the board had nearly ten times the participation from their vendors than in organizations that just requested it piecemeal.

Cross-posted from Veracode

Possibly Related Articles:
7658
Webappsec->General
Software
Application Security Secure Coding Software Security Assurance
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.