State of the Software Supply Chain 2021(sonatype.com)
sonatype.com
State of the Software Supply Chain 2021
https://www.sonatype.com/resources/state-of-the-software-supply-chain-2021
13 comments
To read this on a phone, you have to trick the content into loading by scrolling past it, then scrolling back up.
Or, y'know, think carefully before adding a dependency to your project, and add as few dependencies as possible.
insert obligatory node_modules joke here
"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.
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.
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.
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.
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.
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
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.
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?
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.
I would really love to see these stats broken out by the type of update. Non-breaking changes (UI, interface, or otherwise) and transparent updates (filling some security holes, UI tweaks / alignment, performance, etc), though I wouldn't quite know how to mechanically label updates myself.
Basically, I'm advocating for slower user facing releases in general. We're getting overwhelmed on the flip side here.
Basically, I'm advocating for slower user facing releases in general. We're getting overwhelmed on the flip side here.
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.
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 :-)