Pick up changes from PR #1316

Signed-off-by: Arnaud Le Hors <[email protected]>

Author: lehors

Diff for: docs/spec/v1.1-rc2/terminology.md

@@ -157,12 +157,13 @@ It is the primary identifier to which consumers attach expectations.
 
 | Term | Description
 | ---- | -----------
+| Distribution platform | An entity responsible for mapping package names to immutable package artifacts.
 | Package | An identifiable unit of software intended for distribution, ambiguously meaning either an "artifact" or a "package name". Only use this term when the ambiguity is acceptable or desirable.
 | Package artifact | A file or other immutable object that is intended for distribution.
 | Package ecosystem | A set of rules and conventions governing how packages are distributed, including how clients resolve a package name into one or more specific artifacts.
 | Package manager client | Client-side tooling to interact with a package ecosystem.
 | Package name | <p>The primary identifier for a mutable collection of artifacts that all represent different versions of the same software. This is the primary identifier that consumers use to obtain the software.<p>A package name is specific to an ecosystem + registry, has a maintainer, is more general than a specific hash or version, and has a "correct" source location. A package ecosystem may group package names into some sort of hierarchy, such as the Group ID in Maven, though SLSA does not have a special term for this.
-| Package registry | An entity responsible for mapping package names to artifacts within a packaging ecosystem. Most ecosystems support multiple registries, usually a single global registry and multiple private registries.
+| Package registry | A specific type of "distribution platform" used within a packaging ecosystem. Most ecosystems support multiple registries, usually a single global registry and multiple private registries.
 | Publish [a package] | Make an artifact available for use by registering it with the package registry. In technical terms, this means associating an artifact to a package name. This does not necessarily mean making the artifact fully public; an artifact may be published for only a subset of users, such as internal testing or a closed beta.
 
 <details><summary>Ambiguous terms to avoid</summary>

Diff for: docs/spec/v1.1-rc2/threats.md

@@ -110,30 +110,30 @@ A best practice is to require approval of any changes via a change management to
 *Mitigation:* The producer must ensure that no actor is able to control or influence multiple accounts with review privileges.
 
 *Example:* Adversary creates a pull request using a secondary account and approves it using their primary account.
-
-Solution: The producer must track all actors who have both explicit review permissions and the independent ability to control a privileged bot.
-A common vector for this attack is to influence a robot account with the permission to review or contribute code.
-Control of the robot account and an actor's own personal account is enough to exploit this vulnerability.
-A common solution to this flow is to deny bot accounts from contributing or reviewing code, or to require more human reviews in those cases.
+Solution: The producer must track all actors who have both explicit review permissions and the independent ability to control
+a privileged bot. A common vector for this attack is to influence a robot account with the permission to review or contribute
+code. Control of the robot account and an actor's own personal account is enough to exploit this vulnerability. A common
+solution to this flow is to deny bot accounts from contributing or reviewing code, or to require more human reviews in those
+cases.
 
 </details>
 <details><summary>Use a robot account to submit change</summary>
 
 *Threat:* Exploit a robot account that has the ability to submit changes without
 two-person review.
 
-*Mitigation:* All changes require two-person review, even changes authored by
+*Mitigation:* All changes require review by two people, even changes authored by
 robots.
 
 *Example:* A file within the source repository is automatically generated by a
 robot, which is allowed to submit without review.
 Adversary compromises the robot and submits a malicious change.
-Solution: Require review for such changes.
+Solution: Require two-person review for such changes, ignoring the robot.
 
 </details>
 <details><summary>Abuse of rule exceptions</summary>
 
-*Threat:* Rule exceptions provide vector for abuse
+*Threat:* Rule exceptions provide vector for abuse.
 
 *Mitigation:* Remove rule exceptions.
 
@@ -770,7 +770,7 @@ packages. If a misconfigured victim attempts to install attacker's package with
 an internal name but from the public registry, then verification against
 expectations will fail.
 
-For more information see [Verifying artifacts](/spec/v1.1/verifying-artifacts)
+For more information see [Verifying artifacts](verifying-artifacts.md)
 and [Defender's Perspective: Dependency Confusion and Typosquatting Attacks](/blog/2024/08/dep-confusion-and-typosquatting).
 
 </details>