Article by Nate Lord
This summer, Veracode Solutions Architect Chad Holmes presented a webinar on third party application analysis. The webinar recommended several best practices for enterprises, application vendors, and application analyzers to follow in the third party application analysis process. In this blog post we’ll highlight Chad’s best practices and the key takeaways from his presentation.
Chad’s best practices start with policy definition. It is important that organizations focus on their business and analysis goals when defining policies, as different business goals call for different types of analysis (static, dynamic, or manual). When selecting analysis methods, organizations need to be ready for the possible outcomes (pass/fail) of their analysis. Enterprises should also consider the impact on vendor relationships when writing policies.
In addition to their business goals, enterprises need to determine their analysis goals before requesting a scan. This requires setting a timeline for the analysis, outlining remediation expectations, and documenting the process for mitigation. Finally, the exception process needs to be defined so that actions are laid out in the event that a vendor declines a scan.
Chad’s next best practice for third party application analysis is maintaining strong business-to-business communication. Enterprises need to clearly communicate the reason for their request to the correct vendor stakeholder(s) to ensure that both parties understand the need for analysis. The best way to accomplish this at the start of the process is a three-way kickoff call between the enterprise, vendor, and third party.
The next best practice is vendor education and commitment. The suggested three-way kickoff call provides an excellent opportunity to address all questions or concerns regarding analysis methodologies, processes, expectations, or intellectual property protection. Any guidances developed in this call should be documented. The goal of the three-way kickoff call is verbal vendor commitment to the enterprise. From here the vendor and third party can begin conducting the analysis.
Communication and execution are crucial to successful third party analyses. A huge contributing factor for these best practices is project management. Project management activities such as status meetings, enterprise follow-ups, and open discussions will facilitate the analysis process. Additionally, the third party needs to enable the vendor throughout the process. Delivering timely responses and accurate results will help maintain a strong vendor/third party relationship.
Chad’s final best practice is results communication. The third party needs to deliver the appropriate results to both vendor and enterprise without risking the trust of either. Vendors need to be confident that their intellectual property will be protected in results and disclosure of the analysis. When delivering results, third parties should limit disclosure of details to the enterprise to demonstrate what flaws are significant without overwhelming the enterprise with reports of every single flaw. Vendors, however, should receive the full set of results. This provides the vendor with every possible resource they could need for remediation. It is up to the third party to provide the vendor with planned actions for remediation and mitigation/FP reasoning. Finally, third parties should set reasonable review timelines for vendors.
The webinar offers several key lessons focusing on vendors. The first is that vendors will have legitimate delays in the analysis process. These delays can be caused by legal reviews (assessment agreements can take up to a week), IP concerns that require investigation, or limited team availability. In addition to delaying for legitimate reasons, some vendors will try to strategically delay. Vendors that are not used to getting application security requests may do this as a means of trying to get out of the whole process. In many cases, vendors are able to delay because their contracts do not bind them to a timeline. Some vendors will even delay so that they can request an exception deal. Organizations that are privy to these tendencies can write stronger contracts and be prepared for working with vendors.
Chad also provides some important takeaways for the enterprise perspective. For starters, it is important to understand that enterprises are not fully empowered in the application analysis process. This is often due to appsec groups being understaffed or simply not vested in the process. Additionally, the analysis team should not be responsible for the entire analysis – enterprises need to be a part of the process. This includes making the initial request for a scan and staying involved in the analysis as needed.
View the full webinar here for Veracode Third Party data, case studies, and more.
Cross-posted from Veracode