diff --git a/process/security_baseline.md b/process/security_baseline.md index 06577723..d535b7c1 100644 --- a/process/security_baseline.md +++ b/process/security_baseline.md @@ -79,7 +79,7 @@ As a software project progresses through the [OpenSSF technical initiative life This phased approach intends to support maintainers, contributors, and the community in innovating quickly with security built into the design or enabled by default. -### Baseline - Once Sandbox +### Security Baseline - Once Sandbox When the project starts, it's critical to have a security foundation to reduce a class of vulnerabilities and secure your digital assets with strong credential protections. | Security Baseline | Objective | How to Implement | How to Verify| @@ -87,7 +87,7 @@ When the project starts, it's critical to have a security foundation to reduce a | A memory-safe language is adopted for new projects or new components. | Reduce memory safety vulnerabilities at scale. | Choose one of the [memory-safe languages](https://www.memorysafety.org/docs/memory-safety/)

For preexisting projects in C or C++, follow the [Compiler Options Hardening Guide](https://best.openssf.org/Compiler-Hardening-Guides/Compiler-Options-Hardening-Guide-for-C-and-C++) | Check the [file extension](#Standard-File-Extensions-of-Common-Programming-Languages) and compare with the code.

|Two-factor authentication (2FA) is enabled for repository interactive access. | Reduce the risks of credential compromise and attacks on the digital assets.| 2FA is enabled by default at the enterprise level for all the organizations.

Refer to [SCM Best Practices](https://best.openssf.org/SCM-BestPractices/) for more information.

See [instructions for device setup](https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa/configuring-two-factor-authentication).|[2FA verification, drift detection and correction](#2FA-Verification-Drift-Detection-and-Correction) provides details for verifying 2FA is enabled, monitoring and restoring 2FA if it’s disabled. | -### Baseline - To Become Incubating +### Security Baseline - To Become Incubating As the project codebase grows and more features are added, increasing complexity, it becomes crucial to leverage security tools to identify vulnerabilities in the codebase or dependent software early on. Addressing critical issues early prevents costly fixes in the future. At this stage, projects MUST onboard to OpenSSF Scorecard by following the [installation instructions](https://github.com/ossf/scorecard-action#installation) of [Scorecard GitHub Action](https://github.com/ossf/scorecard-action). The Action runs on any repository change and raises alerts. ​​Repository administrators, organization owners, and people with write or maintain access to a repository can view the alerts in the repository’s Security tab. Ensure Scorecard is enabled for the project by following [Scorecard Verify Runs](https://github.com/ossf/scorecard-action?tab=readme-ov-file#verify-runs) instruction. @@ -97,9 +97,9 @@ As the project codebase grows and more features are added, increasing complexity |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 stand-alone 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). +|Direct dependencies are pinned in internet or infrastructure 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). -### Baseline - Once Incubating +### Security Baseline - Once Incubating As a project matures and enters into the incubation stage, the project is expected to have more adopters. Additional security needs to be built into the project in order to sustain the secure project development and protect the consumers of the open source project. Some requirements might be only applicable to some projects, for example, architecture design will apply to projects that have systems integration. @@ -109,9 +109,9 @@ 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)| -|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.| +|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.

[TAC project lifecycle governance process](https://github.com/ossf/tac/blob/main/process/project-lifecycle.md) SHALL be used if encryption is not achievable. |[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 +### Security Baseline - To Become Graduated As a project matures and progresses towards graduation, it gains wider adoption. To prepare for its general availability and sustainability, additional security measures beyond the incubation baseline are necessary to safeguard project consumers. | Security Baseline | Objective | How to Implement | How to Verify| @@ -124,17 +124,17 @@ As a project matures and progresses towards graduation, it gains wider adoption. |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.

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.

Example SBOM:
OpenSSF: [GUAC](https://github.com/guacsec/guac/blob/main/.github/workflows/release.yaml) SPDX
CNCF: [Kyverno](https://github.com/kyverno/kyverno/blob/68df5af40e9820633162e8d1c0b9966032eb7eb8/.github/actions/publish-image/action.yaml#L3) CycloneDX

SECURITY_INSIGHTS.yml SHALL be updated under “dependencies” > “sbom” to include all the build SBOM’s.

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

Examples signed release:
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).

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

SECURITY_INSIGHTS.yml SHALL be updated under “security-artifacts” > “other-artifacts” to include attestation information.

Examples:
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.

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 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.| -|Monitoring of security events is implemented if your project provides internet service on behalf of the foundation.|To monitor security relevant events for incident response.|If the project provides a service, monitoring SHALL be in place to raise actionable alerts when security relevant events meets pre-defined thresholds, for example host level firewall configuration is changed.|Manual review.| -|If your project provides internet service on behalf of the foundation, an initial security audit is conducted. Audit findings are addressed.|To identify and remediate the vulnerabilities in the internet service.|Security audit SHALL be funded through the [TAC TI funding process](https://github.com/ossf/tac/blob/main/process/TI%20Funding%20Request%20Process.md).

SECURITY_INSIGHTS.yml SHALL be updated under “security-assessments” with a link to the audit report.|SECURITY_INSIGHTS.yml identifies the security audit report. The report provides details of the audit methodology, findings and recommendations.| +|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.| +|Monitoring of security events is implemented if your project provides internet or infrastructure service on behalf of the foundation.|To monitor security relevant events for incident response.|If the project provides a service, monitoring SHALL be in place to raise actionable alerts when security relevant events meets pre-defined thresholds, for example host level firewall configuration is changed.|Manual review.| +|If your project provides internet or infrastructure service on behalf of the foundation, an initial security audit is conducted. Audit findings are addressed.|To identify and remediate the vulnerabilities in the internet service.|Security audit SHALL be funded through the [TAC TI funding process](https://github.com/ossf/tac/blob/main/process/TI%20Funding%20Request%20Process.md).

SECURITY_INSIGHTS.yml SHALL be updated under “security-assessments” with a link to the audit report.|SECURITY_INSIGHTS.yml identifies the security audit report. The report provides details of the audit methodology, findings and recommendations.| -### Baseline - Graduated +### Security Baseline - Graduated Additional security MVP baseline on top of incubating baseline: | Security Baseline | Objective | How to Implement | How to Verify| |-------|-------|-------|-------| |Publicly known vulnerabilities of critical severity are fixed and released in coordination with project consumers promptly.

Publicly known vulnerabilities of medium or high severity are fixed and released in coordination with project consumers within 60 days.|To protect your software from known vulnerabilities.

To protect downstream consumers from vulnerable software via transitive dependency|Continue to use automatic dependency update tools to actively manage vulnerabilities.

Leverage [OSV](https://osv.dev/) to identify and remediate vulnerabilities.

Keep the project security policy up to date, follow the vulnerability disclosure and response process consistently.

Subscribe to OpenSSF [SIREN](https://lists.openssf-vuln.org/g/siren) to receive real-time threat intelligence updates to stay connected with both open source community and OSS consumers.

If tooling support is available, Collaborate with [OpenSSF vexctl](https://github.com/openvex/vexctl) to generate VEX statements when reported vulnerabilities are not exploitable, and update SECURITY_INSIGHTS.yml.|Monitor the vulnerabilities reported through the project vulnerability disclosure process and follow the response process.

Monitor your project’s Scorecard report actively, especially vulnerabilities check results to validate vulnerabilities and take actions accordingly.

SECURITY_INSIGHTS.yml identifies the VEX statements. The statements provide evidence that the project is not subject to the vulnerability exploit.| -|If your project provides internet service on behalf of the foundation, a security audit is conducted on as-needed basis following the initial audit. Audit findings are addressed.|To keep the project up with the evolving threat landscape.|Security audit SHALL be funded through the OpenSSF [TAC TI funding process](https://github.com/ossf/tac/blob/main/process/TI%20Funding%20Request%20Process.md).

SECURITY_INSIGHTS.yml SHALL be updated under “security-assessments” with a link to the new audit report.|SECURITY_INSIGHTS.yml identifies the security audit report . The report provides details of the audit methodology, findings and recommendations.| +|If your project provides internet or infrastructure service on behalf of the foundation, a security audit is conducted on as-needed basis following the initial audit. Audit findings are addressed.|To keep the project up with the evolving threat landscape.|Security audit SHALL be funded through the OpenSSF [TAC TI funding process](https://github.com/ossf/tac/blob/main/process/TI%20Funding%20Request%20Process.md).

SECURITY_INSIGHTS.yml SHALL be updated under “security-assessments” with a link to the new audit report.|SECURITY_INSIGHTS.yml identifies the security audit report . The report provides details of the audit methodology, findings and recommendations.|