DISQUS

dre · 2 years ago

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

Richard Johnson · 2 years ago

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 · 2 years ago

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 · 2 years ago

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 · 2 years ago

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 · 2 years ago

What about asking about their development practices?

Thomas Ptacek · 2 years ago

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 · 2 years ago

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

Adam · 2 years ago

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.