Consider adopting OpenSSF SSGP in project on boarding / best practices

[caniszczyk]

https://github.com/ossf/wg-best-practices-os-developers/blob/main/docs/SecureSoftwareGuidingPrinciples.md

These are a solid set of principles we should have our projects strive to adopt.

We could in theory add this to the updated CNCF TOC Principles somewhere too

cc: @TheFoxAtWork

[TheFoxAtWork]

@PushkarJ @mnm678 @sublimino. (CC @dzolotusky @mauilion ) Would TAG Security be interested in pursuing an effort with projects socialize adoption of commit signing, release signing, SBOM production, SLSA Level assertions, and other practices described? Perhaps incorporating this into project Self- Assessments and Joint- Assessments?

[anvega]

When it comes to security pledges, we're entering a domain that requires careful consideration. Asking project teams to solemnly commit to following the SSGP entails a spectrum of risks and potential liabilities, particularly if such principles are viewed as binding commitments.

Should a team pledge to these principles and then fall short, the repercussions extend beyond reputational damage. There could be legal ramifications, especially if the principles are integrated into regulatory frameworks or contractual obligations. Non-compliance might invite scrutiny and sanctions from regulatory bodies.

To reduce these risks, it's paramount that we foster a culture of transparency amongst our maintainers and project teams. Should there be instances where principles are not fully met, prompt, responsible communication and corrective measures are essential. Moreover, being upfront about any trade-offs or instances today where adherence to a principle is not feasible will be crucial for maintaining trust and integrity. Instead of a broad statement, we could encourage the projects to produce attestations for the aspects of it that they do meet.

For example, in the SPIFFE project, our maintainer guidelines explicitly prioritize "secure by default" and "it just works" principles at the time of making decisions, in that particular order, emphasizing security while acknowledging the threat model, context, and circumstances of edge cases, may call for practicality.

Perhaps ascribing to the SSGP is not a one-off binding declaration, but something to set the intention of striving towards as @caniszczyk put it. That aim alone will require unwavering dedication, appropriate resources, and an ingrained culture of prioritizing security at every step of building and sustaining our projects.

[angellk]

@anvega is there language that you would recommend?

What about @TheFoxAtWork 's suggestion for project's to adopt:

commit signing, release signing, SBOM production, SLSA Level assertions..

That is not necessarily a security pledge but more adopting cloud native best practices. I also wonder if this could be uncovered during a technical domain review versus adopt during project onboarding. Thoughts?

[anvega]

Thanks for following up, @angellk. As I mentioned before, we should be cautious about framing these as binding pledges. Instead, I think it's better to present them as aspirational goals that projects can strive towards. Something along the lines of "CNCF projects are encouraged to adopt and work towards these secure software development practices as part of their ongoing maturity journey."

Regarding the specific practices you mentioned - while commit signing is relatively straightforward, the others (release signing, SBOM production, and SLSA Level assertions which can be easy of using GH Actions SLSA generator but not for other workflows) are far from trivial. Implementing these consistently across our diverse project landscape is a significant challenge. Most maintainers are busy with feature work, and these security practices that time time often don't balance well with those priorities. The projects with more mature security practices tend to have dedicated security leads or staff, but that's rare. There's also the question of trust - should projects accept drive-by contributions to their build toolchains?

Rather than a blanket statement or mandate across the board, it would be best to have each individual project's maintainers opt in and recognize the ones that do (Things like Security Slam have accomplished exactly that). This allows projects to assess their own readiness and priorities, likely leading to more meaningful and sustainable adoption of important security practices.

Ultimately, I believe our public statements should reflect the actual state of our projects rather than making aspirational claims that don't match that state. We should aim for transparency about the state of projects that have gaps in these areas and realistic goals for improvement.

[TheFoxAtWork]

This has previously been discussed by the TOC and has not reached consensus to pursue. Additionally, since the creation of this issue several opportunities are being explored with OpenSSF to provide tangible security value and measurement for projects, of particular note the Security Baselines effort between TAG Security and OpenSSF.

• [Commons WG] Develop Baseline Security Probes tag-security#1386
• https://github.com/ossf/security-baseline
  which ideally will be incorporated into the OpenSSF's best practice passing badge, a requirement for incubation level projects.

This issue is being closed.