I’m sure we want a bug fixed as soon as possible but there are many reasons why this just isn’t possible, right this minute. It all begins with the developers. To fix a bug, the average time taken varies depends on where it began. In other words, the platform the bug was found in. So, let’s see perhaps one group could learn from another group of developers. Or do we need to just accept that some bugs can’t be fixed right this minute?
The time taken to fix a known bug is called “bug fixing time”, it’s the time between being made aware of an existing bug – to issuing a fix for the bug. So why is it important to better understand and know the time it takes to bug-fix?
Because it helps the
- project team better estimate software maintenance efforts
- and better manage software projects.
Reasons to fix ASAP
We want to push and install bug fixes as soon as possible for some obvious reasons:
- Improved security by fixing the vulnerability.
- If a vulnerability is found by a researcher and then disclosure, there is a good chance others will be able to duplicate the researcher’s effort. This could result in a zero-day vulnerability.
- When you are working on a new version, a critical bug in the old version is holding you back if you don’t know how to fix it.
- If it’s taken awhile to bug-fix and the information is published, it will reflect badly on your company. As a result, customers could question whether you care about security.
Certainly, then you can say that bug-fixing time is an important factor for bug related analysis. For instance, if you want to measure the quality of your software and find its buggy, it won’t help you increase sales.
You will no doubt need to prioritize what needs to be fixed first.
Differences in platform
Recently, the team at Google – Project Zero looked at reported fixed bugs that were between January 2019 and December 2021.
Of which 376 issues were reported to vendors under their standard 90-day deadline, according to Project Zero.
Most importantly, note that the number of issues is too small and not chosen randomly enough to give the full picture when reading the data, but it gives you an idea at least.
On average almost all of the big vendors here are coming in under 90 days
Complaints from bug bounty hunters
Meanwhile bugs that are reported directly to vendors by Project Zero are taken very seriously by vendors.
However, bugs reported by individual bounty hunters have had issues with their bugs being accepted. So, there has been come complaints. For instance, a vulnerability in Apple’s IOMobileFrameBuffer, where a malicious app could execute random code with kernel privileges, back in January CVE-2022-22587.
Individual bounty hunters, however, have been complaining about getting their bugs accepted. For example, a vulnerability in Apple’s IOMobileFrameBuffer, where a malicious app could execute random code with kernel privileges. After one of the bounty hunters posted a Proof-of-Concept (PoC), this vulnerability that was exploited in the wild back in January CVE-2022-22587, the vulnerability ended up being a zero-day vulnerability.
As a result, many researchers decide to use the Zero-Day-Initiative (ZDI) rather than reporting directly to vendors. And ZDI was initially created for the purpose of encouraging the reporting of zero-day vulnerabilities privately. Researchers are rewarded financially for their discovery. However there have been complaints by the researchers that here too, ZDI didn’t take the issue seriously.
The next step
Certainly, it is imperative that these vulnerabilities are fixed ASAP. But why is there such as time lapse before fixes happen and patches are installed?
Jess Dodson, said in a recent podcast that the problem of patching is a matter of mindset, as well as resources, time, staffing and funding. And that the refusal to patch almost brings a bizarre sense of pride for some organisations, Dodson said.
Meanwhile the CISA list also know as the Known Exploited Vulnerabilities Catalog can act as a good guideline, even if you are not a Federal Civilian Executive Branch (FCEB) agency that needs to follow the Binding Operation Directive 22-01.
That is to say that FCEB agencies use the catalog to see the
- list of vulnerabilities that are known to be exploited in the wild
- and gives the agencies a due date by when the vulnerability needs to be patched in their organization.
Let’s hope we all get better at squashing those pesty bugs in time.
