3 ms·

State of the Software Supply Chain 2021

15 points by livealight 5y ago

makeitrain 5y ago
To read this on a phone, you have to trick the content into loading by scrolling past it, then scrolling back up.
marcus_holmes 5y ago
Or, y'know, think carefully before adding a dependency to your project, and add as few dependencies as possible.
- livealight 5y ago
  insert obligatory node_modules joke here
timw4mail 5y ago
"Vulnerabilities are more common in popular projects." - meaning more popular projects have more known issues, which seems kind of obvious. Perhaps 'security by obscurity' has its parallel in 'vulnerability in popularity'. While not a good security tactic in general, there is something to the fact that an obscure library will be less exploited.
- stephen-magill 5y ago
  Yep. The question is whether the engineering trade-offs are worth it. Less-used libraries might have more undiscovered bugs that crop up in production and could have lower levels of support as well.
nixpulvis 5y ago
With so many irrelevant advisories, I'm not sure I can take much from this report TBH. Not to mention that I disagree about MTTU, a stat that is clearly skewed toward pencil pushers. The more time you spend updating dependencies, the less time you spend actually coding things. Well, unless the updates actually give you new features, which is generally not what people are looking for when running an update for some reason.
- livealight 5y ago
  Yeah oddly the outcome of MTTU is a maintained transitive tree seems to be a better indicator of security status than any other more complex framework. How to do it effectively is a matter on to itself
  - stephen-magill 5y ago
    This is exactly right. Low MTTU and keeping up-to-date across the transitive dependency tree makes it less likely that vulnerabilities creep in due to those transitive dependencies. I think there's also a certain aspect of "faster is better" akin to what we see in Forsgren et al's Accelerate / State of DevOps research. If you have the team structure, development discipline, and release infrastructure required to update dependencies frequently then that probably benefits other aspects of project quality as well.
    - nixpulvis 5y ago
      What if your discipline is more like Debian or others who make a point to update more dependencies at the same time on a slower cadence?
      - stephen-magill 5y ago
        I think that works provided the cadence isn't too slow. We see an average of 8 to 12 project versions per year being published depending on ecosystem. That matches nicely with the 28 day average MTTU for 2021 in the Maven ecosystem. I wouldn't want to see projects releasing less frequently than that. But I think the right answer also depends on where in the dependency chain your project tends to live. Projects near the "leaves" should aim to update faster so that downstream consumers aren't blocked waiting on them to remediate issues. Projects more toward the base of the tree might update every month or so and not worry about releasing a new version every time a transitive dependency changes, as that would be too much version churn.
        5y ago
phkahler 5y ago
Interesting read. One thing seems to be missing, and that is any notion of participating in upstream development. In open source you don't have to just be a consumer, you can actively participate in the development of dependencies to varying degrees. They do point to people near the edge vs on the edge as having better practices, and I'd think that's because they at least follow and understand what's going on vs just using the latest. Following and understanding seems very close to participating, though they are different.
- stephen-magill 5y ago
  This is something we studied in last year's report. Based on a survey similar to the one described in Chapter 4 we found that a mix of features measuring participation in the open source community was associated with positive security outcomes. It makes sense that if you follow the projects you're using closely then you would be more aware of security advisories and fixes for those projects. My favorite part was the term we used for this mix of features: Open Source Enlightenment :-)

15 points by livealight 5y ago

makeitrain 5y ago

To read this on a phone, you have to trick the content into loading by scrolling past it, then scrolling back up.

marcus_holmes 5y ago

Or, y'know, think carefully before adding a dependency to your project, and add as few dependencies as possible.

livealight 5y ago
insert obligatory node_modules joke here

timw4mail 5y ago

"Vulnerabilities are more common in popular projects." - meaning more popular projects have more known issues, which seems kind of obvious. Perhaps 'security by obscurity' has its parallel in 'vulnerability in popularity'. While not a good security tactic in general, there is something to the fact that an obscure library will be less exploited.

stephen-magill 5y ago
Yep. The question is whether the engineering trade-offs are worth it. Less-used libraries might have more undiscovered bugs that crop up in production and could have lower levels of support as well.

nixpulvis 5y ago

With so many irrelevant advisories, I'm not sure I can take much from this report TBH. Not to mention that I disagree about MTTU, a stat that is clearly skewed toward pencil pushers. The more time you spend updating dependencies, the less time you spend actually coding things. Well, unless the updates actually give you new features, which is generally not what people are looking for when running an update for some reason.

livealight 5y ago
Yeah oddly the outcome of MTTU is a maintained transitive tree seems to be a better indicator of security status than any other more complex framework. How to do it effectively is a matter on to itself
- stephen-magill 5y ago
  This is exactly right. Low MTTU and keeping up-to-date across the transitive dependency tree makes it less likely that vulnerabilities creep in due to those transitive dependencies. I think there's also a certain aspect of "faster is better" akin to what we see in Forsgren et al's Accelerate / State of DevOps research. If you have the team structure, development discipline, and release infrastructure required to update dependencies frequently then that probably benefits other aspects of project quality as well.
  - nixpulvis 5y ago
    What if your discipline is more like Debian or others who make a point to update more dependencies at the same time on a slower cadence?
    - stephen-magill 5y ago
      I think that works provided the cadence isn't too slow. We see an average of 8 to 12 project versions per year being published depending on ecosystem. That matches nicely with the 28 day average MTTU for 2021 in the Maven ecosystem. I wouldn't want to see projects releasing less frequently than that. But I think the right answer also depends on where in the dependency chain your project tends to live. Projects near the "leaves" should aim to update faster so that downstream consumers aren't blocked waiting on them to remediate issues. Projects more toward the base of the tree might update every month or so and not worry about releasing a new version every time a transitive dependency changes, as that would be too much version churn.
      - 5y ago

phkahler 5y ago

Interesting read. One thing seems to be missing, and that is any notion of participating in upstream development. In open source you don't have to just be a consumer, you can actively participate in the development of dependencies to varying degrees. They do point to people near the edge vs on the edge as having better practices, and I'd think that's because they at least follow and understand what's going on vs just using the latest. Following and understanding seems very close to participating, though they are different.

stephen-magill 5y ago
This is something we studied in last year's report. Based on a survey similar to the one described in Chapter 4 we found that a mix of features measuring participation in the open source community was associated with positive security outcomes. It makes sense that if you follow the projects you're using closely then you would be more aware of security advisories and fixes for those projects. My favorite part was the term we used for this mix of features: Open Source Enlightenment :-)