From fabaacef04fb525f6c223a0a7f52031ae996d0c2 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Alexis=20M=C3=A9taireau?= Date: Thu, 12 Dec 2024 11:37:53 +0100 Subject: [PATCH] Fix a typo in the threat model docs MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Alexis Métaireau --- content/en/about/threat-model.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/about/threat-model.md b/content/en/about/threat-model.md index ab7aaa76..fbeb2731 100644 --- a/content/en/about/threat-model.md +++ b/content/en/about/threat-model.md @@ -28,7 +28,7 @@ It does not guarantee that the signer *should* be able to authenticate (for inst Further, if Sigstore itself is compromised, this property may not hold; see our analysis below. **What should I do or keep in mind to mitigate these threats when using Sigstore?** -First, users of Sigstore should ensure that they have tooling to audit Sigstore’s transparency logs for consistency and to monitor the use of their identities in Sigstore. Sistore operators provide [some tooling](https://github.com/sigstore/rekor-monitor) for these efforts. Second, all OIDC accounts used to create Sigstore signatures should have 2FA enabled to reduce the likelihood of a compromise. +First, users of Sigstore should ensure that they have tooling to audit Sigstore’s transparency logs for consistency and to monitor the use of their identities in Sigstore. Sigstore operators provide [some tooling](https://github.com/sigstore/rekor-monitor) for these efforts. Second, all OIDC accounts used to create Sigstore signatures should have 2FA enabled to reduce the likelihood of a compromise. In this threat model, we consider the compromise of any of the following: