I’m sure this is the only community that might pay attention to a software BOM as mentioned in the article, but this is a great idea and makes a lot of sense (to me as a consumer at least).
Developers are relying more and more on automated scanners and the likes to manage this. Your modern python or javaScript stack just has way too many packages and they change daily. Just look at your dependency lockfile balloon when a random dependency updates a point and brings in a few more packages. It’s really a horrible thing.
I’d like to say the scanners were fast but not fast enough because the first wave of attacks was nearly instant. This was definitely a nightmare scenario where a simple unauthenticated GET could pull in a kit that was already live and ready to go.
I don't think anyone in the Java community is surprised to find they have a dependency on Log4j. It's one of those libraries used so widely that it's practically stdlib.
In the production of electronic things I've been pointing out that software needs to be on the BOM for other reasons. It is so often overlooked and considered zero cost even though companies pay people to develop it.
Making people look at a BOM would also discourage the mess that is npm.
Most systems use package management now; npm is only the poster child.
Reviewing a stack of BOMs is going to be a challenge for any organization. Say your production Linux has 1000 packages. Each of those might have hundreds or thousands of deps in varying versions, in their respective package managers (BOMs).
Business needs to step up its process game. How are BOMS (dep lists) reviewed? Do we expect zero CVEs? How do you filter out false positives, or irrelevant ones? Do you dump everything with that dep or help the maintainer fix it? Many questions.
We do something along this axis with our products. We have to be able to provide B2B software that will be stable on timelines measured in half-decades (per contractual requirements), so the specific vendors we decide to depend upon are a huge part of our decision making process. I will happily admit we probably wrote a little bit too much stuff in-house, but the number of clear wins easily outweighs the "no DIY allowed" concerns.
Getting us to vendor out something like logging/tracing/telemetry would take an act of god at this point. We explicitly spent a week ripping out Microsoft's byzantine logging from AspNetCore in favor of something we could trust and understand. Our entire logging framework now lives in 1 class file and consists of maybe 30 useful lines of source code. None of them have the capability to reach out to a remote host, download a DLL and then execute it in the current context. This sort of problem we are seeing with Log4j today is precisely the sort of experience we hope to avoid by doing a lot of our tooling in-house.
I think those who parroted "don't reinvent the wheel" over and over like it's some doomsday cult should accept some shame for the situation many developer ecosystems find themselves in today.
