Generate SLSA Build L3 provenance

[ianlewis]

Hi 👋

I'm Ian, working on behalf of Google and the Open Source Security Foundation (OpenSSF) to help open source projects to improve their supply chain security.

After some analysis minimist showed up as one of the top transitive dependencies in the JavaScript/Node ecosystem.

I would like to offer help update minimist builds to generate a SLSA Build Level 3 Provenance. The Supply chain Levels for Software Artifacts, or SLSA (salsa) framework aims to improve security in the build process by defining increasing levels of build integrity.

Now that npm supports distributing package provenance via the official npm registry, I think this would be a good time introduce provenance generation to minimist.

Given minimist is such a highly used package, I suggest generating SLSA Build L3 provenance using the Node.js Builder reusable workflow for GitHub Actions. This would provide the highest level of integrity for the build while hopefully being a fairly simple publish workflow.

Would the minimist project be open to a PR introducing these changes?

• Add a publish.yml to call the Node.js builder workflow and publish the resulting package when a new tag is created. This could alternatively be run manually via workflow_dispatch.
• README: A brief description for end-user to know how to verify the package integrity using the generated provenance.
• README: A SLSA Level 3 badge (optional)

[shadowspawn]

Thanks Ian. I will pay attention, but the conversation for this project is likely to be driven by @ljharb who handles the releases. Jordan has some sophisticated and paranoid scripting support around testing and publishing.

[ianlewis]

Thanks! @ljharb is everywhere! Jordan and I have interacted elsewhere so perhaps we can work something out.

[ljharb]

In general, I'm opposed to publishing from CI because it can only be done with either 1) a single factor, which is objectively way less secure than publishing locally with 2FA, or 2) a process that can sit and wait for the OTP code, or the web auth link to be visited, which for the former requires trusting a separate server (since github doesn't have this feature natively) and i haven't tried out the latter yet.

Additionally, npm's provenance feature guarantees only the publish location, and I haven't yet seen anyone demonstrate why that's valuable nor a single security incident that would have mitigated, so I'm hopeful there's evidence I'm unaware of :-)

[ljharb]

I'm going to close this for now; I continue to have not been shown a single concrete incident that publish provenance would have prevented, and since we don't have a build process at all, the git repo always precisely matches the published package, so there's no better form of verification achievable.

I will always be happy to reopen this if I'm shown persuasive evidence :-)