Generate provenance for releases to meet SLSA Build Level 1?

[BethGriggs]

trafficstars

From my understanding of the specification, the remaining step to achieve SLSA Build Level 1 compliance would be to produce a simple provenance out of our build system for release assets.

This issue is mostly just to gauge the desire/appetite for outputting provenance and share some ideas on how we think we could achieve it. It is required for SLSA Version 1, but as quoted in https://github.com/nodejs/security-wg/issues/876:

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 SLSA 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 at that time.

See https://github.com/nodejs/security-wg/issues/876 for more information and the linked spreadsheet for more background.

Why?

SLSA is a set of incrementally adoptable guidelines for supply chain security. At a minimum, going through the specification will help us identify places where we can harden the build process. SLSA has traction amongst various build infrastructure providers (GitHub Actions, Google Cloud Build) and npm. Much like SBOMs, we may reach a point where consumers are asking for this information.

Also, having the provenance information of what was built, with which tools, on which machines may be useful for debugging purposes.

How should we generate it?

• Writing our own script that gets run as part of the build to extract the necessary information from the build job.
• Use the SLSA Jenkins Generator plugin:
  • As far as I can tell, this plugin hasn't yet been updated to adhere to the latest SLSA specification. But I do think it'd be preferred to delegate this work to a platform plugin (as GitHub actions do). And, we'd save ourselves and other projects the effort of creating bespoke solutions.^*

^{*I potentially may have some time to explore updating and maintaining the plugin if that's the route that makes sense for the project.}

Where would/should the provenance be hosted/stored?

• GitHub assets?
• Download server?

Initially, for testing purposes, I'd propose we start by just having the provenance as an output asset of the build for us to see. We can worry about where it gets stored and/or hosted after.

Note that because the provenance should have information about the environment used to build, I believe we'd likely need one per release asset. Again, I'd propose we start with a single platform (probably linux-x64) to keep it simple while gauging the benefit to ourselves and end users.

Example

This is a simple provenance output that I believe meets the requirements (and some) for SLSA Build Level 1:

{
    "_type": "https://in-toto.io/Statement/v1",
	"subject": [
		{
			"name": "node-v20.4.0-linux-x64.tar.gz",
			"digest": {
				"sha256": "2a9b03dd17fa6d9241b93e244d7e8f2524c4019fb5cfe3a99e59da1ee983cb9a"
			}
		}
	],
    "predicateType": "https://slsa.dev/provenance/v1",
    "predicate": {
        "buildDefinition": {
            "buildType": "https://javadoc.jenkins.io/hudson/model/Job.html",
            "externalParameters": {
				"NODEJS_VERSION": "20.4.0",
				"NODEJS_MAJOR_VERSION": "20",
				"repository": "https://github.com/nodejs/node.git",
				"commit": "51174cd444",
				"datestring": "",
				"disttype": "release",
				"rc": "0"
			}
        },
        "runDetails": {
            "builder": {
                "id": "https://ci-release.nodejs.org/job/iojs+release/nodes=rhel8-release-sources/9474"
            },
            "metadata": {
                "startedOn": "2023-07-04T14:07:47Z",
                "finishedOn": "2023-07-04T14:31:19.644Z"
            }
        }
    }
}

It's possible to enrich the provenance with more detailed information about the build environment and tools used, but I think we should make incremental progress on that.