Updating vulnerable dependencies is possible (best practices badge project & omniauth)


David A. Wheeler
 

FYI:

Here's another story showing it's possible to plan for & rapidly handle vulnerable dependencies,
as outlined in "Concise Guide for Developing More Secure Software".

--- David A. Wheeler


==========================

The Best Practices badge application is a web application that
depends on 193 other libraries, not including system applications & libraries.
We received on automated report that a particular component
(omniauth) had vulnerability CVE-2020-36599, which scores as "critical"
under CVSS (9.8/10). So we got moving.

We received an automated notification on Aug 31 16:18:16 2022 -0400.
We updated, ran our automated test suite, pushed to staging, and then
pushed to production in less than 4 hours: ~ Aug 31 19:59:00 2022 -0400.

I'm sure that many things can be improved, and different projects have different circumstances.
But a lot of organizations think about security updates in terms of "a year or so", which is
just another way of saying that attackers own them. Defenders need to try to update
*faster* than the attackers' attacks.

Since we *know* vulnerabilities will be found,
it's important to be prepared by using package managers, monitoring
for vulnerabilities, having an automated test suite (to verify that the update works), and
make it easy for users to update. Note that ALL these points are part of the
"Concise Guide for Developing More Secure Software".

Yes, I'm preaching to the choir here. But here's a simple example you can sing elsewhere :-).


Brian Behlendorf
 

Thanks! I think about this each day as I run "software updater" on my Ubuntu box. :)

Brian

On 8/31/22 17:14, David A. Wheeler wrote:
FYI:

Here's another story showing it's possible to plan for & rapidly handle vulnerable dependencies,
as outlined in "Concise Guide for Developing More Secure Software".

--- David A. Wheeler


==========================

The Best Practices badge application is a web application that
depends on 193 other libraries, not including system applications & libraries.
We received on automated report that a particular component
(omniauth) had vulnerability CVE-2020-36599, which scores as "critical"
under CVSS (9.8/10). So we got moving.

We received an automated notification on Aug 31 16:18:16 2022 -0400.
We updated, ran our automated test suite, pushed to staging, and then
pushed to production in less than 4 hours: ~ Aug 31 19:59:00 2022 -0400.

I'm sure that many things can be improved, and different projects have different circumstances.
But a lot of organizations think about security updates in terms of "a year or so", which is
just another way of saying that attackers own them. Defenders need to try to update
*faster* than the attackers' attacks.

Since we *know* vulnerabilities will be found,
it's important to be prepared by using package managers, monitoring
for vulnerabilities, having an automated test suite (to verify that the update works), and
make it easy for users to update. Note that ALL these points are part of the
"Concise Guide for Developing More Secure Software".

Yes, I'm preaching to the choir here. But here's a simple example you can sing elsewhere :-).




--
Brian Behlendorf
General Manager, Open Source Security Foundation
bbehlendorf@...
Twitter: @brianbehlendorf