3 ms·

Aside from the git trademark issue, which is easily resolvable, this project is interesting from a professional point of view because the concepts of SBOMs and

by rswail 5y ago

Aside from the git trademark issue, which is easily resolvable, this project is interesting from a professional point of view because the concepts of SBOMs and the requirement to deliver them as part of NIST standards is becoming more important. It's likely that these standards will start to "trickle down" from US Federal Government to other levels of US government and across general contract negotiations for software deliveries. Has anyone started delivering SBOMs as part of their delivery? We've had to deliver reproducible build infrastructure and source as part of contractual escrow conditions, but there's a big difference between "reproducible" and actually byte-for-byte equality to a released SBOM.

pabs3 5y ago
Personally I'd just use Debian as my SBOM if one was required. For anything open source, just make new packages and upload them to Debian. It has probably many of the things needed (including in-progress deterministic reproducible builds), apart from building proprietary software, but you can create Debian packages internally and use your own build servers and apt repository. https://www.reproducible-builds.org/ https://www.reproducible-builds.org/ https://tests.reproducible-builds.org/debian/reproducible.html https://tests.reproducible-builds.org/debian/reproducible.ht... Any other distro can be treated similarly really.
- rswail 5y ago
  That's fine if you're running on a Linux platform, but if you're running on AWS/GCP/Azure with lambdas/workers/serverless, you need to have the SBOM for your own software. Not everything is going to be accepted as part of Debian as a distribution.
  - pabs3 5y ago
    If you are using a proprietary cloud platform there can be no real SBOM, because you're relying on software you can't even get a hash of. The SBOM for the part of the software that you do control when running on such platformas has to be something that the proprietary platform supports, which obviously will have zero overlap with Debian packaging, so in that situation you just need to look at what the platform supports. For situations where one is using Debian but also software not in Debian, you can create an internal apt repository and make internal .deb packages to put in the internal apt repository.

by rswail 5y ago

pabs3 5y ago

Personally I'd just use Debian as my SBOM if one was required. For anything open source, just make new packages and upload them to Debian. It has probably many of the things needed (including in-progress deterministic reproducible builds), apart from building proprietary software, but you can create Debian packages internally and use your own build servers and apt repository. https://www.reproducible-builds.org/ https://www.reproducible-builds.org/ https://tests.reproducible-builds.org/debian/reproducible.html https://tests.reproducible-builds.org/debian/reproducible.ht... Any other distro can be treated similarly really.

rswail 5y ago
That's fine if you're running on a Linux platform, but if you're running on AWS/GCP/Azure with lambdas/workers/serverless, you need to have the SBOM for your own software. Not everything is going to be accepted as part of Debian as a distribution.
- pabs3 5y ago
  If you are using a proprietary cloud platform there can be no real SBOM, because you're relying on software you can't even get a hash of. The SBOM for the part of the software that you do control when running on such platformas has to be something that the proprietary platform supports, which obviously will have zero overlap with Debian packaging, so in that situation you just need to look at what the platform supports. For situations where one is using Debian but also software not in Debian, you can create an internal apt repository and make internal .deb packages to put in the internal apt repository.