Verifying provenances of internal builds on external mirrors?

[deeglaze]

I'm seeking to provide a "transparent release" of virtual firmware that both ships in production and is published for customer audit. Due to source governance rules, I need for the source to be hosted on an internal server that we will push to a mirror. The build service is called Kokoro-on-RBE (remote build execution) and it's similar to Cloud Build in that it combines known sources and a known toolchain container to produce its binary artifacts.

The build service has its own source mounting method that can be reproduced in a different way with a straight docker command, but Kokoro-on-RBE is not an externally usable tool. Is this kind of verifiable retargeting something that could be supported in the slsa-verifier?

[TomHennen]

Hey Dionna,

I think there might be two questions embedded in there (note I'm not an slsa-verifier expert).

1. Can slsa-verifier support verifying provenance from proprietary tools? (IMO we should make this work if it doesn't already)
2. Would it be possible to provide a public/private mapping to be used when verifying provenance to support use of internal mirrors? (I think this is what you mean by 'variable retargetting').

For 1, something we'd need a slsa-verifier expert to chime in on is how the buildType would be handled. SLSA allows each builder to specify their own, and I don't know what type Kokoro-on-RBE would use.

For 2, would something like this work how you'd expect?

Assumptions:

https://some.internal.mirror.repo/foo/bar is an exact mirror of https://github.com/foo/bar.

Input provenance

{
    "_type": "https://in-toto.io/Statement/v1",
    "predicateType": "https://slsa.dev/provenance/v1",
    "predicate": {
        "buildDefinition": {
            "buildType": "kokoro-on-rbe-or-whatever",
            "externalParameters": {
                "configSource": {
                    "ref": "refs/heads/main",
                    "repository": "git+https://some.internal.mirror.repo/foo/bar",
                    "path": "basic-config/kokoro.yaml"
                },
            "resolvedDependencies": [
                {
                    "uri": "git+https://some.internal.mirror.repo/foo/bar@refs/heads/main",
                    "digest": { "gitCommit": "bb0fe8075f92bb82b679afe400a47b106f0cec4b" }
                }
            ]

Example command line

$ slsa-verifier verify-artifact foo.blob \
  --provenance-path foo.blob.intoto.jsonl \
  --source-uri github.com/foo/bar \
  --source-branch main
  --rewrite-mirror git+https://some.internal.mirror.repo/foo/bar,git+https://github.com/foo/bar

Where the caller says "hey, if the provenance says git+https://some.internal.mirror.repo/foo/bar, replace that with git+https://github.com/foo/bar". Somehow you'd have to tell users to do the rewrite, and I'm not quite sure how to ensure that's safe. One way might be "check that the gitCommit listed in the provenance matches a commit on the upstream repo and that it appears on the same branch."

But... maybe you have something else in mind. Can you perhaps provide a sample of what you'd like the command line invocation to look like?

[ramonpetgrave64]

Thanks @TomHennen. To help, I have some additional questions.

Which aspects are transparency were you looking for? Publishing the build event and signing event to a public log like Rekor?

If your build process is able to access the instance's identities, and your firmware are actually container images, then you may be able to use GCB's built-in support for producing SLSA attestations, and slsa-verifier to verify the images.

I think you mentioned pushing your internal source code to an external mirror. Did you mean Github? If so, would you consider performing your builds on Github, if you can get a bit-for-bit reproduced builds with your docker commands? This way, you can use our slsa-github-generators to produce attestations, publicly verifiable with our slsa-verifier. (You can also use Github's similar attestation system)

If the SLSA Build levels are not your necessarily part of your goal, you can consider producing a VSA with a static signing key. You can distribute your firmware, the VSAs and the public key to your consumers, and use slsa-verifier to verify the artifact, VSA, and public key.