scorecard VS in-toto

For general open source hygiene, I'd recommend running OpenSSF scorecards on your github repo and following-up on anything it suggests. https://github.com/ossf/scorecard.

The OSSF scorecard initiative is really good to assess your project against security best practices. I am not the first to write about this.

Each area has its own associated risk, so the overall score is the average of the five areas. Here, you can check the details of each by consulting the documentation in detail.

Mitigation, according to Sean, is a combination of appropriate (network) access control, SCA (Software Composition Analysis) tooling to manage your policies around CVEs, and purging “all the things”. He also thinks MFA (multi-factor authentication) for authors of (critical) packages should be required. Sean gets his vulnerability insights from deps.dev, ossindex.sonatype, and cvedetails.com, and closely monitors interesting initiatives such as the OpenSSF Security Scorecards - a tool to assess open source projects for security risks through a series of automated checks.

Give feedback on new security standards: The various security standards like OpenSSF Scorecard and SLSA.dev can be a lot to digest, but they are likely going to be very influential in developing government standards. Take a peek at them, and if you have concerns or questions, file issues. The people behind them want to hear from a broad range of maintainers, so your feedback really does matter. (If you're a Tidelift maintainer partner, you can also bring the feedback to us—we are participating in these discussions, and may be able to either point to existing discussions, explain them more deeply, or bring your feedback to the appropriate places.)

Security Scorecards

I recommend using https://deps.dev to get a feeling for what you are bringing into your project. It also integrates with OSSF Scorecards, which gives a good overview over how healthy the project is, and whether it employs industry best practices.

The things you mentioned are not solved by a typical "SBOM" but e.g. CycloneDX has extra fields to record provenance and pedigree and things like in-toto (https://in-toto.io/) or SLSA (https://slsa.dev/) also aim to work in this field.

I've spent the last six months in this field and people will tell you that this or that is an industry best practice or "a standard" but in my experience none of that is true. Everyone is still trying to figure out how best to protect the software supply chain security and things are still very much in flux.

in-toto is an open source project that focuses on the attestation part of software supply chain security. You use it to define a “layout” for a project, i.e., how the different components should fit together. A project ships this definition with its code, and then another user of that software can compare what they have with the attached definition to see if it matches the structure and contents they expect. If it doesn’t, then this could point to external tampering or other issues.

But it's not all doom and gloom because the industry is evolving. Companies like Google are formulating tools like scorecard to heuristically reduce risk by encouraging you to rely on trustable dependencies only. There's also more complex tools like in-toto that actually look at the integrity of your supply chain (don't ask me how this one works, I just know that people like it).