diff --git a/process/security_baseline.md b/process/security_baseline.md index 0698794c..a8bca99f 100644 --- a/process/security_baseline.md +++ b/process/security_baseline.md @@ -1,9 +1,9 @@ ## Overview -OpenSSF’s mission is to make open source software more secure. The OpenSSF Security Baseline is one of the key initiatives to achieve this mission. The baseline establishes the minimum practical security standards for OpenSSF software projects throughout various lifecycle stages, ensuring a strong Minimum Viable Secure Product (MVSP) across Linux Foundation projects and internal work. +The purpose of the Open Source Security Foundation (the “OpenSSF”) is to inspire and enable the community to secure the open source software (OSS) we all depend on. The OpenSSF Security Baseline is combination of process, configurations, and tooling that helps open source projects achieve this mission. The OpenSSF Security Baseline establishes the minimum practical security standards for OpenSSF software projects throughout various lifecycle stages, ensuring a strong Minimum Viable Secure Product (MVSP) across Linux Foundation projects and internal work. -The existing OpenSSF guides and technologies will be used to frame the baseline, define objectives, provide implementation recommendations, and suggest verification methods. Through community engagement and collaboration, the baseline will first be adopted by a few software-based pilot projects before being fully adopted by all OpenSSF projects. +Existing OpenSSF gmaterials, including guides and other technologies will be used to frame the baseline, define objectives, provide implementation recommendations, and suggest verification methods. Through community engagement and collaboration, the baseline will first be adopted by a few software-based pilot projects before being fully adopted by all OpenSSF projects. -The baseline provides a foundational framework for systematic adoption across the Linux Foundation. Collaboration with peer foundations is essential for baseline customization and adoption, aiming to enhance the security of the open source software ecosystem. +The Security Baseline provides a foundational framework for systematic adoption across the Linux Foundation. Collaboration with peer foundations is essential for baseline customization and adoption, aiming to enhance the security of the open source software ecosystem. As technology and the threat landscape evolve, the baseline will continuously adapt. The primary goal of this initiative is to maintain a balance between security, reliability, performance, and cost-effectiveness. @@ -12,27 +12,27 @@ The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL ## Background The initiative was one of the outcomes of the October 2023 Linux Foundation Member Summit. Making open source software more secure is one of the top priorities across the Linux Foundation. OpenSSF is leading the charge. -In the United States, open source software is used across all critical infrastructure sectors defined by CISA (Cybersecurity and Infrastructure Security Agency), for example, health care, defense, financial services, utilities, telecommunications, etc. Open source security directly impacts national security, economics and social stability. Enhancing open source security is imperative. NIST has published a [Secure Software Development Framework](https://csrc.nist.gov/Projects/ssdf) (SSDF) as a result of Executive Order (EO) 14028 on "[Improving the Nation's Cybersecurity](https://www.federalregister.gov/documents/2021/05/17/2021-10460/improving-the-nations-cybersecurity)". +The security of open source softweare is a matter of global interest and concern. In the United States, open source software is used across all critical infrastructure sectors defined by CISA (Cybersecurity and Infrastructure Security Agency), for example, health care, defense, financial services, utilities, telecommunications, etc. Open source security directly impacts national security, economics and social stability. Enhancing open source security is imperative. NIST has published a [Secure Software Development Framework](https://csrc.nist.gov/Projects/ssdf) (SSDF) as a result of Executive Order (EO) 14028 on "[Improving the Nation's Cybersecurity](https://www.federalregister.gov/documents/2021/05/17/2021-10460/improving-the-nations-cybersecurity)". In the European Union, [Cyber Resiliency Act](https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CONSIL:ST_17000_2023_INIT) (CRA) has declared a new role - Open Source Steward(Article 3(18a). The legislation is to ensure that consumers of products with digital features are protected, and manufacturers of these products are held accountable for product security. Open source security is the foundation for manufacturers to be compliant with the legislation. ## Success Criteria The success of the security baseline SHOULD be quantified and qualified in a few dimensions: * **Adoption and Advancement of Security Technologies** - * **Objective**: The security baseline promotes improved open source security outcomes. + * **Objective**: The Security Baseline promotes improved open source security outcomes. * **Approach**: Utilize technical outcomes from the OSS community to implement, and verify the security baseline. * **Collaborations**: Partner with other foundations to enhance OSS security through education, specifications, frameworks, and tooling. * **Automation and Tooling**: Identify opportunities for automation and tooling to ease the burden on maintainers and contributors, facilitating secure by design and secure by default principles. * **Increased Security Baseline Adoption Rate** - * **Objective**: Ensure the security baseline is widely adopted. + * **Objective**: Ensure the Security Baseline is widely adopted. * **Metrics**: * Three OpenSSF software-based pilot projects meet the baseline requirements for each project's life cycle by 9/15/2024. * All OpenSSF software-based projects meet the baseline requirements for each project's life cycle by the end of 2024, an aspirational goal. - * At least two other LF foundations adopt the baseline by the end of 2024, an aspirational goal. + * At least two other Linux Foundation (LF) foundations adopt the baseline by the end of 2024, an aspirational goal. * **Reduction in Security Findings** * **Objective**: Measure the effectiveness of the baseline in improving a project’s security posture. * **Metrics**: - * Use Scorecard statistics to track the reduction of Critical, High, and Medium risk findings through the project lifecycle. Benchmark is established at the adoption time. + * Use OpenSSF Scorecard statistics to track the reduction of Critical, High, and Medium risk findings through the project lifecycle. Benchmark is established at the adoption time. * Monitor the number of exceptions at both project and foundation levels, expecting a decline as projects mature and become more secure. * **Improved OSS Maintainer and Consumer Experience** * **Objective**: Enhance the experience for both OSS maintainers and consumers. @@ -40,14 +40,14 @@ The success of the security baseline SHOULD be quantified and qualified in a few * **Shared Responsibility**: Encourage private sector consumers to support OSS security by funding or contributing developer hours. ## Scope -The security baseline SHALL apply to technical initiatives under the OpenSSF GitHub enterprise accounts. +The Security Baseline SHALL apply to technical initiatives under the OpenSSF GitHub enterprise accounts. ## Constraints **Ecosystem support for tooling and configuration capabilities**: They vary depending on the programming languages and the roadmaps for new features or feature enhancements. **Shortage of contributors for tooling development**: Security in open source can only be achieved at scale with the right tool. Lack of easily adopted tools prevents us from achieving a higher level of security baseline. -**Maintainers' time strained by disproportionate open-source consumer demands**: The security baseline aims to enable more secure software development at speed. Nevertheless, the primary constraint remains the limited time available to maintainers, coupled with the demand for open-source software maintenance, including the enhancement of software security. +**Maintainers' time constrained by disproportionate open-source consumer demands**: The security baseline aims to enable more secure software development at speed. Nevertheless, the primary constraint remains the limited time available to maintainers, coupled with the demand for open-source software maintenance, including the enhancement of software security. ## Basic Operating Principles To navigate these constraints, the following operating principles are adopted: @@ -58,17 +58,17 @@ To navigate these constraints, the following operating principles are adopted: * **Minimal, Achievable, and Practical Baseline Requirements** * **Objective**: Design a security baseline that balances software reliability, performance, cost, and security. * **Approach**: - * Ensure the baseline is minimal and achievable with current technology. + * Ensure the Security Baseline is minimal and achievable with current technology. * Allow for incremental adoption throughout a software project’s lifecycle by shifting security left in the SDLC process. * Reuse existing OpenSSF guides and technologies with minimal new requirements. * **Documented Governance Process** * **Objective**: * Establish a consistent set of objective security measures for all participating foundations and projects. - * Ensure the baseline is an integral part of the TAC life cycle process, and maintenance of the baseline follows the TAC decisioning process. + * Ensure the Security Baseline is an integral part of the TAC Technical Initiative life cycle process, and maintenance of the baseline follows the TAC decisioning process. * **Approach**: * Provide clear, implementable, and definitive guidelines for maintainers and contributors. * Incorporate the baseline into OpenSSF Technical Advisory Council (TAC) [technical initiative life cycle process](https://github.com/ossf/tac/blob/main/process/project-lifecycle.md). - * Rely on every adopting project to submit issues to log the friction points and provide feedback to refine the baseline, facilitating easier adoption. + * Rely on every adopting project to submit issues to log the friction points and provide feedback to refine the Security Baseline, facilitating easier adoption. * Revision to the baseline will be a community effort following the [TAC Issue/PR process](https://github.com/ossf/tac/blob/main/process/TAC-Decision-Process.md#issuepull-request-types). ## Security Baseline @@ -91,8 +91,8 @@ As the project codebase grows and more features are added, increasing complexity | Security Baseline | Objective | How to Implement | How to Verify| |-------|-------|-------|-------| -| There is no hard-coded active secrets in the project source repository. |Prevent unauthorized access to repository assets.| GitHub secret scanning and push protection is enabled in the enterprise account. Repo admin can disable the setting for a sandbox project. The setting is monitored and enforced by the staff members.|[Secrete Scanning and Push Protection Verification, Drift Detection and Correction](#Secrete-Scanning-and-Push-Protection) provides information for verifying secret scanning and push protection config is as expected, monitoring and restoring the config if it drifts.| -|Credentials are provisioned with minimal permissions.|Minimize security risks by only granting necessary access to reduce potential attack surfaces. |Apply [Principle of Least Privilege](https://csrc.nist.gov/glossary/term/least_privilege) to manage programmatic and interactive access.

Follow this [guide](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#modifying-the-permissions-for-the-github_token) to grant GITHUB_TOKEN the least required permissions in your workflows.

Establish role-based access control by assigning [organization roles](https://docs.github.com/en/enterprise-cloud@latest/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles) and [repository roles](https://docs.github.com/en/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/repository-roles-for-an-organization) based on members’ responsibilities.

An Organization Owner SHOULD group members and manage their repo Permissions through [GitHub Teams](https://docs.github.com/en/organizations/organizing-members-into-teams/about-teams).

Organization Owner role SHALL be assigned to a minimal number of 2 and maximum 3 members. Same practice applies to the Repo Admin role.

Refer to [SCM Best Practices](https://best.openssf.org/SCM-BestPractices/) for more information.|[Scorecard checks Token-Permissions](https://github.com/ossf/scorecard/blob/98ec491a888a8a0db9d83a3c7d379ae1f46321de/docs/checks.md#token-permissions) and reports if your project's automated workflow tokens follow the principle of least privilege.

Example report: [Scorecard](https://scorecard.dev/viewer/?uri=github.com/ossf/scorecard&sort_by=risk-level&sort_direction=desc)

[Allstar](https://github.com/ossf/allstar) raises an issue against the repo when it detects tokens with excessive permission and adds new comments every 24 hours until the issue is resolved.

The Organization Owner SHALL periodically audit organization member permissions and token permissions manually before this can be automated.| +| There are no hard-coded active secrets in the project source repository. |Prevent unauthorized access to repository assets.| GitHub secret scanning and push protection is enabled in the enterprise account. Repo admin can disable the setting for a sandbox project. The setting is monitored and enforced by the staff members.|[Secrete Scanning and Push Protection Verification, Drift Detection and Correction](#Secrete-Scanning-and-Push-Protection) provides information for verifying secret scanning and push protection config is as expected, monitoring and restoring the config if it drifts.| +|Credentials are provisioned with minimal permissions.|Minimize security risks by only granting necessary access to reduce potential attack surfaces. |Apply [Principle of Least Privilege](https://csrc.nist.gov/glossary/term/least_privilege) to manage programmatic and interactive access.

Follow this [guide](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#modifying-the-permissions-for-the-github_token) to grant GITHUB_TOKEN the least required permissions in your workflows.

Establish role-based access control by assigning [organization roles](https://docs.github.com/en/enterprise-cloud@latest/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles) and [repository roles](https://docs.github.com/en/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/repository-roles-for-an-organization) based on members’ responsibilities.

An Organization Owner SHOULD group members and manage their repo Permissions through [GitHub Teams](https://docs.github.com/en/organizations/organizing-members-into-teams/about-teams).

Organization Owner role SHALL be assigned to a minimal number of 2 and maximum 3 members. Same practice applies to the Repo Admin role.

Refer to [SCM Best Practices](https://best.openssf.org/SCM-BestPractices/) for more information.|[Scorecard checks Token-Permissions](https://github.com/ossf/scorecard/blob/98ec491a888a8a0db9d83a3c7d379ae1f46321de/docs/checks.md#token-permissions) and reports if your project's automated workflow tokens follow the principle of least privilege.

Example report: [Scorecard](https://scorecard.dev/viewer/?uri=github.com/ossf/scorecard&sort_by=risk-level&sort_direction=desc)

[Allstar](https://github.com/ossf/allstar) raises an issue against the repo when it detects tokens with excessive permission and adds new comments every 24 hours until the issue is resolved.

The Organization Owner SHALL periodically audit organization member permissions and token permissions manually before this can be automated.| |An initial set of metadata is established for gaining security insights into the project.|To start providing insights into your project’s security in both human and machine processable format.|Create SECURITY_INSIGHTS.yml at the root of the repository and ensure [schema](https://github.com/ossf/security-insights-spec/blob/main/security-insights-schema.yaml) compliance.

The insights SHALL provide header information, project lifecycle, and contributing policy.

Example SECURITY_INSIGHTS.yml :
OpenSSF: [GUAC](https://github.com/guacsec/guac/blob/main/SECURITY-INSIGHTS.yml), [Security Insight](https://github.com/ossf/security-insights-spec/blob/main/SECURITY-INSIGHTS.yml)|SECURITY_INSIGHTS.yml is found at the root of the repository, and contains metadata for project life cycle and contribution guides.|SECURITY_INSIGHTS.yml is found at the root of the repository, and contains metadata for project life cycle and contribution guides.| |A dependencies policy is published, maintained and followed.|Sets clear guidelines for selecting and maintaining secure dependencies.|Follow [Concise Guide for Evaluating Open Source Software](https://best.openssf.org/Concise-Guide-for-Evaluating-Open-Source-Software) to evaluate the dependencies before using them in the project.

Publish a dependencies policy to guide contributors on dependency management, using a standalone file or CONTRIBUTING.md.

Example dependency policy:
CNCF: [Kubescape](https://github.com/kubescape/kubescape/blob/master/docs/environment-dependencies-policy.md), [Argo Helm](https://github.com/argoproj/argo-helm/blob/main/CONTRIBUTING.md#new-application-versions)

The policy SHALL be added to SECURITY_INSIGHTS.yml section “dependencies” > “env-dependencies-policy”.

Example SECURITY_INSIGHTS.yml with dependencies policy:
CNCF: [Kubescape](https://github.com/kubescape/kubescape/blob/master/SECURITY-INSIGHTS.yml), [capsule](https://github.com/projectcapsule/capsule/blob/main/SECURITY-INSIGHTS.yml).|SECURITY_INSIGHTS.yml identifies the dependencies policy, the policy provides guidance on dependencies evaluation and maintenance.| |Direct dependencies are pinned in internet services and applications your project provides.|Ensures that only a known safe version of a dependency is used to protect against malware and credential compromise.|Follow Scorecard documentation to [pin dependencies](https://github.com/ossf/scorecard/blob/7ce8609469289d5f3b1bf5ee3122f42b4e3054fb/docs/checks.md#pinned-dependencies)

Examples:
OpenSSF: [Sigstore Fulcio](https://github.com/sigstore/fulcio?tab=readme-ov-file), [GUAC](https://github.com/guacsec/guac)|[Scorecard checks dependency pinning](https://github.com/ossf/scorecard/blob/7ce8609469289d5f3b1bf5ee3122f42b4e3054fb/docs/checks.md#license) and reports whether dependencies are pinned.

Example report:
[Scorecard](https://github.com/ossf/scorecard/blob/49c0eed3a423f00c872b5c3c9f1bbca9e8aae799/SECURITY.md), [Sigstore Fulcio](https://api.securityscorecards.dev/projects/github.com/sigstore/fulcio). @@ -106,7 +106,7 @@ Some requirements might be only applicable to some projects, for example, archit |-------|-------|-------|-------| |GitHub actions and workflows, if any, are set up securely and remain secure.|To reduce the risk of repository compromise introduced by malpractices in CI/CD pipeline.| GitHub context is an attack surface that leads to script injection. Follow GitHub hardening [guide](https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions#good-practices-for-mitigating-script-injection-attacks) to mitigate the risk.

GitHub triggers can be abused to introduce untrusted code into the build process. Follow this [article](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/) for detailed analysis and practices to safeguard your actions and workflows.

Refer to [SCM Best Practices](https://best.openssf.org/SCM-BestPractices/) for more information.|[Scorecard checks dangerous workflow](https://github.com/ossf/scorecard/blob/7ce8609469289d5f3b1bf5ee3122f42b4e3054fb/docs/checks.md#dangerous-workflow) and reports the finding if dangerous workflow is detected.

Example report:
[Scorecard](https://scorecard.dev/viewer/?uri=github.com/ossf/scorecard&sort_by=risk-level&sort_direction=desc), [Sigstore Fulcio](https://api.securityscorecards.dev/projects/github.com/sigstore/fulcio)

[Allstar](https://github.com/ossf/allstar) will raise an issue and add new comments every 24 until the issue is resolved.| |Static code analysis is run in CI/CD pipeline, if code exists, and critical severity exploitable vulnerabilities MUST be fixed promptly.|To identify vulnerabilities in the codebase you develop, and remediate critical vulnerabilities that are exploitable, ensure your project is adoptable.|Adopt a Static Application Security Testing (SAST) tool to run static code analysis, e.g. CI/CD pipeline. The code analysis runs against the codebase that you develop, identify vulnerabilities and provide recommendations on remediation.

Consider [Enable CodeQL](https://github.com/github/codeql-action#usage) in your CI/CD pipeline.

Examples:
OpenSSF:[Sigstore Fulcio](https://github.com/sigstore/fulcio?tab=readme-ov-file), [Scorecard](https://github.com/ossf/scorecard/tree/49c0eed3a423f00c872b5c3c9f1bbca9e8aae799)|[Scorecard checks SAST](https://github.com/ossf/scorecard/blob/7ce8609469289d5f3b1bf5ee3122f42b4e3054fb/docs/checks.md#sast)is used in your CI/CD and reports the finding through the vulnerabilities check. You SHOULD see the report reflects the vulnerability fixes.

Scorecard MAY not detect some SAST tools.

Example report: [Scorecard](https://scorecard.dev/viewer/?uri=github.com/ossf/scorecard&sort_by=risk-level&sort_direction=desc)| -|A security policy is published and followed for vulnerability disclosure and response.|To provide clear guidance on how security findings are reported and the expected response.|SECURITY.md is established as part of the [OpenSSF default community health file](https://github.com/ossf/.github). It serves as the security policy, and provides generic information about how vulnerabilities are reported to the project. Project maintainers SHALL follow the [guide to coordinated vulnerability disclosure](https://github.com/ossf/oss-vulnerability-guide/blob/main/maintainer-guide.md#response-process) to provide project-specific vulnerability disclosure and response process. GitHub private vulnerability reporting SHALL be enabled at the repo level.

The security policy SHALL be added to SECURITY_INSIGHTS.yml under section “vulnerability-reporting”.

Examples SECURITY.md:
OpenSSF: [Sigstore](https://github.com/sigstore/cosign?tab=security-ov-file), [Scorecard](https://github.com/ossf/scorecard/blob/49c0eed3a423f00c872b5c3c9f1bbca9e8aae799/SECURITY.md)

Example SECURITY_INSIGHTS.yml:
OpenSSF: [GUAC](https://github.com/guacsec/guac/blob/main/SECURITY-INSIGHTS.yml)
CNCF: [capsule](https://github.com/projectcapsule/capsule/blob/main/SECURITY-INSIGHTS.yml), [Kyverno](https://github.com/kyverno/kyverno/blob/main/SECURITY-INSIGHTS.yml)|[Scorecard checks security policy](https://github.com/ossf/scorecard/blob/7ce8609469289d5f3b1bf5ee3122f42b4e3054fb/docs/checks.md#security-policy) existence in a project and reports findings.

The SECURITY_INSIGHTS.yml file identifies the security policy file (typically SECURITY.md).

Example security insights :
OpenSSF: [GUAC](https://github.com/guacsec/guac/blob/main/SECURITY-INSIGHTS.yml)| +|A security policy is published and followed for vulnerability disclosure and response.|To provide clear guidance on how security findings are reported and the expected response.|SECURITY.md is established as part of the [OpenSSF default community health file](https://github.com/ossf/.github). It serves as the security policy, and provides generic information about how vulnerabilities are reported to the project. Project maintainers SHALL follow the [Guide to Coordinated Vulnerability Disclosure](https://github.com/ossf/oss-vulnerability-guide/blob/main/maintainer-guide.md#response-process) to provide project-specific vulnerability disclosure and response process. GitHub private vulnerability reporting SHALL be enabled at the repo level.

The security policy SHALL be added to SECURITY_INSIGHTS.yml under section “vulnerability-reporting”.

Examples SECURITY.md:
OpenSSF: [Sigstore](https://github.com/sigstore/cosign?tab=security-ov-file), [Scorecard](https://github.com/ossf/scorecard/blob/49c0eed3a423f00c872b5c3c9f1bbca9e8aae799/SECURITY.md)

Example SECURITY_INSIGHTS.yml:
OpenSSF: [GUAC](https://github.com/guacsec/guac/blob/main/SECURITY-INSIGHTS.yml)
CNCF: [capsule](https://github.com/projectcapsule/capsule/blob/main/SECURITY-INSIGHTS.yml), [Kyverno](https://github.com/kyverno/kyverno/blob/main/SECURITY-INSIGHTS.yml)|[Scorecard checks security policy](https://github.com/ossf/scorecard/blob/7ce8609469289d5f3b1bf5ee3122f42b4e3054fb/docs/checks.md#security-policy) existence in a project and reports findings.

The SECURITY_INSIGHTS.yml file identifies the security policy file (typically SECURITY.md).

Example security insights :
OpenSSF: [GUAC](https://github.com/guacsec/guac/blob/main/SECURITY-INSIGHTS.yml)| |Data in transit must be protected by cryptographic means.|To protect data from unauthorized access, ensure data integrity, confidentiality and availability.|[Encrypting Data in Transit and at Rest](#Encrypting-Data-in-Transit-and-at-Rest) provides detailed rationale behind the baseline and implementation guidance.|[Use curl and openssl to verify](https://docs.google.com/document/d/1-NBXdKvEJ9Wsh2i7lDNYven4fY9Bn6uvNJM5ySlMrdg/edit#heading=h.59ofury7nggp) the TLS protocol version, cipher and certificate chain for HTTPS traffic.| ### Baseline - To Become Graduated @@ -115,7 +115,7 @@ As a project matures and progresses towards graduation, it gains wider adoption. | Security Baseline | Objective | How to Implement | How to Verify| |-------|-------|-------|-------| |Architecture design is created with up-to-date security controls for software-based projects.|Enhance security posture and reduce vulnerabilities.|[Design Doc at Google](https://www.industrialempathy.com/posts/design-docs-at-google/) is a good reference SECURITY_INSIGHTS.yml SHALL be updated under “security-artifacts” > “other-artifacts” to include architecture design. The design SHALL be maintained to be consistent with the implementation.|The SECURITY_INSIGHTS.yml file identifies the architecture design that provides information for the system design and security controls.| -|Project has no medium or higher severity exploitable vulnerabilities from SAST scan.|To ensure your project is safe for wide adoption and protect OSS consumers.|Continue to run SAST scan in your CI/CD pipeline, validate the vulnerabilities findings, remediate exploitable vulnerabilities in a timely fashion. Suppress findings that are not exploitable to reduce the false positives.|[Scorecard checks SAST](https://github.com/ossf/scorecard/blob/7ce8609469289d5f3b1bf5ee3122f42b4e3054fb/docs/checks.md#sast) is used in your CI/CD and reports the finding through the vulnerabilities check. You SHOULD see the report reflects the vulnerability fixes.

Example report:
[Scorecard](https://scorecard.dev/viewer/?uri=github.com/ossf/scorecard&sort_by=risk-level&sort_direction=desc)| +|Project has no medium or higher severity vulnerabilities from SAST scan.|To ensure your project is safe for wide adoption and protect OSS consumers.|Continue to run SAST scan in your CI/CD pipeline, validate the vulnerabilities findings, remediate exploitable vulnerabilities in a timely fashion. Suppress findings that are not exploitable to reduce the false positives.|[Scorecard checks SAST](https://github.com/ossf/scorecard/blob/7ce8609469289d5f3b1bf5ee3122f42b4e3054fb/docs/checks.md#sast) is used in your CI/CD and reports the finding through the vulnerabilities check. You SHOULD see the report reflects the vulnerability fixes.

Example report:
[Scorecard](https://scorecard.dev/viewer/?uri=github.com/ossf/scorecard&sort_by=risk-level&sort_direction=desc)| |Publicly known vulnerabilities of critical severity are fixed promptly. Fixes are released promptly.

Publicly known vulnerabilities of medium or high severity are fixed. Fixes are released within 60 days.|To protect your software from known vulnerabilities.

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.

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.

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.

Example deps.dev insights:
[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.

[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.

Example report:
[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.

Example report:
[Scorecard](https://scorecard.dev/viewer/?uri=github.com/ossf/scorecard&sort_by=risk-level&sort_direction=desc)

[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). |