I recently came across an interesting blog post
by a team member at Acunetix that addressed a challenge many enterprises are facing when it comes to securing third-party components. This is a pretty hot topic in certain circles these days, and understandably so - studies have suggested that as many as 65% of an enterprise’s mission critical applications are developed externally
. Additionally, Veracode research shows that a typical internally developed applications contains somewhere between 30% and 70% of externally developed code, indicating that even internally developed apps are utilizing code originating outside of their own walls.
Given these statistics, Mr. Beaver provides some great advice - involve team members truly at risk to make the risk vs. reward decision rather than leave the decision solely up to IT. However, the challenge of vendor risk management is growth significantly. In the past we’ve seen pre and post procurement assessments covering a variety of topics including the financial security of software vendors, background checks of employees, physical checks of vendor environments and scanning of perimeter components such as firewalls. Surprisingly, it is only in the last several years that we are seeing a rise in the number of enterprises making scanning of third-party software a part of the procurement process. At Veracode this effort is clear as we’re on pace to analyze, educate and help improve the security posture of software at over 1,000 vendors in 2013.
As application security scanning of third-party applications becomes a standard part of the procurement process, we will see the focus move towards the root cause of issues, indentifying code level flaws in applications and driving vendors to fix those. In fact, we currently share our best practices and lessons learned
with the community to help improve their vendor relationships and simplify the scanning process.
While our main focus is on helping large enterprises drive security improvements in their vendor community, we understand that a comprehensive Vendor Application Security Testing
(VAST) may not work for all vendors or those organizations that don’t already embrace the application security best practices in the supply chain.
For those teams looking to begin a vendor risk management program, I recommend the following:
- Clarify the Goal – A simple “Scan and we’ll tell you what to fix” request can be frustrating for vendors who don’t have a clear goal. Define a policy (such as removal of all flaws in the OWASP Top 10), testing techniques (dynamic, static, manual pen testing, etc) and reasonable timelines (think in terms of months, not days) in which vendors should fix their flaws.
- Understand Market Immaturity, But Drive Maturation – Some of the more mature software vendors have very impressive AppSec practices including developer education, static analysis integrated into the SDLC, routine dynamic and penetration testing and a variety of other activities and are typically very cooperative in fulfilling security requests. While these vendors are great to work with, they’re not the norm. Don’t punish those vendors who have not committed to building security in, but make it clear that they will be expected to do so in the very near future or face potential impacts on your business relationship.
- Disparate Responses are OK (for now) – It’s often the case that security is an afterthought for vendors – they’re typically worried more about the next release, new features and keeping the lights on than providing a secure product. The goal of vendor activities should be twofold:
- Gather information your organization needs to make better informed decisions.
- Drive better practices for vendors going forward.
- Tip: Providing vendors with options to do an initial questionnaire like the vBSIMM will get your team short term self-attested answers and drive them to adopting better long term practices. Being realistic but prescriptive in your requests will help not only get initial responses but also drive longer term adoption of best standard practices.
- Work With Your Peers – Vendors are typically selling to dozens, if not hundreds, of customers. If they have to fulfill a separate security requirement for each of those they’ll quickly become frustrated. Most industries have groups that are beginning to focus on AppSec best practices in terms of vendors (such as FS-ISAC in the financial services community). Investigate these groups and begin discussing how you can work together to drive standard goals for vendors.
- Involve Procurement – Nearly every vendor deliverable must go through a procurement process that includes a variety of requirements. Work with this team to include AppSec requirements in the RFP process and include contract language that requires participation in security analysis and remediation. We make our recommend language available for free at: http://www.veracode.com/services/build-security-criteria-into-contracts.html
Securing third-party applications is becoming an increasingly popular topic in the security community. Regardless of the type of solution, enterprises are realizing they don’t control or have any idea what the security posture is for many of the products they use to run their businesses. It could take several years to drive improved awareness and adoption of secure development practices across the broader vendor community, but if businesses begin by following the above recommendations, they are taking a huge first step in making sure the applications they use aren’t putting their business at risk.