Vendors are Fixing Security Flaws Faster

Google’s Project Zero is reporting that software vendors are patching their code faster.

tl;dr

  • In 2021, vendors took an average of 52 days to fix security vulnerabilities reported from Project Zero. This is a significant acceleration from an average of about 80 days 3 years ago.
  • In addition to the average now being well below the 90-day deadline, we have also seen a dropoff in vendors missing the deadline (or the additional 14-day grace period). In 2021, only one bug exceeded its fix deadline, though 14% of bugs required the grace period.
  • Differences in the amount of time it takes a vendor/product to ship a fix to users reflects their product design, development practices, update cadence, and general processes towards security reports. We hope that this comparison can showcase best practices, and encourage vendors to experiment with new policies.
  • This data aggregation and analysis is relatively new for Project Zero, but we hope to do it more in the future. We encourage all vendors to consider publishing aggregate data on their time-to-fix and time-to-patch for externally reported vulnerabilities, as well as more data sharing and transparency in general.

Tags: , , ,

Posted on February 16, 2022 at 7:00 AM • 14 Comments

Comments

Ted • February 16, 2022 9:58 AM

It’s fun to see progress in cybersecurity practices. I hope these kind of metrics encourage companies to continue to streamline and communicate.

That feels like a data set that could mature into an industry-wide report.

It’s interesting that Apple, Microsoft, and Google made up the top three vendors for number of bugs disclosed – with Linux coming in fourth. I wonder how Google Project Zero comes across these bugs. Good updates.

JonKnowsNothing • February 16, 2022 11:20 AM

@ Ted

re: It’s fun to see progress…

It’s actually appalling. So many serious errors introduced, never fixed, laying open for exploit and then a “big pat on the head” for fixing a few programs that should never have been released.

If it were any other product, these would be recalled as a Hazardous Product and for Failed Safety Protections.

Instead they are left to continue to poison the entire internet environment.

Consider:

We know that many “stacks” are broken.

Stacks are used in many products and as such the products are also broken. The number of broken products is large. The number of “recalled or updated” products is small.

One company gets a “pat on the head” for fixing just one of their broken stacks. They do not do and are not required to ensure that 100% of their fixes are deployed to fix all stacks that carry the failed component.

It’s like have a car manufacturer with a serious brake system failure in the master cylinder claim they “fixed” the leaking gasket in the brake master cylinder but only Small-N cars did the fix. Leaving Large-N cars on the road with broken master cylinder and leaking gaskets waiting for a hard brake to fail.

Not fun at all.

Ted • February 16, 2022 12:48 PM

@JohnKnowsNothing

The last 3 years, Linux improved their average bug fix time from 32 to 22 to 15 days. I think that’s great.

I don’t know how companies are responding to EO 14028 on Cybersecurity (May 2021), but I would hope that improvements are expected.

I think cars are regulated differently than software, but you’re right to see how important software security can be.

lurker • February 16, 2022 1:59 PM

@Ted “I think cars are regulated differently than software…”

Why? Lobby dollars going to different places? Because you can see a broken car part and fix it with a wrench, but not software? Relative death rates from software vs car failure?

Ted • February 16, 2022 2:59 PM

@lurker

Yep, if I had to guess it would be that motor vehicles have higher rates of physical injury and death, and therefore more regulations at this point. I’m glad people have lobbied for regulations here – for all of us.

JonKnowsNothing • February 16, 2022 5:11 PM

@ Ted, @lurker, @All

re:
@T: “I think cars are regulated differently than software…”

@L: Relative death rates from software vs car failure?

Cars are regulated differently than over the counter software, but not military or specialized software (1)

In the USA, every aspect of a car from bolts to screws to arm rests to head rests is tracked and monitored.

That’s how they know when Tesla makes a slip.

It’s also how they know about the tires on the car. Every aspect of the manufacturing of tires from the ingredients, batches, pressings and construction is tracked, logged, traced and monitored.

A fair while ago there was a problem when some larger SUVs did a “roll over”. Many people not wearing seat belts were killed on ejection but those that were wearing them had the roof crush inwards causing death and horrific injuries. (2)

Every aspect of those incidents were reviewed and detailed. From the manufacturing of the tires, raw materials thru distribution, to the tire design and air inflation values along with other aspects of the roll over events.

You can see the tracking information on the sidewall of the tires. All those numbers and indicators are track and trace numbers, along with the inflation range of the tire.

Which points to Lurker’s comment:

Modern cars have huge amounts of software. Many of the critical systems rely on software and hardware components.

One aspect of these highly automated vehicles is the Fault Tolerance allowed in the software.

  • Will killing 100 people be acceptable?
  • Will crashes for 10,000 vehicles be acceptable

For shoddy software designs, these are not enough faults allowed.

If you are the one being harmed or driving a vehicle that harms another person that is under automated computer assisted AI/ML software, 1 maybe too many.

The financial cost of the SUV Rollover Tire Blowout

It is estimated that these tire failures and rollovers cost Bridgestone/Firestone $1.67 billion and Ford Motor Company $530 million. Bridgestone’s market price dropped by 50% and the resulting restructuring cost Bridgestone $2 billion. In 2001, Ford recorded a loss of $5.5 billion.

100+ killed, 800+ injured.

===

1) A bad example of specialized faulty government software is the Fujitsu UK Post Office Accounting system that gave false accounting which was used to convict and charge thousands of Post Officer Sub-Station owner-contractors with fraud. Many were imprisoned and forced to repay thousands of UK pounds for funds that were never missing. The fallout is still going because the UK Government doubled down on the convictions. (afaik) No one from the government and no Fujitsu persons have yet been charged with crimes or perjury.

2) Search Terms

  • Firestone and Ford tire controversy
  • Tire code
  • Uniform Tire Quality Grading (UTQG)
  • National Highway Traffic Safety Administration
  • United States Department of Transportation (DOT)
  • All tires manufactured for sale in the United States since March 31, 1979 are federally mandated to have the UTQG ratings on their sidewall as part of the DOT approval process.

Andrew • February 17, 2022 9:02 AM

I assume the “time to patch” is the time for a vendor to produce a fix for their code once notified of it, and not the time it takes for that code to be released? We have a strict release schedule, so fixes get into every open branch possible. This adds on average 2-4 weeks to actually get code to customers (but it takes weeks to months for customers to get it installed). We don’t just “push new firmware out” over the network, releasing code for our products is a big deal.

JonKnowsNothing • February 17, 2022 9:30 PM

@Ted

No…

Topics on security have a lot to do with “perception” in this case that cars are somehow different or lesser vetted than software.

Except cars are much better vetted than software (1) and recalls happen where the vendor, dealer, manufacture MUST take back the vehicle and repair it. They can do this because, unbeknownst to you, there is a huge amount of data stored about every aspect of a car (USA).

I gave you an example of the details on lowly tires and how those tracked logs worked.

In the case of Tech Vendors and Manufactures they nearly never take back their faulty-shoddy goods and in the minimal cases they do, often the best you can get is a discount on repair or discount on “continued services”.

So having an “improvement” in software repair isn’t really much of an improvement as the implementation remains with the end user and by now we know there are a plethora of reasons why fixes are not going to be deployed – including the introduction of new exploits along with the fix. (2)

The new arg-Window$ will attempt to force users to Log-In to a M$ Account but not so much for repairs or security updates but to guarantee M$ gets their telemetry. It’s part of the Bundle-the-Fix with More-Bloat-Trackers methodology.

As to the improvement in software repair rates, that’s fine. The corporate 3 internal versions of bug tracker databases likely already had the bugs listed long ago. The Great Periodic Sweep and Database Truncation swept it all into the bit bucket. The fastest way to fix 10,000 bugs and make the delivery date.

W4M but Not4U

===

1) It should be well noted that NEW cars are MUCH LESS vetted than OLD cars due to the problems with software control systems.

2) A recent fix to a high security bug, introduced an new exploitable path, which was active with 24 hours of the original fix being published.

Grima Squeakersen • February 18, 2022 8:04 AM

That stat is nominally encouraging, but really is not terribly useful knowledge without information/metrics on the quality of the fixes. Any idiot can (and many frequently do) push out some patch that is alleged to repair a software flaw, only to have it fail to do so adequately, or worse, create issues that are worse than the original.

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.