SLSA Requirements for Automation

[melba-lopez]

Problem: To assist with automation (devops/compliance), need to generate a machine readable format for SLSA Requirements.

Propose:

• Use v .1 of SLSA Specification to identify accuracy/development of different formats
• Generate a CSV, XML, JSON of the requirements for ALL, Source, Build, Provenance, and/or High Level
• Attempt to use it with OSCAL for mapping requirements to other frameworks/regulations

Additional Info: Discussed during 9/6/22 positioning meeting

[melba-lopez]

SOURCE Requirements for v .1 specification (FIXED)

SLSA Mapping - Source.csv

SLSA Source Requirements JSON code (Fixed)

[
  {
    "Requirement": "Version controlled",
    "Description": "Every change to the source is tracked in a version control system that meets the following requirements:\n\n[Change history] There exists a record of the history of changes that went into the revision. Each change must contain: the identities of the uploader and reviewers (if any), timestamps of the reviews (if any) and submission, the change description/justification, the content of the change, and the parent revisions.\n\n[Immutable reference] There exists a way to indefinitely reference this particular, immutable revision. In git, this is the {repo URL + branch/tag/ref + commit ID}.\n\nMost popular version control system meet this requirement, such as git, Mercurial, Subversion, or Perforce.\n\nNOTE: This does NOT require that the code, uploader/reviewer identities, or change history be made public. Rather, some organization must attest to the fact that these requirements are met, and it is up to the consumer whether this attestation is sufficient.\n\n“○” = RECOMMENDED.",
    "L1": "○",
    "L2": "✓",
    "L3": "✓",
    "L4": "✓"
  },
  {
    "Requirement": "Verified history",
    "Description": "Every change in the revision’s history has at least one strongly authenticated actor identity (author, uploader, reviewer, etc.) and timestamp. It must be clear which identities were verified, and those identities must use two-step verification or similar. (Exceptions noted below.)\n\n[First-parent history] In the case of a non-linear version control system, where a revision can have more than one parent, only the “first parent history” is in scope. In other words, when a feature branch is merged back into the main branch, only the merge itself is in scope.\n[Historical cutoff] There is some TBD exception to allow existing projects to meet SLSA 3/4 even if historical revisions were present in the history. Current thinking is that this could be either last N months or a platform attestation guaranteeing that future changes in the next N months will meet the requirements.",
    "L1": "",
    "L2": "",
    "L3": "✓",
    "L4": "✓"
  },
  {
    "Requirement": "Retained indefinitely",
    "Description": "The revision and its change history are preserved indefinitely and cannot be deleted, except when subject to an established and transparent policy for obliteration, such as a legal or policy requirement.\n\n[Immutable history] It must not be possible for persons to delete or modify the history, even with multi-party approval, except by trusted platform admins with two-party approval following the obliterate policy.\n[Limited retention for SLSA 3] At SLSA 3 (but not 4), it is acceptable for the retention to be limited to 18 months, as attested by the source control platform.\nExample: If a commit is made on 2020-04-05 and then a retention attestation is generated on 2021-01-01, the commit must be retained until at least 2022-07-01.",
    "L1": "",
    "L2": "",
    "L3": "18 mo.",
    "L4": "✓"
  },
  {
    "Requirement": "Two-person reviewed",
    "Description": "Every change in the revision’s history was agreed to by two trusted persons prior to submission, and both of these trusted persons were strongly authenticated. (Exceptions from Verified History apply here as well.)\n\nThe following combinations are acceptable:\nUploader and reviewer are two different trusted persons.\nTwo different reviewers are trusted persons.\n[Different persons] The platform ensures that no person can use alternate identities to bypass the two-person review requirement.\nExample: if a person uploads with identity X then reviews with alias Y, the platform understands that this is the same person and does not consider the review requirement satisfied.\n[Informed review] The reviewer is able and encouraged to make an informed decision about what they’re approving. The reviewer should be presented with a full, meaningful content diff between the proposed revision and the previously reviewed revision. For example, it is not sufficient to just indicate that file changed without showing the contents.\n[Context-specific approvals] Approvals are for a specific context, such as a repo + branch in git. Moving fully reviewed content from one context to another still requires review. (Exact definition of “context” depends on the project, and this does not preclude well-understood automatic or reviewless merges, such as cutting a release branch.)\nGit example: If a fully reviewed commit in one repo is merged into a different repo, or a commit in one branch is merged into a different branch, then the merge still requires review.",
    "L1": "",
    "L2": "",
    "L3": "",
    "L4": "✓"
  }
]

[melba-lopez]

High Level SLSA Requirements

SLSA Mapping - Summary.csv

SLSA High Level requirements JSON file

[
  {
    "Requirement": "Source - Version controlled",
    "SLSA 1": "",
    "SLSA 2": "✓",
    "SLSA 3": "✓",
    "SLSA 4": "✓"
  },
  {
    "Requirement": "Source - Verified history",
    "SLSA 1": "",
    "SLSA 2": "",
    "SLSA 3": "✓",
    "SLSA 4": "✓"
  },
  {
    "Requirement": "Source - Retained indefinitely",
    "SLSA 1": "",
    "SLSA 2": "",
    "SLSA 3": "18 mo.",
    "SLSA 4": "✓"
  },
  {
    "Requirement": "Source - Two-person reviewed",
    "SLSA 1": "",
    "SLSA 2": "",
    "SLSA 3": "",
    "SLSA 4": "✓"
  },
  {
    "Requirement": "Build - Scripted build",
    "SLSA 1": "✓",
    "SLSA 2": "✓",
    "SLSA 3": "✓",
    "SLSA 4": "✓"
  },
  {
    "Requirement": "Build - Build service",
    "SLSA 1": "",
    "SLSA 2": "✓",
    "SLSA 3": "✓",
    "SLSA 4": "✓"
  },
  {
    "Requirement": "Build - Build as code",
    "SLSA 1": "",
    "SLSA 2": "",
    "SLSA 3": "✓",
    "SLSA 4": "✓"
  },
  {
    "Requirement": "Build - Ephemeral environment",
    "SLSA 1": "",
    "SLSA 2": "",
    "SLSA 3": "✓",
    "SLSA 4": "✓"
  },
  {
    "Requirement": "Build - Isolated",
    "SLSA 1": "",
    "SLSA 2": "",
    "SLSA 3": "✓",
    "SLSA 4": "✓"
  },
  {
    "Requirement": "Build - Parameterless",
    "SLSA 1": "",
    "SLSA 2": "",
    "SLSA 3": "",
    "SLSA 4": "✓"
  },
  {
    "Requirement": "Build - Hermetic",
    "SLSA 1": "",
    "SLSA 2": "",
    "SLSA 3": "",
    "SLSA 4": "✓"
  },
  {
    "Requirement": "Build - Reproducible",
    "SLSA 1": "",
    "SLSA 2": "",
    "SLSA 3": "",
    "SLSA 4": "○"
  },
  {
    "Requirement": "Provenance - Available",
    "SLSA 1": "✓",
    "SLSA 2": "✓",
    "SLSA 3": "✓",
    "SLSA 4": "✓"
  },
  {
    "Requirement": "Provenance - Authenticated",
    "SLSA 1": "",
    "SLSA 2": "✓",
    "SLSA 3": "✓",
    "SLSA 4": "✓"
  },
  {
    "Requirement": "Provenance - Service generated",
    "SLSA 1": "",
    "SLSA 2": "✓",
    "SLSA 3": "✓",
    "SLSA 4": "✓"
  },
  {
    "Requirement": "Provenance - Non-falsifiable",
    "SLSA 1": "",
    "SLSA 2": "",
    "SLSA 3": "✓",
    "SLSA 4": "✓"
  },
  {
    "Requirement": "Provenance - Dependencies complete",
    "SLSA 1": "",
    "SLSA 2": "",
    "SLSA 3": "",
    "SLSA 4": "✓"
  },
  {
    "Requirement": "Common - Security",
    "SLSA 1": "",
    "SLSA 2": "",
    "SLSA 3": "",
    "SLSA 4": "✓"
  },
  {
    "Requirement": "Common - Access",
    "SLSA 1": "",
    "SLSA 2": "",
    "SLSA 3": "",
    "SLSA 4": "✓"
  },
  {
    "Requirement": "Common - Superusers",
    "SLSA 1": "",
    "SLSA 2": "",
    "SLSA 3": "",
    "SLSA 4": "✓"
  }
]

[melba-lopez]

SLSA Build Requirements.(Fixed)

SLSA Mapping - Build.csv

SLSA Build Requirements JSON (Fixed)

[
  {
    "Requirement": "Scripted build",
    "Description": "All build steps were fully defined in some sort of “build script”. The only manual command, if any, was to invoke the build script.\n\nExamples:\n\nBuild script is Makefile, invoked via make all.\nBuild script is .github/workflows/build.yaml, invoked by GitHub Actions.",
    "L1": "✓",
    "L2": "✓",
    "L3": "✓",
    "L4": "✓"
  },
  {
    "Requirement": "Build service",
    "Description": "All build steps ran using some build service, not on a developer’s workstation.\n\nExamples: GitHub Actions, Google Cloud Build, Travis CI.",
    "L1": "",
    "L2": "✓",
    "L3": "✓",
    "L4": "✓"
  },
  {
    "Requirement": "Build as code",
    "Description": "The build definition and configuration executed by the build service is verifiably derived from text file definitions stored in a version control system.\n\nVerifiably derived can mean either fetched directly through a trusted channel, or that the derived definition has some trustworthy provenance chain linking back to version control.\n\nExamples:\n\n.github/workflows/build.yaml stored in git\nTekton bundles generated from text files by a SLSA compliant build process and stored in an OCI registry with SLSA provenance metadata available.",
    "L1": "",
    "L2": "",
    "L3": "✓",
    "L4": "✓"
  },
  {
    "Requirement": "Ephemeral environment",
    "Description": "The build service ensured that the build steps ran in an ephemeral environment, such as a container or VM, provisioned solely for this build, and not reused from a prior build.",
    "L1": "",
    "L2": "",
    "L3": "✓",
    "L4": "✓"
  },
  {
    "Requirement": "Isolated",
    "Description": "The build service ensured that the build steps ran in an isolated environment free of influence from other build instances, whether prior or concurrent.\n\nIt MUST NOT be possible for a build to access any secrets of the build service, such as the provenance signing key.\nIt MUST NOT be possible for two builds that overlap in time to influence one another.\nIt MUST NOT be possible for one build to persist or influence the build environment of a subsequent build.\nBuild caches, if used, MUST be purely content-addressable to prevent tampering.",
    "L1": "",
    "L2": "",
    "L3": "✓",
    "L4": "✓"
  },
  {
    "Requirement": "Parameterless",
    "Description": "The build output cannot be affected by user parameters other than the build entry point and the top-level source location. In other words, the build is fully defined through the build script and nothing else.\n\nExamples:\n\nGitHub Actions workflow_dispatch inputs MUST be empty.\nGoogle Cloud Build user-defined substitutions MUST be empty. (Default substitutions, whose values are defined by the server, are acceptable.)",
    "L1": "",
    "L2": "",
    "L3": "",
    "L4": "✓"
  },
  {
    "Requirement": "Hermetic",
    "Description": "All transitive build steps, sources, and dependencies were fully declared up front with immutable references, and the build steps ran with no network access.\n\nThe user-defined build script:\n\nMUST declare all dependencies, including sources and other build steps, using immutable references in a format that the build service understands.\nThe build service:\n\nMUST fetch all artifacts in a trusted control plane.\nMUST NOT allow mutable references.\nMUST verify the integrity of each artifact.\nIf the immutable reference includes a cryptographic hash, the service MUST verify the hash and reject the fetch if the verification fails.\nOtherwise, the service MUST fetch the artifact over a channel that ensures transport integrity, such as TLS or code signing.\nMUST prevent network access while running the build steps.\nThis requirement is “best effort.” It SHOULD deter a reasonable team from having a non-hermetic build, but it need not stop a determined adversary. For example, using a container to prevent network access is sufficient.",
    "L1": "",
    "L2": "",
    "L3": "",
    "L4": "✓"
  },
  {
    "Requirement": "Reproducible",
    "Description": "Re-running the build steps with identical input artifacts results in bit-for-bit identical output. Builds that cannot meet this MUST provide a justification why the build cannot be made reproducible.\n\n“○” means that this requirement is “best effort”. The user-provided build script SHOULD declare whether the build is intended to be reproducible or a justification why not. The build service MAY blindly propagate this intent without verifying reproducibility. A consumer MAY reject the build if it does not reproduce.",
    "L1": "",
    "L2": "",
    "L3": "",
    "L4": "○"
  }
]

[melba-lopez]

SLSA Provenance Requirements

SLSA Mapping - Provenance.csv

SLSA Mapping - Provenance JSON

[
  {
    "Requirement": "Available",
    "Description": "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.",
    "L1": "✓",
    "L2": "✓",
    "L3": "✓",
    "L4": "✓"
  },
  {
    "Requirement": "Authenticated",
    "Description": "The provenance’s authenticity and integrity can be verified by the consumer. This SHOULD be through a digital signature from a private key accessible only to the service generating the provenance.",
    "L1": "",
    "L2": "✓",
    "L3": "✓",
    "L4": "✓"
  },
  {
    "Requirement": "Service generated",
    "Description": "The data in the provenance MUST be obtained from the build service (either because the generator is the build service or because the provenance generator reads the data directly from the build service).\n\nRegular users of the service MUST NOT be able to inject or alter the contents, except as noted below.\n\nThe following provenance fields MAY be generated by the user-controlled build steps:\n\nThe output artifact hash from Identifies Artifact.\nReasoning: This only allows a “bad” build to falsely claim that it produced a “good” artifact. This is not a security problem because the consumer MUST accept only “good” builds and reject “bad” builds.\nThe “reproducible” boolean and justification from Reproducible.",
    "L1": "",
    "L2": "✓",
    "L3": "✓",
    "L4": "✓"
  },
  {
    "Requirement": "Non-falsifiable",
    "Description": "Provenance cannot be falsified by the build service’s users.\n\nNOTE: This requirement is a stricter version of Service Generated.\n\nAny secret material used to demonstrate the non-falsifiable nature of the provenance, for example the signing key used to generate a digital signature, MUST be stored in a secure management system appropriate for such material and accessible only to the build service account.\nSuch secret material MUST NOT be accessible to the environment running the user-defined build steps.\nEvery field in the provenance MUST be generated or verified by the build service in a trusted control plane. The user-controlled build steps MUST NOT be able to inject or alter the contents, except as noted below.\nThe following provenance fields MAY be generated by the user-controlled build steps without the build service verifying their correctness:\n\nThe output artifact hash from Identifies Artifact.\nReasoning: This only allows a “bad” build to falsely claim that it produced a “good” artifact. This is not a security problem because the consumer MUST accept only “good” builds and reject “bad” builds.\nThe “reproducible” boolean and justification from Reproducible.",
    "L1": "",
    "L2": "",
    "L3": "✓",
    "L4": "✓"
  },
  {
    "Requirement": "Dependencies complete",
    "Description": "Provenance records all build dependencies that were available while running the build steps. This includes the initial state of the machine, VM, or container of the build worker.\n\nMUST include all user-specified build steps, sources, dependencies.\nSHOULD include all service-provided artifacts.",
    "L1": "",
    "L2": "",
    "L3": "",
    "L4": "✓"
  }
]

[melba-lopez]

SLSA Mapping - CONTENTS of Provenance

SLSA Mapping - Contents of Provenance.csv

SLSA Mapping - Contents of Provenance JSON

[
  {
    "Requirement": "Identifies artifact",
    "Description": "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.",
    "L1": "✓",
    "L2": "✓",
    "L3": "✓",
    "L4": "✓"
  },
  {
    "Requirement": "Identifies builder",
    "Description": "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”.",
    "L1": "✓",
    "L2": "✓",
    "L3": "✓",
    "L4": "✓"
  },
  {
    "Requirement": "Identifies build instructions",
    "Description": "The provenance identifies the top-level instructions used to execute the build.\n\nThe 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).\n\nIf build-as-code is used, this SHOULD be the source repo and entry point of the build config (as in the GitHub Actions example).\n\nIf 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).",
    "L1": "✓",
    "L2": "✓",
    "L3": "✓",
    "L4": "✓"
  },
  {
    "Requirement": "Identifies source code",
    "Description": "The provenance identifies the repository origin(s) for the source code used in the build.\n\nThe identified repositories SHOULD only include source used directly in the build. The source of dependencies SHOULD NOT be included.\n\nAt level 2 this information MAY come from users and DOES NOT need to be authenticated by the builder.\n\nAt level 3+ this information MUST be authenticated by the builder (i.e. the builder either needs to have fetched the source itself or observed the fetch).\n\nAt level 4 this information MUST be complete (i.e. all source repositories used in the build are listed).",
    "L1": "",
    "L2": "✓",
    "L3": "✓ (Authenticated)",
    "L4": "✓ (Complete)"
  },
  {
    "Requirement": "Identifies entry point",
    "Description": "The provenance identifies the “entry point” of the build definition (see build-as-code) used to drive the build including what source repo the configuration was read from.\n\nExample:\n\nsource repo: git URL + branch/tag/ref + commit ID\nentrypoint: path to config file(s) (e.g. ./.zuul.yaml) + job name within config (e.g. envoy-build-arm64)",
    "L1": "",
    "L2": "",
    "L3": "✓",
    "L4": "✓"
  },
  {
    "Requirement": "Includes all build parameters",
    "Description": "The provenance includes all build parameters under a user’s control. See Parameterless for details. (At L3, the parameters must be listed; at L4, they must be empty.)",
    "L1": "",
    "L2": "",
    "L3": "✓",
    "L4": "✓"
  },
  {
    "Requirement": "Includes all transitive dependencies",
    "Description": "The provenance includes all transitive dependencies listed in Dependencies Complete.",
    "L1": "",
    "L2": "",
    "L3": "",
    "L4": "✓"
  },
  {
    "Requirement": "Includes reproducible info",
    "Description": "The provenance includes a boolean indicating whether build is intended to be reproducible and, if so, all information necessary to reproduce the build. See Reproducible for more details.",
    "L1": "",
    "L2": "",
    "L3": "",
    "L4": "✓"
  },
  {
    "Requirement": "Includes metadata",
    "Description": "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.\n\n“○” = RECOMMENDED.",
    "L1": "○",
    "L2": "○",
    "L3": "○",
    "L4": "○"
  }
]

[melba-lopez]

SLSA Mapping - COMMON Requirements

SLSA Mapping - Common Requirements.csv

SLSA Mapping - COMMON Requirements JSON

[
  {
    "Requirement": "Security",
    "Description": "The system meets some TBD baseline security standard to prevent compromise. (Patching, vulnerability scanning, user isolation, transport security, secure boot, machine identity, etc. Perhaps NIST 800-53 or a subset thereof.)",
    "L1": "",
    "L2": "",
    "L3": "",
    "L4": "✓"
  },
  {
    "Requirement": "Access",
    "Description": "All physical and remote access must be rare, logged, and gated behind multi-party approval.",
    "L1": "",
    "L2": "",
    "L3": "",
    "L4": "✓"
  },
  {
    "Requirement": "Superusers",
    "Description": "Only a small number of platform admins may override the guarantees listed here. Doing so MUST require approval of a second platform admin.",
    "L1": "",
    "L2": "",
    "L3": "",
    "L4": "✓"
  }
]

[melba-lopez]

@mlieberman85

Is this what we need to move forward with the OSCAL implementation??

[mlieberman85]

Perhaps. I need to read up on the OSCAL spec. The spec itself is a little different. This is useful generally, probably just want to change some of this to true/false or yes, no, optional. Let me take a closer look.

[MarkLodato]

To clarify, is this about verifying that a system meets the SLSA requirements as per #508? Would this essentially be the "evidence of security claims" from the SLSA v1.0 proposal?

[kpk47]

I think this issue was made obsolete by the build system compliance program. Feel free to reopen.