From 78d2e1fd2aadc3c31d83d0ed2a074f070bf1028e Mon Sep 17 00:00:00 2001 From: Ralph Bean Date: Thu, 9 Oct 2025 11:39:09 -0400 Subject: [PATCH 1/7] ADR on SLSA source provenance verification --- ...###-slsa-source-provenance-verification.md | 132 ++++++++++++++++++ 1 file changed, 132 insertions(+) create mode 100644 ADR/####-slsa-source-provenance-verification.md diff --git a/ADR/####-slsa-source-provenance-verification.md b/ADR/####-slsa-source-provenance-verification.md new file mode 100644 index 00000000..4bbf1ac6 --- /dev/null +++ b/ADR/####-slsa-source-provenance-verification.md @@ -0,0 +1,132 @@ +# ####. SLSA Source Provenance Verification + +Date: 2025-10-09 + +## Status + +Proposed + +## Context + +Konflux's trust model is organized entirely around SLSA build provenance. Build provenance attestations, generated by Tekton Chains and stored alongside container images in OCI registries, form the foundation of our verification and release policies in Enterprise Contract/Conforma. This approach follows the SLSA principle of storing attestations close to the artifacts they describe. + +The SLSA specification includes a parallel track - the Source Track - which provides increasing levels of trust in source code by verifying source control system practices. The source track addresses threats like unauthorized source modifications, bypassed code reviews, and compromised version control systems. Just as build attestations are stored alongside the artifacts they describe (container images in OCI registries), the SLSA community proposes storing source verification summary attestations (VSAs) as git notes in source repositories, keeping attestations close to the source commits they verify. + +However, Konflux's build-provenance-centered architecture prompts a question: **How should we verify and incorporate source provenance into our existing trust model?** + +Some different approaches are possible: + +1. **Direct reference**: Include source provenance attestations directly in build provenance +2. **Parallel verification**: Verify source provenance independently alongside build provenance +3. **Chained attestations**: Create build provenance attestations about source provenance attestations + +The challenge is that the source track's storage model (git notes in repositories) differs significantly from our build artifact storage model (OCI registries), making it non-obvious how to integrate source provenance verification into our existing Conforma policies and attestation chains. + +### References + +- [SLSA Source Track Requirements](https://slsa.dev/spec/draft/source-requirements) - Source provenance specification +- [SLSA Verification Summary Attestations](https://slsa.dev/spec/draft/verification_summary) - VSA format specification +- [ADR 48: Movable Build Tests](0048-movable-build-tests.md) - Pattern for independent verification tasks +- [ADR 49: VSA Support](0049-vsa-support.md) - Trusting VSAs for externally-built artifacts +- [ADR 36: Trusted Artifacts](0036-trusted-artifacts.md) - OCI storage patterns for artifacts +- [ADR 20: Source Retention](0020-source-retention.md) - Existing source requirements + +## Decision + +We will verify SLSA source provenance through a **chained attestation** approach that leverages the movable test pattern from [ADR 48](0048-movable-build-tests.md). + +### Verification Workflow + +1. **Source VSA generation** (external to Konflux): + - Source repository maintainers configure automation (GitHub Actions, GitLab CI/CD pipelines, etc.) to generate source VSAs + - These VSAs are stored as git notes in the source repository, contemporaneously with commits + - VSAs attest to source control practices (e.g., two-person review, branch protection, audit logs) + +2. **Source provenance verification task** (in Konflux pipeline): + - A Konflux pipeline task reads the source VSA from git notes for the cloned commit + - The task accepts a public key parameter (provided via IntegrationTestScenario configuration) and verifies the source VSA signature against that key + - The task verifies the VSA contents (format, subject matching the commit, etc.) + - The task pushes the source VSA to the OCI registry as a separate artifact + - The task exposes the pullspec of the OCI representation of the VSA (digest reference) in its task results using `*_ARTIFACT_OUTPUTS` format + - The task records the public key used for verification in its results + +3. **Build provenance chain** (via Tekton Chains): + - Tekton Chains observes the task results containing the source VSA artifact reference + - Chains generates and signs a SLSA build provenance attestation **about** the source provenance attestation + - This creates an attestation chain: `Build Provenance → Source VSA → Source Commit` + +4. **Verification in Conforma**: + - Conforma policies can verify source provenance by checking for the presence of the attestation chain + - Conforma trusts Tekton Chains' signatures (existing trust root) + - Conforma reads the public key from the test attestation (recorded by the verification task) and verifies it matches the expected signer identity for the source repository + - Through the chain, Conforma gains transitive trust in the source VSA's signature verification (performed by the task) without needing to re-verify the signature itself + - This bootstraps trust in source provenance through our existing build-provenance infrastructure + +### Rationale + +This approach provides several advantages: + +- **Preserves existing trust model**: Conforma continues to trust Tekton Chains as its primary attestation source +- **Leverages ADR 48**: Using the movable test pattern makes source verification easier to re-run independently of builds +- **Enables gradual adoption**: Teams can adopt source provenance incrementally without breaking existing workflows + +### Integration Points + +- **Verification task**: New task to read, verify, and republish source VSAs to OCI registry +- **Tekton Chains**: Existing Chains infrastructure generates attestations about the verification task +- **Enterprise Contract**: Conforma policies updated to verify the attestation chain +- **Trusted Artifacts** ([ADR 36](0036-trusted-artifacts.md)): Source VSA artifacts follow the similar OCI storage patterns to other trusted artifacts + +## Consequences + +### Positive + +- **Consistent trust model**: All Conforma verification continues through Tekton Chains attestations +- **Independent verification**: Source provenance can be verified as a separate pipeline task, not embedded in build pipeline +- **Easier re-runs**: Leveraging ADR 48's movable test pattern allows re-running source verification without rebuilding +- **Gradual adoption**: Teams can enable source provenance verification incrementally +- **Complements ADR 49**: Where [ADR 49](0049-vsa-support.md) trusts external VSAs to verify externally-built artifacts for release, this ADR detects and reports source VSAs (generated by external systems) for Konflux-built artifacts + +### Negative + +- **Race condition risk**: Source VSAs should be generated contemporaneously with commits (typically via GitHub Actions or GitLab pipelines), but Konflux's verification task may execute before the external automation completes. This can cause initial verification failures when: + - A commit is pushed to a repository + - Konflux immediately triggers a build pipeline + - The source VSA generation (GitHub Action/GitLab pipeline) is still running + - The verification task attempts to read git notes that don't exist yet + + **Mitigation**: The movable test pattern from ADR 48 significantly helps with this issue. Because source verification runs as an independent integration test scenario rather than an embedded build task, it can be easily re-run once the source VSA is available. This is much easier than if the verification were embedded in the build pipeline, which would require a complete rebuild. + +- **Additional task required**: New verification task must be implemented and maintained (poc in [konflux-ci/build-definitions#2867](https://github.com/konflux-ci/build-definitions/pull/2867)) +- **OCI storage overhead**: Source VSAs are duplicated (git notes + OCI registry) +- **Complexity in Conforma**: Policies must understand attestation chains rather than direct attestations +- **External dependencies**: Requires source repository owners to set up VSA generation automation + +### Implementation Requirements + +1. **New Tekton task**: Implement `verify-source` source provenance verification task that: + - Accepts a public key parameter (configured via IntegrationTestScenario) + - Fetches git notes from cloned repositories + - Verifies source VSA signatures against the provided public key + - Verifies source VSA contents (format, subject, etc.) + - Pushes VSAs to OCI registry + - Exposes pullspec in `*_ARTIFACT_OUTPUTS` results format + - Records the public key used for verification in task results + +2. **Conforma policy updates**: Update Enterprise Contract policies to: + - Detect source provenance attestation chains + - Verify build provenance attestations about source VSAs + - Read the public key from test attestations and verify it matches expected signer identities for source repositories + - Determine if source verification levels meet release requirements + +3. **Documentation for source repository owners**: + - How to generate source VSAs (GitHub Actions, GitLab CI templates) + - How to store VSAs as git notes + - What source verification levels mean + +4. **ITS Provisioning**: Update Konflux onboarding mechanisms to provision a source verification ITS automatically + +### Future Considerations + +- **Standard VSA format**: As SLSA source track specifications stabilize, we may need to update VSA formats +- **Multiple source systems**: Different source control systems (GitHub, GitLab, Gitea) may need special support. From 3ae2a7e8ca85a2cbaea64c37752232086c92a469 Mon Sep 17 00:00:00 2001 From: Ralph Bean Date: Tue, 28 Oct 2025 13:26:02 -0400 Subject: [PATCH 2/7] Remove redundant public key recording in task results MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The verification task already captures the public key as a task parameter, which is included in the build attestation by Tekton Chains. Recording it again in task results is redundant. Updates three references: - Removes bullet point about recording public key in results from verification workflow section - Clarifies Conforma reads public key from task parameters, not results - Removes duplicate line from implementation requirements section Addresses review feedback from chmeliik in PR #268. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Signed-off-by: Ralph Bean --- ADR/####-slsa-source-provenance-verification.md | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/ADR/####-slsa-source-provenance-verification.md b/ADR/####-slsa-source-provenance-verification.md index 4bbf1ac6..511bee1d 100644 --- a/ADR/####-slsa-source-provenance-verification.md +++ b/ADR/####-slsa-source-provenance-verification.md @@ -48,7 +48,6 @@ We will verify SLSA source provenance through a **chained attestation** approach - The task verifies the VSA contents (format, subject matching the commit, etc.) - The task pushes the source VSA to the OCI registry as a separate artifact - The task exposes the pullspec of the OCI representation of the VSA (digest reference) in its task results using `*_ARTIFACT_OUTPUTS` format - - The task records the public key used for verification in its results 3. **Build provenance chain** (via Tekton Chains): - Tekton Chains observes the task results containing the source VSA artifact reference @@ -58,7 +57,7 @@ We will verify SLSA source provenance through a **chained attestation** approach 4. **Verification in Conforma**: - Conforma policies can verify source provenance by checking for the presence of the attestation chain - Conforma trusts Tekton Chains' signatures (existing trust root) - - Conforma reads the public key from the test attestation (recorded by the verification task) and verifies it matches the expected signer identity for the source repository + - Conforma reads the public key from the test attestation's task parameters and verifies it matches the expected signer identity for the source repository - Through the chain, Conforma gains transitive trust in the source VSA's signature verification (performed by the task) without needing to re-verify the signature itself - This bootstraps trust in source provenance through our existing build-provenance infrastructure @@ -111,12 +110,11 @@ This approach provides several advantages: - Verifies source VSA contents (format, subject, etc.) - Pushes VSAs to OCI registry - Exposes pullspec in `*_ARTIFACT_OUTPUTS` results format - - Records the public key used for verification in task results 2. **Conforma policy updates**: Update Enterprise Contract policies to: - Detect source provenance attestation chains - Verify build provenance attestations about source VSAs - - Read the public key from test attestations and verify it matches expected signer identities for source repositories + - Read the public key from test attestation task parameters and verify it matches expected signer identities for source repositories - Determine if source verification levels meet release requirements 3. **Documentation for source repository owners**: From 547e4a18aa1547cb7216c599641c10b0bcd7eaa4 Mon Sep 17 00:00:00 2001 From: Ralph Bean Date: Fri, 31 Oct 2025 13:35:56 -0400 Subject: [PATCH 3/7] Address review comments from arewm on PR #268 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Updates based on code review feedback: 1. Clarify that Conforma reads the public key from the provenance attestation of the verification task (which includes task parameters) 2. Add explicit mention that Conforma verifies trust in the source verification task itself using Trusted Tasks mechanisms (ADR 53) 3. Specify that the verification task will be maintained in build-definitions with possibility of future relocation 4. Remove "OCI storage overhead" from negative consequences as the duplication provides desirable availability/reliability benefits 5. Clarify ITS provisioning is a capability for deployments that choose to adopt source provenance verification, not a mandatory global rollout 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Signed-off-by: Ralph Bean --- ADR/####-slsa-source-provenance-verification.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/ADR/####-slsa-source-provenance-verification.md b/ADR/####-slsa-source-provenance-verification.md index 511bee1d..c5150aa4 100644 --- a/ADR/####-slsa-source-provenance-verification.md +++ b/ADR/####-slsa-source-provenance-verification.md @@ -57,7 +57,8 @@ We will verify SLSA source provenance through a **chained attestation** approach 4. **Verification in Conforma**: - Conforma policies can verify source provenance by checking for the presence of the attestation chain - Conforma trusts Tekton Chains' signatures (existing trust root) - - Conforma reads the public key from the test attestation's task parameters and verifies it matches the expected signer identity for the source repository + - Conforma verifies trust in the source verification task itself using the Trusted Tasks mechanisms described in [ADR 53](0053-trusted-task-model.md) + - Conforma reads the public key from the provenance attestation of the verification task (which includes the task parameters) and verifies it matches the expected signer identity for the source repository - Through the chain, Conforma gains transitive trust in the source VSA's signature verification (performed by the task) without needing to re-verify the signature itself - This bootstraps trust in source provenance through our existing build-provenance infrastructure @@ -96,8 +97,7 @@ This approach provides several advantages: **Mitigation**: The movable test pattern from ADR 48 significantly helps with this issue. Because source verification runs as an independent integration test scenario rather than an embedded build task, it can be easily re-run once the source VSA is available. This is much easier than if the verification were embedded in the build pipeline, which would require a complete rebuild. -- **Additional task required**: New verification task must be implemented and maintained (poc in [konflux-ci/build-definitions#2867](https://github.com/konflux-ci/build-definitions/pull/2867)) -- **OCI storage overhead**: Source VSAs are duplicated (git notes + OCI registry) +- **Additional task required**: New verification task must be implemented and maintained in [konflux-ci/build-definitions](https://github.com/konflux-ci/build-definitions) (poc in [#2867](https://github.com/konflux-ci/build-definitions/pull/2867)); may be relocated to a different repository in the future - **Complexity in Conforma**: Policies must understand attestation chains rather than direct attestations - **External dependencies**: Requires source repository owners to set up VSA generation automation @@ -122,7 +122,7 @@ This approach provides several advantages: - How to store VSAs as git notes - What source verification levels mean -4. **ITS Provisioning**: Update Konflux onboarding mechanisms to provision a source verification ITS automatically +4. **ITS Provisioning**: Konflux deployments that want to adopt source provenance verification across their instance can update their onboarding mechanisms to provision a source verification ITS automatically ### Future Considerations From b8c1085bcada20cfcaadd3cceadad2eb40f52d14 Mon Sep 17 00:00:00 2001 From: Ralph Bean Date: Fri, 31 Oct 2025 13:51:55 -0400 Subject: [PATCH 4/7] Address additional review comments from arewm on PR #268 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Updates based on second round of review feedback: 1. Clarify relationship between Build Track and Source Track in Context section, providing better foundation for discussing source provenance 2. Specify OCI storage mechanism: task uses OCI referrers API (via oras attach) with container image as subject of OCI reference (git commit remains subject within VSA payload) 3. Note that Conforma supports both tag-based and referrers-based attestation storage mechanisms 4. Expand trust model explanation to include reliance on Trusted Tasks mechanisms for verifying task provenance 5. Add timing consideration as race condition mitigation: typical workflows have builds taking longer than VSA generation, reducing likelihood of unfavorable race condition outcomes 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Signed-off-by: Ralph Bean --- ADR/####-slsa-source-provenance-verification.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/ADR/####-slsa-source-provenance-verification.md b/ADR/####-slsa-source-provenance-verification.md index c5150aa4..a68fb719 100644 --- a/ADR/####-slsa-source-provenance-verification.md +++ b/ADR/####-slsa-source-provenance-verification.md @@ -10,7 +10,7 @@ Proposed Konflux's trust model is organized entirely around SLSA build provenance. Build provenance attestations, generated by Tekton Chains and stored alongside container images in OCI registries, form the foundation of our verification and release policies in Enterprise Contract/Conforma. This approach follows the SLSA principle of storing attestations close to the artifacts they describe. -The SLSA specification includes a parallel track - the Source Track - which provides increasing levels of trust in source code by verifying source control system practices. The source track addresses threats like unauthorized source modifications, bypassed code reviews, and compromised version control systems. Just as build attestations are stored alongside the artifacts they describe (container images in OCI registries), the SLSA community proposes storing source verification summary attestations (VSAs) as git notes in source repositories, keeping attestations close to the source commits they verify. +The SLSA specification includes multiple tracks for establishing trust at different stages of the software supply chain. While Konflux uses the Build Track to establish trust through build provenance, the Source Track provides increasing levels of trust in source code by verifying source control system practices. The source track addresses threats like unauthorized source modifications, bypassed code reviews, and compromised version control systems. Just as build attestations are stored alongside the artifacts they describe (container images in OCI registries), the SLSA community proposes storing source verification summary attestations (VSAs) as git notes in source repositories, keeping attestations close to the source commits they verify. However, Konflux's build-provenance-centered architecture prompts a question: **How should we verify and incorporate source provenance into our existing trust model?** @@ -46,7 +46,7 @@ We will verify SLSA source provenance through a **chained attestation** approach - A Konflux pipeline task reads the source VSA from git notes for the cloned commit - The task accepts a public key parameter (provided via IntegrationTestScenario configuration) and verifies the source VSA signature against that key - The task verifies the VSA contents (format, subject matching the commit, etc.) - - The task pushes the source VSA to the OCI registry as a separate artifact + - The task pushes the source VSA to the OCI registry as a separate artifact (manifest) using the OCI referrers API (via `oras attach`), with the container image as the subject of the OCI reference (the git commit remains the subject within the VSA payload itself) - The task exposes the pullspec of the OCI representation of the VSA (digest reference) in its task results using `*_ARTIFACT_OUTPUTS` format 3. **Build provenance chain** (via Tekton Chains): @@ -55,7 +55,7 @@ We will verify SLSA source provenance through a **chained attestation** approach - This creates an attestation chain: `Build Provenance → Source VSA → Source Commit` 4. **Verification in Conforma**: - - Conforma policies can verify source provenance by checking for the presence of the attestation chain + - Conforma policies can verify source provenance by checking for the presence of the attestation chain (supporting both tag-based and referrers-based attestation storage) - Conforma trusts Tekton Chains' signatures (existing trust root) - Conforma verifies trust in the source verification task itself using the Trusted Tasks mechanisms described in [ADR 53](0053-trusted-task-model.md) - Conforma reads the public key from the provenance attestation of the verification task (which includes the task parameters) and verifies it matches the expected signer identity for the source repository @@ -66,7 +66,7 @@ We will verify SLSA source provenance through a **chained attestation** approach This approach provides several advantages: -- **Preserves existing trust model**: Conforma continues to trust Tekton Chains as its primary attestation source +- **Preserves existing trust model**: Conforma continues to trust Tekton Chains as its primary attestation source and relies on Trusted Tasks mechanisms for verifying task provenance - **Leverages ADR 48**: Using the movable test pattern makes source verification easier to re-run independently of builds - **Enables gradual adoption**: Teams can adopt source provenance incrementally without breaking existing workflows @@ -95,7 +95,7 @@ This approach provides several advantages: - The source VSA generation (GitHub Action/GitLab pipeline) is still running - The verification task attempts to read git notes that don't exist yet - **Mitigation**: The movable test pattern from ADR 48 significantly helps with this issue. Because source verification runs as an independent integration test scenario rather than an embedded build task, it can be easily re-run once the source VSA is available. This is much easier than if the verification were embedded in the build pipeline, which would require a complete rebuild. + **Mitigation**: The movable test pattern from ADR 48 significantly helps with this issue. Because source verification runs as an independent integration test scenario rather than an embedded build task, it can be easily re-run once the source VSA is available. This is much easier than if the verification were embedded in the build pipeline, which would require a complete rebuild. Additionally, in typical workflows the artifact build takes longer to complete than source VSA generation, reducing the likelihood of the race condition producing an unfavorable result in practice. - **Additional task required**: New verification task must be implemented and maintained in [konflux-ci/build-definitions](https://github.com/konflux-ci/build-definitions) (poc in [#2867](https://github.com/konflux-ci/build-definitions/pull/2867)); may be relocated to a different repository in the future - **Complexity in Conforma**: Policies must understand attestation chains rather than direct attestations From 05320d4be7f4c0b601173dcf2cf02d265f4d6b88 Mon Sep 17 00:00:00 2001 From: Ralph Bean Date: Fri, 31 Oct 2025 14:13:02 -0400 Subject: [PATCH 5/7] Clarify relevance of source-tool Signed-off-by: Ralph Bean --- ADR/####-slsa-source-provenance-verification.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ADR/####-slsa-source-provenance-verification.md b/ADR/####-slsa-source-provenance-verification.md index a68fb719..48bdfa2c 100644 --- a/ADR/####-slsa-source-provenance-verification.md +++ b/ADR/####-slsa-source-provenance-verification.md @@ -10,7 +10,7 @@ Proposed Konflux's trust model is organized entirely around SLSA build provenance. Build provenance attestations, generated by Tekton Chains and stored alongside container images in OCI registries, form the foundation of our verification and release policies in Enterprise Contract/Conforma. This approach follows the SLSA principle of storing attestations close to the artifacts they describe. -The SLSA specification includes multiple tracks for establishing trust at different stages of the software supply chain. While Konflux uses the Build Track to establish trust through build provenance, the Source Track provides increasing levels of trust in source code by verifying source control system practices. The source track addresses threats like unauthorized source modifications, bypassed code reviews, and compromised version control systems. Just as build attestations are stored alongside the artifacts they describe (container images in OCI registries), the SLSA community proposes storing source verification summary attestations (VSAs) as git notes in source repositories, keeping attestations close to the source commits they verify. +The SLSA specification includes multiple tracks for establishing trust at different stages of the software supply chain. While Konflux uses the Build Track to establish trust through build provenance, the Source Track provides increasing levels of trust in source code by verifying source control system practices. The source track addresses threats like unauthorized source modifications, bypassed code reviews, and compromised version control systems. Just as build provenance attestations are stored alongside the artifacts they describe (container images in OCI registries), the SLSA community has created a tool to store source verification summary attestations (VSAs) as git notes in source repositories, keeping attestations close to the source commits they verify. However, Konflux's build-provenance-centered architecture prompts a question: **How should we verify and incorporate source provenance into our existing trust model?** From 6c18bb30c6efa5c3fbfd4b7fce8d1a8edfef8c14 Mon Sep 17 00:00:00 2001 From: Ralph Bean Date: Fri, 31 Oct 2025 14:24:05 -0400 Subject: [PATCH 6/7] The tag-based fallback is unsupportable here After discussion,we learned that the tag-based fallback is unsupportable here. --- ADR/####-slsa-source-provenance-verification.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ADR/####-slsa-source-provenance-verification.md b/ADR/####-slsa-source-provenance-verification.md index 48bdfa2c..73b7fd7a 100644 --- a/ADR/####-slsa-source-provenance-verification.md +++ b/ADR/####-slsa-source-provenance-verification.md @@ -55,7 +55,7 @@ We will verify SLSA source provenance through a **chained attestation** approach - This creates an attestation chain: `Build Provenance → Source VSA → Source Commit` 4. **Verification in Conforma**: - - Conforma policies can verify source provenance by checking for the presence of the attestation chain (supporting both tag-based and referrers-based attestation storage) + - Conforma policies can verify source provenance by checking for the presence of the attestation chain (using the referrers-based attestation storage) - Conforma trusts Tekton Chains' signatures (existing trust root) - Conforma verifies trust in the source verification task itself using the Trusted Tasks mechanisms described in [ADR 53](0053-trusted-task-model.md) - Conforma reads the public key from the provenance attestation of the verification task (which includes the task parameters) and verifies it matches the expected signer identity for the source repository From bfedfd3fb7d4125cf07991ed6f1343457637a9d0 Mon Sep 17 00:00:00 2001 From: Ralph Bean Date: Fri, 31 Oct 2025 14:38:33 -0400 Subject: [PATCH 7/7] Note signer identity ambiguity --- ADR/####-slsa-source-provenance-verification.md | 1 + 1 file changed, 1 insertion(+) diff --git a/ADR/####-slsa-source-provenance-verification.md b/ADR/####-slsa-source-provenance-verification.md index 73b7fd7a..4c3def83 100644 --- a/ADR/####-slsa-source-provenance-verification.md +++ b/ADR/####-slsa-source-provenance-verification.md @@ -126,5 +126,6 @@ This approach provides several advantages: ### Future Considerations +- **Expected Signer Identities**: We may need to think more deeply about how to efficiently configure the expected signer identities at scale. - **Standard VSA format**: As SLSA source track specifications stabilize, we may need to update VSA formats - **Multiple source systems**: Different source control systems (GitHub, GitLab, Gitea) may need special support.