I have also been encountering the dependencies outlined in Census II with increasing frequency for some time.
I am very glad about this report, as it describes perceived facts and problems more formally than I can. Nevertheless, I now have a source with great credibility at hand to better address the problems presented in everyday work and to justify my arguments.
Scrolling through the long appendices, I found quite a few products again that have been giving me headaches for years. In particular, I think transitive dependencies are regularly underestimated. I often encounter problems multiple times because using freely available software, which in turn is based on other software, creates a depth of dependencies that is practically impossible to keep track of.
How the whole thing can be addressed in a meaningful way, however, is unfortunately written on a different page. Reducing dependencies is a desirable goal on the one hand but developing software yourself and potentially creating more/worse bugs is not an option either. A tool-based approach is certainly an option, but there are many developments that simply can’t do that. Especially not when transitive dependencies expose problems that can’t be trivially influenced.
Not least with Log4J, I was glad to have partners who proactively found solutions here to find and eliminate dependencies. Often, on the other hand, I experience a lack of priority and, more importantly, expertise to address and solve not only the obvious problems, but all relevant potential problems. Persistence is difficult to implement when there are enough other challenges that are easier to understand and solve.
With the increase in supply chain attacks over the last two years, I think there is a lot of room for improvement in this area. However, not least through reports like Census II, I am confident that in the future there will be better ways to build secure software based on a lot of FOSS. The possibilities through tools have also become somewhat better, as far as I can judge. I see further need in the consistent application of regulatory and compliance, which after all rarely demands a depth and stringency to find vulnerabilities in dependent components. Governance that ensures that at least only software is included that is also maintained and patched is unfortunately also not present everywhere.
To have only clean software, probably rather less and for it good (here secure) software should be developed, but the tendency goes into another direction. I can’t exclude myself from this.
Just running this blog currently with the AWS LightSail Bitnami stack I know some dependencies to vulnerable libraries, but I can’t plug them myself, because I’m not master of the stack. I guess that will be a future post then (after the rebuild to a solution I can control better).
Source:
Translated with www.DeepL.com/Translator (free version)