Node.js core SLSA.dev Review

[BethGriggs]

Current state: Still in initial review - but unlikely to be at Level 1.

• Node.js SLSA.dev Review
  ^{*Restricted to comment only, but if you'd like to be added as an editor just let me know.}

---

Background:

Supply chain Levels for Software Artifacts, or SLSA (salsa).

It’s a security framework, a check-list of standards and controls to prevent tampering, improve integrity, and secure packages and infrastructure in your projects, businesses or enterprises. It’s how you get from safe enough to being as resilient as possible, at any link in the chain.

A few of us got together to start looking at the SLSA framework (@mhdawson, @richardlau, @sxa). The plan was to first audit where we believe we are today against the requirements, and then gradually pick a few of the sections to try and move us towards the next level. Any specific actions we agree to take would likely be spread across various working groups - I believe mostly the Build WG, Release WG, and Node.js core.

Edit: I figure I should explicitly mention that there's no expectation that the project will agree to implement all of the work to meet the higher level requirements. We may reach a point where a requirement could add too much work/maintenance to a particular group that we decide not to pursue it at that time.

---

Next steps:

• Collate all of the requirements we have queries on, and find contacts to help answer.
• List remaining steps towards Level 1.
• Pick which of the remaining Level 1 requirements are appropriate to try and meet in the near term.

[RafaelGSS]

Love that. In case you need some help, let us know

[BethGriggs]

Steps remaining to claim SLSA Level 1

• Provenance requirements:
  • Available: The provenance is available to the consumer in a format that the consumer accepts. The format SHOULD be in-toto SLSA Provenance, but another format MAY be used if both producer and consumer agree and it meets all the other requirements.
• Requirements on the contents of the provenance:
  • Identifies artifact: The provenance MUST identify the output artifact via at least one cryptographic hash. The provenance MAY provide multiple identifying cryptographic hashes using different algorithms. When only one hash is provided, the RECOMMENDED algorithm is SHA-256 for cross-system compatibility. If another algorithm is used, it SHOULD be resistant to collisions and second preimages.
  • Identifies builder: The provenance identifies the entity that performed the build and generated the provenance. This represents the entity that the consumer must trust. Examples: “GitHub Actions with a GitHub-hosted worker”, “jdoe@example.com’s machine”.
  • Identifies build instructions: The provenance identifies the top-level instructions used to execute the build.The identified instructions SHOULD be at the highest level available to the build (e.g. if the build is told to run build.sh it should list build.sh and NOT the individual instructions in build.sh).If build-as-code is used, this SHOULD be the source repo and entry point of the build config (as in the GitHub Actions example).If the build isn’t defined in code it MAY list the details of what it was asked to do (as in the Google Cloud Build RPC example or the Explicitly Run Commands example).
  • Includes metadata: The provenance includes metadata to aid debugging and investigations. This SHOULD at least include start and end timestamps and a unique identifier to allow finding detailed debug logs. “○” = RECOMMENDED.

So, my understanding is all of the remaining steps to reach Level 1 would be around producing a simple provenance* that meets these minimum requirements. Likely needs to be discussed/planned with @nodejs/build (and specifically, @sxa who is involved in another project which has produced similar).

[sxa]

Yeah the production of a suitable SBOM likely wouldn't be too tricky to achieve as the minimum requirements are quite low, but we would absolutely want to try and flesh it out with more information as we go forward.
Luckily for Node.js since almost all of the dependencies of the product are part of the source tree it makes it a little easier to know exactly what's gone into any given build since there isn't too much else that's required to build Node.

[github-actions]

This issue is stale because it has been open many days with no activity. It will be closed soon unless the stale label is removed or a comment is made.

[BethGriggs]

I have on my near-term todo list to update the spreadsheet to audit against SLSA 1.0. From what I've read, SLSA 1.0 tries to make some of sections/levels more independently achievable.

[laurentsimon]

Wanted to bring to your attention the https://github.com/slsa-framework/slsa-github-generator that simplifies SLSA provenance generation if your release on GitHub.
There are various builders available:

• npm https://slsa.dev/blog/2023/05/bringing-improved-supply-chain-security-to-the-nodejs-ecosystem. If this does not work, we'd love feedback; and you can always use npm publish --provenance to start with.
• go https://slsa.dev/blog/2022/06/slsa-github-workflows
• others https://slsa.dev/blog/2022/08/slsa-github-workflows-generic-ga (this is the most popular)

I you don't release on GitHub, it's harder :/

[ljharb]

tbh it's still pretty unclear to me what advantage provenance gives you, since the only thing it actually tells you is the location the publish happened - there's no verification of contents at all, and they can come from any source, including remote and thus unauditable sources. Why is the publish location an important piece of information?

[laurentsimon]

In a nutshell it provides an audit trail to the build / package process. Example: It reduces the threat of npm account compromise; GitHub repository recycling. I think you can think of it as "what you download is what you see [in the repo]".

In the case of the OSSF builder, it also gives you the top command if you want to re-build it, e.g. in a world of "reproducible package", in order to reduce the trust in a single platform. ("reproducible package" could be that the content of the tarball is the same, not necessarily that it's bit-by-bit the same)

[ljharb]

Sure, but for npm, which already has the ability to link a user's github account and know for certain that the publisher has write access on the repo at publish time, i'm not sure why this much more limited thing that requires user setup is a more reliable approach.

(Reproducible builds are a largely unattainable goal in JS by the typical definition, so i'm not sure that's a useful motivation)

[laurentsimon]

Sure, but for npm, which already has the ability to link a user's github account and know for certain that the publisher has write access on the repo at publish time, i'm not sure why this much more limited thing that requires user setup is a more reliable approach.

I think it can add some transparency and reduce trust in the registry - if other entities want to monitor for the provenance themselves. iiuc, there's WIP enabling publishing to the default registry with the GITHUB_TOKEN (like https://docs.github.com/en/actions/publishing-packages/publishing-nodejs-packages#authenticating-to-the-destination-repository). Is there some other existing feature in the registry that allows to "link a user's github account and know for certain that the publisher has write access on the repo at publish time"?

[ljharb]

https://www.npmjs.com/settings/ljharb/profile (replace ljharb with your own username) has a "link accounts" option where an npm author can link their account to github. The rest is just an API call (and since github owns npm it'd probably be even simpler than that).

npm could then, serverside, write anything desired to rekor/sigstore so that it was independently auditable.

[laurentsimon]

Yep, this is definitely a simple option that allows npm to generate an attestation for the repo origin. It's similar to publishing with GITHUB_TOKEN, iiuc. The provenance based on a builder simply adds some additional transparency to keep the registry honest, if external entities want to verify by themselves. There are ways (for a registry) to prove that they were presented a valid JWT without revealing the signature, but that's not supported by Rekor atm.

/cc @znewman01