4 ms·

People in this thread are worried that they are significantly vulnerable if they don't update right away. However, this is mostly not an issue in practice. A lo

by layer8 1y ago

People in this thread are worried that they are significantly vulnerable if they don't update right away. However, this is mostly not an issue in practice. A lot of software doesn't have continuous deployment, but instead has customer-side deployment of new releases, which follow a slower rhythm of several weeks or months, barring emergencies. They are fine. Most vulnerabilities that aren't supply-chain attacks are only exploitable under special circumstances anyway. The thing to do is to monitor your dependencies and their published vulnerabilities, and for critical vulnerabilities to assess whether your product is affect by it. Only then do you need to update that specific dependency right away.

silvestrov 1y ago
I think the main question is: do your app get unknown input (i.e. controlled by other people). Browsers get a lot of unknown input, so they have to update often. A Weather app is likely to only get input from one specific site (controlled by the app developers), so it should be relatively safe.
duped 1y ago
A million times this. You update a dependency when there are bug fixes or features that you need (and this includes patching vulnerabilities!). Those situations are rare. Otherwise you're just introducing risk into your system - and not that you're going to be caught in some dragnet supply chain attack, but that some dependency broke something you relied on by accident. Dependencies are good. Churn is bad.
- latentsea 1y ago
  I'd rather have excellent quality test suites, and pipelines I can have a high degree of confidence in to catch these issues and mitigate the risk, than dependencies that basically never get updated and then become very difficult to do so, which just introduce different classes of risk.
- jbkgujklgui 1y ago
  Vulnerabilities are not rare, the two most popular programming languages, javascript (node) and python, have 1000+ CVEs in their official docker images. I.e. in practice useless and shouldn't be used by anyone for anything.
embedding-shape 1y ago
> for critical vulnerabilities to assess whether your product is affect by it. Only then do you need to update that specific dependency right away. This is indeed what's missing from the ecosystem at large. People seem to be under the impression that if a new release of software/library/OS/application is released, you need to move to it today. They don't seem to actually look through the changes, only doing that if anything breaks, and then proceed to upgrade because "why not" or "it'll only get harder in the future", neither which feel like solid choices considering the trade-offs. While we've seen to already have known that it introduces massive churn and unneeded work, it seems like we're waking up to the realization that it is a security tradeoff as well, to stay at the edge of version numbers. Sadly, not enough tooling seems to take this into account (yet?).
- hypeatei 1y ago
  > Sadly, not enough tooling seems to take this into account Most tooling (e.g. Dependabot) allows you to set an interval between version checks. What more could be done on that front exactly? Devs can already choose to check less frequently.
  - mirashii 1y ago
    The check frequency isn't the problem, it's the latency between release and update. If a package was released 5 minutes before dependabot runs and you still update to it, your lower frequency hasn't really done anything.
    - hypeatei 1y ago
      What are the chances of that, though? The same could happen if you wait X amount of days for the version to "mature" as well. A security issue could be found five minutes after you update. EDIT: Github supports this scenario too (as mentioned in the article): https://github.blog/changelog/2025-07-01-dependabot-supports-configuration-of-a-minimum-package-age/ https://github.blog/changelog/2025-07-01-dependabot-supports... https://docs.github.com/en/code-security/dependabot/working-with-dependabot/dependabot-options-reference#cooldown- https://docs.github.com/en/code-security/dependabot/working-...
jerf 1y ago
Also, if you are updating "right away" it is presumably because of some specific vulnerability (or set of them). But if you're in an "update right now" mode you have the most eyes on the source code in question at that point in time, and it's probably a relatively small patch for the targeted problem. Such a patch is the absolute worst time for an attacker to try to sneak anything in to a release, the exact and complete opposite of the conditions they are looking for. Nobody is proposing a system that utterly and completely locks you out of all updates if they haven't aged enough. There is always going to be an override switch.
justsomehnguy 1y ago
> People in this thread are worried that they are significantly vulnerable if they don't update right away Most of them assume what if they are working on some public accessible website then 99% of the people and orgs in the world are running nothing but some public accessible website.
bumblehean 1y ago
>The thing to do is to monitor your dependencies and their published vulnerabilities, and for critical vulnerabilities to assess whether your product is affect by it. Only then do you need to update that specific dependency right away. The practical problem with this is that many large organizations have a security/infosec team that mandates a "zero CVE" posture for all software. Where I work, if our infosec team's scanner detect a critical vulnerability in any software we use, we have 7 days to update it. If we miss that window we're "out of compliance" which triggers a whole process that no one wants to deal with. The path of least resistance is to update everything as soon as updates are available. Consequences be damned.
- BrenBarn 1y ago
  > The practical problem with this is that many large organizations have a security/infosec team that mandates a "zero CVE" posture for all software. The solution is to fire those teams.
  - bumblehean 1y ago
    Sure I'll go suggest that to my C-suite lol
    - paulddraper 1y ago
      Someone has the authority to fix the problem. Maybe it’s them.
  - acdha 1y ago
    This isn’t a serious response. Even if you had the clout to do that, you’d then own having to deal with the underlying pressure which lead them to require that in the first place. It’s rare that this is someone waking up in the morning and deciding to be insufferable, although you can’t rule that out in infosec, but they’re usually responding to requirements added by customers, auditors needed to get some kind of compliance status, etc. What you should do instead is talk with them about SLAs and validation. For example, commit to patching CRITICAL within x days, HIGH with y, etc. but also have a process where those can be cancelled if the bug can be shown not to be exploitable in your environment. Your CISO should be talking about the risk of supply chain attacks and outages caused by rushed updates, too, since the latter are pretty common.
ozim 1y ago
Fun part is people are worried about 0 days but in reality most problems come from 300 or 600 days old not patched vulns.
nrhrjrjrjtntbt 1y ago
I agree. Pick yout poison. my poison is waiting before upgrades, assess zero days case by case.
weinzierl 1y ago
"The thing to do is to monitor your dependencies and their published vulnerabilities, and for critical vulnerabilities to assess whether your product is affect by it." Yes "Only then do you need to update that specific dependency right away." Big no. If you do that it is guaranteed one day you miss a vulnerability that hurts you. To frame it differently: What you propose sounds good in theory but in practice the effort to evaluate vulnerabilities against your product will be higher than the effort to update plus taking appropriate measures against supply chain attacks.
slaymaker1907 1y ago
And it needs to be said that you generally cannot tell if a vulnerability is critical for a given application except by evaluating the vulnerability in the context of said application. One that I've seen is some critical DoS vulnerability due to a poorly crafted regex. That sort of vulnerability is only relevant if you are passing untrusted input to that regex.

by layer8 1y ago

silvestrov 1y ago

I think the main question is: do your app get unknown input (i.e. controlled by other people). Browsers get a lot of unknown input, so they have to update often. A Weather app is likely to only get input from one specific site (controlled by the app developers), so it should be relatively safe.

duped 1y ago

A million times this. You update a dependency when there are bug fixes or features that you need (and this includes patching vulnerabilities!). Those situations are rare. Otherwise you're just introducing risk into your system - and not that you're going to be caught in some dragnet supply chain attack, but that some dependency broke something you relied on by accident. Dependencies are good. Churn is bad.

latentsea 1y ago
I'd rather have excellent quality test suites, and pipelines I can have a high degree of confidence in to catch these issues and mitigate the risk, than dependencies that basically never get updated and then become very difficult to do so, which just introduce different classes of risk.
jbkgujklgui 1y ago
Vulnerabilities are not rare, the two most popular programming languages, javascript (node) and python, have 1000+ CVEs in their official docker images. I.e. in practice useless and shouldn't be used by anyone for anything.

embedding-shape 1y ago

> for critical vulnerabilities to assess whether your product is affect by it. Only then do you need to update that specific dependency right away. This is indeed what's missing from the ecosystem at large. People seem to be under the impression that if a new release of software/library/OS/application is released, you need to move to it today. They don't seem to actually look through the changes, only doing that if anything breaks, and then proceed to upgrade because "why not" or "it'll only get harder in the future", neither which feel like solid choices considering the trade-offs. While we've seen to already have known that it introduces massive churn and unneeded work, it seems like we're waking up to the realization that it is a security tradeoff as well, to stay at the edge of version numbers. Sadly, not enough tooling seems to take this into account (yet?).

hypeatei 1y ago
> Sadly, not enough tooling seems to take this into account Most tooling (e.g. Dependabot) allows you to set an interval between version checks. What more could be done on that front exactly? Devs can already choose to check less frequently.
- mirashii 1y ago
  The check frequency isn't the problem, it's the latency between release and update. If a package was released 5 minutes before dependabot runs and you still update to it, your lower frequency hasn't really done anything.
  - hypeatei 1y ago
    What are the chances of that, though? The same could happen if you wait X amount of days for the version to "mature" as well. A security issue could be found five minutes after you update. EDIT: Github supports this scenario too (as mentioned in the article): https://github.blog/changelog/2025-07-01-dependabot-supports-configuration-of-a-minimum-package-age/ https://github.blog/changelog/2025-07-01-dependabot-supports... https://docs.github.com/en/code-security/dependabot/working-with-dependabot/dependabot-options-reference#cooldown- https://docs.github.com/en/code-security/dependabot/working-...

jerf 1y ago

Also, if you are updating "right away" it is presumably because of some specific vulnerability (or set of them). But if you're in an "update right now" mode you have the most eyes on the source code in question at that point in time, and it's probably a relatively small patch for the targeted problem. Such a patch is the absolute worst time for an attacker to try to sneak anything in to a release, the exact and complete opposite of the conditions they are looking for. Nobody is proposing a system that utterly and completely locks you out of all updates if they haven't aged enough. There is always going to be an override switch.

justsomehnguy 1y ago

> People in this thread are worried that they are significantly vulnerable if they don't update right away Most of them assume what if they are working on some public accessible website then 99% of the people and orgs in the world are running nothing but some public accessible website.

bumblehean 1y ago

>The thing to do is to monitor your dependencies and their published vulnerabilities, and for critical vulnerabilities to assess whether your product is affect by it. Only then do you need to update that specific dependency right away. The practical problem with this is that many large organizations have a security/infosec team that mandates a "zero CVE" posture for all software. Where I work, if our infosec team's scanner detect a critical vulnerability in any software we use, we have 7 days to update it. If we miss that window we're "out of compliance" which triggers a whole process that no one wants to deal with. The path of least resistance is to update everything as soon as updates are available. Consequences be damned.

BrenBarn 1y ago
> The practical problem with this is that many large organizations have a security/infosec team that mandates a "zero CVE" posture for all software. The solution is to fire those teams.
- bumblehean 1y ago
  Sure I'll go suggest that to my C-suite lol
  - paulddraper 1y ago
    Someone has the authority to fix the problem. Maybe it’s them.
- acdha 1y ago
  This isn’t a serious response. Even if you had the clout to do that, you’d then own having to deal with the underlying pressure which lead them to require that in the first place. It’s rare that this is someone waking up in the morning and deciding to be insufferable, although you can’t rule that out in infosec, but they’re usually responding to requirements added by customers, auditors needed to get some kind of compliance status, etc. What you should do instead is talk with them about SLAs and validation. For example, commit to patching CRITICAL within x days, HIGH with y, etc. but also have a process where those can be cancelled if the bug can be shown not to be exploitable in your environment. Your CISO should be talking about the risk of supply chain attacks and outages caused by rushed updates, too, since the latter are pretty common.

ozim 1y ago

Fun part is people are worried about 0 days but in reality most problems come from 300 or 600 days old not patched vulns.

nrhrjrjrjtntbt 1y ago

I agree. Pick yout poison. my poison is waiting before upgrades, assess zero days case by case.

weinzierl 1y ago

"The thing to do is to monitor your dependencies and their published vulnerabilities, and for critical vulnerabilities to assess whether your product is affect by it." Yes "Only then do you need to update that specific dependency right away." Big no. If you do that it is guaranteed one day you miss a vulnerability that hurts you. To frame it differently: What you propose sounds good in theory but in practice the effort to evaluate vulnerabilities against your product will be higher than the effort to update plus taking appropriate measures against supply chain attacks.

slaymaker1907 1y ago

And it needs to be said that you generally cannot tell if a vulnerability is critical for a given application except by evaluating the vulnerability in the context of said application. One that I've seen is some critical DoS vulnerability due to a poorly crafted regex. That sort of vulnerability is only relevant if you are passing untrusted input to that regex.