From BruCON 2015
Revision as of 21:13, 9 September 2014 by Znb (talk | contribs) (Created page with "The penetration test finds a bug in the code that was coded four months ago and could have been prevented a year ago during requirements gathering. The vendor says they will f...")

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

The penetration test finds a bug in the code that was coded four months ago and could have been prevented a year ago during requirements gathering. The vendor says they will fix it shortly after the software launches—if a change order is issued and they’re paid for their work. Many organisations find themselves paying for insecure software, paying for a security test, then paying the vendor to fix the software. It’s not just inefficient, it puts the enterprise and its customers at risk. An organisation’s procurement department, when supplied with the right assistance from security and legal teams, can be a very effective ally in this process. Are you a security person frustrated at vulnerabilities being fixed after they go live because they were caught so late? Are you a developer frustrated at the quality of software provided by a partner? This case study describes how one of the largest online retailers in the UK brought security, legal, and procurement into the same room and established security requirements that become part of the contract with vendors and service providers. When the security team discover issues in the software, procurement can use contractual obligations to require vendors to fix broken software. The result is software that is substantially more secure at the beginning, and a lot more visibility into the partner’s software development lifecycle. We provide a three-step action plan and a framework for engaging legal and procurement in this process.