3 ms·

I don't see how you have really fixed the break much. Especially if you can "push back" and say no to an update, you are just setting yourself up for when the

by taeric 4y ago

I don't see how you have really fixed the break much. Especially if you can "push back" and say no to an update, you are just setting yourself up for when the update is even harder to accept. (That is, the further behind on an update you are, the harder to take it. Typically.) And then there is the "I want the fix, but I don't want the added attack vector of features that comes with it."

kelnos 4y ago
Sure, but you're in control, and can decide to do what's best for you and your organization. Taking on the technical debt of allowing your dependencies to get further and further behind isn't a decision I usually make, but it can be a valid one depending on the individual circumstances.
- taeric 4y ago
  I mean, you aren't wrong. But this is akin to saying you don't need a memory safe language, because you can decide what is best for your applications memory needs. That is, I think the ask is more of "why haven't we come up with something that is a bit better at mitigating risks, here?"
  - SomeCallMeTim 4y ago
    Software engineering is complex. Some of the challenges are simply irreducible. I believe this is one of them.
SomeCallMeTim 4y ago
99% of the time it's a minor update patch that you really should just apply, or Snyk will add a patch to the build to fix the security hole directly. Honestly it's just not worth worrying about whether a security hole is exploitable when the decision is whether to accept a minor update patch. Just accept the patch PR and move on. The times you need to do a major update to get a patch fix it's equally important to just make that upgrade, since that means the ancient version you're using is likely out of maintenance and likely is throwing warnings that you're using a deprecated version. Yes, it's more work to perform a major upgrade. But that doesn't mean it isn't good engineering to keep your tools up to date.

by taeric 4y ago

kelnos 4y ago

Sure, but you're in control, and can decide to do what's best for you and your organization. Taking on the technical debt of allowing your dependencies to get further and further behind isn't a decision I usually make, but it can be a valid one depending on the individual circumstances.

taeric 4y ago
I mean, you aren't wrong. But this is akin to saying you don't need a memory safe language, because you can decide what is best for your applications memory needs. That is, I think the ask is more of "why haven't we come up with something that is a bit better at mitigating risks, here?"
- SomeCallMeTim 4y ago
  Software engineering is complex. Some of the challenges are simply irreducible. I believe this is one of them.

SomeCallMeTim 4y ago

99% of the time it's a minor update patch that you really should just apply, or Snyk will add a patch to the build to fix the security hole directly. Honestly it's just not worth worrying about whether a security hole is exploitable when the decision is whether to accept a minor update patch. Just accept the patch PR and move on. The times you need to do a major update to get a patch fix it's equally important to just make that upgrade, since that means the ancient version you're using is likely out of maintenance and likely is throwing warnings that you're using a deprecated version. Yes, it's more work to perform a major upgrade. But that doesn't mean it isn't good engineering to keep your tools up to date.