stephen-magill

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.

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 :-)

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.

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.

We closely monitor the "fix rate" -- what percentage of issues reported by Lift are ultimately fixed by developers. If the fix rate for a particular tool or type of rule is too low, then we modify how we configure and run the tool to eliminate the false positives we're seeing. It's very much like what Google reports doing internally in their use of ErrorProne (where they require all rules to have a 90%+ fix rate).

We provide deeper analysis and can surface things like thread safety issues and resource leaks. We also focus very closely on ensuring our tools have low false positive rates and so we tend to have less noisy output. This is especially important when you're using the pull request integration (you don't want a bunch of noise in code review).

We do support Python. Here's an example of a Python scan: https://lift.sonatype.com/result/smagill-lift-demo/posthog/0... That gives an idea of the sorts of results we flag in Python code, though we don't expect people to interact with that full bug list often. Recommended usage is to enable Lift on a repo and use the pull request integration so you can focus on results related to code changes as they come in.