Security Boat Anchors: 3rd Party Products/Libraries

Dave G. | June 11th, 2007 | Filed Under: Industry Punditry

Problem Statement

One of the more interesting problems product companies face is the embedding of 3rd party applications and libraries. Apart from all of the normal support challenges, API changes and the like, you are tied to another vendor’s security posture. This includes:

  1. How they respond to security vulnerabilities. If they sit on vulnerability reports, those are latent vulnerabilities in your product. I do not envy the vendor who tries to explain to customers why they are vulnerable. Even if it isn’t your code, it is your responsibility.

  2. Patching release cycles. When your popular database program releases a patch that fixes 5 critical remote code execution on Monday, how do you vet out the patches and get them out to your customers? How fast can you reasonably move? Take a look at how this impacted Mac OS X with the recent Samba vulnerability.

The second issue is really challenging for vendors, as they don’t even have an early warning system in many situations. They find out at the same time everyone else does.

What Do You Do

  1. Vendor. Perform your vendor selection for your third party components carefully. Ask them what their policies are on vulnerability disclosure. When interacting with commercial developers try and get early access to security updates so you can start your internal testing processes. For open source, you should always be tracking the projects you are leveraging.

  2. Enterprise. Identify what third party components (and their version numbers) exist inside of the applications you purchase. This will let you track which libraries and open source/third party projects that are actively deployed in your enterprise. That should let you apply pressure on vendors when you find that your database is 9 months behind on critical security patches.

What other advice do our readers have for this problem?

9 Comments so far

  • dre

    June 11th, 2007 5:05 pm

    secure software contract annexes backed by open industry certifications/review (owasp, mitre, wasc, sans-ssi, et al)

  • Richard Johnson

    June 11th, 2007 7:40 pm

    As a customer of vendors who embed 3rd party products and libraries, we’re leaning towards requiring security patches for the 3rd party components be applied and an updated version of the package available to us within a short, reasonable interval. Eventually, a vendor’s failure to provide such an assurance will be enough to kill their proposal.

  • Sheran

    June 12th, 2007 1:49 am

    Here in the Middle East, I’ve seen vendors of certain Applications running really old versions of 3rd party software which are riddled with vulnerabilities. I get called in to conduct an application security assessment and I usually include these findings in addition to the application audit itself.

    The problem I see is when the customer has already selected the product and deployed it without proper guidance in the beginning. Richard makes a valid point that if it is a contractual obligation, then you’re covered to a certain extent, but how do you solve it after it has been put into place?

    One of my customers has been waiting for a fix to a 3rd party product for over 6 months. In my case, it has taken countless extra days (at no cost) for me to sit with the vendor and try to explain why these patches need to be applied only to receive the response that the patches will break the functionality of the application. When I ask for technical proof of this or a demo in a staging environment, I never receive it. At this point, I offer the customer an addendum to my contract which lets me act on behalf of the customer to work out the problem technically with the vendor. In most cases, the customer will not want to spend the additional amount, will concede and take on the responsibility as an “acceptable risk”. These are banks. I don’t think people take security seriously here.

  • ivan

    June 12th, 2007 2:19 am

    ahah good luck! now, seriously, what about all those that have embedded 3rd party libraries and don’t disclose it (and some may not even _know_ they do). some plausible examples: zlib, libpng, xerces, openssl (or portions of it), multiple audio/video codecs, etc. Some of them may have been “namespace-cosmetized” and statically linked into the product just to get it out the door in time several release cycles (years) ago and now nobody even knows the code is there…implausible you say?

  • Rhys Kidd

    June 12th, 2007 8:38 am

    If you as a developer find a need to plug in one of a shortlist of open source projects to complete a task, consider that the larger and more responsive the project’s community the:

    A. More likely code audits will be done, and present vulns fixed.
    B. The quicker any bugs from step A will be patched.
    C. The more noise will be made about any vulns found in step A, so the more likely you will hear about them.

  • Adam

    June 13th, 2007 12:15 pm

    What about asking about their development practices?

  • Thomas Ptacek

    June 13th, 2007 3:35 pm

    Adam: what’s a short questionairre a security-savvy front-line developer could use to quiz a third-party partner, and reasonably expect to get a meaningful response on?

  • dre

    June 13th, 2007 6:12 pm

    I came across this when looking for something else:
    http://www.cigital.com/labs/reliability/certification.php

  • Adam

    June 14th, 2007 12:31 am

    Tom:

    We could start with a single question:

    “Do you mandate any sort of security activity as part of your product development lifecycle?”

    There’s a follow-on, which is “please explain.”

    Since 90% of the vendors don’t make it to the follow-on (yet), considerations of comparisons between explanations are secondary. But I’m happy to go there at length.

    • Leave a reply