From 5899846b536d538dc834cdf7fc6ebcd8d254facb Mon Sep 17 00:00:00 2001 From: Dana Wang Date: Wed, 10 Jul 2024 17:53:00 -0500 Subject: [PATCH 01/24] Create security_baseline.MD GitHub version of the security baseline for TAC review. Signed-off-by: Dana Wang --- process/baseline/security_baseline.MD | 254 ++++++++++++++++++++++++++ 1 file changed, 254 insertions(+) create mode 100644 process/baseline/security_baseline.MD diff --git a/process/baseline/security_baseline.MD b/process/baseline/security_baseline.MD new file mode 100644 index 00000000..0649a417 --- /dev/null +++ b/process/baseline/security_baseline.MD @@ -0,0 +1,254 @@ +## 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 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. + +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. + +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. + +The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC 2119](https://www.rfc-editor.org/rfc/rfc2119/). + +## 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 Softeare 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 dimension: + * **Security Outcomes Adoption and Advancement** + * **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 Adoption Rate** + * **Objective**: Ensure the security baseline is widely adopted. + * **Metrics**: + * Three OpenSSF software-based pilot projects adopt the baseline by 9/15/2024. + * All OpenSSF software-based projects adopt the baseline by the end of 2024. + * At least two other LF foundations adopt the baseline by the end of 2024. +* **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. + * 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. + * **Approach**: Shift security left in the OSS supply chain to reduce downstream risks. + * **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. + +## 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. + +## Basic Operating Principles +To navigate these constraints, the following operating principles are adopted: + + * **Strong Bias Towards Automation and Automatability** + * **Objective**: Enhance security by default and position security as an enabler rather than an inhibitor. + * **Approach**: Prioritize automation and automatability in all processes. + * **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. + * Allow for incremental adoption throughout a software project’s lifecycle by shifting security left in the SDLC process. + * Reuse existing OpenSSF guides and technologies without imposing new requirements. + * **Continuous Improvement** + * **Objective**: Establish a consistent set of objective security measures for all participating foundations and projects. + * **Approach**: + * Provide clear, implementable, and definitive guidelines for maintainers and contributors. + * Rely on every adopting project to submit issues to log the friction points and provide feedback to refine the baseline, facilitating easier adoption. + * **Documented Governance Process** + * **Objective**: Maintain and refine the baseline requirements effectively. + * **Approach**: + * Incoporate the baseline into OpenSSF Technical Advisory Council (TAC) [technical initiative life cycle process](https://github.com/ossf/tac/blob/main/process/project-lifecycle.md). + * 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 +As a software project progresses through the [OpenSSF technical initiative life cycle](https://github.com/ossf/tac/blob/main/process/project-lifecycle.md), it is beneficial to incrementally integrate more security measures. + * Sandbox stage - baseline awareness, and initial requirements + * Incubation stage - sandbox requirements plus additional baselines to sustain the secure project development and protect early adopters. + * Graduated stage: Incubation baseline plus additional baselines to prepare for its general availability and sustainability. + +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 | Objective | How to Implement | How to Verify| +|-------|-------|-------|-------| +| 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 pre-existing 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 + +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 SHOULD 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. + +| 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.| +|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). + +### 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. + +| Security Baseline | Objective | How to Implement | How to Verify| +|-------|-------|-------|-------| +|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.| + +### 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| +|-------|-------|-------|-------| +|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)| +|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). | +|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.| + +### 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.| + + + + +## Appendix +### Standard File Extensions of Common Programming Languages + * Rust + * .rs for source files + * .toml for the Cargo configuration files + * Cargo is Rust's build system and package manager. + * Go + * .go for source files. + * C#: + * .cs for source files + * .csproj for project files + * Java + * .java for source files + * .class for compiled bytecode files + * .jar For Java archive files + * Swift + * .swift for source files. + * Python + * .py for source files + * .pyc for compiled bytecode files + * JavaScript + * .js for standard JavaScript files + * [Common JavaScript File Extension](https://www.npmjs.com/package/common-js-file-extensions) provides a comprehensive list. + * C + * .c for C source files + * .h for header files. + * C++ + * .cpp, .cxx, .cc, .C (uppercase C, less common) for C++ source files + * .hpp, .hxx, .hh, or .H for C++ header files. + * .h is also commonly used for C++ header files in projects that are written in both C and C++. + * Assembly + * .asm for source files + * The file extensions for Assembly language can vary more widely depending on the target platform and the assembler being used. + +### 2FA Verification, Drift Detection and Correction +The 2FA setting changes are captured in the GitHub audit log. The enterprise audit log is being monitored and alerted on using Linux Foundation DataDog and Jira. Two OpenSSF staff members are the enterprise owners, and they are the first responders to the alerts. + +When 2FA is disabled in GitHub Enterprise or an organization, an alert MUST be raised for enterprise owners and organization owners to respond and re-enable 2FA. Enterprise owners MUST confirm 2FA enablement by verifying the event in the audit log. + * Enterprise account + * Event + * Disable 2FA: business.disable_two_factor_requirement + * Enable 2FA: business.enable_two_factor_requirement + * Response: + * DataDog will trigger an alert when detecting the above events + * OpenSSF staff with the enterprise owner role MUST take action to triage and restore the setting, following change management process + * Organization + * Event + * Disable 2FA: org.disable_two_factor_requirement + * Enable 2FA: org.enable_two_factor_requirement + * Response: + * DataDog will trigger an alert on detection of the above event + * OpenSSF staff MUST take action to triage and restore the setting in “ossf” org, following change management process + * OpenSSF staff MUST take action to inform the owner of the impacted organization and support restoring 2FA + +### Secrete Scanning and Push Protection +The [Secret Scanning](https://docs.github.com/en/enterprise-cloud@latest/code-security/secret-scanning/about-secret-scanning) and [Push Protection](https://docs.github.com/en/enterprise-cloud@latest/code-security/secret-scanning/push-protection-for-repositories-and-organizations) setting changes are captured in the GitHub audit log. The enterprise audit log is being monitored and alerted on using Linux Foundation DataDog and Jira. Two OpenSSF staff members are the enterprise owners, and they are the first responders to the alerts. + +When Secret Scanning and Push Protection features are disabled in GitHub Enterprise or an organization, an alert MUST be raised for enterprise owners to respond and coordinate with organizations owners or repo admins to restore the settings. Enterprise owners MUST confirm feature enablement by verifying the event in the audit log. + * Disable Secret Scanning and Push Protection + * Event + * Enterprise account + * business_secret_scanning.disable + * Repository + * repository_secret_scanning.disable + * repository_secret_scanning_push_protection.disable + * Response + * DataDog will trigger an alert when detecting the above events + * OpenSSF staff with the enterprise owner role MUST take action to triage, identify where the setting has changed, and restore the setting in collaboration with organization and repo admins, following change management process. + * Enable Secret Scanning and Push Protection + * Event + * Enterprise + * business_secret_scanning.enable + * From repository + * repository_secret_scanning.enable + +### Encrypting Data in Transit and at Rest +Encrypting data in transit ensures that data transmitted over networks or between systems is protected from unauthorized access, man-in-the-middle attack ([MitM](https://csrc.nist.gov/glossary/term/man_in_the_middle_attack)), [tampering](https://csrc.nist.gov/glossary/term/tampering) of data and systems, and data [breach](https://csrc.nist.gov/glossary/term/breach). These attacks lead to disruptions to critical infrastructure operations, for example, health care, utilities, banking and telecommunications. Businesses and individuals suffer from financial and reputation losses, regulatory compliance consequences and intellectual property loss. Recent ransomware attack on US hospital networks [endangered patients’ health](https://www.cnn.com/2024/05/29/tech/ransomware-attacks-hospitals-patients-danger/index.html#:~:text=A%20ransomware%20attack%20on%20a,by%20the%20cyberattack%20told%20CNN.).

Here are common use cases for encrypting data in transit to protect the data confidentiality and integrity: + * **Secure Web Communications (HTTPS)**: Web traffic is protected via HTTPS to ensure that confidential information, such as login credentials, financial transactions, and personally identifiable information (PII), is protected from tampering and loss. + * **Secure Messaging**: Applying cryptography to emails and instant messages ensures that the content of messages remains confidential and cannot be read or altered by unauthorized parties during transmission. + * **File Transfers**: Applying cryptography to data during file transfers (e.g., using secure file transfer protocols like SFTP or FTPS) ensures that files exchanged between systems or individuals are protected from tampering and loss. + * **Database Connections**: Applying cryptography to database connections (e.g., using TLS/SSL) ensures that data transmitted between applications and databases remains confidential and secure, preventing unauthorized access and data breaches. + * **Remote Access**: Applying cryptography to remote access sessions (e.g., using VPNs or SSH) ensures that data transmitted across networks is protected from MitM. + * **API Communications**: Applying cryptography to API communications ensures that data exchanged between different software applications or services over the network is protected from MitM, data loss and tamping.

To protect data confidentiality, integrity, and authenticity during transmission over networks or between systems, applying cryptography to data in transit is critical.

When using cryptographic libraries, refer to section “Use basic good cryptographic practices” in [OpenSSF Best Practice Badge](https://www.bestpractices.dev/en/criteria/0).

HTTPS MUST be used for API communications. TLS 1.2 and above protocol SHALL be used.

You can access GitHub repositories over HTTPS. If you have not installed GitHub CLI, you need to use a personal access token to run commands against GitHub. HTTPS access allows you to access GitHub API, or run Git commands using repositories HTTPS URL.

You can use [SSH](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/about-authentication-to-github) to authenticate to GitHub from the command line to work on your repositories. The setup is one time effort generating a SSH key pair, uploading a public key to GitHub, and pointing Git to the remote SSH URL. With SSH keys, you can connect to GitHub without supplying your username/password or personal access token every time when you log in to commit code, clone repo, etc. DSA SHALL NOT be used to generate SSH keys. The following algorithm SHALL be used: + * RSA (Rivest-Shamir-Adleman): + * Minimum recommended key length: 2048 bits + * Higher security: 3072 bits or 4096 bits + * ECDSA (Elliptic Curve Digital Signature Algorithm): + * Minimum recommended key length: 256 bits + * Higher security: 384 bits or 521 bits + * Ed25519: + * Fixed key length: 256 bits + +For data at rest, follow the instructions from the storage solutions for encryption practices + +### Curl and openssl Tips +[curl](https://curl.se/docs/sslcerts.html) is a powerful CLI tool to troubleshoot and observe details of HTTPS traffic, including the TLS handshake and certificate information. For example the following command provides insights into a HTTPS GET request and response, including the x.509 certificate details, TLS protocol and cipher, etc. This [article](https://www.sectigo.com/resource-library/what-is-x509-certificate) provides a comprehensive overview of x.509 certificates. +``` +curl -vI https://google.com + +-v: verbose mode, provides more details about the HTTPS response, including the SSL handshake and server side certificate information. + +-I: Fetches the headers only (HEAD request), not the body of the response. +``` +[openssl](https://www.openssl.org/) is another powerful CLI tool to [create CSR’s](https://www.openssl.org/docs/man1.1.1/man1/openssl-req.html) and troubleshoot certificate related issues, especially issues along the certificate chain. For example, the following command provides details of the certificate chain for google.com, including the server certificate, the intermediate cert and the root CA that issues the intermediate cert. +``` +openssl s_client -showcerts -servername google.com -connect google.com:443 Date: Thu, 11 Jul 2024 08:56:06 +0200 Subject: [PATCH 02/24] Update process/baseline/security_baseline.MD Signed-off-by: Arnaud J Le Hors --- process/baseline/security_baseline.MD | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/process/baseline/security_baseline.MD b/process/baseline/security_baseline.MD index 0649a417..0dbdce78 100644 --- a/process/baseline/security_baseline.MD +++ b/process/baseline/security_baseline.MD @@ -12,7 +12,7 @@ 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 Softeare 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 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. From 00c2a6ccadf2eab856d0c2b5f8e0eda7c2d6ca49 Mon Sep 17 00:00:00 2001 From: Arnaud J Le Hors Date: Thu, 11 Jul 2024 08:58:24 +0200 Subject: [PATCH 03/24] Update process/baseline/security_baseline.MD Signed-off-by: Arnaud J Le Hors --- process/baseline/security_baseline.MD | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/process/baseline/security_baseline.MD b/process/baseline/security_baseline.MD index 0dbdce78..beecbe74 100644 --- a/process/baseline/security_baseline.MD +++ b/process/baseline/security_baseline.MD @@ -232,7 +232,7 @@ Encrypting data in transit ensures that data transmitted over networks or betwee For data at rest, follow the instructions from the storage solutions for encryption practices -### Curl and openssl Tips +### Curl and OpenSSL Tips [curl](https://curl.se/docs/sslcerts.html) is a powerful CLI tool to troubleshoot and observe details of HTTPS traffic, including the TLS handshake and certificate information. For example the following command provides insights into a HTTPS GET request and response, including the x.509 certificate details, TLS protocol and cipher, etc. This [article](https://www.sectigo.com/resource-library/what-is-x509-certificate) provides a comprehensive overview of x.509 certificates. ``` curl -vI https://google.com From e5c1d823bd6b35da5d3a09feed33d4ea8445c25f Mon Sep 17 00:00:00 2001 From: Arnaud J Le Hors Date: Thu, 11 Jul 2024 09:09:25 +0200 Subject: [PATCH 04/24] Update process/baseline/security_baseline.MD Signed-off-by: Arnaud J Le Hors --- process/baseline/security_baseline.MD | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/process/baseline/security_baseline.MD b/process/baseline/security_baseline.MD index beecbe74..5593301a 100644 --- a/process/baseline/security_baseline.MD +++ b/process/baseline/security_baseline.MD @@ -69,7 +69,7 @@ To navigate these constraints, the following operating principles are adopted: * **Documented Governance Process** * **Objective**: Maintain and refine the baseline requirements effectively. * **Approach**: - * Incoporate the baseline into OpenSSF Technical Advisory Council (TAC) [technical initiative life cycle process](https://github.com/ossf/tac/blob/main/process/project-lifecycle.md). + * 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). * 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 From 689c1238c17902e538bc2a0288e047b00fd9c406 Mon Sep 17 00:00:00 2001 From: Dana Wang Date: Thu, 11 Jul 2024 09:34:09 -0500 Subject: [PATCH 05/24] Rename security_baseline.MD to security_baseline.md Signed-off-by: Dana Wang --- process/baseline/{security_baseline.MD => security_baseline.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename process/baseline/{security_baseline.MD => security_baseline.md} (100%) diff --git a/process/baseline/security_baseline.MD b/process/baseline/security_baseline.md similarity index 100% rename from process/baseline/security_baseline.MD rename to process/baseline/security_baseline.md From a87572b75025e136bd951c3048c699003bb1a91b Mon Sep 17 00:00:00 2001 From: Dana Wang Date: Thu, 11 Jul 2024 09:44:52 -0500 Subject: [PATCH 06/24] Create security_baseline.md in TAC process folder This is to fix the path issue in PR https://github.com/ossf/tac/pull/353. Unfortunately I cannot use the original PR to move the file to the parent folder. Signed-off-by: Dana Wang --- process/security_baseline.md | 253 +++++++++++++++++++++++++++++++++++ 1 file changed, 253 insertions(+) create mode 100644 process/security_baseline.md diff --git a/process/security_baseline.md b/process/security_baseline.md new file mode 100644 index 00000000..231cd4bc --- /dev/null +++ b/process/security_baseline.md @@ -0,0 +1,253 @@ +## 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 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. + +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. + +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. + +The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC 2119](https://www.rfc-editor.org/rfc/rfc2119/). + +## 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)". + +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 dimension: + * **Security Outcomes Adoption and Advancement** + * **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 Adoption Rate** + * **Objective**: Ensure the security baseline is widely adopted. + * **Metrics**: + * Three OpenSSF software-based pilot projects adopt the baseline by 9/15/2024. + * All OpenSSF software-based projects adopt the baseline by the end of 2024. + * At least two other LF foundations adopt the baseline by the end of 2024. +* **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. + * 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. + * **Approach**: Shift security left in the OSS supply chain to reduce downstream risks. + * **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. + +## 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. + +## Basic Operating Principles +To navigate these constraints, the following operating principles are adopted: + + * **Strong Bias Towards Automation and Automatability** + * **Objective**: Enhance security by default and position security as an enabler rather than an inhibitor. + * **Approach**: Prioritize automation and automatability in all processes. + * **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. + * Allow for incremental adoption throughout a software project’s lifecycle by shifting security left in the SDLC process. + * Reuse existing OpenSSF guides and technologies without imposing new requirements. + * **Continuous Improvement** + * **Objective**: Establish a consistent set of objective security measures for all participating foundations and projects. + * **Approach**: + * Provide clear, implementable, and definitive guidelines for maintainers and contributors. + * Rely on every adopting project to submit issues to log the friction points and provide feedback to refine the baseline, facilitating easier adoption. + * **Documented Governance Process** + * **Objective**: Maintain and refine the baseline requirements effectively. + * **Approach**: + * 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). + * 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 +As a software project progresses through the [OpenSSF technical initiative life cycle](https://github.com/ossf/tac/blob/main/process/project-lifecycle.md), it is beneficial to incrementally integrate more security measures. + * Sandbox stage - baseline awareness, and initial requirements + * Incubation stage - sandbox requirements plus additional baselines to sustain the secure project development and protect early adopters. + * Graduated stage: Incubation baseline plus additional baselines to prepare for its general availability and sustainability. + +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 | Objective | How to Implement | How to Verify| +|-------|-------|-------|-------| +| 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 pre-existing 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 + +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 SHOULD 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. + +| 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.| +|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). + +### 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. + +| Security Baseline | Objective | How to Implement | How to Verify| +|-------|-------|-------|-------| +|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.| + +### 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| +|-------|-------|-------|-------| +|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)| +|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). | +|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.| + +### 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.| + + + + +## Appendix +### Standard File Extensions of Common Programming Languages + * Rust + * .rs for source files + * .toml for the Cargo configuration files + * Cargo is Rust's build system and package manager. + * Go + * .go for source files. + * C#: + * .cs for source files + * .csproj for project files + * Java + * .java for source files + * .class for compiled bytecode files + * .jar For Java archive files + * Swift + * .swift for source files. + * Python + * .py for source files + * .pyc for compiled bytecode files + * JavaScript + * .js for standard JavaScript files + * [Common JavaScript File Extension](https://www.npmjs.com/package/common-js-file-extensions) provides a comprehensive list. + * C + * .c for C source files + * .h for header files. + * C++ + * .cpp, .cxx, .cc, .C (uppercase C, less common) for C++ source files + * .hpp, .hxx, .hh, or .H for C++ header files. + * .h is also commonly used for C++ header files in projects that are written in both C and C++. + * Assembly + * .asm for source files + * The file extensions for Assembly language can vary more widely depending on the target platform and the assembler being used. + +### 2FA Verification, Drift Detection and Correction +The 2FA setting changes are captured in the GitHub audit log. The enterprise audit log is being monitored and alerted on using Linux Foundation DataDog and Jira. Two OpenSSF staff members are the enterprise owners, and they are the first responders to the alerts. + +When 2FA is disabled in GitHub Enterprise or an organization, an alert MUST be raised for enterprise owners and organization owners to respond and re-enable 2FA. Enterprise owners MUST confirm 2FA enablement by verifying the event in the audit log. + * Enterprise account + * Event + * Disable 2FA: business.disable_two_factor_requirement + * Enable 2FA: business.enable_two_factor_requirement + * Response: + * DataDog will trigger an alert when detecting the above events + * OpenSSF staff with the enterprise owner role MUST take action to triage and restore the setting, following change management process + * Organization + * Event + * Disable 2FA: org.disable_two_factor_requirement + * Enable 2FA: org.enable_two_factor_requirement + * Response: + * DataDog will trigger an alert on detection of the above event + * OpenSSF staff MUST take action to triage and restore the setting in “ossf” org, following change management process + * OpenSSF staff MUST take action to inform the owner of the impacted organization and support restoring 2FA + +### Secrete Scanning and Push Protection +The [Secret Scanning](https://docs.github.com/en/enterprise-cloud@latest/code-security/secret-scanning/about-secret-scanning) and [Push Protection](https://docs.github.com/en/enterprise-cloud@latest/code-security/secret-scanning/push-protection-for-repositories-and-organizations) setting changes are captured in the GitHub audit log. The enterprise audit log is being monitored and alerted on using Linux Foundation DataDog and Jira. Two OpenSSF staff members are the enterprise owners, and they are the first responders to the alerts. + +When Secret Scanning and Push Protection features are disabled in GitHub Enterprise or an organization, an alert MUST be raised for enterprise owners to respond and coordinate with organizations owners or repo admins to restore the settings. Enterprise owners MUST confirm feature enablement by verifying the event in the audit log. + * Disable Secret Scanning and Push Protection + * Event + * Enterprise account + * business_secret_scanning.disable + * Repository + * repository_secret_scanning.disable + * repository_secret_scanning_push_protection.disable + * Response + * DataDog will trigger an alert when detecting the above events + * OpenSSF staff with the enterprise owner role MUST take action to triage, identify where the setting has changed, and restore the setting in collaboration with organization and repo admins, following change management process. + * Enable Secret Scanning and Push Protection + * Event + * Enterprise + * business_secret_scanning.enable + * From repository + * repository_secret_scanning.enable + +### Encrypting Data in Transit and at Rest +Encrypting data in transit ensures that data transmitted over networks or between systems is protected from unauthorized access, man-in-the-middle attack ([MitM](https://csrc.nist.gov/glossary/term/man_in_the_middle_attack)), [tampering](https://csrc.nist.gov/glossary/term/tampering) of data and systems, and data [breach](https://csrc.nist.gov/glossary/term/breach). These attacks lead to disruptions to critical infrastructure operations, for example, health care, utilities, banking and telecommunications. Businesses and individuals suffer from financial and reputation losses, regulatory compliance consequences and intellectual property loss. Recent ransomware attack on US hospital networks [endangered patients’ health](https://www.cnn.com/2024/05/29/tech/ransomware-attacks-hospitals-patients-danger/index.html#:~:text=A%20ransomware%20attack%20on%20a,by%20the%20cyberattack%20told%20CNN.).

Here are common use cases for encrypting data in transit to protect the data confidentiality and integrity: + * **Secure Web Communications (HTTPS)**: Web traffic is protected via HTTPS to ensure that confidential information, such as login credentials, financial transactions, and personally identifiable information (PII), is protected from tampering and loss. + * **Secure Messaging**: Applying cryptography to emails and instant messages ensures that the content of messages remains confidential and cannot be read or altered by unauthorized parties during transmission. + * **File Transfers**: Applying cryptography to data during file transfers (e.g., using secure file transfer protocols like SFTP or FTPS) ensures that files exchanged between systems or individuals are protected from tampering and loss. + * **Database Connections**: Applying cryptography to database connections (e.g., using TLS/SSL) ensures that data transmitted between applications and databases remains confidential and secure, preventing unauthorized access and data breaches. + * **Remote Access**: Applying cryptography to remote access sessions (e.g., using VPNs or SSH) ensures that data transmitted across networks is protected from MitM. + * **API Communications**: Applying cryptography to API communications ensures that data exchanged between different software applications or services over the network is protected from MitM, data loss and tamping.

To protect data confidentiality, integrity, and authenticity during transmission over networks or between systems, applying cryptography to data in transit is critical.

When using cryptographic libraries, refer to section “Use basic good cryptographic practices” in [OpenSSF Best Practice Badge](https://www.bestpractices.dev/en/criteria/0).

HTTPS MUST be used for API communications. TLS 1.2 and above protocol SHALL be used.

You can access GitHub repositories over HTTPS. If you have not installed GitHub CLI, you need to use a personal access token to run commands against GitHub. HTTPS access allows you to access GitHub API, or run Git commands using repositories HTTPS URL.

You can use [SSH](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/about-authentication-to-github) to authenticate to GitHub from the command line to work on your repositories. The setup is one time effort generating a SSH key pair, uploading a public key to GitHub, and pointing Git to the remote SSH URL. With SSH keys, you can connect to GitHub without supplying your username/password or personal access token every time when you log in to commit code, clone repo, etc. DSA SHALL NOT be used to generate SSH keys. The following algorithm SHALL be used: + * RSA (Rivest-Shamir-Adleman): + * Minimum recommended key length: 2048 bits + * Higher security: 3072 bits or 4096 bits + * ECDSA (Elliptic Curve Digital Signature Algorithm): + * Minimum recommended key length: 256 bits + * Higher security: 384 bits or 521 bits + * Ed25519: + * Fixed key length: 256 bits + +For data at rest, follow the instructions from the storage solutions for encryption practices + +### Curl and OpenSSL Tips +[curl](https://curl.se/docs/sslcerts.html) is a powerful CLI tool to troubleshoot and observe details of HTTPS traffic, including the TLS handshake and certificate information. For example the following command provides insights into a HTTPS GET request and response, including the x.509 certificate details, TLS protocol and cipher, etc. This [article](https://www.sectigo.com/resource-library/what-is-x509-certificate) provides a comprehensive overview of x.509 certificates. +``` +curl -vI https://google.com + +-v: verbose mode, provides more details about the HTTPS response, including the SSL handshake and server side certificate information. + +-I: Fetches the headers only (HEAD request), not the body of the response. +``` +[openssl](https://www.openssl.org/) is another powerful CLI tool to [create CSR’s](https://www.openssl.org/docs/man1.1.1/man1/openssl-req.html) and troubleshoot certificate related issues, especially issues along the certificate chain. For example, the following command provides details of the certificate chain for google.com, including the server certificate, the intermediate cert and the root CA that issues the intermediate cert. +``` +openssl s_client -showcerts -servername google.com -connect google.com:443 Date: Thu, 11 Jul 2024 09:58:06 -0500 Subject: [PATCH 07/24] Delete process/baseline/security_baseline.md Moving the file to process folder Signed-off-by: Dana Wang --- process/baseline/security_baseline.md | 254 -------------------------- 1 file changed, 254 deletions(-) delete mode 100644 process/baseline/security_baseline.md diff --git a/process/baseline/security_baseline.md b/process/baseline/security_baseline.md deleted file mode 100644 index 5593301a..00000000 --- a/process/baseline/security_baseline.md +++ /dev/null @@ -1,254 +0,0 @@ -## 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 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. - -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. - -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. - -The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC 2119](https://www.rfc-editor.org/rfc/rfc2119/). - -## 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)". - -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 dimension: - * **Security Outcomes Adoption and Advancement** - * **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 Adoption Rate** - * **Objective**: Ensure the security baseline is widely adopted. - * **Metrics**: - * Three OpenSSF software-based pilot projects adopt the baseline by 9/15/2024. - * All OpenSSF software-based projects adopt the baseline by the end of 2024. - * At least two other LF foundations adopt the baseline by the end of 2024. -* **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. - * 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. - * **Approach**: Shift security left in the OSS supply chain to reduce downstream risks. - * **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. - -## 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. - -## Basic Operating Principles -To navigate these constraints, the following operating principles are adopted: - - * **Strong Bias Towards Automation and Automatability** - * **Objective**: Enhance security by default and position security as an enabler rather than an inhibitor. - * **Approach**: Prioritize automation and automatability in all processes. - * **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. - * Allow for incremental adoption throughout a software project’s lifecycle by shifting security left in the SDLC process. - * Reuse existing OpenSSF guides and technologies without imposing new requirements. - * **Continuous Improvement** - * **Objective**: Establish a consistent set of objective security measures for all participating foundations and projects. - * **Approach**: - * Provide clear, implementable, and definitive guidelines for maintainers and contributors. - * Rely on every adopting project to submit issues to log the friction points and provide feedback to refine the baseline, facilitating easier adoption. - * **Documented Governance Process** - * **Objective**: Maintain and refine the baseline requirements effectively. - * **Approach**: - * 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). - * 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 -As a software project progresses through the [OpenSSF technical initiative life cycle](https://github.com/ossf/tac/blob/main/process/project-lifecycle.md), it is beneficial to incrementally integrate more security measures. - * Sandbox stage - baseline awareness, and initial requirements - * Incubation stage - sandbox requirements plus additional baselines to sustain the secure project development and protect early adopters. - * Graduated stage: Incubation baseline plus additional baselines to prepare for its general availability and sustainability. - -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 | Objective | How to Implement | How to Verify| -|-------|-------|-------|-------| -| 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 pre-existing 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 - -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 SHOULD 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. - -| 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.| -|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). - -### 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. - -| Security Baseline | Objective | How to Implement | How to Verify| -|-------|-------|-------|-------| -|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.| - -### 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| -|-------|-------|-------|-------| -|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)| -|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). | -|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.| - -### 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.| - - - - -## Appendix -### Standard File Extensions of Common Programming Languages - * Rust - * .rs for source files - * .toml for the Cargo configuration files - * Cargo is Rust's build system and package manager. - * Go - * .go for source files. - * C#: - * .cs for source files - * .csproj for project files - * Java - * .java for source files - * .class for compiled bytecode files - * .jar For Java archive files - * Swift - * .swift for source files. - * Python - * .py for source files - * .pyc for compiled bytecode files - * JavaScript - * .js for standard JavaScript files - * [Common JavaScript File Extension](https://www.npmjs.com/package/common-js-file-extensions) provides a comprehensive list. - * C - * .c for C source files - * .h for header files. - * C++ - * .cpp, .cxx, .cc, .C (uppercase C, less common) for C++ source files - * .hpp, .hxx, .hh, or .H for C++ header files. - * .h is also commonly used for C++ header files in projects that are written in both C and C++. - * Assembly - * .asm for source files - * The file extensions for Assembly language can vary more widely depending on the target platform and the assembler being used. - -### 2FA Verification, Drift Detection and Correction -The 2FA setting changes are captured in the GitHub audit log. The enterprise audit log is being monitored and alerted on using Linux Foundation DataDog and Jira. Two OpenSSF staff members are the enterprise owners, and they are the first responders to the alerts. - -When 2FA is disabled in GitHub Enterprise or an organization, an alert MUST be raised for enterprise owners and organization owners to respond and re-enable 2FA. Enterprise owners MUST confirm 2FA enablement by verifying the event in the audit log. - * Enterprise account - * Event - * Disable 2FA: business.disable_two_factor_requirement - * Enable 2FA: business.enable_two_factor_requirement - * Response: - * DataDog will trigger an alert when detecting the above events - * OpenSSF staff with the enterprise owner role MUST take action to triage and restore the setting, following change management process - * Organization - * Event - * Disable 2FA: org.disable_two_factor_requirement - * Enable 2FA: org.enable_two_factor_requirement - * Response: - * DataDog will trigger an alert on detection of the above event - * OpenSSF staff MUST take action to triage and restore the setting in “ossf” org, following change management process - * OpenSSF staff MUST take action to inform the owner of the impacted organization and support restoring 2FA - -### Secrete Scanning and Push Protection -The [Secret Scanning](https://docs.github.com/en/enterprise-cloud@latest/code-security/secret-scanning/about-secret-scanning) and [Push Protection](https://docs.github.com/en/enterprise-cloud@latest/code-security/secret-scanning/push-protection-for-repositories-and-organizations) setting changes are captured in the GitHub audit log. The enterprise audit log is being monitored and alerted on using Linux Foundation DataDog and Jira. Two OpenSSF staff members are the enterprise owners, and they are the first responders to the alerts. - -When Secret Scanning and Push Protection features are disabled in GitHub Enterprise or an organization, an alert MUST be raised for enterprise owners to respond and coordinate with organizations owners or repo admins to restore the settings. Enterprise owners MUST confirm feature enablement by verifying the event in the audit log. - * Disable Secret Scanning and Push Protection - * Event - * Enterprise account - * business_secret_scanning.disable - * Repository - * repository_secret_scanning.disable - * repository_secret_scanning_push_protection.disable - * Response - * DataDog will trigger an alert when detecting the above events - * OpenSSF staff with the enterprise owner role MUST take action to triage, identify where the setting has changed, and restore the setting in collaboration with organization and repo admins, following change management process. - * Enable Secret Scanning and Push Protection - * Event - * Enterprise - * business_secret_scanning.enable - * From repository - * repository_secret_scanning.enable - -### Encrypting Data in Transit and at Rest -Encrypting data in transit ensures that data transmitted over networks or between systems is protected from unauthorized access, man-in-the-middle attack ([MitM](https://csrc.nist.gov/glossary/term/man_in_the_middle_attack)), [tampering](https://csrc.nist.gov/glossary/term/tampering) of data and systems, and data [breach](https://csrc.nist.gov/glossary/term/breach). These attacks lead to disruptions to critical infrastructure operations, for example, health care, utilities, banking and telecommunications. Businesses and individuals suffer from financial and reputation losses, regulatory compliance consequences and intellectual property loss. Recent ransomware attack on US hospital networks [endangered patients’ health](https://www.cnn.com/2024/05/29/tech/ransomware-attacks-hospitals-patients-danger/index.html#:~:text=A%20ransomware%20attack%20on%20a,by%20the%20cyberattack%20told%20CNN.).

Here are common use cases for encrypting data in transit to protect the data confidentiality and integrity: - * **Secure Web Communications (HTTPS)**: Web traffic is protected via HTTPS to ensure that confidential information, such as login credentials, financial transactions, and personally identifiable information (PII), is protected from tampering and loss. - * **Secure Messaging**: Applying cryptography to emails and instant messages ensures that the content of messages remains confidential and cannot be read or altered by unauthorized parties during transmission. - * **File Transfers**: Applying cryptography to data during file transfers (e.g., using secure file transfer protocols like SFTP or FTPS) ensures that files exchanged between systems or individuals are protected from tampering and loss. - * **Database Connections**: Applying cryptography to database connections (e.g., using TLS/SSL) ensures that data transmitted between applications and databases remains confidential and secure, preventing unauthorized access and data breaches. - * **Remote Access**: Applying cryptography to remote access sessions (e.g., using VPNs or SSH) ensures that data transmitted across networks is protected from MitM. - * **API Communications**: Applying cryptography to API communications ensures that data exchanged between different software applications or services over the network is protected from MitM, data loss and tamping.

To protect data confidentiality, integrity, and authenticity during transmission over networks or between systems, applying cryptography to data in transit is critical.

When using cryptographic libraries, refer to section “Use basic good cryptographic practices” in [OpenSSF Best Practice Badge](https://www.bestpractices.dev/en/criteria/0).

HTTPS MUST be used for API communications. TLS 1.2 and above protocol SHALL be used.

You can access GitHub repositories over HTTPS. If you have not installed GitHub CLI, you need to use a personal access token to run commands against GitHub. HTTPS access allows you to access GitHub API, or run Git commands using repositories HTTPS URL.

You can use [SSH](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/about-authentication-to-github) to authenticate to GitHub from the command line to work on your repositories. The setup is one time effort generating a SSH key pair, uploading a public key to GitHub, and pointing Git to the remote SSH URL. With SSH keys, you can connect to GitHub without supplying your username/password or personal access token every time when you log in to commit code, clone repo, etc. DSA SHALL NOT be used to generate SSH keys. The following algorithm SHALL be used: - * RSA (Rivest-Shamir-Adleman): - * Minimum recommended key length: 2048 bits - * Higher security: 3072 bits or 4096 bits - * ECDSA (Elliptic Curve Digital Signature Algorithm): - * Minimum recommended key length: 256 bits - * Higher security: 384 bits or 521 bits - * Ed25519: - * Fixed key length: 256 bits - -For data at rest, follow the instructions from the storage solutions for encryption practices - -### Curl and OpenSSL Tips -[curl](https://curl.se/docs/sslcerts.html) is a powerful CLI tool to troubleshoot and observe details of HTTPS traffic, including the TLS handshake and certificate information. For example the following command provides insights into a HTTPS GET request and response, including the x.509 certificate details, TLS protocol and cipher, etc. This [article](https://www.sectigo.com/resource-library/what-is-x509-certificate) provides a comprehensive overview of x.509 certificates. -``` -curl -vI https://google.com - --v: verbose mode, provides more details about the HTTPS response, including the SSL handshake and server side certificate information. - --I: Fetches the headers only (HEAD request), not the body of the response. -``` -[openssl](https://www.openssl.org/) is another powerful CLI tool to [create CSR’s](https://www.openssl.org/docs/man1.1.1/man1/openssl-req.html) and troubleshoot certificate related issues, especially issues along the certificate chain. For example, the following command provides details of the certificate chain for google.com, including the server certificate, the intermediate cert and the root CA that issues the intermediate cert. -``` -openssl s_client -showcerts -servername google.com -connect google.com:443 Date: Fri, 12 Jul 2024 12:37:36 -0500 Subject: [PATCH 08/24] Update process/security_baseline.md fix a typo Co-authored-by: Marcela Melara Signed-off-by: Dana Wang --- process/security_baseline.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/process/security_baseline.md b/process/security_baseline.md index 231cd4bc..3a7255e7 100644 --- a/process/security_baseline.md +++ b/process/security_baseline.md @@ -17,7 +17,7 @@ In the United States, open source software is used across all critical infrastru 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 dimension: +The success of the security baseline SHOULD be quantified and qualified in a few dimensions: * **Security Outcomes Adoption and Advancement** * **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. From 3de7e60de4cf65b0f317b07bf9fafacef832efba Mon Sep 17 00:00:00 2001 From: Dana Wang Date: Fri, 12 Jul 2024 12:38:18 -0500 Subject: [PATCH 09/24] Update process/security_baseline.md Agree with the recommendation. Co-authored-by: Marcela Melara Signed-off-by: Dana Wang --- process/security_baseline.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/process/security_baseline.md b/process/security_baseline.md index 3a7255e7..4b0bc17b 100644 --- a/process/security_baseline.md +++ b/process/security_baseline.md @@ -18,7 +18,7 @@ In the European Union, [Cyber Resiliency Act](https://eur-lex.europa.eu/legal-co ## Success Criteria The success of the security baseline SHOULD be quantified and qualified in a few dimensions: - * **Security Outcomes Adoption and Advancement** + * **Adoption and Advancement of Security Technologies** * **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. From aa4254335a4fdb0a6037981f2fea6fb56c9a64d9 Mon Sep 17 00:00:00 2001 From: Dana Wang Date: Fri, 12 Jul 2024 12:39:20 -0500 Subject: [PATCH 10/24] Update process/security_baseline.md agree with the recommendation Co-authored-by: Marcela Melara Signed-off-by: Dana Wang --- process/security_baseline.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/process/security_baseline.md b/process/security_baseline.md index 4b0bc17b..0018537c 100644 --- a/process/security_baseline.md +++ b/process/security_baseline.md @@ -23,7 +23,7 @@ The success of the security baseline SHOULD be quantified and qualified in a few * **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 Adoption Rate** + * **Increased Security Baseline Adoption Rate** * **Objective**: Ensure the security baseline is widely adopted. * **Metrics**: * Three OpenSSF software-based pilot projects adopt the baseline by 9/15/2024. From 308c777124a05f1903301400653f1a7a944bd7be Mon Sep 17 00:00:00 2001 From: Dana Wang Date: Fri, 12 Jul 2024 13:37:05 -0500 Subject: [PATCH 11/24] Update security_baseline.md Updated the basic operating principles: changed "without imposing new requirements" to "with minimal new requirements" for principle "Minimal, Achievable, and Practical Baseline Requirements" updated "Documented Governance Process" to make the objective more clear Signed-off-by: Dana Wang --- process/security_baseline.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/process/security_baseline.md b/process/security_baseline.md index 0018537c..13616eaf 100644 --- a/process/security_baseline.md +++ b/process/security_baseline.md @@ -60,14 +60,14 @@ To navigate these constraints, the following operating principles are adopted: * **Approach**: * Ensure the 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 without imposing new requirements. + * Reuse existing OpenSSF guides and technologies with minimal new requirements. * **Continuous Improvement** * **Objective**: Establish a consistent set of objective security measures for all participating foundations and projects. * **Approach**: * Provide clear, implementable, and definitive guidelines for maintainers and contributors. * Rely on every adopting project to submit issues to log the friction points and provide feedback to refine the baseline, facilitating easier adoption. * **Documented Governance Process** - * **Objective**: Maintain and refine the baseline requirements effectively. + * **Objective**: Ensure the baseline is an integral part of the TAC life cycle process, and maintenance of the baseline follows the TAC decisioning process. * **Approach**: * 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). * 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). From 4ee861563383c3911a9fa32e552082fe1535ae78 Mon Sep 17 00:00:00 2001 From: Dana Wang Date: Fri, 12 Jul 2024 22:25:34 -0500 Subject: [PATCH 12/24] Update security_baseline.md basic operating principle added reference for automation and automatibility RE @marcelamelara comment. Signed-off-by: Dana Wang --- process/security_baseline.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/process/security_baseline.md b/process/security_baseline.md index 13616eaf..1821a0ca 100644 --- a/process/security_baseline.md +++ b/process/security_baseline.md @@ -54,7 +54,7 @@ To navigate these constraints, the following operating principles are adopted: * **Strong Bias Towards Automation and Automatability** * **Objective**: Enhance security by default and position security as an enabler rather than an inhibitor. - * **Approach**: Prioritize automation and automatability in all processes. + * **Approach**: Prioritize automation and automatability to manage dependencies and vulnerabilities more effectively.[[Know, Prevent, Fix](https://security.googleblog.com/2021/02/know-prevent-fix-framework-for-shifting.html)] * **Minimal, Achievable, and Practical Baseline Requirements** * **Objective**: Design a security baseline that balances software reliability, performance, cost, and security. * **Approach**: From df78b3993cb414655eb96064785f584add353d20 Mon Sep 17 00:00:00 2001 From: Dana Wang Date: Fri, 12 Jul 2024 22:42:54 -0500 Subject: [PATCH 13/24] Update security_baseline.md to clarify adoption and operating principles address comments from @marcelamelara Updated success criteria around adoption, made adoption more specific. Consolidated continuous improvements operating principle into governance process Signed-off-by: Dana Wang --- process/security_baseline.md | 17 ++++++++--------- 1 file changed, 8 insertions(+), 9 deletions(-) diff --git a/process/security_baseline.md b/process/security_baseline.md index 1821a0ca..a3cad63f 100644 --- a/process/security_baseline.md +++ b/process/security_baseline.md @@ -26,9 +26,9 @@ The success of the security baseline SHOULD be quantified and qualified in a few * **Increased Security Baseline Adoption Rate** * **Objective**: Ensure the security baseline is widely adopted. * **Metrics**: - * Three OpenSSF software-based pilot projects adopt the baseline by 9/15/2024. - * All OpenSSF software-based projects adopt the baseline by the end of 2024. - * At least two other LF foundations adopt the baseline by the end of 2024. + * 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. * **Reduction in Security Findings** * **Objective**: Measure the effectiveness of the baseline in improving a project’s security posture. * **Metrics**: @@ -61,15 +61,14 @@ To navigate these constraints, the following operating principles are adopted: * Ensure the 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. - * **Continuous Improvement** - * **Objective**: Establish a consistent set of objective security measures for all participating foundations and projects. - * **Approach**: - * Provide clear, implementable, and definitive guidelines for maintainers and contributors. - * Rely on every adopting project to submit issues to log the friction points and provide feedback to refine the baseline, facilitating easier adoption. * **Documented Governance Process** - * **Objective**: Ensure the baseline is an integral part of the TAC life cycle process, and maintenance of the baseline follows the TAC decisioning 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. * **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. * 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 From b62698b0fdff30a46006e730929cfff8d81a836f Mon Sep 17 00:00:00 2001 From: Dana Wang Date: Fri, 12 Jul 2024 22:58:18 -0500 Subject: [PATCH 14/24] Update security_baseline.md added reference for automation Signed-off-by: Dana Wang --- process/security_baseline.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/process/security_baseline.md b/process/security_baseline.md index a3cad63f..0698794c 100644 --- a/process/security_baseline.md +++ b/process/security_baseline.md @@ -54,7 +54,7 @@ To navigate these constraints, the following operating principles are adopted: * **Strong Bias Towards Automation and Automatability** * **Objective**: Enhance security by default and position security as an enabler rather than an inhibitor. - * **Approach**: Prioritize automation and automatability to manage dependencies and vulnerabilities more effectively.[[Know, Prevent, Fix](https://security.googleblog.com/2021/02/know-prevent-fix-framework-for-shifting.html)] + * **Approach**: Prioritize automation and automatability to manage dependencies and vulnerabilities more effectively.[[Know, Prevent, Fix](https://security.googleblog.com/2021/02/know-prevent-fix-framework-for-shifting.html)], [[software supply chain transparency logical model](https://github.com/guacsec/guac?tab=readme-ov-file)] * **Minimal, Achievable, and Practical Baseline Requirements** * **Objective**: Design a security baseline that balances software reliability, performance, cost, and security. * **Approach**: From 86b9ce72e3b52a100206300ad38eb59ab0ccd5fa Mon Sep 17 00:00:00 2001 From: CRob <69357996+SecurityCRob@users.noreply.github.com> Date: Mon, 15 Jul 2024 09:52:38 -0400 Subject: [PATCH 15/24] Update security_baseline.md typos and other corrections + some additional explanatory text Signed-off-by: CRob <69357996+SecurityCRob@users.noreply.github.com> --- process/security_baseline.md | 34 +++++++++++++++++----------------- 1 file changed, 17 insertions(+), 17 deletions(-) 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). | From 22639387114e387c5f3f303c0d30ad88e9a79c1e Mon Sep 17 00:00:00 2001 From: CRob <69357996+SecurityCRob@users.noreply.github.com> Date: Tue, 16 Jul 2024 09:42:56 -0400 Subject: [PATCH 16/24] Update security_baseline.md fixed my typos Signed-off-by: CRob <69357996+SecurityCRob@users.noreply.github.com> --- process/security_baseline.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/process/security_baseline.md b/process/security_baseline.md index a8bca99f..50e34f2d 100644 --- a/process/security_baseline.md +++ b/process/security_baseline.md @@ -1,7 +1,7 @@ ## Overview 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. -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. +Existing OpenSSF materials, 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 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. @@ -12,7 +12,7 @@ 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. -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)". +The security of open source software 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. @@ -82,7 +82,7 @@ This phased approach intends to support maintainers, contributors, and the commu ### Baseline - Once Sandbox | Security Baseline | Objective | How to Implement | How to Verify| |-------|-------|-------|-------| -| 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 pre-existing 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.

+| 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 @@ -94,7 +94,7 @@ As the project codebase grows and more features are added, increasing complexity | 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.| +|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). ### Baseline - Once Incubating From 4f77544a72793ad4814db1f605fec8277f0176d3 Mon Sep 17 00:00:00 2001 From: Dana Wang Date: Tue, 16 Jul 2024 20:09:14 -0500 Subject: [PATCH 17/24] Update process/security_baseline.md Co-authored-by: Marcela Melara Signed-off-by: Dana Wang --- process/security_baseline.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/process/security_baseline.md b/process/security_baseline.md index 50e34f2d..87d53252 100644 --- a/process/security_baseline.md +++ b/process/security_baseline.md @@ -73,8 +73,8 @@ To navigate these constraints, the following operating principles are adopted: ## Security Baseline As a software project progresses through the [OpenSSF technical initiative life cycle](https://github.com/ossf/tac/blob/main/process/project-lifecycle.md), it is beneficial to incrementally integrate more security measures. - * Sandbox stage - baseline awareness, and initial requirements - * Incubation stage - sandbox requirements plus additional baselines to sustain the secure project development and protect early adopters. + * Sandbox stage: Baseline awareness, and initial requirements + * Incubation stage: Sandbox requirements plus additional baselines to sustain the secure project development and protect early adopters. * Graduated stage: Incubation baseline plus additional baselines to prepare for its general availability and sustainability. This phased approach intends to support maintainers, contributors, and the community in innovating quickly with security built into the design or enabled by default. From 85dfe6229fdf2d8c02fd719bac6f876d383dee06 Mon Sep 17 00:00:00 2001 From: Dana Wang Date: Wed, 17 Jul 2024 08:12:30 -0500 Subject: [PATCH 18/24] Update process/security_baseline.md Co-authored-by: Marcela Melara Signed-off-by: Dana Wang --- process/security_baseline.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/process/security_baseline.md b/process/security_baseline.md index 87d53252..60b18a1a 100644 --- a/process/security_baseline.md +++ b/process/security_baseline.md @@ -1,5 +1,5 @@ ## Overview -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 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 combines process, configurations, and tooling to help 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. Existing OpenSSF materials, 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. From ecd09c7324ae428b2eb2a3d75413b8eb3dfef946 Mon Sep 17 00:00:00 2001 From: Dana Wang Date: Wed, 17 Jul 2024 08:19:21 -0500 Subject: [PATCH 19/24] Update process/security_baseline.md Co-authored-by: Marcela Melara Signed-off-by: Dana Wang --- process/security_baseline.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/process/security_baseline.md b/process/security_baseline.md index 60b18a1a..1a3a9ca1 100644 --- a/process/security_baseline.md +++ b/process/security_baseline.md @@ -55,7 +55,7 @@ To navigate these constraints, the following operating principles are adopted: * **Strong Bias Towards Automation and Automatability** * **Objective**: Enhance security by default and position security as an enabler rather than an inhibitor. * **Approach**: Prioritize automation and automatability to manage dependencies and vulnerabilities more effectively.[[Know, Prevent, Fix](https://security.googleblog.com/2021/02/know-prevent-fix-framework-for-shifting.html)], [[software supply chain transparency logical model](https://github.com/guacsec/guac?tab=readme-ov-file)] - * **Minimal, Achievable, and Practical Baseline Requirements** + * **Minimal, Achievable, and Practical Security Baseline Requirements** * **Objective**: Design a security baseline that balances software reliability, performance, cost, and security. * **Approach**: * Ensure the Security Baseline is minimal and achievable with current technology. From 5145d9689c75b634345a898c9f651fe645d55351 Mon Sep 17 00:00:00 2001 From: Dana Wang Date: Wed, 17 Jul 2024 08:28:43 -0500 Subject: [PATCH 20/24] Update security_baseline.md @marcelamelara added goals for once sandbox Signed-off-by: Dana Wang --- process/security_baseline.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/process/security_baseline.md b/process/security_baseline.md index 1a3a9ca1..690fb9f1 100644 --- a/process/security_baseline.md +++ b/process/security_baseline.md @@ -80,6 +80,8 @@ 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 +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| |-------|-------|-------|-------| | 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.

From 989e50a20ec842cdca8c62cd1a108770db1ff034 Mon Sep 17 00:00:00 2001 From: Dana Wang Date: Wed, 17 Jul 2024 10:32:26 -0500 Subject: [PATCH 21/24] Update security_baseline.md Updated "SHOULD" to "MUST" for Scorecard onboarding for to becoming incubating Signed-off-by: Dana Wang --- process/security_baseline.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/process/security_baseline.md b/process/security_baseline.md index 690fb9f1..06577723 100644 --- a/process/security_baseline.md +++ b/process/security_baseline.md @@ -89,7 +89,7 @@ When the project starts, it's critical to have a security foundation to reduce a ### 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 SHOULD 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. +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. | Security Baseline | Objective | How to Implement | How to Verify| |-------|-------|-------|-------| From 3d963c68925ef9a8fde86952710a6533494cb9b0 Mon Sep 17 00:00:00 2001 From: Dana Wang Date: Wed, 17 Jul 2024 10:55:21 -0500 Subject: [PATCH 22/24] Update security_baseline.md A few changes: For "Data in transit must be protected by cryptographic means.", added "TAC project lifecycle governance process SHALL be followed if encryption is not achievable" Change "Baseline" to "Security Baseline" for the heading of each level Changed "internet service" to "internet or infrastructure service" to consider RSTUF as an infrastructure service Signed-off-by: Dana Wang --- process/security_baseline.md | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) 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.| From f0219fdcbf04c99242a7fc05dd49ec25fee7bee5 Mon Sep 17 00:00:00 2001 From: Dana Wang Date: Tue, 23 Jul 2024 11:04:36 -0500 Subject: [PATCH 23/24] Update process/security_baseline.md Co-authored-by: Zach Steindler Signed-off-by: Dana Wang --- process/security_baseline.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/process/security_baseline.md b/process/security_baseline.md index d535b7c1..7399a753 100644 --- a/process/security_baseline.md +++ b/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.

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). | -|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, 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 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.| From 5a8dfec8b5c44724687df81f02cd1f1a7e0845e7 Mon Sep 17 00:00:00 2001 From: CRob <69357996+SecurityCRob@users.noreply.github.com> Date: Tue, 23 Jul 2024 12:05:15 -0400 Subject: [PATCH 24/24] Update process/security_baseline.md Co-authored-by: Zach Steindler Signed-off-by: CRob <69357996+SecurityCRob@users.noreply.github.com> --- process/security_baseline.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/process/security_baseline.md b/process/security_baseline.md index 7399a753..4c8af64e 100644 --- a/process/security_baseline.md +++ b/process/security_baseline.md @@ -128,7 +128,7 @@ As a project matures and progresses towards graduation, it gains wider adoption. |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.| -### Security Baseline - Graduated +### Security Baseline - Once Graduated Additional security MVP baseline on top of incubating baseline: | Security Baseline | Objective | How to Implement | How to Verify|