You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The OpenSSF has published their first version of the Security Baselines. The Security baseline is intended to provide a universal floor for open source projects, regardless of their source code hosting, to apply basic security practices to their project. FAQs here
The baseline is not reflected in scorecards and the baseline does touch on some items from OpenSSF's best practices badge with discussions underway to provide clarity and interoperability between these. In TAG Security's meeting yesterday, @eddie-knight demoed a proof of concept for detecting baseline implementation with automated scanner for projects to use via CLI / CI.
Why add the baselines level 1 for sandbox?
We are finding many organizations adopting sandbox projects directly because of their awesome features and capabilities (yay!) but may unknowingly introduce risk to their dev/int/ and in some cases production environments because adopters rely on the CNCF brand as trusted and not the due diligence evaluation which assesses the project's maturity, engineering practices, design, and security to identify and address items that may create risk or undesirable effects. The Sandbox still remains the home for experimentation and innovation for new cloud native projects, and we provide no assurances as the quality, stability, and security of these projects because they are not evaluated in accordance with our due diligence practices.
When sandbox projects become unhealthy, unresponsive, or slow, adopters push the CNCF to address this, which falls to the TOC to explain what the moving levels process is, how organizations may use it, and the level of assessment we perform. In recent adopter interviews, we're finding more organizations leverage the due diligence as an initial basis to evaluate the project for themselves, supplementing their own criteria we do not cover. This is not true in all cases, but is significant enough to call out a misalignment in understanding.
Additionally, the TOC is seeing a significant increase in projects wishing to join CNCF, whether they are cloud native or not. We have the ability to influence positive change across open source when projects wish to join CNCF by requiring level 1 of the baselines to be met at time of sandbox application. The baselines also has additional benefits to organizations that may be considered software manufacturers under CRA and are adopting these projects.
If the TOC chooses to make this change it will provide a consistent security understanding and set of security practices for all accepted sandbox projects that will simplify self-assessment criteria, and position projects to a stronger security posture as they move to incubation, security audit, and eventual graduation.
The text was updated successfully, but these errors were encountered:
https://baseline.openssf.org/versions/2025-02-25
The OpenSSF has published their first version of the Security Baselines. The Security baseline is intended to provide a universal floor for open source projects, regardless of their source code hosting, to apply basic security practices to their project. FAQs here
The baseline is not reflected in scorecards and the baseline does touch on some items from OpenSSF's best practices badge with discussions underway to provide clarity and interoperability between these. In TAG Security's meeting yesterday, @eddie-knight demoed a proof of concept for detecting baseline implementation with automated scanner for projects to use via CLI / CI.
Why add the baselines level 1 for sandbox?
We are finding many organizations adopting sandbox projects directly because of their awesome features and capabilities (yay!) but may unknowingly introduce risk to their dev/int/ and in some cases production environments because adopters rely on the CNCF brand as trusted and not the due diligence evaluation which assesses the project's maturity, engineering practices, design, and security to identify and address items that may create risk or undesirable effects. The Sandbox still remains the home for experimentation and innovation for new cloud native projects, and we provide no assurances as the quality, stability, and security of these projects because they are not evaluated in accordance with our due diligence practices.
When sandbox projects become unhealthy, unresponsive, or slow, adopters push the CNCF to address this, which falls to the TOC to explain what the moving levels process is, how organizations may use it, and the level of assessment we perform. In recent adopter interviews, we're finding more organizations leverage the due diligence as an initial basis to evaluate the project for themselves, supplementing their own criteria we do not cover. This is not true in all cases, but is significant enough to call out a misalignment in understanding.
Additionally, the TOC is seeing a significant increase in projects wishing to join CNCF, whether they are cloud native or not. We have the ability to influence positive change across open source when projects wish to join CNCF by requiring level 1 of the baselines to be met at time of sandbox application. The baselines also has additional benefits to organizations that may be considered software manufacturers under CRA and are adopting these projects.
If the TOC chooses to make this change it will provide a consistent security understanding and set of security practices for all accepted sandbox projects that will simplify self-assessment criteria, and position projects to a stronger security posture as they move to incubation, security audit, and eventual graduation.
The text was updated successfully, but these errors were encountered: