Merge pull request #496 from andrewpollock/patch-1

Fix typo

Author: bobcallaway

process/security_baseline.md

@@ -121,7 +121,7 @@ As a project matures and progresses towards graduation, it gains wider adoption.
 |Publicly known vulnerabilities of critical severity are fixed promptly. Fixes are  released promptly. <br /><br />Publicly known vulnerabilities of medium or high severity are fixed. Fixes are  released within 60 days.|To protect your software from known vulnerabilities.<br /><br />To protect downstream consumers from vulnerable software via transitive dependency.|Follow [Scorecard instructions to use a  tool](https://github.com/ossf/scorecard/blob/7ce8609469289d5f3b1bf5ee3122f42b4e3054fb/docs/checks.md#sast) to automatically update dependencies. <br /><br />Follow [Scorecard instructions to fix vulnerabilities or suppress warnings](https://github.com/ossf/scorecard/blob/7ce8609469289d5f3b1bf5ee3122f42b4e3054fb/docs/checks.md#vulnerabilities) when the vulnerabilities are not exploitable.<br /><br />You can also add [GitHub dependency review for PR](https://github.com/actions/dependency-review-action) workflows. There's a 'warn-on-openssf-scorecard-level' parameter that you can configure to a custom Scorecard threshold to raise warning on the Scorecard checks that are important to the project.|[deps.dev](http://deps.dev) provides insights into your projects’ dependencies including transitive dependencies, the security advisories relevant to your project, and your projects’ Scorecard report at a high level.<br /><br />Example deps.dev insights:<br />[Sigstore Rekor](https://deps.dev/go/github.com%2Fsigstore%2Frekor)|
 |Merging into the main branch requires a minimum of one maintainer approval (not including the PR submitter) and all CI/CD status checks passing.|Reduce the risks of malicious code injection into the repo, and unintentional errors that impact system availability|An Organization Owner or Repo Admin creates a [branch protection](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule) rule to enforce pull request approval by at least two maintainers.<br /><br />[TAC project lifecycle governance process](https://github.com/ossf/tac/blob/main/process/project-lifecycle.md) SHALL be used for exception approval when the project does not have enough maintainers.|[Scorecard checks Branch Protection](https://github.com/ossf/scorecard/blob/7ce8609469289d5f3b1bf5ee3122f42b4e3054fb/docs/checks.md#branch-protection) and assigns a score at least 8 out of 10 when your project is enforcing this protection.<br /><br />Example report:<br />[Scorecard](https://scorecard.dev/viewer/?uri=github.com/ossf/scorecard&sort_by=risk-level&sort_direction=desc)| 
 |Source repository is free of generated executable artifacts.|To eliminate  the risks of maliciously subverted executables, ensure that generated executables are reproducible from source code|Remove the executable files from the source repository, always build from source code.|Scorecard Binary-Artifacts check reports if your project has executable artifacts in the source repository. <br /><br />Example report: <br />[Scorecard](https://scorecard.dev/viewer/?uri=github.com/ossf/scorecard&sort_by=risk-level&sort_direction=desc)<br /><br />[Allstar](https://github.com/ossf/allstar) verifies that  binaries are checked into the source code repo for testing purposes, these binaries can be exempted from Scorecard binary check via [Maintainer Annotation](https://github.com/ossf/scorecard/blob/main/config/README.md). |
-|If release artifacts are created, SBOM is generated and distributed as a release artifact.|To provide accurate and complete inventory of the software version, license,  dependencies and vulnerabilities to enhance supply chain security, in both human and  machine processable format.|Refer to [OpenSSF SBOM Everywhere SIG](https://github.com/ossf/sbom-everywhere) for the importance of  SBOM generation, consumption and process improvement.<br /><br />Generate SBOM’s in your project’s GitHub release workflow, ensure [minimal data fields recommended by NTIA](https://www.ntia.gov/report/2021/minimum-elements-software-bill-materials-sbom) are populated.<br /><br />Example SBOM: <br />OpenSSF: [GUAC](https://github.com/guacsec/guac/blob/main/.github/workflows/release.yaml) SPDX<br />CNCF: [Kyverno](https://github.com/kyverno/kyverno/blob/68df5af40e9820633162e8d1c0b9966032eb7eb8/.github/actions/publish-image/action.yaml#L3) CycloneDX<br /><br />SECURITY_INSIGHTS.yml SHALL be updated under “dependencies” > “sbom” to include all the build SBOM’s.<br /><br />[TAC project lifecycle governance process](https://github.com/ossf/tac/blob/main/process/project-lifecycle.md) SHALL be used for exception approval when there is no tooling support to implement the baseline.|SECURITY_INSIGHTS.yml identifies the SBOM’s. SMOB’s provide information for dependency management, vulnerability management. |
+|If release artifacts are created, SBOM is generated and distributed as a release artifact.|To provide accurate and complete inventory of the software version, license,  dependencies and vulnerabilities to enhance supply chain security, in both human and  machine processable format.|Refer to [OpenSSF SBOM Everywhere SIG](https://github.com/ossf/sbom-everywhere) for the importance of  SBOM generation, consumption and process improvement.<br /><br />Generate SBOM’s in your project’s GitHub release workflow, ensure [minimal data fields recommended by NTIA](https://www.ntia.gov/report/2021/minimum-elements-software-bill-materials-sbom) are populated.<br /><br />Example SBOM: <br />OpenSSF: [GUAC](https://github.com/guacsec/guac/blob/main/.github/workflows/release.yaml) SPDX<br />CNCF: [Kyverno](https://github.com/kyverno/kyverno/blob/68df5af40e9820633162e8d1c0b9966032eb7eb8/.github/actions/publish-image/action.yaml#L3) CycloneDX<br /><br />SECURITY_INSIGHTS.yml SHALL be updated under “dependencies” > “sbom” to include all the build SBOM’s.<br /><br />[TAC project lifecycle governance process](https://github.com/ossf/tac/blob/main/process/project-lifecycle.md) SHALL be used for exception approval when there is no tooling support to implement the baseline.|SECURITY_INSIGHTS.yml identifies the SBOM’s. SBOM’s provide information for dependency management, vulnerability management. |
 |If release artifacts are created, release artifacts are cryptographically signed.|To ensure the integrity, authenticity, and trustworthiness of release artifacts|Projects SHOULD use [Sigstore](https://www.sigstore.dev/) for signatures. Follow [Scorecard Signed-Releases](https://github.com/ossf/scorecard/blob/7ce8609469289d5f3b1bf5ee3122f42b4e3054fb/docs/checks.md#signed-releases) documentation for detailed instructions. <br /><br />Examples signed release: <br />OpenSSF: [Sigstore Fulcio](https://github.com/sigstore/fulcio?tab=readme-ov-file), [Scorecard](https://github.com/ossf/scorecard/tree/49c0eed3a423f00c872b5c3c9f1bbca9e8aae799.)|[Scorecard Signed-Releases Check](https://github.com/ossf/scorecard/blob/7ce8609469289d5f3b1bf5ee3122f42b4e3054fb/docs/checks.md#signed-releases) reports that release artifacts are signed. When the Scorecard score is below 8, [Allstar](https://github.com/ossf/allstar) will raise an issue and add new comments every 24 hours until the issue is resolved.|
 |If release artifacts are created, SLSA v1.0 Build Level 3 artifact attestation is generated and distributed as a release artifact.|To provide verifiable and non-forgeable claims about software origin and build process. |GitHub actions can be used to produce build provenance at SLSA v1.0 Build Level 3. For details, check [GitHub artifact attestation](https://docs.github.com/en/actions/security-guides/using-artifact-attestations-to-establish-provenance-for-builds) and [reusable workflow](https://docs.github.com/en/actions/using-workflows/reusing-workflows).<br /><br />To get familiar with SLSA specification and available tooling, visit this [workshop material](https://github.com/slsa-framework/oss-na24-slsa-workshop?tab=readme-ov-file). <br /><br />SECURITY_INSIGHTS.yml SHALL be updated under “security-artifacts” > “other-artifacts” to include attestation information.<br /><br />Examples:<br />OpenSSF: [Sigstore Fulcio](https://github.com/sigstore/fulcio/releases), [Scorecard](https://github.com/ossf/scorecard/blob/main/.github/workflows/slsa-goreleaser.yml) |[Scorecard Signed-Releases Check](https://github.com/ossf/scorecard/blob/7ce8609469289d5f3b1bf5ee3122f42b4e3054fb/docs/checks.md#signed-releases) reports attestation is generated as a release artifact. When the Scorecard score is > 8 and !=10, [Allstar](https://github.com/ossf/allstar) will raise an issue and add new comments every 24 hours until the issue is resolved.<br /><br />SECURITY_INSIGHTS.yml identifies  the attestation file. The attestation is  verifiable using these [instructions](https://docs.github.com/en/actions/security-guides/using-artifact-attestations-and-reusable-workflows-to-achieve-slsa-v1-build-level-3#step-2-verifying-artifact-attestations-built-with-a-reusable-workflow).|
 |Logging of security events is implemented if your project provides internet or infrastructure service on behalf of the foundation.|To capture security relevant events for incident response.|Application/software level logging SHALL be in place to capture security relevant events, for example authentication. Sensitive information MUST NOT be logged.|Application/software logging is a continuous improvement process to help rapid incident response. The logs are consumed by the project’s maintainers.|