In our introduction to this series, we talked about how securing the software supply chain is like other supply chain transformation initiatives and our intention to learn from initiatives like “green” supply chain and RFID rollouts. This post highlights the last of Seven Habits of Highly Successful Supply Chain Transformations, drawing analogies and translating into application security.
We’ve talked about a wide variety of issues related to a secure supply chain makeover in this series: Industry standards for defining appsec compliance. Segmenting the supply chain for best results. Collaboration for creative solutions. Cascading secure software compliance programs. Enforcing compliance programs. Showing what’s in it for the supplier. Now we come to the hardest question of all: who pays for the cost of the compliance program?
On the face of it, it seems a straightforward proposition: the enterprise is calling the shots, so they pay for the scans. But the concern of many enterprises is whether such an expenditure scales over the long term, across what may be hundreds or thousands of suppliers, never mind applications that are revised several (or, in the case of mobile applications, dozens) of times a year.
There’s also a subtler concern about whether paying for one time assessments actually drives the right behavior. Does a single point in time measurement make a software product more secure? The issues identified in that assessment might get fixed, but the underlying process and product deficiencies that caused the security problems might go unresolved.
Addressing these concerns was why Veracode created the VAST model in the first place, in which an enterprise paid only for the setup of a security program and vendors paid for their own assessments. The model helps enterprises scale to a larger supply chain, and vendors gain the benefit of ongoing access to the Veracode service to bake security into their processes. (The recent webinar “Atlas Ventures Explains Why You Need to Be a Secure Supplier,” with Chris Lynch of Atlas and Chris Wysopal and Bob Brennan of Veracode, explores the benefits to the vendor more fully.)
But… what if the vendor doesn’t see it that way? The vendor who has a single customer requesting a security scan—maybe a customer with whom they only do a small amount of business—may not view the cost of ongoing access to security testing as a justifiable expense. Should the enterprise excuse that vendor from participation in the program, or is there another choice?
Here, economics research on the mechanics of other supply chain transformation efforts suggests the right solution. In Gaukler and Seifert’s paper “Applications of RFID in Supply Chains,” the authors describe an analogous situation to the appsec problem, in which the optimum investment in the technology (RFID tags) for the retailer is not the same as the optimum investment for the manufacturer. Manufacturers wanted to tag at the level of a pallet of goods, which provided the most benefit to them, whereas retailers gained most if each item was tagged. Gaukler cites a paper showing that, in the absence of a mandating entity (government procurement mandate, retailer with enormous market power), that the optimal path is to share the cost of the technology between the manufacturer and the retailer.
The application to the software supply chain problem is similar. If the value and expenditures are not aligned, then the enterprise should expect to bear at least a share of the cost of the scan, or provide some other way to shift the burden from the software vendor such as paying to achieve a discounted rate for their suppliers. However, when the benefit to the vendor is clearer, the vendor should bear the cost of software testing, yielding a more optimal outcome for everyone.