From 8a9b40250987c7d7a4bb119d672007cfb825e1de Mon Sep 17 00:00:00 2001 From: Zachariah Cox Date: Mon, 30 Sep 2024 14:57:47 -0400 Subject: [PATCH 01/14] delete open issues, rename SCP to SCS, adjust copy where needed to make that work --- docs/spec/draft/source-requirements.md | 53 ++++++++++---------------- docs/spec/draft/verifying-source.md | 4 +- 2 files changed, 23 insertions(+), 34 deletions(-) diff --git a/docs/spec/draft/source-requirements.md b/docs/spec/draft/source-requirements.md index 89178bacc..360b5e0a0 100644 --- a/docs/spec/draft/source-requirements.md +++ b/docs/spec/draft/source-requirements.md @@ -3,18 +3,7 @@ ## Outstanding TODOs Open issues are tracked with the [source-track](https://github.com/slsa-framework/slsa/issues?q=is%3Aissue+is%3Aopen+label%3Asource-track) label in the [slsa-framework/slsa](https://github.com/slsa-framework/slsa) repository. - -- [] [Structure & formatting don't match the build track](https://github.com/slsa-framework/slsa/issues/1069) -- [] [Either identify the unique value of L1 or merge it with L2](https://github.com/slsa-framework/slsa/issues/1070) -- [] [How to communicate SLSA source track metadata?](https://github.com/slsa-framework/slsa/issues/1071) -- [] [Clarify source track objective](https://github.com/slsa-framework/slsa/issues/1072) -- [] [Clarify the 'merger' identity in source track](https://github.com/slsa-framework/slsa/issues/1074) -- [] [Flesh out the definition and bounds of 'identity', and why they're required](https://github.com/slsa-framework/slsa/issues/1075) -- [] [VCS and SCP concerns are mixed or too prescriptive](https://github.com/slsa-framework/slsa/issues/1076) -- [] [Clarify that self-hosted SCPs are allowed](https://github.com/slsa-framework/slsa/issues/1077) -- [] [Create guidance for consumers on how to evaluate the source platform](https://github.com/slsa-framework/slsa/issues/1078) -- [] [Clarify what must be retained during source migrations](https://github.com/slsa-framework/slsa/issues/1079) -- [] [Refine requirements/guidance for trusted robots](https://github.com/slsa-framework/slsa/issues/1080) +Source Track issues are triaged on the [SLSA Source Track](https://github.com/orgs/slsa-framework/projects/5) project board. ## Objective @@ -31,17 +20,17 @@ Consumers can examine the various source provenance attestations to determine if | Term | Description | --- | --- | Source | An identifiable set of text and binary files and associated metadata. Source is regularly used as input to a build system (see [SLSA Build Track](requirements.md)). +| Organization | A collection of people who collectively create the Source. Examples of organizations include open-source projects, a company, or a team within a company. The organization defines the goals and methods of the source. | Version Control System (VCS)| Software for tracking and managing changes to source. Git and Subversion are examples of version control systems. | Revision | A specific state of the source with an identifier provided by the version control system. As an example, you can identify a git revision by its tree hash. -| Source Control Platform (SCP) | A service or suite of services (self-hosted or SaaS) for hosting version-controlled software. GitHub and GitLab are examples of source control platforms, as are combinations of tools like Gerrit code reviews with GitHub source control. -| Source Provenance | Information about which Source Control Platform (SCP) produced a revision, when it was generated, what process was used, who the contributors were, and what parent revisions it was based on. -| Organization | A collection of people who collectively create the Source. Examples of organizations include open-source projects, a company, or a team within a company. The organization defines the goals and methods of the repository. -| Repository / Repo | A uniquely identifiable instance of a VCS hosted on an SCP. The repository controls access to the Source in the version control system. The objective of a repository is to reflect the intent of the organization that controls it. -| Branch | A named pointer to a revision. Branches may be modified by authorized actors. In git, cloning a repo will download all revisions in the history of the "default" branch to the local machine. Branches may have different security requirements. -| Change | A set of modifications to the source in a specific context. Can be proposed and reviewed before being accepted. +| Source Control System (SCS) | A service or suite of services (self-hosted or SaaS) relied upon by the organization to produce new revisions of the source. GitHub and GitLab are examples, as are combinations of tools like Gerrit code reviews with GitHub Repositories. +| Source Provenance | Information about how a revision came to exist, where it was hosted, when it was generated, what process was used, who the contributors were, and what parent revisions it was based on. +| Repository / Repo | A uniquely identifiable instance of a VCS. The repository controls access to the Source in the VCS. The objective of a repository is to reflect the intent of the organization that controls it. +| Branch | A named pointer to a revision. Branches may be modified by authorized actors. Branches may have different security requirements. +| Change | A set of modifications to the source in a specific context. A change can be proposed and reviewed before being accepted. | Change History | A record of the history of revisions that preceded a specific revision. -| Push / upload / publish | When an actor authenticates to an SCP to add or modify content. Typically makes a new revision reachable from a branch. -| Review / approve / vote | When an actor authenticates to a change review tool to leave comments or endorse / reject the source change proposal they were presented. +| Push / upload / publish | When an actor authenticates to a Repository to add or modify content. Typically makes a new revision reachable from a branch. +| Review / approve / vote | When an actor authenticates to a change review tool to comment upon, endorse, or reject a source change proposal. ## Source Roles @@ -121,18 +110,18 @@ The source MUST have a location where the "official" revisions are stored and ma #### Revisions are immutable and uniquely identifiable This requirement ensures that a consumer can determine that the source revision they have is the same as a canonical revision. -The combination of SCP and VCS MUST provide a deterministic way to identify a particular revision. +The SCS MUST provide a deterministic way to identify a particular revision. Virtually all modern tools provide this guarantee via a combination of the repository ID and revision ID. ##### Repository IDs -The repository ID is generated by the SCP and MUST be unique in the context of that instance of the SCP. +The repository ID is defined by the SCS and MUST be unique in the context of that instance of the SCS. ##### Revision IDs When the revision ID is a digest of the content of the revision (as in git) nothing more is needed. -When the revision ID is a number or otherwise not a digest, then the SCP and VCS MUST document how the immutability of the revision is established. +When the revision ID is a number or otherwise not a digest, then the SCS MUST document how the immutability of the revision is established. The same revision ID MAY be present in multiple repositories. See also [Use cases for non-cryptographic, immutable, digests](https://github.com/in-toto/attestation/blob/main/spec/v1/digest_set.md#use-cases-for-non-cryptographic-immutable-digests). @@ -151,7 +140,7 @@ Requirements: #### Branches -If the SCP and VCS combination supports multiple branches, the organization MUST indicate which branches are intended for consumption. +If the SCS supports multiple branches, the organization MUST indicate which branches are intended for consumption. This may be implied or explicit. For example, an organization may declare that the `default` branch of a repo contains revisions intended for consumption my protected it. @@ -176,14 +165,14 @@ Exceptions are allowed via the [safe expunging process](#safe-expunging-process) There exists an identity management system or some other means of identifying actors. This system may be a federated authentication system (AAD, Google, Okta, GitHub, etc) or custom implementation (gittuf, gpg-signatures on commits, etc). -The SCP MUST document how actors are identified for the purposes of attribution. +The SCS MUST document how actors are identified for the purposes of attribution. -Activities conducted on the SCP SHOULD be attributed to authenticated identities. +Activities conducted on the SCS SHOULD be attributed to authenticated identities. ### Level 3: Source Provenance Attestations Summary: -A consumer can ask the SCP for everything it knows about a specific revision of a repository. +A consumer can ask the SCS for everything it knows about a specific revision of a repository. The information is provided in a documented and tamper-resistant format. Intended for: @@ -197,12 +186,12 @@ Requirements: #### Source attestations A source attestation contains information about how a specific revision was created and how it came to exist in its present context. -They are associated with the revision identifier delivered to consumers and are a statement of fact from the perspective of the SCP. +They are associated with the revision identifier delivered to consumers and are a statement of fact from the perspective of the SCS. If a consumer is authorized to access source on a particular branch, they MUST be able to fetch the source attestation documents for revisions in the history of that branch. -It is possible that an SCP can make no claims about a particular revision. -For example, this would happen if the revision was created on another SCP, or if the revision was not the result of an accepted change management process. +It is possible that an SCS can make no claims about a particular revision. +For example, this would happen if the revision was created on another SCS, or if the revision was not the result of an accepted change management process. #### Change management process @@ -221,8 +210,8 @@ The change management tool MUST provide at a minimum: User accounts that can modify the source or the project's configuration must use multi-factor authentication or its equivalent. This strongly authenticated identity MUST be used for the generation of source provenance attestations. -The SCP MUST declare which forms of identity it considers to be trustworthy for this purpose. -For cloud-based SCPs, this will typically be the identity used to push to a git server. +The SCS MUST declare which forms of identity it considers to be trustworthy for this purpose. +For cloud-based SCSs, this will typically be the identity used to push to a repository. Other forms of identity MAY be included as informational. Examples include a git commit's "author" and "committer" fields and a gpg signature's "user id." diff --git a/docs/spec/draft/verifying-source.md b/docs/spec/draft/verifying-source.md index 80701d01e..93998f8ef 100644 --- a/docs/spec/draft/verifying-source.md +++ b/docs/spec/draft/verifying-source.md @@ -8,7 +8,7 @@ The intended audience is platform implementers, security engineers, and software SLSA uses attestations to indicate security claims associated with a repository revision, but attestations don't do anything unless somebody inspects them. SLSA calls that inspection **verification**, and this page describes how to verify properties of source revisions using their SLSA source provenance attestations. -Source Control Platforms (SCPs) may issue attestations of the process that was used to create specific revisions of a repository. +Source Control Systems (SCSs) may issue attestations of the process that was used to create specific revisions of a repository. A Verification Summary Attestation (VSA) can make verification more efficient by recording the result of prior verifications. VSA may be issued by a VSA provider to make a SLSA source level determination based on the content of those attestations. @@ -168,7 +168,7 @@ It is not sufficient to indicate that a file changed without showing the content Require a squash merge strategy for the protected branch. -To guarantee that only commits representing reviewed diffs are cloned, the SCP MUST rebase (or "squash") the reviewed diff into a single new commit (the "squashed" commit) that has only a single parent (the revision previously pointed-to by the protected branch). +To guarantee that only commits representing reviewed diffs are cloned, the SCS MUST rebase (or "squash") the reviewed diff into a single new commit (the "squashed" commit) that has only a single parent (the revision previously pointed-to by the protected branch). This is different than a standard merge commit strategy which would cause all the user-contributed commits to become reachable from the protected branch via the second parent. It is not acceptable to replay the sequence of commits from the topic branch onto the protected branch. From 26a9012ba0c24146238e0f903ac12bc124157351 Mon Sep 17 00:00:00 2001 From: Mend Renovate Date: Wed, 21 Aug 2024 15:10:27 +0200 Subject: [PATCH 02/14] impl: Update dependency github-pages to v232 (#1116) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit [![Mend Renovate](https://app.renovatebot.com/images/banner.svg)](https://renovatebot.com) This PR contains the following updates: | Package | Change | Age | Adoption | Passing | Confidence | |---|---|---|---|---|---| | [github-pages](https://togithub.com/github/pages-gem) | `231` -> `232` | [![age](https://developer.mend.io/api/mc/badges/age/rubygems/github-pages/232?slim=true)](https://docs.renovatebot.com/merge-confidence/) | [![adoption](https://developer.mend.io/api/mc/badges/adoption/rubygems/github-pages/232?slim=true)](https://docs.renovatebot.com/merge-confidence/) | [![passing](https://developer.mend.io/api/mc/badges/compatibility/rubygems/github-pages/231/232?slim=true)](https://docs.renovatebot.com/merge-confidence/) | [![confidence](https://developer.mend.io/api/mc/badges/confidence/rubygems/github-pages/231/232?slim=true)](https://docs.renovatebot.com/merge-confidence/) | --- ### Release Notes
github/pages-gem (github-pages) ### [`v232`](https://togithub.com/github/pages-gem/releases/tag/v232) [Compare Source](https://togithub.com/github/pages-gem/compare/v231...v232) #### What's Changed - Bump docker/build-push-action from 5 to 6 by [@​dependabot](https://togithub.com/dependabot) in [https://github.com/github/pages-gem/pull/916](https://togithub.com/github/pages-gem/pull/916) - Fix obscured gemfile issue by [@​mrmanc](https://togithub.com/mrmanc) in [https://github.com/github/pages-gem/pull/912](https://togithub.com/github/pages-gem/pull/912) - Add webrick as Ruby 3 doesn’t include it by [@​mrmanc](https://togithub.com/mrmanc) in [https://github.com/github/pages-gem/pull/914](https://togithub.com/github/pages-gem/pull/914) - Update nokogiri CVE-2024-25062 by [@​naxhh](https://togithub.com/naxhh) in [https://github.com/github/pages-gem/pull/911](https://togithub.com/github/pages-gem/pull/911) - Parkr jekyll3.10 by [@​yoannchaudet](https://togithub.com/yoannchaudet) in [https://github.com/github/pages-gem/pull/919](https://togithub.com/github/pages-gem/pull/919) - Fix improperly bound regex by [@​yoannchaudet](https://togithub.com/yoannchaudet) in [https://github.com/github/pages-gem/pull/921](https://togithub.com/github/pages-gem/pull/921) - Prep 232 by [@​yoannchaudet](https://togithub.com/yoannchaudet) in [https://github.com/github/pages-gem/pull/923](https://togithub.com/github/pages-gem/pull/923) #### New Contributors - [@​naxhh](https://togithub.com/naxhh) made their first contribution in [https://github.com/github/pages-gem/pull/911](https://togithub.com/github/pages-gem/pull/911) **Full Changelog**: https://github.com/github/pages-gem/compare/v231...v232
--- ### Configuration 📅 **Schedule**: Branch creation - "every weekend" (UTC), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] If you want to rebase/retry this PR, check this box --- This PR was generated by [Mend Renovate](https://www.mend.io/free-developer-tools/renovate/). View the [repository job log](https://developer.mend.io/github/slsa-framework/slsa). --------- Signed-off-by: Mend Renovate Signed-off-by: Tom Hennen Co-authored-by: Tom Hennen --- docs/Gemfile.lock | 37 ++++++++++++++++--------------------- 1 file changed, 16 insertions(+), 21 deletions(-) diff --git a/docs/Gemfile.lock b/docs/Gemfile.lock index d7acccb49..8f11c6cda 100644 --- a/docs/Gemfile.lock +++ b/docs/Gemfile.lock @@ -1,7 +1,7 @@ GEM remote: https://rubygems.org/ specs: - activesupport (7.1.3) + activesupport (7.1.3.4) base64 bigdecimal concurrent-ruby (~> 1.0, >= 1.0.2) @@ -11,22 +11,21 @@ GEM minitest (>= 5.1) mutex_m tzinfo (~> 2.0) - addressable (2.8.6) - public_suffix (>= 2.0.2, < 6.0) + addressable (2.8.7) + public_suffix (>= 2.0.2, < 7.0) base64 (0.2.0) - bigdecimal (3.1.6) + bigdecimal (3.1.8) coffee-script (2.4.1) coffee-script-source execjs coffee-script-source (1.12.2) colorator (1.1.0) commonmarker (0.23.10) - concurrent-ruby (1.2.3) + concurrent-ruby (1.3.4) connection_pool (2.4.1) - dnsruby (1.70.0) + dnsruby (1.72.2) simpleidn (~> 0.2.1) - drb (2.2.0) - ruby2_keywords + drb (2.2.1) em-websocket (0.5.3) eventmachine (>= 0.12.9) http_parser.rb (~> 0) @@ -97,7 +96,7 @@ GEM activesupport (>= 2) nokogiri (>= 1.4) http_parser.rb (0.8.0) - i18n (1.14.1) + i18n (1.14.5) concurrent-ruby (~> 1.0) jekyll (3.9.5) addressable (~> 2.4) @@ -212,16 +211,16 @@ GEM kramdown-parser-gfm (1.1.0) kramdown (~> 2.0) liquid (4.0.4) - listen (3.8.0) + listen (3.9.0) rb-fsevent (~> 0.10, >= 0.10.3) rb-inotify (~> 0.9, >= 0.9.10) mercenary (0.3.6) - mini_portile2 (2.8.5) + mini_portile2 (2.8.7) minima (2.5.1) jekyll (>= 3.5, < 5.0) jekyll-feed (~> 0.9) jekyll-seo-tag (~> 2.1) - minitest (5.22.2) + minitest (5.25.1) mutex_m (0.2.0) netrc (0.11.0) nokogiri (1.15.6) @@ -232,12 +231,12 @@ GEM sawyer (~> 0.9) pathutil (0.16.2) forwardable-extended (~> 2.6) - public_suffix (5.0.4) - racc (1.7.3) + public_suffix (5.1.1) + racc (1.8.1) rb-fsevent (0.11.2) - rb-inotify (0.10.1) + rb-inotify (0.11.1) ffi (~> 1.0) - rexml (3.3.3) + rexml (3.3.5) strscan rouge (3.30.0) ruby2_keywords (0.0.5) @@ -251,8 +250,7 @@ GEM sawyer (0.9.2) addressable (>= 2.3.5) faraday (>= 0.17.3, < 3) - simpleidn (0.2.1) - unf (~> 0.1.4) + simpleidn (0.2.3) strscan (3.1.0) terminal-table (1.8.0) unicode-display_width (~> 1.1, >= 1.1.1) @@ -260,9 +258,6 @@ GEM ethon (>= 0.9.0) tzinfo (2.0.6) concurrent-ruby (~> 1.0) - unf (0.1.4) - unf_ext - unf_ext (0.0.9.1) unicode-display_width (1.8.0) webrick (1.8.1) From 36af4852894daf2837446ecc08fb088e7657f024 Mon Sep 17 00:00:00 2001 From: Arnaud J Le Hors Date: Mon, 26 Aug 2024 19:03:00 +0200 Subject: [PATCH 03/14] content: Move v1.1 to Candidate Release (CR) (#1117) This PR proposes to change the status of v1.1 to Candidate Release in preparation for final publication. I ought to point out that there is a bunch of VSA related issues that had been targeted for this release and that have not been addressed. See Issue #900. However, until someone works on any of these issues there is no hope of making progress and waiting for these to close will delay getting 1.1 out indefinitely. Although not ideal I therefore propose to defer these and publish what we have. Signed-off-by: Arnaud J Le Hors --- docs/_data/versions.yml | 4 ++-- docs/_includes/header.html | 2 +- docs/spec/v1.1/whats-new.md | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/_data/versions.yml b/docs/_data/versions.yml index e7587377a..c468cf91f 100644 --- a/docs/_data/versions.yml +++ b/docs/_data/versions.yml @@ -37,8 +37,8 @@ spec: name: Version 1.0 status: Approved v1.1: - name: Version 1.1 (DRAFT) - status: Draft + name: Version 1.1 RC + status: Candidate draft: true draft: name: Working Draft diff --git a/docs/_includes/header.html b/docs/_includes/header.html index a9d1fb16d..ce5065db9 100644 --- a/docs/_includes/header.html +++ b/docs/_includes/header.html @@ -81,7 +81,7 @@ {%- else %} {%- assign new_url = "/" + spec_id + "/" + spec.current %} {%- endif %} -

{{ current_version.name }} is available! See the newest documentation.

+

{{ current_version.name }} is the current version. See the {{ current_version.name }} documentation.

{%- endif %} {%- endif %} diff --git a/docs/spec/v1.1/whats-new.md b/docs/spec/v1.1/whats-new.md index 12133fc55..c4cc6ca53 100644 --- a/docs/spec/v1.1/whats-new.md +++ b/docs/spec/v1.1/whats-new.md @@ -5,7 +5,7 @@ description: SLSA v1.1 is a minor release of SLSA. That is, all changes are inte SLSA v1.1 is a minor release of SLSA v1 which brings clarifications and additional content without changing the meaning of the specification. This -document describes the major changes in v1.1 relative to the prior release, +document describes the main changes in v1.1 relative to the prior release, [v1.0]. ## Summary of changes From 1674a74a1cd48bea4168744ac862171f64e43d3f Mon Sep 17 00:00:00 2001 From: Mend Renovate Date: Tue, 27 Aug 2024 12:09:35 +0200 Subject: [PATCH 04/14] impl: Update dependency github-pages to v232 (#1119) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit [![Mend Renovate](https://app.renovatebot.com/images/banner.svg)](https://renovatebot.com) This PR contains the following updates: | Package | Change | Age | Adoption | Passing | Confidence | |---|---|---|---|---|---| | [github-pages](https://togithub.com/github/pages-gem) | `231` -> `232` | [![age](https://developer.mend.io/api/mc/badges/age/rubygems/github-pages/232?slim=true)](https://docs.renovatebot.com/merge-confidence/) | [![adoption](https://developer.mend.io/api/mc/badges/adoption/rubygems/github-pages/232?slim=true)](https://docs.renovatebot.com/merge-confidence/) | [![passing](https://developer.mend.io/api/mc/badges/compatibility/rubygems/github-pages/231/232?slim=true)](https://docs.renovatebot.com/merge-confidence/) | [![confidence](https://developer.mend.io/api/mc/badges/confidence/rubygems/github-pages/231/232?slim=true)](https://docs.renovatebot.com/merge-confidence/) | --- ### Release Notes
github/pages-gem (github-pages) ### [`v232`](https://togithub.com/github/pages-gem/releases/tag/v232) [Compare Source](https://togithub.com/github/pages-gem/compare/v231...v232) #### What's Changed - Bump docker/build-push-action from 5 to 6 by [@​dependabot](https://togithub.com/dependabot) in [https://github.com/github/pages-gem/pull/916](https://togithub.com/github/pages-gem/pull/916) - Fix obscured gemfile issue by [@​mrmanc](https://togithub.com/mrmanc) in [https://github.com/github/pages-gem/pull/912](https://togithub.com/github/pages-gem/pull/912) - Add webrick as Ruby 3 doesn’t include it by [@​mrmanc](https://togithub.com/mrmanc) in [https://github.com/github/pages-gem/pull/914](https://togithub.com/github/pages-gem/pull/914) - Update nokogiri CVE-2024-25062 by [@​naxhh](https://togithub.com/naxhh) in [https://github.com/github/pages-gem/pull/911](https://togithub.com/github/pages-gem/pull/911) - Parkr jekyll3.10 by [@​yoannchaudet](https://togithub.com/yoannchaudet) in [https://github.com/github/pages-gem/pull/919](https://togithub.com/github/pages-gem/pull/919) - Fix improperly bound regex by [@​yoannchaudet](https://togithub.com/yoannchaudet) in [https://github.com/github/pages-gem/pull/921](https://togithub.com/github/pages-gem/pull/921) - Prep 232 by [@​yoannchaudet](https://togithub.com/yoannchaudet) in [https://github.com/github/pages-gem/pull/923](https://togithub.com/github/pages-gem/pull/923) #### New Contributors - [@​naxhh](https://togithub.com/naxhh) made their first contribution in [https://github.com/github/pages-gem/pull/911](https://togithub.com/github/pages-gem/pull/911) **Full Changelog**: https://github.com/github/pages-gem/compare/v231...v232
--- ### Configuration 📅 **Schedule**: Branch creation - "every weekend" (UTC), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] If you want to rebase/retry this PR, check this box --- This PR was generated by [Mend Renovate](https://www.mend.io/free-developer-tools/renovate/). View the [repository job log](https://developer.mend.io/github/slsa-framework/slsa). --------- Signed-off-by: Mend Renovate Signed-off-by: Arnaud J Le Hors Co-authored-by: Arnaud J Le Hors --- docs/Gemfile.lock | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/Gemfile.lock b/docs/Gemfile.lock index 8f11c6cda..58c4644b4 100644 --- a/docs/Gemfile.lock +++ b/docs/Gemfile.lock @@ -1,7 +1,7 @@ GEM remote: https://rubygems.org/ specs: - activesupport (7.1.3.4) + activesupport (7.1.4) base64 bigdecimal concurrent-ruby (~> 1.0, >= 1.0.2) @@ -236,7 +236,7 @@ GEM rb-fsevent (0.11.2) rb-inotify (0.11.1) ffi (~> 1.0) - rexml (3.3.5) + rexml (3.3.6) strscan rouge (3.30.0) ruby2_keywords (0.0.5) From d3e9e97360c7a36f4fbae252a980a122d6c97194 Mon Sep 17 00:00:00 2001 From: Meder Kydyraliev <1212257+meder@users.noreply.github.com> Date: Thu, 5 Sep 2024 04:41:11 +1000 Subject: [PATCH 05/14] blog: Dependency Confusion and Typosquatting Attacks (#1109) Blogpost that looks at dependency confusion and typosquatting attacks from defender's perspective and defines "managed ingestion" as an important capability for supply chain risk management. --------- Signed-off-by: Meder Kydyraliev <1212257+meder@users.noreply.github.com> Co-authored-by: Joshua Lock Co-authored-by: Marcela Melara --- ...4-08-13-dep-confusion-and-typosquatting.md | 85 +++++++++++++++++++ 1 file changed, 85 insertions(+) create mode 100644 docs/_posts/2024-08-13-dep-confusion-and-typosquatting.md diff --git a/docs/_posts/2024-08-13-dep-confusion-and-typosquatting.md b/docs/_posts/2024-08-13-dep-confusion-and-typosquatting.md new file mode 100644 index 000000000..90fa4edba --- /dev/null +++ b/docs/_posts/2024-08-13-dep-confusion-and-typosquatting.md @@ -0,0 +1,85 @@ +--- +title: "Defender's Perspective: Dependency Confusion and Typosquatting Attacks" +author: "Meder Kydyraliev (Google)" +is_guest_post: false +--- + +_Dependency confusion_ and _typosquatting_ attacks are very similar in their nature. They both exploit the weakness in the way many package managers identify packages using only their names. Successfully exploiting this weakness enables the attacker to run arbitrary code at install time or at application's run time. These attacks are scalable, portable, and extremely cost-effective to carry out—making them very appealing to malicious actors. + +This blog post explores the attacks from the defender's perspective and highlights how SLSA can be used to help defend against them. It also describes some additional capabilities which might be required to mitigate this and other supply chain risks more robustly. + +## What is Dependency Confusion? + +The convenience of package registries has been recognized by developers and organizations worldwide as an effective way to manage and distribute internally developed software packages using existing tooling. One common approach involves running an internal, private instance of a package registry to distribute internal dependencies and configuring **_all_** build processes to first look for a package in the private registry and only if it is not found there going to the public instance of the package registry to fetch it[^1]. + +This works but is fragile. If someone in the organization attempts to build software that uses internal packages but doesn't correctly configure the build to use the private registry instance first then the package installer will attempt to fetch internal packages from the public registry instance. Under normal circumstances this will return an error, as the internal package name would not be present in the public instance. + +### The Attack + +The attacker begins by performing reconnaissance to acquire names of internal packages. This can be done using a number of techniques, e.g., trawling through organization's open source repositories, inspecting shipped software or simply guessing the names. Once the attacker has the names of internal packages, they register these targeted packages with the public registry and release a new version with a malicious payload. At this point the attacker has to wait for one of the misconfigured builds to run and use the attacker's package — resulting in compromise. Effective use of this technique is described in detail in blog posts such as [Dependency Confusion: How I Hacked Into Apple, Microsoft and Dozens of Other Companies](https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610). + +## What is Typosquatting? + +The workflow for developers to add a new dependency to a software project commonly involves modification of a manifest file to list the new package by its name and version. The package name is usually manually typed in, copied/pasted from the web, or added by the IDE. Most of the input modes that involve humans are prone to transcription errors and typos, ranging from missing hyphens, lookalike characters, to transposed letters. Under normal circumstances the build would fail if a non-existent dependency is requested. + +### The Attack + +The attacker pre-registers (or "squats") a large number of package names with commonly seen typos in them—usually using popular package names as the starting point—and waits for victims to install their packages. The attack is opportunistic since, unlike dependency confusion, it doesn't target a specific organization. Notably, however, unlike dependency confusion, this attack has the potential to result in a more severe and hard to detect compromise. Public availability of packages that attackers target for squatting enables them to distribute original copies of the targeted packages and only deliver malicious payload at a later date by releasing an update. This attack vector can result in applications incorporating and using the attacker's package in production. + +There are a number of potential vectors that attackers can use as the source of names to squat on to increase the chances of success, e.g. package names popular in other ecosystems, variants of the package name used by Linux distributions or OSS package names "hallucinated" by LLMs. + +## Mitigations + +The fragility of just using package names as the way to identify software packages is hopefully obvious by now. Let's first explore common recommendations([1](https://fossa.com/blog/dependency-confusion-understanding-preventing-attacks/), [2](https://www.activestate.com/blog/how-to-prevent-dependency-confusion/)). to mitigate _dependency confusion_ attacks and their limitations: + +- **Namespacing:** Some package registries support namespacing, sometimes called scoping or organization support. This feature enables organizations to claim a namespace in the public registry for their internal dependencies. This prevents attackers from registering internal names, as they are not authorized to publish to the organization's namespace. Confidentiality concerns would likely prevent large organizations, that are usually targeted by the dependency confusion attacks, from hosting internal dependencies in the public instance; claiming the namespace is, however, sufficient to prevent attackers from exploiting dependency confusion. Namespacing is not supported by all package registries, and moreover the solution is not very robust as trust is placed into another forgeable identifier outside of the organization's control. +- **Registering internal names in the public registry:** a common practical workaround for registries that lack namespacing support is for organizations to do what the attackers do and claim internal package names in the public registry instance to prevent attackers from doing so. This recommendation doesn't address the root cause of dependency confusion attacks and requires ongoing coordination and synchronization of the names between public and private registries, which is fragile. +- **Pinning or hash validation:** some client-side tooling supports pinning or locking of dependencies by hash. Both internal and external dependencies will be listed in the lockfile. Effectively preventing a dependency confusion attack using lockfiles requires all updates to the lock file to ensure that hashes for internal packages match the list of authorized hashes for that package. Not all ecosystems universally support pinning with lockfiles, and even those that do may lack the functionality to manage and distinguish between internal and external dependencies. + +In case of _typosquatting_ attacks the mitigation is not very straightforward and for the most part requires intervention at the point when developers are adding a new dependency. Effective mitigation could involve presenting the developer with metadata about the package being added (e.g. number of dependents, downloads) and prompting them to verify and ensure that the package being installed is the one that developer intended. This unscalable approach is prone to human errors, which can happen for reasons ranging from time pressure and fatigue to the lack of security expertise and simple misreading of key parts of metadata. + +### SLSA + +Now let's look at how SLSA's **existing** controls can can be used to prevent each of the attacks. + +#### Dependency Confusion + +A much more robust way to address dependency confusion is to use SLSA. SLSA build provenance contains metadata about an artifact, which includes the URL of the source repository and identifies the build system that produced the artifact. This metadata enables secure binding of the package name and version to the canonical source repository and its build system, which is referred to as [expectations forming](https://slsa.dev/spec/v1.0/verifying-artifacts#forming-expectations) in SLSA. + +Let's examine how SLSA build provenance prevents successful dependency confusion exploitation: + +1. Organization defines a policy for its internal packages by binding each package to the authorized builder and the expected canonical source repository. +2. Organization's internal packages are built with a SLSA-compliant build system, which produces SLSA build provenance. +3. SLSA build provenance is [distributed along with the artifact](https://slsa.dev/spec/v1.0/distributing-provenance), e.g. by the internal registry instance. +4. Upon installation of the internal packages their build provenance is verified aginst the policy defined earlier. The verification ensures that the internal packages were built by the authorized build system using source code from the canonical source repository. + +Attackers are unable to forge SLSA Level 2+ build provenance thus all dependency confusion attempts will be immediately detected due to a different canonical source repository or builder ID. Native support for SLSA build provenance and its verification in ecosystems like npm will enable this robust form of protection against dependency confusion attacks. + +#### Typosquatting + +Dealing with typosquatting attacks is trickier because at the time of the attack the developer is adding a new dependency, potentially interacting with it for the first time. Trust on first use (TOFU) is a common approach to bootstrapping trust and [forming expectations](https://slsa.dev/spec/v1.0/verifying-artifacts#forming-expectations), however, since it's impossible to know the developer's intent, all tooling can do is present them with the metadata about the package they are adding. Unfortunately that metadata could be for the attacker's impostor package. + +Effective mitigation of typosquatting attacks requires ongoing integration of heuristics to proactively flag packages that appear like typosquatting attempts into all workflows that add new dependencies. Heuristics could range from evaluation over static data (e.g. package age) to ones requiring more time and resources (e.g. graph resolution or dynamic analysis). Managed ingestion, described below, is one very efficient and effective way to deploy such protections across larger enterprises. + +### Managed Ingestion + +Effective OSS supply chain security risk management hinges on an organization's ability to control what OSS can be used in an organization's products. This concept is not new, as it mirrors the approach taken in food supply chain management, where control over the ingredients included in food products is paramount. The concept is also reflected in [OpenSSF's s2c2f framework](https://github.com/ossf/s2c2f), which highlights control over ingestion in organizations as a crucial first step towards securing their software supply chains. + +For a typical build process this means control over resolution of the OSS dependency graph and retrieval of the resolved dependencies from the Internet. Historically both processes lacked explicit control and transparency leading to a significant level of trust being placed in package managers and their associated registries. + +Managed ingestion describes a dedicated deliberate process that happens separately from the build and involves an organization importing and assessing OSS packages before making them available to developers internally. While there is more than one way to implement managed ingestion, combining managed ingestion with existing artifact management solutions creates a very potent capability that provides organizations with control over the graph resolution and an opportunity for centralized supply chain risk management. Native support for different package ecosystems provided by most modern artifact management solutions ensures compatibility with most existing build and dependency management tools. + +In this context, based on practical experience, managed ingestion needs to provide the following capabilities: + +- **Implementation of an ingestion delay** for new versions of OSS packages. A simple but very effective mitigation against a number of supply chain attacks. +- **Mitigation of availability concerns** ensuring organizations are able to build and deploy even if upstream infrastructure is down. +- **Mitigation of dependency confusion attacks** by flagging upstream packages whose names clash with internal package names or that fail SLSA build provenance verification. +- **Mitigation of typosquatting** attacks by flagging upstream packages based on heuristics. +- Opportunity to **deploy existing content scanning tools on OSS packages** to flag known indicators of maliciousness or unexpected changes (e.g. changes in capabilities reported by [CAPSLOCK](https://github.com/google/capslock)). + +The process of using OSS packages via registries presents a lot of risks beyond typosquatting and dependency confusion—and requires the same level of attention and control as the build process itself. Managed ingestion is the fundamental capability required to successfully manage OSS supply chain risk. As part of the ongoing [SLSA dependencies track](https://github.com/slsa-framework/slsa/issues/961) effort we will work to formalize these concepts, including [those from s2c2f](https://github.com/slsa-framework/slsa/issues/1105), within the SLSA specification. + + +## Notes + +[^1]: Multi-registry behaviour is ecosystem and configuration specific, e.g. PyPI configured with the discouraged --extra-index-url flag would pick the highest version if a package is present in private and public instance. Overall the mechanics of the attack remain the same. From 73b9c71b55c90cf3807049b45de7cff47f2983e6 Mon Sep 17 00:00:00 2001 From: Arnaud J Le Hors Date: Wed, 4 Sep 2024 21:01:51 +0200 Subject: [PATCH 06/14] impl: Fix Jekyll front matter (#1124) I noticed that the jekyll build was producing an error because the `description` variable in the front matter of the `verifying-source.md` file contained multiple lines. This fixes the format so that there is no longer any error and as a consequence the page title is now displayed correctly. However, I must admit that although every page contains a description I cannot find whether it is actually used anywhere... Signed-off-by: Arnaud J Le Hors --- docs/spec/draft/verifying-source.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/docs/spec/draft/verifying-source.md b/docs/spec/draft/verifying-source.md index 93998f8ef..cafea710c 100644 --- a/docs/spec/draft/verifying-source.md +++ b/docs/spec/draft/verifying-source.md @@ -1,8 +1,9 @@ --- title: Verifying source -description: SLSA uses attestations to indicate security claims associated with a repository revision, but attestations don't do anything unless somebody inspects them. -SLSA calls that inspection verification, and this page describes how to verify properties of source revisions using their SLSA source provenance attestations. -The intended audience is platform implementers, security engineers, and software consumers. +description: | + SLSA uses attestations to indicate security claims associated with a repository revision, but attestations don't do anything unless somebody inspects them. + SLSA calls that inspection verification, and this page describes how to verify properties of source revisions using their SLSA source provenance attestations. + The intended audience is platform implementers, security engineers, and software consumers. --- SLSA uses attestations to indicate security claims associated with a repository revision, but attestations don't do anything unless somebody inspects them. From 2d125f0468b50aec36ad86751c8e7f183d574148 Mon Sep 17 00:00:00 2001 From: Tom Hennen Date: Tue, 10 Sep 2024 05:23:53 -0400 Subject: [PATCH 07/14] fix: Fix linter errors from blog post. (#1131) 1. Only check for duplicate headings in siblings. It's useful to have allow duplicated headings that aren't in siblings to let docs have parallel construction across the entire doc. 2. Remove absolute references to slsa.dev Signed-off-by: Tom Hennen --- .markdownlint.yaml | 5 +++++ docs/_posts/2024-08-13-dep-confusion-and-typosquatting.md | 6 +++--- 2 files changed, 8 insertions(+), 3 deletions(-) diff --git a/.markdownlint.yaml b/.markdownlint.yaml index e3374fad8..e5646d8d0 100644 --- a/.markdownlint.yaml +++ b/.markdownlint.yaml @@ -9,6 +9,11 @@ MD007: # MD013/line-length - Line length MD013: false +# MD024/no-duplicate-heading - No duplicate headings +MD024: + # Only check that siblings aren't duplicated. + siblings_only: true + # MD025/single-title/single-h1 - Multiple top-level headings MD025: # Disable checking of YAML frontmatter. diff --git a/docs/_posts/2024-08-13-dep-confusion-and-typosquatting.md b/docs/_posts/2024-08-13-dep-confusion-and-typosquatting.md index 90fa4edba..20df7f837 100644 --- a/docs/_posts/2024-08-13-dep-confusion-and-typosquatting.md +++ b/docs/_posts/2024-08-13-dep-confusion-and-typosquatting.md @@ -44,20 +44,20 @@ Now let's look at how SLSA's **existing** controls can can be used to prevent ea #### Dependency Confusion -A much more robust way to address dependency confusion is to use SLSA. SLSA build provenance contains metadata about an artifact, which includes the URL of the source repository and identifies the build system that produced the artifact. This metadata enables secure binding of the package name and version to the canonical source repository and its build system, which is referred to as [expectations forming](https://slsa.dev/spec/v1.0/verifying-artifacts#forming-expectations) in SLSA. +A much more robust way to address dependency confusion is to use SLSA. SLSA build provenance contains metadata about an artifact, which includes the URL of the source repository and identifies the build system that produced the artifact. This metadata enables secure binding of the package name and version to the canonical source repository and its build system, which is referred to as [expectations forming](/spec/v1.0/verifying-artifacts#forming-expectations) in SLSA. Let's examine how SLSA build provenance prevents successful dependency confusion exploitation: 1. Organization defines a policy for its internal packages by binding each package to the authorized builder and the expected canonical source repository. 2. Organization's internal packages are built with a SLSA-compliant build system, which produces SLSA build provenance. -3. SLSA build provenance is [distributed along with the artifact](https://slsa.dev/spec/v1.0/distributing-provenance), e.g. by the internal registry instance. +3. SLSA build provenance is [distributed along with the artifact](/spec/v1.0/distributing-provenance), e.g. by the internal registry instance. 4. Upon installation of the internal packages their build provenance is verified aginst the policy defined earlier. The verification ensures that the internal packages were built by the authorized build system using source code from the canonical source repository. Attackers are unable to forge SLSA Level 2+ build provenance thus all dependency confusion attempts will be immediately detected due to a different canonical source repository or builder ID. Native support for SLSA build provenance and its verification in ecosystems like npm will enable this robust form of protection against dependency confusion attacks. #### Typosquatting -Dealing with typosquatting attacks is trickier because at the time of the attack the developer is adding a new dependency, potentially interacting with it for the first time. Trust on first use (TOFU) is a common approach to bootstrapping trust and [forming expectations](https://slsa.dev/spec/v1.0/verifying-artifacts#forming-expectations), however, since it's impossible to know the developer's intent, all tooling can do is present them with the metadata about the package they are adding. Unfortunately that metadata could be for the attacker's impostor package. +Dealing with typosquatting attacks is trickier because at the time of the attack the developer is adding a new dependency, potentially interacting with it for the first time. Trust on first use (TOFU) is a common approach to bootstrapping trust and [forming expectations](/spec/v1.0/verifying-artifacts#forming-expectations), however, since it's impossible to know the developer's intent, all tooling can do is present them with the metadata about the package they are adding. Unfortunately that metadata could be for the attacker's impostor package. Effective mitigation of typosquatting attacks requires ongoing integration of heuristics to proactively flag packages that appear like typosquatting attempts into all workflows that add new dependencies. Heuristics could range from evaluation over static data (e.g. package age) to ones requiring more time and resources (e.g. graph resolution or dynamic analysis). Managed ingestion, described below, is one very efficient and effective way to deploy such protections across larger enterprises. From 7130cad96a71cf2db05e48f3bdf7f2dc1462f62c Mon Sep 17 00:00:00 2001 From: Arnaud J Le Hors Date: Tue, 17 Sep 2024 00:37:26 +0200 Subject: [PATCH 08/14] editorial: Address some of the TODOs in threats and mitigation section (#1123) This patch focuses on merely editorial changes such as moving sections around and changing 'out of scope' to 'not currently addressed'. There are a lot more TODOs to go through but that's a first step... Signed-off-by: Arnaud J Le Hors --- docs/spec/draft/threats.md | 306 ++++++++++++++++++------------------- 1 file changed, 147 insertions(+), 159 deletions(-) diff --git a/docs/spec/draft/threats.md b/docs/spec/draft/threats.md index db6e5bfe7..8e14b0800 100644 --- a/docs/spec/draft/threats.md +++ b/docs/spec/draft/threats.md @@ -15,9 +15,6 @@ The examples on this page are meant to: - Help implementers better understand what they are protecting against so that they can better design and implement controls. -**TODO:** Update the ordering to match the diagram. We're currently in the -middle of refactoring, with a jumble of new and old. - **TODO:** Expand this threat model to also cover "unknowns". Not sure if that is a "threat" or a "risk". Example: If libFoo is compromised, how do you know if you are compromised? At a first level, if you don't even know whether you @@ -27,12 +24,6 @@ that somehow. This isn't specific to dependencies - it applies to the entire diagram. ([discussion](https://github.com/slsa-framework/slsa/pull/1046/files/ebf34a8f9e874b219f152bad62673eae0b3ba2c3#r1585440922)) -**TODO:** Revisit and possibly update any item that says "out of scope", since -we want to really expand SLSA's scope to include all of these threats. A more -nuanced answer would be that the current version does not define a specific -mitigation, but it's in scope for the project overall. We can also list specific -mitigations even if they're not listed as a level requirement. -
## Overview @@ -264,8 +255,8 @@ does not accept this because the version X is not considered reviewed. *Threat:* Two trusted persons collude to author and approve a bad change. -*Mitigation:* **Outside the scope of SLSA.** We use "two trusted persons" as a -proxy for "intent of the software producer". +*Mitigation:* This threat is not currently addressed by SLSA. We use "two +trusted persons" as a proxy for "intent of the software producer".
Trick reviewer into approving bad code @@ -273,7 +264,7 @@ proxy for "intent of the software producer". *Threat:* Construct a change that looks benign but is actually malicious, a.k.a. "bugdoor." -*Mitigation:* **Outside the scope of SLSA.** +*Mitigation:* This threat is not currently addressed by SLSA.
Reviewer blindly approves changes @@ -281,7 +272,7 @@ proxy for "intent of the software producer". *Threat:* Reviewer approves changes without actually reviewing, a.k.a. "rubber stamping." -*Mitigation:* **Outside the scope of SLSA.** +*Mitigation:* This threat is not currently addressed by SLSA.
@@ -339,13 +330,22 @@ change to MyPackage without review. *Threat:* Exploit a vulnerability in the implementation of the source code management system to bypass controls. -*Mitigation:* **Outside the scope of SLSA.** +*Mitigation:* This threat is not currently addressed by SLSA. -### (D) External build parameters +## Build threats -**TODO:** Move under "Build threats". +A build integrity threat is a potential for an adversary to introduce behavior +to an artifact without changing its source code, or to build from a +source, dependency, and/or process that is not intended by the software +producer. + +The SLSA Build track mitigates these threats when the consumer +[verifies artifacts](verifying-artifacts.md) against expectations, confirming +that the artifact they received was built in the expected manner. + +### (D) External build parameters An adversary builds from a version of the source code that does not match the official source control repository, or changes the build parameters to inject @@ -433,141 +433,6 @@ the source repo does not match the expected value. -## Dependency threats - -**TODO:** Move after Usage Threats. - -A dependency threat is a potential for an adversary to introduce unintended -behavior in one artifact by compromising some other artifact that the former -depends on at build time. (Runtime dependencies are excluded from the model, as -[noted below](#runtime-dep).) - -Unlike other threat categories, dependency threats develop recursively through -the supply chain and can only be exploited indirectly. For example, if -application *A* includes library *B* as part of its build process, then a build -or source threat to *B* is also a dependency threat to *A*. Furthermore, if -library *B* uses build tool *C*, then a source or build threat to *C* is also a -dependency threat to both *A* and *B*. - -This version of SLSA does not explicitly address dependency threats, but we -expect that a future version will. In the meantime, you can [apply SLSA -recursively] to your dependencies in order to reduce the risk of dependency -threats. - -- **TODO:** Should we distinguish 1P vs 3P boundaries in the diagram, or - otherwise visualize 1P/3P? -- **TODO:** Expand to cover typosquatting, dependency confusion, and other - "dependency" threats. -- **TODO:** The word "compromised" is a bit too restrictive. If the publisher - intends to do harm, either because they tricked you into using a dependency - (typosquatting or dependency confusion), or because they were good and now - do something bad, that's not really "compromised" per se. -- **TODO:** Should we expand this to cover "transitive SLSA verification"? -- **TODO:** Update the Terminology page to show "build time" vs "runtime", - since the latter term results in confusion. Also consider the term "deploy - time" as an alternative. - -[apply SLSA recursively]: verifying-artifacts.md#step-3-optional-check-dependencies-recursively - -### Build dependency - -An adversary compromises the target artifact through one of its build -dependencies. Any artifact that is present in the build environment and has the -ability to influence the output is considered a build dependency. - -
Include a vulnerable dependency (library, base image, bundled file, etc.) - -*Threat:* Statically link, bundle, or otherwise include an artifact that is -compromised or has some vulnerability, causing the output artifact to have the -same vulnerability. - -*Example:* The C++ program MyPackage statically links libDep at build time. A -contributor accidentally introduces a security vulnerability into libDep. The -next time MyPackage is built, it picks up and includes the vulnerable version of -libDep, resulting in MyPackage also having the security vulnerability. - -*Mitigation:* **TODO** - -
-
Use a compromised build tool (compiler, utility, interpreter, OS package, etc.) - -*Threat:* Use a compromised tool or other software artifact during the build -process, which alters the build process and injects unintended behavior into the -output artifact. - -*Example:* MyPackage is a tarball containing an ELF executable, created by -running `/usr/bin/tar` during its build process. An adversary compromises the -`tar` OS package such that `/usr/bin/tar` injects a backdoor into every ELF -executable it writes. The next time MyPackage is built, the build picks up the -vulnerable `tar` package, which injects the backdoor into the resulting -MyPackage artifact. - -*Mitigation:* **TODO** - -
- -Reminder: dependencies that look like [runtime dependencies](#runtime-dep) -actually become build dependencies if they get loaded at build time. - -
Use a compromised runtime dependency during the build (for tests, dynamic linking, etc.) - -*Threat:* During the build process, use a compromised runtime dependency (such -as during testing or dynamic linking), which alters the build process and -injects unwanted behavior into the output. - -**NOTE:** This is technically the same case as [Use a compromised build -tool](#build-tool). We call it out to remind the reader that -[runtime dependencies](#runtime-dep) can become build dependencies if they are -loaded during the build. - -*Example:* MyPackage has a runtime dependency on package Dep, meaning that Dep -is not included in MyPackage but required to be installed on the user's machine -at the time MyPackage is run. However, Dep is also loaded during the build -process of MyPackage as part of a test. An adversary compromises Dep such that, -when run during a build, it injects a backdoor into the output artifact. The -next time MyPackage is built, it picks up and loads Dep during the build -process. The malicious code then injects the backdoor into the new MyPackage -artifact. - -*Mitigation:* In addition to all the mitigations for build tools, you can often -avoid runtime dependencies becoming build dependencies by isolating tests to a -separate environment that does not have write access to the output artifact. - -
- -### Related threats - -The following threats are related to "dependencies" but are not modeled as -"dependency threats". - -
Use a compromised dependency at runtime (modeled separately) - -*Threat:* Load a compromised artifact at runtime, thereby compromising the user -or environment where the software ran. - -*Example:* MyPackage lists package Dep as a runtime dependency. Adversary -publishes a compromised version of Dep that runs malicious code on the user's -machine when Dep is loaded at runtime. An end user installs MyPackage, which in -turn installs the compromised version of Dep. When the user runs MyPackage, it -loads and executes the malicious code from Dep. - -*Mitigation:* N/A - This threat is out of scope of SLSA. SLSA's threat model -does not explicitly model runtime dependencies. Instead, each runtime dependency -is considered a distinct artifact with its own threats. - -
- -## Build threats - -A build integrity threat is a potential for an adversary to introduce behavior -to an artifact without changing its source code, or to build from a -source, dependency, and/or process that is not intended by the software -producer. - -The SLSA Build track mitigates these threats when the consumer -[verifies artifacts](verifying-artifacts.md) against expectations, confirming -that the artifact they received was built in the expected manner. - ### (E) Build process An adversary introduces an unauthorized change to a build output through @@ -808,9 +673,10 @@ from the public registry instead of the internal one. *Threat:* Register a package name that is similar looking to a popular package and get users to use your malicious package instead of the benign one. -*Mitigation:* **Mostly outside the scope of SLSA.** That said, the requirement -to make the source available can be a mild deterrent, can aid investigation or -ad-hoc analysis, and can complement source-based typosquatting solutions. +*Mitigation:* This threat is not currently addressed by SLSA. That said, the +requirement to make the source available can be a mild deterrent, can aid +investigation or ad-hoc analysis, and can complement source-based typosquatting +solutions. @@ -818,6 +684,128 @@ ad-hoc analysis, and can complement source-based typosquatting solutions. **TODO:** What should we put here? +## Dependency threats + +A dependency threat is a potential for an adversary to introduce unintended +behavior in one artifact by compromising some other artifact that the former +depends on at build time. (Runtime dependencies are excluded from the model, as +[noted below](#runtime-dep).) + +Unlike other threat categories, dependency threats develop recursively through +the supply chain and can only be exploited indirectly. For example, if +application *A* includes library *B* as part of its build process, then a build +or source threat to *B* is also a dependency threat to *A*. Furthermore, if +library *B* uses build tool *C*, then a source or build threat to *C* is also a +dependency threat to both *A* and *B*. + +This version of SLSA does not explicitly address dependency threats, but we +expect that a future version will. In the meantime, you can [apply SLSA +recursively] to your dependencies in order to reduce the risk of dependency +threats. + +- **TODO:** Should we distinguish 1P vs 3P boundaries in the diagram, or + otherwise visualize 1P/3P? +- **TODO:** Expand to cover typosquatting, dependency confusion, and other + "dependency" threats. +- **TODO:** The word "compromised" is a bit too restrictive. If the publisher + intends to do harm, either because they tricked you into using a dependency + (typosquatting or dependency confusion), or because they were good and now + do something bad, that's not really "compromised" per se. +- **TODO:** Should we expand this to cover "transitive SLSA verification"? +- **TODO:** Update the Terminology page to show "build time" vs "runtime", + since the latter term results in confusion. Also consider the term "deploy + time" as an alternative. + +[apply SLSA recursively]: verifying-artifacts.md#step-3-optional-check-dependencies-recursively + +### Build dependency + +An adversary compromises the target artifact through one of its build +dependencies. Any artifact that is present in the build environment and has the +ability to influence the output is considered a build dependency. + +
Include a vulnerable dependency (library, base image, bundled file, etc.) + +*Threat:* Statically link, bundle, or otherwise include an artifact that is +compromised or has some vulnerability, causing the output artifact to have the +same vulnerability. + +*Example:* The C++ program MyPackage statically links libDep at build time. A +contributor accidentally introduces a security vulnerability into libDep. The +next time MyPackage is built, it picks up and includes the vulnerable version of +libDep, resulting in MyPackage also having the security vulnerability. + +*Mitigation:* **TODO** + +
+
Use a compromised build tool (compiler, utility, interpreter, OS package, etc.) + +*Threat:* Use a compromised tool or other software artifact during the build +process, which alters the build process and injects unintended behavior into the +output artifact. + +*Example:* MyPackage is a tarball containing an ELF executable, created by +running `/usr/bin/tar` during its build process. An adversary compromises the +`tar` OS package such that `/usr/bin/tar` injects a backdoor into every ELF +executable it writes. The next time MyPackage is built, the build picks up the +vulnerable `tar` package, which injects the backdoor into the resulting +MyPackage artifact. + +*Mitigation:* **TODO** + +
+ +Reminder: dependencies that look like [runtime dependencies](#runtime-dep) +actually become build dependencies if they get loaded at build time. + +
Use a compromised runtime dependency during the build (for tests, dynamic linking, etc.) + +*Threat:* During the build process, use a compromised runtime dependency (such +as during testing or dynamic linking), which alters the build process and +injects unwanted behavior into the output. + +**NOTE:** This is technically the same case as [Use a compromised build +tool](#build-tool). We call it out to remind the reader that +[runtime dependencies](#runtime-dep) can become build dependencies if they are +loaded during the build. + +*Example:* MyPackage has a runtime dependency on package Dep, meaning that Dep +is not included in MyPackage but required to be installed on the user's machine +at the time MyPackage is run. However, Dep is also loaded during the build +process of MyPackage as part of a test. An adversary compromises Dep such that, +when run during a build, it injects a backdoor into the output artifact. The +next time MyPackage is built, it picks up and loads Dep during the build +process. The malicious code then injects the backdoor into the new MyPackage +artifact. + +*Mitigation:* In addition to all the mitigations for build tools, you can often +avoid runtime dependencies becoming build dependencies by isolating tests to a +separate environment that does not have write access to the output artifact. + +
+ +### Related threats + +The following threats are related to "dependencies" but are not modeled as +"dependency threats". + +
Use a compromised dependency at runtime (modeled separately) + +*Threat:* Load a compromised artifact at runtime, thereby compromising the user +or environment where the software ran. + +*Example:* MyPackage lists package Dep as a runtime dependency. Adversary +publishes a compromised version of Dep that runs malicious code on the user's +machine when Dep is loaded at runtime. An end user installs MyPackage, which in +turn installs the compromised version of Dep. When the user runs MyPackage, it +loads and executes the malicious code from Dep. + +*Mitigation:* N/A - This threat is not currently addressed by SLSA. SLSA's +threat model does not explicitly model runtime dependencies. Instead, each +runtime dependency is considered a distinct artifact with its own threats. + +
+ ## Availability threats **TODO:** Merge into the list above rather than having a separate section. @@ -849,23 +837,23 @@ retention and availability of the source code. *Threat:* Unable to perform a build with the intended dependencies. -*Mitigation:* **Outside the scope of SLSA.** That said, some solutions to -support hermetic and reproducible builds may also reduce the impact of this -threat. +*Mitigation:* This threat is not currently addressed by SLSA. That said, some +solutions to support hermetic and reproducible builds may also reduce the +impact of this threat.
De-list artifact *Threat:* The package registry stops serving the artifact. -*Mitigation:* N/A - This threat is out of scope of SLSA v1.0. +*Mitigation:* N/A - This threat is not currently addressed by SLSA.
De-list provenance *Threat:* The package registry stops serving the provenance. -*Mitigation:* N/A - This threat is out of scope of SLSA v1.0. +*Mitigation:* N/A - This threat is not currently addressed by SLSA.
From 882a5f1baa1bdffbfb8b4d92a9e92c20fca57f07 Mon Sep 17 00:00:00 2001 From: Tom Hennen Date: Mon, 23 Sep 2024 10:55:22 -0400 Subject: [PATCH 09/14] content: draft: define how downstream users can verify the SLSA source track level of revisions (#1094) fixes #1071 fixes #1042 refs #241 This PR modifies _draft_ content of the SLSA spec. See [discussions here](https://docs.google.com/document/d/13Xt8mA_2b00McGX2vkyhu4GQdFAqtXPu7YXE8ZA6ISE/edit?resourcekey=0-EqfHF79tUWAKp4PzsE3z1A&tab=t.0#heading=h.fhg4lsemfpz2) [and here](https://docs.google.com/document/d/1PwhekVB1iDpcgCQRNVN_aesoVdOiTruoebCs896aGxw/edit#bookmark=id.oqoqjt4urxm). Google document requires [slsa-discussion@googlegroups.com](mailto:slsa-discussion@googlegroups.com) membership. Define how downstream users can verify the SLSA source track level of revisions by using a [VSAs](http://slsa.dev/verification_summary) produced by the Source Control Platform (SCP). To use these VSAs users do not need to know the specifics of how any given SCP or Version Control System (VCS) meets the SLSA source requirements (which may vary greatly from implementation to implementation). Instead it is left to the SCP or another trusted 'authority' to make that determination for downstream users. The question of _how_ the authority ensures those claims to be true is left undefined in this change. Future updates can include guidance for how to verify source level when combined with [build provenance](https://slsa.dev/provenance). 1. A user wants to verify https://github.com/slsa-framework/slsa/commit/9a04d1ee393b5be2773b1ce204f61fe0fd02366a is SLSA source level 3. 2. The user 'trusts' GitHub as the authority for source revisions managed by GitHub. 3. The user requests a VSA for https://github.com/slsa-framework/slsa/commit/9a04d1ee393b5be2773b1ce204f61fe0fd02366a from a TBD API 4. The user verifies the VSA following [the standard instructions](https://slsa.dev/spec/draft/verification_summary#how-to-verify) or using [standard tooling](https://github.com/slsa-framework/slsa-verifier?tab=readme-ov-file#verification-summary-attestations-vsa) and looking for `SLSA_SOURCE_LEVEL_2` in the `verifiedLevels` field. --------- Signed-off-by: Tom Hennen Signed-off-by: Tom Hennen Co-authored-by: Zachariah Cox Co-authored-by: Aditya Sirish <8928778+adityasaky@users.noreply.github.com> Co-authored-by: Marcela Melara --- docs/spec/draft/source-requirements.md | 117 +++++++++++++++++++++++++ 1 file changed, 117 insertions(+) diff --git a/docs/spec/draft/source-requirements.md b/docs/spec/draft/source-requirements.md index 360b5e0a0..da783a7de 100644 --- a/docs/spec/draft/source-requirements.md +++ b/docs/spec/draft/source-requirements.md @@ -233,3 +233,120 @@ Branches may have differing security postures, and a change can be approved for The change management tool MUST record timestamps for all contributions and review-related activities. User-provided timestamps MUST NOT be used. + +## Communicating source levels + +SLSA source level details are communicated using attestations. +These attestations either refer to a source revision itself or provide context needed to evaluate an attestation that _does_ refer to a revision. + +There are two broad categories of source attestations within the source track: + +1. Summary attestations: Used to communicate to downstream users what high level security properties a given source revision meets. +2. Provenance attestations: Provide trustworthy, tamper-proof, metadata with the necessary information to determine what high level security properties a given source revision has. + +To provide interoperability and ensure ease of use, it's essential that the summary attestations are applicable across all Source Control Platforms. +Due to the significant differences in how SCPs operate and how they may chose to meet the Source Track requirements it is preferable to +allow for flexibility with the full attestations. To that end SLSA leaves provenance attestations undefined and up to the SCPs to determine +what works best in their environment. + +### Summary attestation + +Summary attestations are issued by some authority that has sufficient evidence to make the determination of a given +revision's source level. Summary attestations convey properties about the revision as a whole and summarize properties computed over all +the changes that contributed to that revision over its history. + +The source track issues summary attestations using [Verification Summary Attestations (VSAs)](./verification_summary.md) as follows: + +1. `subject.uri` SHOULD be set to a human readable URI of the revision. +2. `subject.digest` MUST include the revision identifier (e.g. `gitCommit`) and MAY include other digests over the contents of the revision (e.g. `gitTree`, `dirHash`, etc...). +SCPs that do not use cryptographic digests MUST define a canonical type that is used to identify immutable revisions (e.g. `svn_revision_id`)[^1]. +3. `subject.annotations.source_branches` SHOULD be set to a list of branches that pointed to this revision at any point in their history. + - git branches MUST be fully qualified (e.g. `refs/head/main`) to reduce the likelyhood of confusing downstream tooling. +4. `resourceUri` MUST be set to the URI of the repository, preferably using [SPDX Download Location](https://spdx.github.io/spdx-spec/v2.3/package-information/#77-package-download-location-field). +E.g. `git+https://github.com/foo/hello-world`. +5. `verifiedLevels` MUST include the SLSA source track level the verifier asserts the revision meets. One of `SLSA_SOURCE_LEVEL_0`, `SLSA_SOURCE_LEVEL_1`, `SLSA_SOURCE_LEVEL_2`, `SLSA_SOURCE_LEVEL_3`. +MAY include additional properties as asserted by the verifier. The verifier MUST include _only_ the highest SLSA source level met by the revision. +6. `dependencyLevels` MAY be empty as source revisions are typically terminal nodes in a supply chain. + +Verifiers MAY issue these attestations based on their understanding of the underlying system (e.g. based on design docs, security reviews, etc...), +but at SLSA Source Level 3 MUST use tamper-proof [provenance attestations](#provenance-attestations) appropriate to their SCP when making the assessment. + +The SLSA source track MAY create additional tags to include in `verifiedLevels` which attest +to other properties of a revision (e.g. if it was code reviewed). All SLSA source tags will start with `SLSA_SOURCE_`. + +#### Populating source_branches + +The summary attestation issuer may choose to populate `source_branches` in any way they wish. +Downstream users are expected to be familiar with the method used by the issuer. + +Example implementations: + +- Issue a new VSA for each merged Pull Request and add the destination branch to `source_branches`. +- Issue a new VSA each time a 'consumable branch' is updated to point to a new revision. + +#### Example + +```json +"_type": "https://in-toto.io/Statement/v1", +"subject": [{ + "uri": "https://github.com/foo/hello-world/commit/9a04d1ee393b5be2773b1ce204f61fe0fd02366a", + "digest": {"gitCommit": "9a04d1ee393b5be2773b1ce204f61fe0fd02366a"}, + "annotations": {"source_branches": ["refs/heads/main", "refs/heads/release_1.0"]} +}], + +"predicateType": "https://slsa.dev/verification_summary/v1", +"predicate": { + "verifier": { + "id": "https://example.com/source_verifier", + }, + "timeVerified": "1985-04-12T23:20:50.52Z", + "resourceUri": "git+https://github.com/foo/hello-world", + "policy": { + "uri": "https://example.com/slsa_source.policy", + }, + "verificationResult": "PASSED", + "verifiedLevels": ["SLSA_SOURCE_LEVEL_3"], +} +``` + +#### How to verify + +- VSAs for source revisions MUST follow [the standard method of VSA verification](./verification_summary.md#how-to-verify). +- Users SHOULD check that an allowed branch is listed in `subject.annotations.source_branches` to ensure the revision is from an appropriate context within the repository. +- Users SHOULD check that the expected `SLSA_SOURCE_LEVEL_` is listed within `verifiedLevels`. +- Users MUST ignore any unrecognized values in `verifiedLevels`. + +### Provenance attestations + +Source provenance attestations provide tamper-proof evidence (ideally signed [in-toto attestations](https://github.com/in-toto/attestation/blob/main/README.md)) +that can be used to determine what SLSA Source Level or other high level properties a given revision meets. +This evidence can be used by an authority as the basis for issuing a [Summary Attestation](#summary-attestation). + +SCPs and VCSes may have different methods of operating that necessitate different forms of evidence. +E.g. GitHub-based workflows may need different evidence than Gerrit-based workflows, which would both likely be different from workflows that +operate over Subversion repositories. + +These differences also mean that depending on the SCP and the repo's configuration the issuers of +provenance attestations may vary from implementation to implementation, often because entities with +the knowledge to issue them may vary. The authority that issues +[summary-attestations](#summary-attestation) MUST understand which entity should issue each provenance +attestation type and ensure the full attestations come from the appropriate issuer. + +'Source provenance attestations' is a generic term used to refer to any type of attestation that provides +evidence the process used to create a revision. + +Example source provenance attestations: + +- A TBD attestation which describes the revision's parents and the actors involved in creating this revision. +- A "code review" attestation which describes the basics of any code review that took place. +- An "authentication" attestation which describes how the actors involved in any revision were authenticated. +- A [Vuln Scan attestation](https://github.com/in-toto/attestation/blob/main/spec/predicates/vuln.md) + which describes the results of a vulnerability scan over the contents of the revision. +- A [Test Results attestation](https://github.com/in-toto/attestation/blob/main/spec/predicates/test-result.md) + which describes the results of any tests run on the revision. +- An [SPDX attestation](https://github.com/in-toto/attestation/blob/main/spec/predicates/spdx.md) + which provides a software bill of materials for the revision. +- A [SCAI attestation](https://github.com/in-toto/attestation/blob/main/spec/predicates/scai.md) used to + describe which source quality tools were run on the revision. + +[^1]: in-toto attestations allow non-cryptographic digest types: https://github.com/in-toto/attestation/blob/main/spec/v1/digest_set.md#supported-algorithms. From a38c701c7fb4193f6ddbadc86d03ec66fa2b889f Mon Sep 17 00:00:00 2001 From: Mend Renovate Date: Tue, 24 Sep 2024 16:48:52 +0200 Subject: [PATCH 10/14] impl: Update dependency webrick to v1.8.2 [SECURITY] (#1153) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This PR contains the following updates: | Package | Change | Age | Adoption | Passing | Confidence | |---|---|---|---|---|---| | [webrick](https://redirect.github.com/ruby/webrick) | `1.8.1` -> `1.8.2` | [![age](https://developer.mend.io/api/mc/badges/age/rubygems/webrick/1.8.2?slim=true)](https://docs.renovatebot.com/merge-confidence/) | [![adoption](https://developer.mend.io/api/mc/badges/adoption/rubygems/webrick/1.8.2?slim=true)](https://docs.renovatebot.com/merge-confidence/) | [![passing](https://developer.mend.io/api/mc/badges/compatibility/rubygems/webrick/1.8.1/1.8.2?slim=true)](https://docs.renovatebot.com/merge-confidence/) | [![confidence](https://developer.mend.io/api/mc/badges/confidence/rubygems/webrick/1.8.1/1.8.2?slim=true)](https://docs.renovatebot.com/merge-confidence/) | ### GitHub Vulnerability Alerts #### [CVE-2024-47220](https://nvd.nist.gov/vuln/detail/CVE-2024-47220) An issue was discovered in the WEBrick toolkit through 1.8.1 for Ruby. It allows HTTP request smuggling by providing both a Content-Length header and a Transfer-Encoding header, e.g., "GET /admin HTTP/1.1\r\n" inside of a "POST /user HTTP/1.1\r\n" request. NOTE: the supplier's position is "Webrick should not be used in production." --- ### Release Notes
ruby/webrick (webrick) ### [`v1.8.2`](https://redirect.github.com/ruby/webrick/releases/tag/v1.8.2) [Compare Source](https://redirect.github.com/ruby/webrick/compare/v1.8.1...v1.8.2) #### What's Changed - Drop commented-out line by [@​olleolleolle](https://redirect.github.com/olleolleolle) in [https://github.com/ruby/webrick/pull/108](https://redirect.github.com/ruby/webrick/pull/108) - Add Ruby 3.1 & 3.2 to CI matrix by [@​tricknotes](https://redirect.github.com/tricknotes) in [https://github.com/ruby/webrick/pull/109](https://redirect.github.com/ruby/webrick/pull/109) - Fix/redos by [@​ooooooo-q](https://redirect.github.com/ooooooo-q) in [https://github.com/ruby/webrick/pull/114](https://redirect.github.com/ruby/webrick/pull/114) - Raise HTTPStatus::BadRequest for requests with invalid/duplicate content-length headers by [@​jeremyevans](https://redirect.github.com/jeremyevans) in [https://github.com/ruby/webrick/pull/120](https://redirect.github.com/ruby/webrick/pull/120) - Bump actions/checkout from 3 to 4 by [@​dependabot](https://redirect.github.com/dependabot) in [https://github.com/ruby/webrick/pull/121](https://redirect.github.com/ruby/webrick/pull/121) - Improve CI by [@​hsbt](https://redirect.github.com/hsbt) in [https://github.com/ruby/webrick/pull/123](https://redirect.github.com/ruby/webrick/pull/123) - Fix WEBrick::TestFileHandler#test_short_filename test not working on mswin by [@​KJTsanaktsidis](https://redirect.github.com/KJTsanaktsidis) in [https://github.com/ruby/webrick/pull/128](https://redirect.github.com/ruby/webrick/pull/128) - Fix bug chunk extension detection by [@​jeremyevans](https://redirect.github.com/jeremyevans) in [https://github.com/ruby/webrick/pull/125](https://redirect.github.com/ruby/webrick/pull/125) - Fix CI. by [@​ioquatix](https://redirect.github.com/ioquatix) in [https://github.com/ruby/webrick/pull/131](https://redirect.github.com/ruby/webrick/pull/131) - Merge multiple cookie headers, preserving semantic correctness. by [@​ioquatix](https://redirect.github.com/ioquatix) in [https://github.com/ruby/webrick/pull/130](https://redirect.github.com/ruby/webrick/pull/130) - Test on macos-latest by [@​byroot](https://redirect.github.com/byroot) in [https://github.com/ruby/webrick/pull/132](https://redirect.github.com/ruby/webrick/pull/132) - Require CRLF line endings in request line and headers by [@​jeremyevans](https://redirect.github.com/jeremyevans) in [https://github.com/ruby/webrick/pull/138](https://redirect.github.com/ruby/webrick/pull/138) - Prefer squigly heredocs. by [@​ioquatix](https://redirect.github.com/ioquatix) in [https://github.com/ruby/webrick/pull/143](https://redirect.github.com/ruby/webrick/pull/143) - Only strip space and horizontal tab in headers by [@​jeremyevans](https://redirect.github.com/jeremyevans) in [https://github.com/ruby/webrick/pull/141](https://redirect.github.com/ruby/webrick/pull/141) - Treat missing CRLF separator after headers as an EOFError by [@​jeremyevans](https://redirect.github.com/jeremyevans) in [https://github.com/ruby/webrick/pull/142](https://redirect.github.com/ruby/webrick/pull/142) - Return 400 response for chunked requests with unexpected data after chunk by [@​jeremyevans](https://redirect.github.com/jeremyevans) in [https://github.com/ruby/webrick/pull/136](https://redirect.github.com/ruby/webrick/pull/136) - Fix reference to URI::REGEXP::PATTERN::HOST by [@​casperisfine](https://redirect.github.com/casperisfine) in [https://github.com/ruby/webrick/pull/144](https://redirect.github.com/ruby/webrick/pull/144) - Prevent request smuggling by [@​jeremyevans](https://redirect.github.com/jeremyevans) in [https://github.com/ruby/webrick/pull/146](https://redirect.github.com/ruby/webrick/pull/146) #### New Contributors - [@​tricknotes](https://redirect.github.com/tricknotes) made their first contribution in [https://github.com/ruby/webrick/pull/109](https://redirect.github.com/ruby/webrick/pull/109) - [@​ooooooo-q](https://redirect.github.com/ooooooo-q) made their first contribution in [https://github.com/ruby/webrick/pull/114](https://redirect.github.com/ruby/webrick/pull/114) - [@​KJTsanaktsidis](https://redirect.github.com/KJTsanaktsidis) made their first contribution in [https://github.com/ruby/webrick/pull/128](https://redirect.github.com/ruby/webrick/pull/128) - [@​byroot](https://redirect.github.com/byroot) made their first contribution in [https://github.com/ruby/webrick/pull/132](https://redirect.github.com/ruby/webrick/pull/132) - [@​casperisfine](https://redirect.github.com/casperisfine) made their first contribution in [https://github.com/ruby/webrick/pull/144](https://redirect.github.com/ruby/webrick/pull/144) **Full Changelog**: https://github.com/ruby/webrick/compare/v1.8.1...v1.8.2
--- ### Configuration 📅 **Schedule**: Branch creation - "" (UTC), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] If you want to rebase/retry this PR, check this box --- This PR was generated by [Mend Renovate](https://mend.io/renovate/). View the [repository job log](https://developer.mend.io/github/slsa-framework/slsa). Signed-off-by: Mend Renovate --- docs/Gemfile.lock | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/Gemfile.lock b/docs/Gemfile.lock index 58c4644b4..0f8cfd4fa 100644 --- a/docs/Gemfile.lock +++ b/docs/Gemfile.lock @@ -259,7 +259,7 @@ GEM tzinfo (2.0.6) concurrent-ruby (~> 1.0) unicode-display_width (1.8.0) - webrick (1.8.1) + webrick (1.8.2) PLATFORMS ruby From 1382832fd0e12fab1f34895cde4d041cb93036b4 Mon Sep 17 00:00:00 2001 From: Mend Renovate Date: Tue, 24 Sep 2024 16:49:11 +0200 Subject: [PATCH 11/14] impl: Update actions/setup-node action to v4.0.4 (#1147) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [actions/setup-node](https://redirect.github.com/actions/setup-node) | action | patch | `v4.0.3` -> `v4.0.4` | --- ### Release Notes
actions/setup-node (actions/setup-node) ### [`v4.0.4`](https://redirect.github.com/actions/setup-node/compare/v4.0.3...v4.0.4) [Compare Source](https://redirect.github.com/actions/setup-node/compare/v4.0.3...v4.0.4)
--- ### Configuration 📅 **Schedule**: Branch creation - "every weekend" (UTC), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] If you want to rebase/retry this PR, check this box --- This PR was generated by [Mend Renovate](https://mend.io/renovate/). View the [repository job log](https://developer.mend.io/github/slsa-framework/slsa). Signed-off-by: Mend Renovate --- .github/workflows/lint.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/lint.yml b/.github/workflows/lint.yml index df584fbf3..e9a949740 100644 --- a/.github/workflows/lint.yml +++ b/.github/workflows/lint.yml @@ -8,7 +8,7 @@ jobs: - name: Checkout uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4.1.7 - name: Setup Node - uses: actions/setup-node@1e60f620b9541d16bece96c5465dc8ee9832be0b # v4.0.3 + uses: actions/setup-node@0a44ba7841725637a19e28fa30b79a866c81b0a6 # v4.0.4 - run: npm ci --ignore-scripts - run: npm run lint --silent - run: ./lint.sh From 0a0696ed49ccc5f47d9c42688d2f2df4b17905f8 Mon Sep 17 00:00:00 2001 From: Tom Hennen Date: Wed, 25 Sep 2024 11:27:12 -0400 Subject: [PATCH 12/14] nonspec: Suggest people assign reviewers to PRs (#1154) Suggest PR authors assign specific reviewers and ping the Slack channel if they want. The goal is to make it more clear who is expected to take the next action on PRs vs the current situation where the maintainers may think someone else will take a look or that they may have missed the initial PR request. fixes #1149 --------- Signed-off-by: Tom Hennen Signed-off-by: Tom Hennen Co-authored-by: Marcela Melara --- CONTRIBUTING.md | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 9d13f4479..3279b9059 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -160,14 +160,24 @@ Review process: 1. Ensure that the PR meets the [pull request conventions]. -2. GitHub will automatically assign the maintainers as reviewers. You will need - a different number of approvals for different PR types. Your reviewers may - ask that you use a different PR type. +2. If there is a particular set of maintainers you've been working with, feel + free to assign the PR to them. If they don't have time to review they + should feel free to assign to someone else, or provide feedback on when + they can get to it. Otherwise, assign to + `@slsa-framework/specification-maintainers`. + - Feel free to ping the reviwers in the + [slsa-specification Slack](https://openssf.slack.com/archives/C03NUSAPKC6) + when the PR is ready for review. + - You will need a different number of approvals for different + [PR types](#pull-request-types). Your reviewers may ask that you use a + different PR type. 3. Wait an appropriate amount of time to allow for lazy consensus. Different types have different minimum waiting periods. The waiting period begins at the timestamp of either the final required approval or the latest non-author comment, whichever is later. + - If a few days have passed without any feedback please feel free to ping + the PR and [in Slack](https://openssf.slack.com/archives/C03NUSAPKC6). 4. Once the waiting period has passed, a maintainer will merge your PR. Expect your PR to be squashed+merged unless your reviewers advise you otherwise. From e1b9c50ffcc1f6c5c26831d425bdf9b2fb8b9941 Mon Sep 17 00:00:00 2001 From: Arnaud J Le Hors Date: Mon, 30 Sep 2024 11:36:50 +0200 Subject: [PATCH 13/14] editorial: Update statement about compliance with SSDF (#1157) Closes #1155. Signed-off-by: Arnaud J Le Hors --- docs/spec/draft/about.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/docs/spec/draft/about.md b/docs/spec/draft/about.md index dc1bfade4..b27a90f03 100644 --- a/docs/spec/draft/about.md +++ b/docs/spec/draft/about.md @@ -19,8 +19,7 @@ SLSA offers: - A common vocabulary to talk about software supply chain security - A way to secure your incoming supply chain by evaluating the trustworthiness of the artifacts you consume - An actionable checklist to improve your own software's security -- A way to measure your efforts toward compliance with forthcoming - Executive Order standards in the [Secure Software Development Framework (SSDF)](https://csrc.nist.gov/Projects/ssdf) +- A way to measure your efforts toward compliance with the [Secure Software Development Framework (SSDF)](https://csrc.nist.gov/Projects/ssdf) ## Why SLSA is needed From 8629a9be8aa664e1ff613599076bafde79a1b031 Mon Sep 17 00:00:00 2001 From: Zachariah Cox Date: Tue, 1 Oct 2024 09:10:13 -0400 Subject: [PATCH 14/14] catch a few more places. --- docs/spec/draft/source-requirements.md | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/docs/spec/draft/source-requirements.md b/docs/spec/draft/source-requirements.md index da783a7de..372c62457 100644 --- a/docs/spec/draft/source-requirements.md +++ b/docs/spec/draft/source-requirements.md @@ -245,8 +245,9 @@ There are two broad categories of source attestations within the source track: 2. Provenance attestations: Provide trustworthy, tamper-proof, metadata with the necessary information to determine what high level security properties a given source revision has. To provide interoperability and ensure ease of use, it's essential that the summary attestations are applicable across all Source Control Platforms. -Due to the significant differences in how SCPs operate and how they may chose to meet the Source Track requirements it is preferable to -allow for flexibility with the full attestations. To that end SLSA leaves provenance attestations undefined and up to the SCPs to determine +Due to the significant differences in how SCSs operate and how they may chose to meet the Source Track requirements it is preferable to +allow for flexibility with the full attestations. +To that end SLSA leaves provenance attestations undefined and up to each SCS to determine what works best in their environment. ### Summary attestation @@ -259,9 +260,9 @@ The source track issues summary attestations using [Verification Summary Attesta 1. `subject.uri` SHOULD be set to a human readable URI of the revision. 2. `subject.digest` MUST include the revision identifier (e.g. `gitCommit`) and MAY include other digests over the contents of the revision (e.g. `gitTree`, `dirHash`, etc...). -SCPs that do not use cryptographic digests MUST define a canonical type that is used to identify immutable revisions (e.g. `svn_revision_id`)[^1]. +SCSs that do not use cryptographic digests MUST define a canonical type that is used to identify immutable revisions (e.g. `svn_revision_id`)[^1]. 3. `subject.annotations.source_branches` SHOULD be set to a list of branches that pointed to this revision at any point in their history. - - git branches MUST be fully qualified (e.g. `refs/head/main`) to reduce the likelyhood of confusing downstream tooling. + - git branches MUST be fully qualified (e.g. `refs/head/main`) to reduce the likelihood of confusing downstream tooling. 4. `resourceUri` MUST be set to the URI of the repository, preferably using [SPDX Download Location](https://spdx.github.io/spdx-spec/v2.3/package-information/#77-package-download-location-field). E.g. `git+https://github.com/foo/hello-world`. 5. `verifiedLevels` MUST include the SLSA source track level the verifier asserts the revision meets. One of `SLSA_SOURCE_LEVEL_0`, `SLSA_SOURCE_LEVEL_1`, `SLSA_SOURCE_LEVEL_2`, `SLSA_SOURCE_LEVEL_3`. @@ -269,7 +270,7 @@ MAY include additional properties as asserted by the verifier. The verifier MUS 6. `dependencyLevels` MAY be empty as source revisions are typically terminal nodes in a supply chain. Verifiers MAY issue these attestations based on their understanding of the underlying system (e.g. based on design docs, security reviews, etc...), -but at SLSA Source Level 3 MUST use tamper-proof [provenance attestations](#provenance-attestations) appropriate to their SCP when making the assessment. +but at SLSA Source Level 3 MUST use tamper-proof [provenance attestations](#provenance-attestations) when making the assessment. The SLSA source track MAY create additional tags to include in `verifiedLevels` which attest to other properties of a revision (e.g. if it was code reviewed). All SLSA source tags will start with `SLSA_SOURCE_`. @@ -322,11 +323,11 @@ Source provenance attestations provide tamper-proof evidence (ideally signed [in that can be used to determine what SLSA Source Level or other high level properties a given revision meets. This evidence can be used by an authority as the basis for issuing a [Summary Attestation](#summary-attestation). -SCPs and VCSes may have different methods of operating that necessitate different forms of evidence. +SCSs may have different methods of operating that necessitate different forms of evidence. E.g. GitHub-based workflows may need different evidence than Gerrit-based workflows, which would both likely be different from workflows that operate over Subversion repositories. -These differences also mean that depending on the SCP and the repo's configuration the issuers of +These differences also mean that depending on configuration the issuers of provenance attestations may vary from implementation to implementation, often because entities with the knowledge to issue them may vary. The authority that issues [summary-attestations](#summary-attestation) MUST understand which entity should issue each provenance