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[bot]]

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

[ljharb]

It seems, then, that my suggestion would be a much better default, and the current provenance option would be an enhancement with future value for those that wanted to opt in to it?

[BethGriggs]

Appreciate the resources @laurentsimon. I'm not sure the the npm provenance approach will help us here as this issue is covering Node.js core runtime builds. Specifically, we'll be looking to provide an SBOM and provenance for the Node.js core runtime binaries.

Unfortunately, I think we're going to need something a little more bespoke to abstract all the dependency and build information for Node.js release builds. We use Jenkins for Node.js release builds (unlikely to change).

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

I have added a tab to the spreadsheet for SLSA 1.0 audit. Now it's a smaller specification just focusing on the Build track, I believe we could reach SLSA Build Level 1 by just providing a simple provenance.

I have an idea of what we need/want the SBOM to contain, but also a few ??? on when/how it should be generated. For example, we'd like dependency information included...the low-hanging fruit way of doing that would be to rely on the output of process.versions but that doesn't seem appropriate, it think it needs to also be done at build time.

[richardlau]

I have an idea of what we need/want the SBOM to contain, but also a few ??? on when/how it should be generated. For example, we'd like dependency information included...the low-hanging fruit way of doing that would be to rely on the output of process.versions but that doesn't seem appropriate, it think it needs to also be done at build time.

FWIW It's not generated at build time, but https://github.com/nodejs/node/pull/48081 landed a couple of weeks ago to add versions of dependencies to https://github.com/nodejs/node/blob/main/doc/contributing/maintaining/maintaining-dependencies.md.

[laurentsimon]

Appreciate the resources @laurentsimon. I'm not sure the the npm provenance approach will help us here as this issue is covering Node.js core runtime builds. Specifically, we'll be looking to provide an SBOM and provenance for the Node.js core runtime binaries.

SBOMs and provenance are distinct concepts. SBOM provides a list of dependencies. Provenance gives information about how the builds were made (e.g., what script was executed). They are both important. Provenance can also attest to the generated SBOM, if's it's generated at "build time" (common practice to ensure integrity of the SBOM as well). cc'ing @kpk47 who works on the SLSA specs

[kpk47]

+1 to what @laurentsimon said about SBOMs vs provenance. While provenance can contain a full list of build dependencies, its main purpose is to provide a verifiable link between source code and binary artifacts. That link gives stronger assurances that the artifact is benefiting from security controls being used on the source code (e.g. code review, vuln scanning).

You mentioned that your core libraries are built using Jenkins. I know that @mlieberman85 has expressed interest in developing SLSA for Jenkins, but I'm not aware of its current state. There's also an old prototype using SLSA v0.1 at https://github.com/slsa-framework/slsa-jenkins-generator, but I don't know much about it.

Reaching Build L1 is meant to be easy, and you should be able to do so by adding a step to your build process that generates provenance with the minimum required fields. The full details are available at https://slsa.dev/provenance/v1, but minimal provenance would look something like

{
    "_type": "https://in-toto.io/Statement/v1",
    "subject": [
      {
        "name": "<name>", // Optional. You define the name.
        "digest": {
          "sha256": <SHA256-digest>
        }
      }
    ],
    "predicateType": "https://slsa.dev/provenance/v1",
    "predicate": {
        "buildDefinition": {
            "buildType": "nodeJS-jenkins", // You define the build type.
            "externalParameters": { // URI of build script + any parameters not included in the script
              "<PARAMETER_1>": "<VALUE>",
              "<PARAMETER_2>": "<VALUE>",
          },
        },
        "runDetails": {
            "builder": {
                "id": string, // You define the builder ID.
            },
        }
    }
}

[BethGriggs]

Thanks for jumping in @kpk47. From that, it seems to make sense for us to not focus on including dependencies in the provenance (for now) to make a start. And any work on an SBOM can be independent of that.

I'll take a look at the plugin, but we'd need agreement from our Build WG to add a new plugin (especially if it's a proof of concept).

[BethGriggs]

I put my understanding/ideas/discussion points in https://github.com/nodejs/build/issues/3425

[github-actions[bot]]

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.

[RafaelGSS]

@BethGriggs I think it's safe to close this issue as concluded considering the points you've raised in the document + nodejs/build issue, right?

[github-actions[bot]]

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.

[mhdawson]

I'm going to close based on @RafaelGSS suggestion above.