Hacker News Reader

Comment by jamescun | Hacker News Reader

Why is silently patching considered a "no-no by the infosec community"?

If your product's automatic update functionality can reach most users within the responsible disclosure window, that sounds like a net positive? We still learn about the vulnerability but limits the potential fallout of the disclosure.

I'm very much in-favour of the private vulnerability research and responsible disclosure, but the "no silently patching vulnerabilities" sounds more like wanting to own the press to me than actually wanting to improve people's security.

View on HN

The general theory is that there's really no such thing as silently patching. Consider:

- Company silently patches issue. Patches have to be applied, which can take some time if people don't know they need to apply them. Even in the case of automatic updates, patching can be delayed if it requires an app restart, for example. - Malicious actors examine patches, work out exploit, begin exploiting in the wild. - Customers left in the dark. - Company assumes that having issued patches is good enough, substantially delays disclosure.

Co-ordinated disclosure aims to prevent all of that by ensuring everyone knows about it at the same time. That removes some of the ability of threat actors to exploit and allows SOCs, EDRs, etc., to update as well, so anything unpatched gets caught. If there are workarounds or other defenses that can be implemented until patching is possible, those can be employed as well.

For anyone trying to understand the issue at hand, this is an excellent summary. Thanks for your comment!

Not sure how this,

> Co-ordinated disclosure aims to prevent all of that by ensuring everyone knows about it at the same time

helps with this,

> Even in the case of automatic updates, patching can be delayed if it requires an app restart, for example.

Not saying they don't have a use-case. Just not sure how it's fixed.

For starters, it (hopefully) delays when a bad actor knows about it, meaning they start their process of reverse engineering the vulnerability after customers have been notified.

There are always going to be situations where out of date software hangs around. This at least levels the playing field when compared to the idea of trying to silently patch something.

It is common for organizations to delay routine patching for some fixed period of time (allow others to be early adopters and assume the risks of negative impacts from the patch), and/or schedule patches to occur during a predetermined maintenance window.

When you make a public security disclosure coordinated with the release of a patch to fix the issue disclosed, you alert the aforementioned organizations that there is an exploitable security vulnerability present and allow them to make an educated assessment of the comparative risks of patching immediately versus waiting and potentially being exploited.

It's not a perfect system, but transparency is the best compromise possible and allows everyone to make an educated choice. All other options have greater downsides.

>I'm very much in-favour of the private vulnerability research and responsible disclosure, but the "no silently patching vulnerabilities" sounds more like dick swinging to me than actually wanting to improve people's security.

Rather than dick-swinging, it's generally an acknowledgement that large organizations move slowly and need a bit of prodding to apply patches in a timely manner.

If you're a big-and-slow company, there is a significant difference in how quickly you'll worry about applying the patch that says "here's a minor patch" and the patch that says "here's a patch for a severe vulnerability".

I have worked with several companies which simply will not update something unless they are either mandated to or it is a large enough security risk.

Read more about Rapid7s opinion on silent patching at https://www.rapid7.com/blog/post/2022/06/06/the-hidden-harm-...

Reply on news.ycombinator.com