The Five Parts of Third-Party Application Security

Third-party application security assurance is an essential part of a mature IT security program. While it’s true that every company today is a software company, the majority of applications within an enterprise’s application portfolio will be developed by third parties – often as off-the-shelf products. 

A study by Quocirca found that the average enterprise has roughly 600 mission-critical applications. Of those applications, 28 percent are developed by a third party, 34 percent are sourced from a commercial software vendor, and 38 percent are developed internally by the enterprise (Source: IDG Study, “Majority of Internally Developed Apps not Assessed for Critical Security Vulnerabilities” June 2014).

Collectively, 62 percent of an enterprise’s apps are sourced from external developers. This means that the average enterprise has more than 370 applications that are not covered by an internal software development lifecycle.   

This figure highlights the necessity of securing the software supply chain. However the execution of a third-party application security program is typically difficult – often failing before getting off the ground. It is often perceived as simply too difficult to produce a good return on investment. However, based on our experience with vendor application security testing, we have identified five key areas to focus on in order to effectively secure this critical part of your application landscape.

No. 1: Application Inventory

What products are in your enterprise portfolio, what version are you using, which supplier makes them, and who do you talk to about them? Without these data points, any attempt to secure third-party applications will fall flat. Gathering this information is vital, and best practice is to integrate the data collection with early communication so the data gathered can be put to use immediately.

No. 2: Internal Mandate

There is little value in communicating security requirements to vendors if the internal community is not aligned. Veracode has seen instances where IT security teams have mandated programs, only for procurement teams to tell suppliers that they can ignore the program! Third-party application security is a multidisciplinary field, part of why it is so difficult to implement effective programs. Ultimately, procurement and IT security functions must work hand-in-hand to present a united front to third parties.

No. 3: External Mandate

The third area of focus is the requirement to present the security requirements as an external mandate. In essence, why a vendor is being asked to comply with an enterprise’s security policy and the ramifications if it does not. Here, it is evident why the internal mandate is a pre-requisite, as procurement will generally have the working relationships with software suppliers. In many instances, a hard mandate may be unfeasible. In these cases, consider providing funding for the security testing for vendors that agree to participate in the program as a form of soft mandate – the carrot instead of the stick.

No. 4: Software Suppliers’ Participation

The penultimate requirement is the one least in control of the enterprise as the buyer of software. The software suppliers must ultimately agree to participate in a security program. It is perhaps too obvious a point to belabor; however, it deserves recognition. Even with a fully mandated, fully funded enterprise security program, a third party must still make an independent and voluntary effort to participate. It will cost time out of the development cycle to comply with an enterprise’s requirements. 

It is here that three prior elements come together:

1. Application Inventory – Are you talking to the vendor about the right product? Consider if it makes sense to conduct security testing against that specific application. 
2. Internal Mandate – Will procurement support the security requirements set by IT? Consider if it makes business sense to approach the vendor at this time.
3. External Mandate – Why should the third party agree? Consider providing positive incentives, such as funding for scanning and remediation. Also consider adding contractual clauses that vendors must provide evidence of secure code development.

With these three elements properly aligned, the majority of vendors will agree to participate in third-party security programs.

No. 5: Governance

Finally, it is important to wrap the program in a governance layer. This will protect the enterprise’s investment as well as provide a forum to resolve escalations involving both internal and external parties.

Collectively, these five points create a model to understand the definition and execution of third-party application security programs.

Intelligent application of these principles will facilitate a successful third-party security program. 

Need help getting started?Veracode has the expertise to help you implement the five parts of third-party application security. With our combination of people, process and technology, we will work with you to effectively execute against this vital aspect of IT security.