SecurityCRob
commented
3 months ago TAC Pr 294 merged. Vuln Disc is officially a Graduated TI
Closed SecurityCRob closed 3 months ago
SecurityCRob
commented
3 months ago TAC Pr 294 merged. Vuln Disc is officially a Graduated TI
It is desired that all TIs have a PR filed and approved by the TAC that documents where they are within the TI Lifecycle:
https://github.com/ossf/tac/blob/main/process/working-group-lifecycle.md https://github.com/ossf/tac/blob/main/process/TI-Gives%2BGets.md
Here is what I've worked out. Ideally we can talk through and address the three-ish things I see we're missing at this point to become labeled as "Graduated"
Vuln WG checklist Sandbox level Gives & Gets Gives/Requirements
To become Sandbox
x Proposal of scope for review by TAC - This is to help ensure limited overlap with existing WGs x Have at least 3 interested individuals from different organizations supporting the proposal x TAC will vote to approve or provide constructive guidance
Once Sandbox
x The TAC will add the WG to the list of WGs to its README. x If the WG has meetings at this stage: They should appear on the OpenSSF calendar The WG should have a document with upcoming agendas and notes from past meetings x The WG should develop a charter or mission statement defining its goals and seek a TAC sponsor.
TI Sandbox Requirements
x TI must be aligned with the OpenSSF mission and either be a novel approach for existing areas or address an unfulfilled need. It is expected that the initial code needed for an OpenSSF WG to work be kept within their repository and will not function as a project in its own right. Should initial WG code grow and mature that it warrants its own Project status, then it is subject to Sandbox entry requirements. It is preferred that extensions of existing OpenSSF projects collaborate with the existing project rather than seek a new project. x TI must maintain a diversified contributor base (i.e. not a single-vendor project). TI must have a minimum of two maintainers with different organization affiliations. x TI must find an aligned WG to host the TI and must have a TAC sponsor that can help guide the TI through processes. x TI agrees to follow the Secure Software Development Guiding Principles and the Open Source Consumption Manifesto. If contributing an existing Project to the OpenSSF, the contribution must undergo license and IP due diligence by the Linux Foundation (LF). x Provides quarterly updates to the TAC on technical vision and progress on vision. x TI will have a SECURITY.md that describes how the Project manages vulnerabilities, or more broadly how the OSSF handles vulnerability reports
To become Incubating
x Have a charter or mission statement for review by TAC x Have met at least 5 times For these, meeting notes (or ideally recordings) must be public x Have at least 5 contributors from at least 3 different organizations attending regularly x 1 TAC sponsor x TAC sponsor agrees to attend WG meetings regularly TAC sponsor does not need to have a formal role in WG, e.g., chair TAC sponsor requests TAC approval x TAC will vote to approve or provide constructive guidance
Once Incubating x Operate as part of the OpenSSF adhering to community policies x Deliver quarterly reviews to TAC x Complete and request TAC approval of README.md which defines the WG's Charter and lists primary point(s) of contact from the TAC to the WG (this is often the WG Chair). x Meet on a regular cadence. Meetings are public, recorded, and on the calendar Have access to community resources (Zooms, YouTube channels, GitHub, Slack channels, etc.) Can request funding/other resources (subject to TAC/GB approval) NOTE: At this time, funding and resources beyond collaboration tools have not been established in the OpenSSF. WGs should expect that their main resource is the community contributions they are able to recruit.
TI Incubating Requirements
x All requirements of Sandbox must be fulfilled. PR filed to promote group to Incubating stage.
x Group has met no less than 5 times within the last calendar quarter x Maintains a diversified contributor base (i.e. not a single-vendor project) with an active flow of contributions. Projects must have a minimum of three maintainers with a minimum of two different organization affiliations, and document the current list of maintainers. x Projects must have defined a contributor guide, which makes it clear how and when contributors should be given increasing responsibilities towards maintainership of the project. (Example guides: Sigstore, AllStar) x Projects should be able to show adoption by multiple parties and adoption's value to the open source community and/or end users (may include adoption of beta/early versions) with the intent to showcase wide adoption by the project's consumers. x TI must have documented, initial group governance. x Maintains a point of contact for vulnerability reports in the security.md Implements, practices, and refines mature software development and release practices such as following a version schema. x TI follows security best practices (as recommended by the OpenSSF and others), including passing the OpenSSF Best Practices criteria, secret scanning, and code scanning. TIs that include code use Scorecards x Begins to establish the appropriate governance that enables its sustainment for potential graduation.
To become Graduated x Have received TAC approval of the README.md per Incubating requirements above x Have met at least 4 times over a period of at least 2 months since becoming Incubating x Have at least 5 contributors from at least 3 different organizations attending regularly as recorded in meeting minutes. x Request TAC approval. TAC will vote to approve or provide constructive guidance
Once Graduated
x All requirements of Incubating must be fulfilled and additionally: x Have at least annual goals and metrics for success
TI Graduated Requirements
x Projects must be able to show a consistent release cadence. x Maintains a point of contact for vulnerability reports and follow coordinated vulnerability disclosure practices. x Implements, practices, and refines mature software development and release practices, such as adherence to semantic versioning, and having a declared policy for stable releases and backported fixes. x Projects must have documented project governance and be able to demonstrate that governance in action. When applicable, projects must have completed a security audit through a third party and addressed audit findings and recommendations. Projects should harden their build systems in accordance with the SLSA Framework
To remain Graduated x A WG is expected to continue operating per the above guidelines, and to provide the TAC with quarterly status updates, and to approach the TAC when seeking approval of substantial changes (such as when accepting or promoting new Projects).