4 ms·

True story: They already do. I know one company that forked Ruby, and would likely claim every library they run under it is thereby forked for the sake of repor

True story: They already do. I know one company that forked Ruby, and would likely claim every library they run under it is thereby forked for the sake of reporting.

mattcwilson 6y ago
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.
- mannykannot 6y ago
  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.)
- sokoloff 6y ago
  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.
TeMPOraL 6y ago
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.)
- jacques_chester 6y ago
  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.

True story: They already do. I know one company that forked Ruby, and would likely claim every library they run under it is thereby forked for the sake of reporting.

mattcwilson 6y ago

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.

mannykannot 6y ago
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.)
sokoloff 6y ago
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.

TeMPOraL 6y ago

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

jacques_chester 6y ago
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.