It's a natural next step after pinning versions and keeping all dependencies cached in-house. If the rolling disaster that NPM is taught us anything, is that it's critical to have control over the update process of the code that goes into your product. Not to mention, CI runs faster if you don't have to redownload everything from GitHub on each build :).

(Though then developers don't get a day off when GitHub goes down, as it does every couple months.)

A good asset graph / asset transparency log / whathaveyou would help a lot. If an SBOM is asserted and timestamped, you can compare assets you download to the earlier assertion to see if they are the same.

When I worked on buildpacks we added something like this. Each buildpack carried a simple BOM of the binaries it referred to and digests for them. When it fetched dependencies it compared the digests and bombed out if there were any mismatches.

This led us to capture far more of our dependency graph than before. It is surprising how many folks will replace binaries in-place without changing version numbers. We also managed to catch bugs in our own CI/CD process.

Ok, but there would still be some point of contact where an SBOM would show “company X fork of Ruby, company X fork of package Z” etc, right?

And then the choice gets back to how much to trust company X and package Z, weighed against alternative solutions.

Unless penalties for doing so are legislated, they need not claim that the fork they are actually using is a fork of anything; they could treat it as if part of their proprietary code (though they might be in violation of license agreements if they do this.)

It seems like it could equally be “internal package UUID1 version X, internal package UUID2 version Y” if malicious compliance and/or industrious laziness was the goal.