4 ms·

I really hate dependabot making generic security people at work so pushy about updates updates updates. They seem to just be dogmatic about whatever dependabot

I really hate dependabot making generic security people at work so pushy about updates updates updates. They seem to just be dogmatic about whatever dependabot says, forcing churn even when the documented issues are clearly not relevant. I’m not sure how to handle it politically. I’m convinced that updating so much more often is worse, not better.

bluejellybean 3mo ago
I'm in a similar camp, I dislike how often third-party package updates get pushed out, especially given the lack of serious inspection. The reality is that each update is its own potential security issue and with supply chain attacks being all too frequent, it's not a panacea.
- cesarb 3mo ago
  > The reality is that each update is its own potential security issue Even beyond security issues: each update is a new opportunity for breakage, not only from bugs in the third-party package, but also from unexpected dependencies on the third-party package's behavior.
  - yearolinuxdsktp 3mo ago
    And that’s exactly why semantic versioning provides only an illusion of stability. This is also why ecosystems that don’t pin their versions such as floating versions that are the default in JavaScript ecosystems are so much more vulnerable from a security and a regression standpoint.
bunderbunder 3mo ago
I’ve mainly handled it by pushing my team to be extremely conservative about what dependencies we take, especially if they pull in scads and scads of transitive dependencies. This elegantly mitigates three problems in one go: update churn, dependency hell, and supply chain attack surface. It also, frankly, tends to make the code easier to understand. I’m not a huge NIH person but I do have to say that a lot of packages these days tend to encourage ways of doing things that are unnecessarily complex. More than once I’ve replaced a dependency with homegrown code and reduced LOC in the same commit.
demosthanos 3mo ago
I don't know if all ecosystems are as bad as node is, but the node ecosystem has terrible issue severity ranking which makes infosec squeamish for no reason. Every week or so there's a new High+ "vulnerability" that gets published against our dependencies and I have to go look at it to confirm that it's yet another case of "it's possible for someone to give this dev-only tool a bad regex that would cause the test runner to OOM on that branch".
- sonukapoor 3mo ago
  The direct vs transitive split helps a lot here. Most of that noise is transitive deps your app never actually calls with attacker-controlled input.
  - demosthanos 3mo ago
    I don't think transitive definitionally means we can ignore it. Any input that I give to my direct dependencies could theoretically end up inside of its dependencies and I can't know that it doesn't without auditing the source. The actual split is on which environments the dependency exists in and who can control inputs in those environments. For most private companies who aren't running CI on an open source repo, the dev/prod split is the operative one that determines what you can safely ignore.
333c 3mo ago
I feel the same. So so so many "regular expression denial-of-service" issues at my last job that just didn't seem serious or often reachable.
- 0cf8612b2e1e 3mo ago
  All of my services are internal, yet I am continually getting red alerts that there is a novel denial-of-service that needs to be patched immediately.
- mook 3mo ago
  I keep getting things like "denial of service when the SCSS or whatever parse is given malicious input”. Great, that's part of the build chain, all of its inputs are stuff we control. Why do we care.
esikich 3mo ago
As a sysadmin I'm in the same boat. I've unfortunately never worked with security folks that seemed to have any sysadmin or dev experience. Whether or not this is universal, idk, and I have no idea what they are teaching in these security courses. But I'm tired of security teams telling me "you need to implement these 230 group policies this quarter" or whatever. They don't seem to grasp the externalities of a request like that and how much fucking work it is to vet, test, deploy, monitor, verify, etc. 80% of the time, they don't even know what they do or if it's even impactful for us.
- pixl97 3mo ago
  As a previous sysadmin that does stuff in tangently related things to security (not the security person that makes these rules) I agree. The rules they come out with to address issues in operating systems that haven't been deployed in 10 years blows my mind. "Ya, Windows something ancient had an issue with WevDAV 2 decades ago, but that is not a reason to block the http DELETE verb at the WAF"
JoshTriplett 3mo ago
> I’m convinced that updating so much more often is worse, not better. The issue of cooldowns aside (which is about delaying updates, not reducing their frequency): you're going to have the same set of problems when you update, whether you do it frequently or infrequently. The difference is that if you update frequently, you'll have a smaller set of updates (so it's easier to debug) and you'll have more opportunity to report issues upstream and fix them in a timely fashion. It's the same underlying problem as CI and build time. Most people abandoned the concept of projects that take so long to build you can only do testing once a week, because CI that runs on every PR provides a much better experience. This is the same lesson applied to updates.
- Waterluvian 3mo ago
  My logical read of the situation is that I end up making fewer overall changes if I end up upgrading a dependency once, not thrice, to a specific version. And the changes are their own source of risk.
  - jjmarr 3mo ago
    In reality, one massive update is too big to digest and it never happens. So you're stuck on out-of-date packages having lost the ability to update. That's never a problem until it suddenly is. Company is put at significant risk (courts want to reason by analogy and "engineers skipped maintenance and endangered people" is an easy one) and nobody is to blame since nobody owned the task.
    - Waterluvian 3mo ago
      Except I’ve been doing it this way for years and it’s not actually a real problem. Just an imagined one.
      - bunderbunder 3mo ago
        I think that’s the response the “it’s never a real problem until suddenly it is” observation was trying to head off. There’s always someone who doesn’t want to take the advice of all the people who’ve been burned because “well it’s never happened to me.” I used to be that someone myself. Until the day it happened to me.
deleted 3mo ago
[deleted]
deleted 3mo ago
[deleted]
rcxdude 3mo ago
It's essentially blowback from the number-one security problem being out of date software with known vulnerabilities. It's also easy to measure without deeper knowledge of the system, so it gets focused on to the detriment of strategies based on deeper analysis and reducing overall attack surface.
deleted 3mo ago
[deleted]
sonukapoor 3mo ago
[dead]

bluejellybean 3mo ago

I'm in a similar camp, I dislike how often third-party package updates get pushed out, especially given the lack of serious inspection. The reality is that each update is its own potential security issue and with supply chain attacks being all too frequent, it's not a panacea.

cesarb 3mo ago
> The reality is that each update is its own potential security issue Even beyond security issues: each update is a new opportunity for breakage, not only from bugs in the third-party package, but also from unexpected dependencies on the third-party package's behavior.
- yearolinuxdsktp 3mo ago
  And that’s exactly why semantic versioning provides only an illusion of stability. This is also why ecosystems that don’t pin their versions such as floating versions that are the default in JavaScript ecosystems are so much more vulnerable from a security and a regression standpoint.

bunderbunder 3mo ago

I’ve mainly handled it by pushing my team to be extremely conservative about what dependencies we take, especially if they pull in scads and scads of transitive dependencies. This elegantly mitigates three problems in one go: update churn, dependency hell, and supply chain attack surface. It also, frankly, tends to make the code easier to understand. I’m not a huge NIH person but I do have to say that a lot of packages these days tend to encourage ways of doing things that are unnecessarily complex. More than once I’ve replaced a dependency with homegrown code and reduced LOC in the same commit.

demosthanos 3mo ago

I don't know if all ecosystems are as bad as node is, but the node ecosystem has terrible issue severity ranking which makes infosec squeamish for no reason. Every week or so there's a new High+ "vulnerability" that gets published against our dependencies and I have to go look at it to confirm that it's yet another case of "it's possible for someone to give this dev-only tool a bad regex that would cause the test runner to OOM on that branch".

sonukapoor 3mo ago
The direct vs transitive split helps a lot here. Most of that noise is transitive deps your app never actually calls with attacker-controlled input.
- demosthanos 3mo ago
  I don't think transitive definitionally means we can ignore it. Any input that I give to my direct dependencies could theoretically end up inside of its dependencies and I can't know that it doesn't without auditing the source. The actual split is on which environments the dependency exists in and who can control inputs in those environments. For most private companies who aren't running CI on an open source repo, the dev/prod split is the operative one that determines what you can safely ignore.

333c 3mo ago

I feel the same. So so so many "regular expression denial-of-service" issues at my last job that just didn't seem serious or often reachable.

0cf8612b2e1e 3mo ago
All of my services are internal, yet I am continually getting red alerts that there is a novel denial-of-service that needs to be patched immediately.
mook 3mo ago
I keep getting things like "denial of service when the SCSS or whatever parse is given malicious input”. Great, that's part of the build chain, all of its inputs are stuff we control. Why do we care.

esikich 3mo ago

As a sysadmin I'm in the same boat. I've unfortunately never worked with security folks that seemed to have any sysadmin or dev experience. Whether or not this is universal, idk, and I have no idea what they are teaching in these security courses. But I'm tired of security teams telling me "you need to implement these 230 group policies this quarter" or whatever. They don't seem to grasp the externalities of a request like that and how much fucking work it is to vet, test, deploy, monitor, verify, etc. 80% of the time, they don't even know what they do or if it's even impactful for us.

pixl97 3mo ago
As a previous sysadmin that does stuff in tangently related things to security (not the security person that makes these rules) I agree. The rules they come out with to address issues in operating systems that haven't been deployed in 10 years blows my mind. "Ya, Windows something ancient had an issue with WevDAV 2 decades ago, but that is not a reason to block the http DELETE verb at the WAF"

JoshTriplett 3mo ago

> I’m convinced that updating so much more often is worse, not better. The issue of cooldowns aside (which is about delaying updates, not reducing their frequency): you're going to have the same set of problems when you update, whether you do it frequently or infrequently. The difference is that if you update frequently, you'll have a smaller set of updates (so it's easier to debug) and you'll have more opportunity to report issues upstream and fix them in a timely fashion. It's the same underlying problem as CI and build time. Most people abandoned the concept of projects that take so long to build you can only do testing once a week, because CI that runs on every PR provides a much better experience. This is the same lesson applied to updates.

Waterluvian 3mo ago
My logical read of the situation is that I end up making fewer overall changes if I end up upgrading a dependency once, not thrice, to a specific version. And the changes are their own source of risk.
- jjmarr 3mo ago
  In reality, one massive update is too big to digest and it never happens. So you're stuck on out-of-date packages having lost the ability to update. That's never a problem until it suddenly is. Company is put at significant risk (courts want to reason by analogy and "engineers skipped maintenance and endangered people" is an easy one) and nobody is to blame since nobody owned the task.
  - Waterluvian 3mo ago
    Except I’ve been doing it this way for years and it’s not actually a real problem. Just an imagined one.
    - bunderbunder 3mo ago
      I think that’s the response the “it’s never a real problem until suddenly it is” observation was trying to head off. There’s always someone who doesn’t want to take the advice of all the people who’ve been burned because “well it’s never happened to me.” I used to be that someone myself. Until the day it happened to me.

deleted 3mo ago

[deleted]

deleted 3mo ago

[deleted]

rcxdude 3mo ago

It's essentially blowback from the number-one security problem being out of date software with known vulnerabilities. It's also easy to measure without deeper knowledge of the system, so it gets focused on to the detriment of strategies based on deeper analysis and reducing overall attack surface.

deleted 3mo ago

[deleted]

sonukapoor 3mo ago

[dead]