├── .gitignore ├── CODEOWNERS ├── process ├── project-lifecycle-documents │ ├── .keep │ ├── maliciouspackages_sandbox_stage.md │ ├── cve-bin-tool_sandbox_stage.md │ ├── openbao_sandbox_stage.md │ ├── repository_service_for_tuf_sandbox_stage.md │ ├── gemara_sandbox_stage.md │ ├── bomctl_sandbox_stage.md │ ├── minder_sandbox_stage.md │ ├── SBOMit_sandbox_stage.md │ └── repository_service_for_tuf_incubation_stage.md ├── sig-lifecycle-documents │ ├── .gitignore │ ├── MEMORY_SAFETY_sandbox_stage.md │ └── security_baseline_sandbox_stage.md ├── wg-lifecycle-documents │ ├── .gitignore │ ├── securing_software_repositories_graduation_stage.md │ ├── security_tooling_wg_graduation_stage.md │ ├── ai_ml_incubating_stage.md │ ├── securing_critical_projects_incubating_stage.md │ ├── BEST_practices_wg_graduation_stage.md │ ├── Vuln_Disc_wg_graduation_stage.md │ ├── Global_Cyber_Policy_WG_sandbox_stage.md │ └── WG_DEI_incubating_stage.md ├── project-stages.png ├── incubation-process.png ├── templates │ ├── PROJECT_NAME_archived_stage.md │ ├── WG_NAME_archived_stage.md │ ├── SIG_NAME_archived_stage.md │ ├── SIG_NAME_incubating_stage.md │ ├── WG_NAME_graduation_stage.md │ ├── SIG_NAME_sandbox_stage.md │ ├── WG_NAME_incubating_stage.md │ ├── SIG_NAME_graduation_stage.md │ ├── WG_NAME_sandbox_stage.md │ ├── PROJECT_NAME_sandbox_stage.md │ ├── PROJECT_NAME_incubation_stage.md │ └── PROJECT_NAME_graduation_stage.md ├── wg-lead-R&Rs.md ├── README.md ├── Technical_Initiative_Lifecycle.md └── building-an-open-source-community.md ├── files ├── images │ ├── readme.md │ ├── OpenSSF_StagesBadges_archived.png │ ├── OpenSSF_StagesBadges_graduated.png │ ├── OpenSSF_StagesBadges_sandbox.png │ └── OpenSSF_StagesBadges_incubating.png └── readme.md ├── minutes ├── 2022-11-29.md ├── 2022-01-11.md ├── 2022-12-27.md ├── 2023-01-24.md ├── 2020-11-03.md ├── assets │ ├── dashboard.png │ └── crob_diagram.png ├── 2021-06-01.md ├── 2022-05-17.md ├── 2021-06-29.md ├── 2021-06-15.md ├── 2021-01-26.md ├── 2020-11-17.md ├── 2020-12-01.md ├── 2021-05-18.md ├── 2021-08-24.md ├── 2021-07-27.md ├── 2021-02-23.md ├── 2021-09-07.md ├── 2022-10-18.md ├── 2021-04-06.md ├── 2021-09-21.md ├── 2021-02-09.md ├── 2020-10-20.md ├── 2022-03-08.md ├── 2022-04-05.md ├── 2022-12-13.md ├── 2021-04-20.md ├── 2021-01-12.md ├── 2022-11-01.md ├── 2021-10-19.md ├── 2021-12-14.md ├── 2021-08-10.md ├── 2020-12-15.md ├── 2022-09-20.md ├── 2022-06-14.md ├── 2022-09-06.md ├── 2022-07-18.md ├── 2020-10-06.md ├── 2020-09-22.md └── 2022-01-25.md ├── presentations ├── readme.md ├── OpenSSF Nov 2024 GB MVSR.pdf └── OSSF GB TAC Updates - 2023.pdf ├── elections ├── OpenSSF-TAC-Nominations-2022.pdf ├── OpenSSF-TAC-Nominations-2023.pdf ├── OpenSSF-SCIR-Nominations-2022.pdf ├── OpenSSF-SCIR-Nominations-2023.pdf └── OpenSSF-TAC-Nominations-from-GB-2023.pdf ├── .gitvote.yml ├── EMERITUS.md ├── TI-reports ├── 2024 │ ├── 2024-Q3-SCP-WG.md │ ├── 2024-Q4-Repos-WG.md │ ├── 2024-Q3-AI-ML-WG.md │ └── 2024-Q4-VULN-WG.md ├── 2025 │ ├── 2025-Q3-Repos-WG.md │ ├── 2025-Q4-Repos-WG.md │ ├── 2025-Q2-Repos-WG.md │ ├── 2025-Q1-Repos-WG.md │ ├── 2025-Q1-Vulnerability-Disclosure-WG.md │ ├── 2025-Q1-SCP-WG.md │ └── 2025-Q2-SCP-WG.md ├── README.md └── 0000-quarterly-update-template.md ├── CHANGELOG.md ├── working-group-abilities.md ├── policies └── access.md ├── .github └── ISSUE_TEMPLATE │ └── approved_project_onboarding.yml └── dco.md /.gitignore: -------------------------------------------------------------------------------- 1 | .vscode/ 2 | -------------------------------------------------------------------------------- /CODEOWNERS: -------------------------------------------------------------------------------- 1 | * @ossf/tac 2 | -------------------------------------------------------------------------------- /process/project-lifecycle-documents/.keep: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /process/sig-lifecycle-documents/.gitignore: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /process/wg-lifecycle-documents/.gitignore: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /files/images/readme.md: -------------------------------------------------------------------------------- 1 | Image files for the OpenSSF 2 | -------------------------------------------------------------------------------- /minutes/2022-11-29.md: -------------------------------------------------------------------------------- 1 | # **2022-11-29 Meeting - CANCELLED** 2 | 3 | -------------------------------------------------------------------------------- /minutes/2022-01-11.md: -------------------------------------------------------------------------------- 1 | # 2022-01-11 Meeting 2 | 3 | Meeting canceled 4 | -------------------------------------------------------------------------------- /minutes/2022-12-27.md: -------------------------------------------------------------------------------- 1 | # **2022-12-27 Meeting - CANCELLED** 2 | 3 | 4 | -------------------------------------------------------------------------------- /minutes/2023-01-24.md: -------------------------------------------------------------------------------- 1 | # **2023-01-24 Meeting - CANCELLED** 2 | 3 | 4 | -------------------------------------------------------------------------------- /minutes/2020-11-03.md: -------------------------------------------------------------------------------- 1 | # **2020-11-03 Meeting (canceled)** 2 | 3 | Cancelled -------------------------------------------------------------------------------- /files/readme.md: -------------------------------------------------------------------------------- 1 | Location to place files related to the TAC and the Foundation at large 2 | -------------------------------------------------------------------------------- /process/project-stages.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ossf/tac/HEAD/process/project-stages.png -------------------------------------------------------------------------------- /minutes/assets/dashboard.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ossf/tac/HEAD/minutes/assets/dashboard.png -------------------------------------------------------------------------------- /minutes/assets/crob_diagram.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ossf/tac/HEAD/minutes/assets/crob_diagram.png -------------------------------------------------------------------------------- /process/incubation-process.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ossf/tac/HEAD/process/incubation-process.png -------------------------------------------------------------------------------- /minutes/2021-06-01.md: -------------------------------------------------------------------------------- 1 | # **2021-06-01 Meeting** 2 | 3 | CANCELLED per email from Ryan Haning on TAC mailing list. -------------------------------------------------------------------------------- /presentations/readme.md: -------------------------------------------------------------------------------- 1 | Presentations give to or by the TAC about the Technical Intiatives within the OpenSSF 2 | -------------------------------------------------------------------------------- /elections/OpenSSF-TAC-Nominations-2022.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ossf/tac/HEAD/elections/OpenSSF-TAC-Nominations-2022.pdf -------------------------------------------------------------------------------- /elections/OpenSSF-TAC-Nominations-2023.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ossf/tac/HEAD/elections/OpenSSF-TAC-Nominations-2023.pdf -------------------------------------------------------------------------------- /presentations/OpenSSF Nov 2024 GB MVSR.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ossf/tac/HEAD/presentations/OpenSSF Nov 2024 GB MVSR.pdf -------------------------------------------------------------------------------- /elections/OpenSSF-SCIR-Nominations-2022.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ossf/tac/HEAD/elections/OpenSSF-SCIR-Nominations-2022.pdf -------------------------------------------------------------------------------- /elections/OpenSSF-SCIR-Nominations-2023.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ossf/tac/HEAD/elections/OpenSSF-SCIR-Nominations-2023.pdf -------------------------------------------------------------------------------- /presentations/OSSF GB TAC Updates - 2023.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ossf/tac/HEAD/presentations/OSSF GB TAC Updates - 2023.pdf -------------------------------------------------------------------------------- /files/images/OpenSSF_StagesBadges_archived.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ossf/tac/HEAD/files/images/OpenSSF_StagesBadges_archived.png -------------------------------------------------------------------------------- /files/images/OpenSSF_StagesBadges_graduated.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ossf/tac/HEAD/files/images/OpenSSF_StagesBadges_graduated.png -------------------------------------------------------------------------------- /files/images/OpenSSF_StagesBadges_sandbox.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ossf/tac/HEAD/files/images/OpenSSF_StagesBadges_sandbox.png -------------------------------------------------------------------------------- /files/images/OpenSSF_StagesBadges_incubating.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ossf/tac/HEAD/files/images/OpenSSF_StagesBadges_incubating.png -------------------------------------------------------------------------------- /minutes/2022-05-17.md: -------------------------------------------------------------------------------- 1 | # **2022-05-17 Meeting** 2 | 3 | _Meeting was canceled due to several TAC members being at KubeCon EU_ 4 | 5 | 6 | -------------------------------------------------------------------------------- /elections/OpenSSF-TAC-Nominations-from-GB-2023.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/ossf/tac/HEAD/elections/OpenSSF-TAC-Nominations-from-GB-2023.pdf -------------------------------------------------------------------------------- /process/templates/PROJECT_NAME_archived_stage.md: -------------------------------------------------------------------------------- 1 | ## Application for archiving of a project 2 | 3 | ### Reasons for archiving 4 | Projects may become inactive over time or not want to be supported by OpenSSF any longer. 5 | * "description of why this project should be archived" 6 | -------------------------------------------------------------------------------- /process/templates/WG_NAME_archived_stage.md: -------------------------------------------------------------------------------- 1 | ## Application for archiving of a Working Group 2 | 3 | ### Reasons for archiving 4 | 5 | The work has stopped because it has completed its chartered deliverables or is no longer progressing on its deliverables as determined by the TAC. 6 | 7 | * "description of why this WG should be archived" 8 | -------------------------------------------------------------------------------- /.gitvote.yml: -------------------------------------------------------------------------------- 1 | profiles: 2 | default: 3 | duration: 2w 4 | pass_threshold: 55 5 | periodic_status_check: "4 days" 6 | allowed_voters: 7 | teams: 8 | - tac 9 | exclude_team_maintainers: true 10 | close_on_passing: false 11 | announcements: 12 | discussions: 13 | category: announcements 14 | -------------------------------------------------------------------------------- /process/templates/SIG_NAME_archived_stage.md: -------------------------------------------------------------------------------- 1 | ## Archiving of a Special Interest Group (SIG) 2 | 3 | The chairs of a SIG can decide to conclude their work, in which case they must notify their governing body. The chairs of the governing body may have its membership vote, with notice given at the meeting prior to the vote. 4 | 5 | * Link to relevant documentation. 6 | -------------------------------------------------------------------------------- /minutes/2021-06-29.md: -------------------------------------------------------------------------------- 1 | # **2021-06-29 Meeting** 2 | 3 | ## Attendance (please add yourself): 4 | 5 | * Ryan Haning (Microsoft) 6 | * CRob (Intel) 7 | * David A. Wheeler (Linux Foundation) 8 | * Phil Estes (AWS) 9 | * Jennifer Fernick (NCC Group) 10 | * Rao L (JPMC) 11 | 12 | ## Agenda 13 | 14 | * Budget voting 15 | * Budgets for the Best Practices and Identifying Security Threats WG’s have been approved. 16 | * Best Practices WG evaluating the use of Azure to utilize the provided credits 17 | * OSTIF has created an updated proposal to review. Ryan will send it to the TAC for a vote. -------------------------------------------------------------------------------- /EMERITUS.md: -------------------------------------------------------------------------------- 1 | # Emeritus OpenSSF TAC members 2 | 3 | - [Dan Appelquist](https://github.com/torgo) 4 | - [Abhishek Arya](https://github.com/inferno-chromium) 5 | - [Aeva Black](https://github.com/AevaOnline) 6 | - [Josh Bressers](https://github.com/joshbressers) 7 | - [Phil Estes](https://github.com/estesp) 8 | - [Sarah Evans](https://github.com/sevansdell) 9 | - Jennifer Fernick 10 | - [Christopher Ferris](https://github.com/christo4ferris) 11 | - [Ryan Haning](https://github.com/rhaning) 12 | - [Luke Hinds](https://github.com/lukehinds) 13 | - [Dustin Ingram](https://github.com/di) 14 | - [Maya Kaczorowski](https://github.com/mayakacz) 15 | - Rao Lakkakula 16 | - [Dan Lorenc](https://github.com/dlorenc) 17 | - [Christopher "CRob" Robinson](https://github.com/SecurityCRob) 18 | -------------------------------------------------------------------------------- /process/wg-lead-R&Rs.md: -------------------------------------------------------------------------------- 1 | # WG Lead Roles & Responsibilities 2 | 3 | - Facilitate WG meetings including agendas, calls for topics, and capturing and following up on action items 4 | - Drive progress on WG efforts whether specifications, code, or other contributions 5 | - Provide technical guidance and sponsorships for sub-projects, coordinate with related Projects and SIGs, and arbitrate technical disputes as needed 6 | - Present quarterly WG updates to the TAC and regularly make the work of the WG legible throughout OpenSSF (i.e. posted in community channels) 7 | - Facilitate WG voting as needed 8 | - Responsible for keeping the WG on track with regard to its mission and negotiating with the TAC any desired changes. 9 | - Accountable for GitHub Repo management including edits/updates, issue and PR backlog management, and delegating responsibility to a separate volunteer, if applicable 10 | - Time commitment: 2-3 hours per week 11 | -------------------------------------------------------------------------------- /TI-reports/README.md: -------------------------------------------------------------------------------- 1 | [//]: # (SPDX-License-Identifier: CC-BY-4.0) 2 | 3 | # Technical Initiative (TI) Updates 4 | TI updates are: 5 | - used by the TAC to determine the health of a TI, including whether it should change state 6 | - provided to the Governing Board on a monthly basis in the TAC Update 7 | - used to highlight interesting updates to the Governing Board about the TIs 8 | - used to share interesting information with member companies by both the staff and TAC members 9 | - suggested as a point of reference for newcomers to determine if a TI would be worth joining based on information like the contributor diversity, as well as, the type of feature work that is ongoing within the TI 10 | 11 | # Instructions for Filing 12 | 1. Copy the `0000-quarterly-update-template.md` file to the subdirectory for the current year and name the file `YYYY-Qn-TI-Name` (e.g., `2024-Q3-Best-Practices-WG.md`). 13 | 1. Text between `` are instructions. Please remove when section has been completed. 14 | 1. Submit a Pull Request adding your report to the TAC repo. 15 | 1. Once reviewed and approved by the TAC members, your PR will be merged. 16 | -------------------------------------------------------------------------------- /process/templates/SIG_NAME_incubating_stage.md: -------------------------------------------------------------------------------- 1 | ## Special Interest Group (SIG) incubation 2 | 3 | SIG has made substantial progress on a deliverable 4 | * "link to deliverable in progress" 5 | 6 | ### SIG has met all Sandbox requirement 7 | * "link to sandbox PR if exists" 8 | 9 | ### List of SIG maintainers 10 | The SIG must have a minimum of three contributors with a minimum of two different organizational affiliations. 11 | * "name, affiliation, GitHub ID" 12 | 13 | ### Governance 14 | SIG has defined group governance 15 | * "link to charter or other document describe how group is managed" 16 | 17 | ### SIG References 18 | The SIG should provide a list of existing resources with links to the repository, and if available, website, a roadmap, demos and walkthroughs, and any other material to showcase the existing breadth, maturity, and direction of the SIG. 19 | 20 | Reference | URL | 21 | |---------------------|-----| 22 | | Repo | | 23 | | Meeting Agenda | | 24 | | OSSF Calendar Entry | | 25 | | Website | | 26 | | Security.md | | 27 | | Roadmap | | 28 | | Other | | 29 | -------------------------------------------------------------------------------- /TI-reports/0000-quarterly-update-template.md: -------------------------------------------------------------------------------- 1 | # YYYY Qn TI Name 2 | 3 | _Copy this template to the subdirectory for the current year and name the file `YYYY-Qn-TI-Name.md` (e.g., `2023-Q1-Best-Practices-WG.md`). Update the information above to change the `title` to the `YYYY Qn TI Name` (e.g., `2024 Q3 Best Practices WG`). Text between `` are instructions. Please remove when section has been completed._ 4 | 5 | 6 | ## Overview 7 | 8 | _Required: Sum up the status, health of your TI, and the community in a few sentences. Consider this the TL;DR for the rest of the report. How is your community doing health-wise (e.g., is the number of active contributors increasing or decreasing) ? What are the latest news? 9 | 10 | 11 | ## Activity #1 12 | 13 | _Required: Replace the section title with the actual name (e.g., "Memory Safety SIG") and fill out each subsection. Repeat this section and subsections as necesssary for other activities. 14 | 15 | 16 | ### Purpose 17 | 18 | ### Current Status 19 | 20 | ### Up Next 21 | 22 | ### Questions/Issues for the TAC 23 | 24 | 25 | ## Additional Information 26 | 27 | _Optional: Please provide any additional information that you feel would be useful for TAC to be aware._ 28 | 29 | 30 | -------------------------------------------------------------------------------- /process/templates/WG_NAME_graduation_stage.md: -------------------------------------------------------------------------------- 1 | ## Working Group graduation application 2 | 3 | ### WG has met all Incubating requirements 4 | * "link to Incubating PR" 5 | 6 | ### List of regular contributors 7 | The WG must have at least 5 contributors from at least 3 different organizations attending regularly as recorded in meeting minutes. 8 | * "name, affiliation, GitHub ID" 9 | 10 | ### Governance 11 | WG must have documented governance and be able to demonstrate that governance in action. 12 | * "link to governance documents" 13 | 14 | WG has met at least 4 times over a period of at least 2 months since becoming incubating 15 | * "link to meeting agenda" 16 | 17 | ### TI References 18 | The TI must provide a list of existing resources with links to the repository, website, a roadmap, contributing guide, demos and walkthroughs, and any other material to showcase the existing breadth, maturity, and direction of the project. 19 | 20 | Reference | URL | 21 | |-----------------------|-----| 22 | | Repo | | 23 | | Meeting Agenda | | 24 | | OSSF Calendar Entry | | 25 | | Website | | 26 | | Contributing guide | | 27 | | Security.md | | 28 | | Roadmap | | 29 | | Other | | 30 | -------------------------------------------------------------------------------- /minutes/2021-06-15.md: -------------------------------------------------------------------------------- 1 | # **2021-06-15 Meeting** 2 | 3 | ## Attendance (please add yourself): 4 | 5 | * David A. Wheeler (Linux Foundation) 6 | * Phil Estes (AWS) 7 | * Jennifer Fernick (NCC Group) 8 | * CRob (Intel) 9 | * Ryan Haning (Microsoft) 10 | * Dan Lorenc (Google) 11 | * Luke Hinds (Red Hat) 12 | * Rao L (JPMC) 13 | * Vinod Anandan (Citi) 14 | * Matt Rutkowski (IBM) 15 | 16 | ## Agenda: 17 | 18 | * Cleanup future agenda topics in this document. I think we’ve hit some of these. (Dan M) 19 | * EO follow-up (David?) 20 | * NIST workshop 21 | * Lots of activity / questions 22 | * Trying to create a list of “things to do to improve OSS security (OpenSSF & not)” 23 | * CoC follow-up. Budget Vote 24 | * DECISION - Will use github issues to conduct vote 25 | * Identifying Security Threats WG: $41,600 26 | * Hosting: $1600 Azure credits 27 | * Development: $40,000 28 | * Developer Best Practices WG: $63,100 29 | * Operational: $30,000 30 | * Development - SKF SSO WebHook: $13,100 31 | * Development - SKF Labs: $20,000 32 | * OSTIF: $60,000 (out of $2.3M requested) 33 | * Revise proposal 34 | * Public vs. Private communication - Dan Lorenc 35 | * John Murdock - Disable private mailing list 36 | * Create new alias? -------------------------------------------------------------------------------- /process/wg-lifecycle-documents/securing_software_repositories_graduation_stage.md: -------------------------------------------------------------------------------- 1 | ## Working Group graduation application 2 | 3 | ### List of regular contributors 4 | The WG must have at least 5 contributors from at least 3 different organizations attending regularly as recorded in meeting minutes. 5 | 6 | * Josef Šimánek, RubyGems, [simi](https://github.com/simi) 7 | * Trishank Kuppusamy, Datadog [trishankatdatadog](https://github.com/trishankatdatadog) 8 | * Kairo Araujo, TestifySec, [kairoaraujo](https://github.com/kairoaraujo) 9 | * Martin Vrachev, Broadcom, [MVrachev](https://github.com/MVrachev) 10 | * Tobias Bieniek, Rust Foundation, [Turbo87](https://github.com/Turbo87) 11 | 12 | ### Working Group activity 13 | The WG must have met at least 4 times over a period of at least 2 months since becoming `Incubating` 14 | 15 | * [Feb 8, 2024](https://docs.google.com/document/d/1HzA4M4toiExUYQAkuLqimy4EuuunHagUQ7rZKJDb1Os/edit#heading=h.gbeadejjbv8l) 16 | * [Jan 24, 2024](https://docs.google.com/document/d/1HzA4M4toiExUYQAkuLqimy4EuuunHagUQ7rZKJDb1Os/edit#heading=h.4oyy6ptjh470) 17 | * [Jan 11, 2024](https://docs.google.com/document/d/1HzA4M4toiExUYQAkuLqimy4EuuunHagUQ7rZKJDb1Os/edit#heading=h.izqx4mbjjgiv) 18 | * [Dec 14, 2023](https://docs.google.com/document/d/1-f6m442MHg9hktrbcp-4sM9GbZC3HLTpZPpxMXjMCp4/edit#heading=h.izqx4mbjjgiv) 19 | -------------------------------------------------------------------------------- /process/templates/SIG_NAME_sandbox_stage.md: -------------------------------------------------------------------------------- 1 | ## Creation of a new Special Interest Group (SIG) at Sandbox stage 2 | 3 | ### Proposed focus, intent, goals, and/or deliverables 4 | 5 | * Link to relevant documentation. 6 | 7 | ### List SIG Lead(s) 8 | The SIG must have a minimum of 1 Lead 9 | * "name, affiliation, GitHub ID" 10 | 11 | ### List of interested individuals 12 | The SIG have a minimum of 3 members with 2 different organizational affiliations. 13 | * "name, affiliation, GitHub ID" 14 | 15 | ### Governing Body 16 | SIGs may report to an existing OpenSSF Working Group or directly to the TAC as their governing body. The SIG commits to providing the governing body quarterly updates on progress. 17 | * "name of governing body (WG or TAC) for this SIG" 18 | 19 | ### SIG References 20 | The SIG should provide a list of existing resources with links to the repository, and if available, website, a roadmap, demos and walkthroughs, and any other material to showcase the existing breadth, maturity, and direction of the SIG. 21 | | Reference | URL | 22 | |---------------------|-----| 23 | | Repo | | 24 | | Meeting Agenda | | 25 | | OSSF Calendar Entry | | 26 | | Website | | 27 | | Security.md | | 28 | | Roadmap | | 29 | | code-of-conduct.md | | 30 | | Demos | | 31 | | Other | | 32 | -------------------------------------------------------------------------------- /process/templates/WG_NAME_incubating_stage.md: -------------------------------------------------------------------------------- 1 | ## Working Group incubation application 2 | 3 | ### List WG Chair(s) and or Vice Chair 4 | The WG must have a minimum of 1 Chair 5 | * "name, affiliation, GitHub ID" 6 | 7 | ### Working Group (WG) has met all Sandbox requirement 8 | * "link to sandbox PR if exists" 9 | 10 | ### List of regular contributors 11 | The WG must have a minimum of 5 contributors from at least 3 different organizations attending regularly. 12 | * "name, affiliation, GitHub ID" 13 | 14 | ### Mission of the Working Group 15 | The WG must have a charter or mission statement for review by TAC 16 | * Link to the WG charter or mission statement defining its goals. 17 | 18 | ### Governance 19 | WG must have documented, initial group governance. 20 | * Link to initial group governance doc 21 | 22 | WG must have met publicly at least 5 times in the last quarter since becoming Sandbox 23 | * Link to public meeting notes (or ideally recordings) 24 | 25 | WG must have defined Contributor Guide 26 | * "link to contributor guide" 27 | 28 | Reference | URL | 29 | |-----------------------|-----| 30 | | Repo | | 31 | | Meeting Agenda | | 32 | | OSSF Calendar Entry | | 33 | | Website | | 34 | | Contributing guide | | 35 | | Security.md | | 36 | | code-of-conduct.md | | 37 | | Other | | 38 | -------------------------------------------------------------------------------- /minutes/2021-01-26.md: -------------------------------------------------------------------------------- 1 | # **2021-01-26 Meeting** 2 | 3 | ## Attendance (please add yourself): 4 | 5 | * Ryan Haning (Microsoft) 6 | * Phil Estes (Amazon) 7 | * Lindsay Gendreau (Linux Foundation) 8 | * Jennifer Fernick (NCC Group) 9 | * Dan Lorenc (Google) 10 | * Kay Williams (Microsoft) 11 | * Altaz Valani (Security Compass) 12 | * David A. Wheeler (Linux Foundation) 13 | * Rao Lakkakula (JPMChase) 14 | * Maya Kaczorowski (GitHub) 15 | * Jon Zeolla (Seiso) 16 | * Luke Hinds (Red Hat) 17 | * Phil Estes (Amazon) 18 | 19 | ## Agenda: 20 | 21 | * Town Hall Meeting - will be delayed to give time for other things, (Kay) 22 | * Monday, Feb 22 1-2 pm Eastern Time 23 | * 2021 Technical Roadmap (Kay) 24 | * Draft - [OpenSSF 2021 Technical Roadmap - Google Docs](https://docs.google.com/document/d/1wMP_BTmfwC1xBq0cLpwh8gFwAef0QhYmKHNpcAPUJKg/edit#) 25 | * Start with Best Practices and Identifying Security Threats WGs 26 | * Roll out to other WGs after working out kinks 27 | * Consider Q1, Q1, 2H timeline 28 | * Describe items by what they enable (or scenarios) rather than technical items 29 | * Link to technical item (WG issue?) 30 | * WG Abilities doc (Dan) 31 | * [https://github.com/ossf/tac/pull/50](https://github.com/ossf/tac/pull/50) 32 | * Finalize TAC election process (Lindsay) 33 | * [https://github.com/ossf/tac/issues/15](https://github.com/ossf/tac/issues/15) 34 | * Scheduling WG reviews? -------------------------------------------------------------------------------- /minutes/2020-11-17.md: -------------------------------------------------------------------------------- 1 | # **2020-11-17 Meeting** 2 | 3 | ## Attendance (please add yourself): 4 | 5 | * Kay Williams (Microsoft) 6 | * Maya Kaczorowski (GitHub) 7 | * Bas van Schaik (GitHub) 8 | * Dan Middleton (Intel) 9 | * Dan Lorenc (Google) 10 | * Jennifer Fernick (NCC Group) 11 | * CRob (RedHat) 12 | * Rao Lakkakula (JPMorgan) 13 | * Phil Estes (IBM) 14 | * Luke Hinds (Red Hat) 15 | * David A. Wheeler (Linux Foundation) 16 | * wenzel 17 | * Lech Sandecki (Canonical) 18 | * Kim Lewandowski (Google) 19 | * Ryan Haning (Microsoft) 20 | 21 | ## Agenda 22 | 23 | * CVE Benchmarking Presentation (Bas van Schaik) - 20 minutes 24 | * CII Best Practices Badge - 5 minutes 25 | * What's the current status? 26 | * Conclusion: No “ownership” of the project need be defined, organization of conversations related to the badging project have been sorted out by the relevant working groups. 27 | * Technical Strategy Update (Ryan & David) - 28 | * [Technical Initiative Options](https://docs.google.com/document/d/1yLo713am8_hvU90Lw0YdYBvXhfTjh7Shn4ATXPNX9ic/edit?ts=5f987cf5#heading=h.vpw70bcgenot) document 29 | * Role of the TAC and process discussion 30 | * Discuss Charter Template (see discussions in the following TAC issues) 31 | * [https://github.com/ossf/tac/issues/26](https://github.com/ossf/tac/issues/26) 32 | * [https://github.com/ossf/tac/issues/13](https://github.com/ossf/tac/issues/13) 33 | * [https://github.com/ossf/tac/issues/9](https://github.com/ossf/tac/issues/9) -------------------------------------------------------------------------------- /process/templates/SIG_NAME_graduation_stage.md: -------------------------------------------------------------------------------- 1 | ## Special Interest Group (SIG) graduation 2 | 3 | SIG has completed a major deliverable 4 | * "link to completed deliverable". 5 | 6 | ## SIG has met all Incubating requirements 7 | * "link to Incubating PR if exists" 8 | 9 | ### List of SIG participants 10 | The SIG must have a minimum of three contributors with a minimum of two different organizational affiliations. 11 | * "name, affiliation, GitHub ID" 12 | 13 | ### Governance 14 | SIG must have documented governance and be able to demonstrate that governance in action. 15 | * "link to governance documents" 16 | 17 | ### Once in Graduated Status 18 | 19 | The SIG should continue to update the state of the SIG on its README as further work is performed, or make the decision to transition to [Archived](https://github.com/ossf/tac/blob/main/process/sig-lifecycle.md#to-become-archived). 20 | 21 | ### SIG References 22 | The SIG should provide a list of existing resources with links to the repository, and if available, website, a roadmap, demos and walkthroughs, and any other material to showcase the existing breadth, maturity, and direction of the SIG. 23 | 24 | Reference | URL | 25 | |-----------------------|-----| 26 | | Repo | | 27 | | Meeting Agenda | | 28 | | OSSF Calendar Entry | | 29 | | Website | | 30 | | Security.md | | 31 | | Roadmap | | 32 | | Other | | 33 | -------------------------------------------------------------------------------- /process/templates/WG_NAME_sandbox_stage.md: -------------------------------------------------------------------------------- 1 | ## Application for creating a new Working Group at Sandbox stage 2 | 3 | ### List of interested individuals 4 | The WG must have a minimum of 3 interested contributors from two different organizations. 5 | * "name, affiliation, GitHub ID" 6 | 7 | ### Mission of the Working Group 8 | The WG must be aligned with the OpenSSF mission and address an unfulfilled need. It is preferred that topics falling with the scope of existing OpenSSF WGs are addressed within the existing wG rather than seek a new WG. 9 | * "description of the WG mission" 10 | 11 | ### IP policy and licensing due diligence 12 | When contributing to OpenSSF any existing material for the new WG to work on, the contribution must undergo license and IP due diligence by the Linux Foundation (LF). 13 | * "yes / no / not applicable. If yes, provide a link to the corresponding GitHub issue." 14 | 15 | ### TAC Sponsor 16 | TAC sponsor agrees to attend WG meetings regularly, although they are not required to have a formal role in WG. 17 | * "name of TAC sponsor" 18 | 19 | ### Working Group References 20 | The WG should provide a list of existing resources with links to the repository, and if available, website and any other material to showcase the existing breadth, maturity, and direction of the WG. 21 | 22 | | Reference | URL | 23 | |---------------------|-----| 24 | | Repo | | 25 | | Website | | 26 | | Security.md | | 27 | | Other | | 28 | -------------------------------------------------------------------------------- /process/README.md: -------------------------------------------------------------------------------- 1 | # TAC Process Documentation # 2 | 3 | This folder contains the policies and procedures the OpenSSF TAC uses to perform their duties as well as guidelines for the Technical Initiatives of the Foundation. 4 | 5 | ## TAC Onboarding ## 6 | 7 | [TAC Onboarding](./tac-onboarding.md) 8 | 9 | ## TAC Decision Process ## 10 | 11 | [TAC Decision Process](https://github.com/ossf/tac/blob/main/process/TAC-Decision-Process.md) 12 | 13 | ## Technical Initiative Processes & Lifecycle ## 14 | 15 | - [Technical Initiative Lifecycles](https://github.com/ossf/tac/blob/main/process/Technical_Initiative_Lifecycle.md) 16 | - [Technical Initiative "Gives & Gets"](https://github.com/ossf/tac/blob/main/process/TI-Gives%2BGets.md) 17 | - [Technical Initiative Funding Process](https://github.com/ossf/tac/blob/main/process/TI%20Funding%20Request%20Process.md) 18 | - [Building an Open Source Community guidelines](https://github.com/ossf/tac/blob/main/process/building-an-open-source-community.md) 19 | - [Technical Initiative Lifecycle Templates](https://github.com/ossf/tac/tree/main/process/templates) 20 | 21 | ## OpenSSF Roles & Responsibilities ## 22 | 23 | - [TAC Member Roles & Responsibilities](https://github.com/ossf/tac/blob/main/process/tac-member-R%26Rs.md) 24 | - [Working Group Lead Roles & Responsibilities](https://github.com/ossf/tac/blob/main/process/wg-lead-R%26Rs.md) 25 | 26 | ## TAC Election Process ## 27 | 28 | - [TAC & SCIR Election Process](https://github.com/ossf/tac/blob/main/elections/tac-and-scir-election-process.md) - revision forthcoming 29 | - [TAC Elections Folder](https://github.com/ossf/tac/tree/main/elections) - contains documentation and historic election results 30 | -------------------------------------------------------------------------------- /minutes/2020-12-01.md: -------------------------------------------------------------------------------- 1 | # **2020-12-01 Meeting** 2 | 3 | ## Attendance (please add yourself): 4 | 5 | * Ryan Haning (Microsoft) 6 | * David A. Wheeler (Linux Foundation) 7 | * Maya Kaczorowski (GitHub) 8 | * Jon Zeolla (Seiso) 9 | * Dan Middleton (Intel) 10 | * Dan Lorenc (Google) 11 | * Luke Hinds (red hat) 12 | * Phil Estes (IBM) 13 | * Rao Lakkakula (JPM) 14 | * Jennifer Fernick (NCC Group) 15 | * CRob (Red Hat) 16 | 17 | ## Agenda 18 | 19 | * Licensing 20 | * Best Practices badge & CVE Benchmarking have an immediate request to use the MIT license. 21 | * No objections in TAC to having these released via MIT license (see email to TAC for details on the badging licensing). 22 | * Additionally need a generalized proposal for the GB to review 23 | * [https://github.com/ossf/tac/issues/26](https://github.com/ossf/tac/issues/26) 24 | * Charter template update/removal 25 | * [https://github.com/ossf/tac/issues/9](https://github.com/ossf/tac/issues/9) 26 | * Decided to delete for now: 27 | * https://github.com/ossf/project-template/pull/2 28 | * OpenSSF Technical Vision 29 | * [https://github.com/ossf/tac/issues/40](https://github.com/ossf/tac/issues/40) 30 | * Per the 2020-12-01 TAC meeting, the plan is to put proposed text in this issue & discuss it here in this issue. Final version will go into a document file on GitHub (e.g., TAC README.md or its own vision.md file); the final version will not be a Google docs document. 31 | * Ryan Haning to start the initial text, others to collaborate on additions/refinements. 32 | * Working Group lifecycle 33 | * [https://github.com/ossf/tac/issues/13](https://github.com/ossf/tac/issues/13) 34 | * Dan Middleton agreed to codify the current proposal into a markdown file. 35 | * Brief discussion about TAC attendance to ensure that all are aware of each others’ work -------------------------------------------------------------------------------- /minutes/2021-05-18.md: -------------------------------------------------------------------------------- 1 | # **2021-05-18 Meeting** 2 | 3 | ## Attendance (please add yourself): 4 | 5 | * David A. Wheeler (Linux Foundation) (expected) 6 | * Ryan Haning (Microsoft) 7 | * Phil Estes (AWS) 8 | * Mark Cox (Red Hat) (first 30 mins only) 9 | * Matt Rutkowski (IBM) 10 | * Kay Williams (Microsoft) 11 | * Dan Middleton (Intel) 12 | * Dan Lorenc (Google) 13 | 14 | ## Agenda: 15 | 16 | * US Executive Order 17 | * Provides opportunities, and risks if we don’t hurry 18 | * LF blog post about LF projects related to it (by David A. Wheeler); [https://www.linuxfoundation.org/en/blog/how-lf-communities-enable-security-measures-required-by-the-us-executive-order-on-cybersecurity/](https://www.linuxfoundation.org/en/blog/how-lf-communities-enable-security-measures-required-by-the-us-executive-order-on-cybersecurity/) 19 | * NIST is hosting a workshop in June I'm planning on attending- [https://www.nist.gov/news-events/events/2021/06/enhancing-software-supply-chain-security-workshop-and-call-position](https://www.nist.gov/news-events/events/2021/06/enhancing-software-supply-chain-security-workshop-and-call-position) 20 | * 21 | * Diversity, Civility/Equity, Inclusion (DCI) Presentation - Dan Middleton 22 | * Wishlist/roadmap discussion Discuss items to do from the “OpenSSF Technical Initiative Wishlist” [https://docs.google.com/document/d/1yLo713am8_hvU90Lw0YdYBvXhfTjh7Shn4ATXPNX9ic/edit](https://docs.google.com/document/d/1yLo713am8_hvU90Lw0YdYBvXhfTjh7Shn4ATXPNX9ic/edit) as discussed in TAC meeting of May 4. The EO has caused this to become a rush, yet this meeting has run out of time. Now what? Maybe move to planning meetings every Monday 23 | * OSTIF has developed a proposed list of critical projects & specifics on how to fund security audits/improvements 24 | * Dan - supportive, but needs funding 25 | * Will continue as part of Monday Planning Committee -------------------------------------------------------------------------------- /CHANGELOG.md: -------------------------------------------------------------------------------- 1 | # OpenSSF TAC Changelog 2 | 3 | * 2025-01-23: Simplify docs around Chair election, roles, and responsibilities [#432](https://github.com/ossf/tac/pull/432) 4 | * 2025-01-13: Adding 2025 funding schedule and listing out example successful funding requests [#435](https://github.com/ossf/tac/pull/435) 5 | * 2025-01-08: Add initial onboarding document for incoming TAC members [#429](https://github.com/ossf/tac/pull/429) 6 | * 2024-12-11: Added global cyber policy to sandbox working groups 7 | * 2024-11-07: Add security baseline reqs to project lifecycle templates 8 | * 2024-10-22: Add TAC decision type for TI quarterly updates [#402](https://github.com/ossf/tac/pull/402) 9 | * 2024-08-20: Label Security Metric project as archived in README 10 | * 2024-08-15: Updated TI-Gives+Gets.md to clarify Logo entitlement based upon lifecycle stage vs. stage Badge usage [#373](https://github.com/ossf/tac/pull/373) 11 | * 2024-07-24: Added security baseline to incubating project responsibilities and graduated project entry requirements in project-lifecycle.md for for incubating projects [#363](https://github.com/ossf/tac/pull/363) 12 | * 2024-07-24: Added security baseline to graduated project responsibilities in project-lifecycle.md for graduated projects [#364](https://github.com/ossf/tac/pull/364) 13 | * 2024-07-12: Update project-lifecycle.md for sandbox to include security baseline [#355](https://github.com/ossf/tac/pull/355) 14 | * 2024-06-27: Add clarity regarding SIG and projects (PR [#348](https://github.com/ossf/tac/pull/348)) 15 | * 2024-06-11: Update funding application to include specific TI, lifecycle, and amount (PR [#344](https://github.com/ossf/tac/pull/344)) 16 | * 2024-05-24: Improve election process and timeline 17 | * 2024-05-22: Add TI funding request to TAC decision process doc (PR [#329](https://github.com/ossf/tac/pull/329)) 18 | * 2024-05-22: Add infrastructure for TI reports to be submitted via github PR 19 | -------------------------------------------------------------------------------- /minutes/2021-08-24.md: -------------------------------------------------------------------------------- 1 | # **2021-08-24 Meeting** 2 | 3 | ## Attendance (please add yourself): 4 | 5 | * CRob [Intel] 6 | * Phil Estes (AWS) 7 | * Michael Scovetta (Microsoft) 8 | * Ryan Haning (Microsoft) 9 | * Rao Lakkakula (JPMC) 10 | * David A. Wheeler (Linux Foundation) 11 | * Kay Williams (Microsoft) 12 | * Matt Rutkowski, he/him, IBM 13 | * Luke Hinds (Red Hat) 14 | 15 | ## Agenda: 16 | 17 | * EO & OpenSSF updates 18 | * Will attempt scheduling a meeting with the leads… again. 19 | * Identifying Critical Projects (Kay Williams) 20 | * Project champions/sponsors for incident response 21 | * Alpha-Omega isn’t limited to the EO, but it helps us meet EO requirements esp. Critical software. 22 | * There’s a meeting at the White House this Wednesday, CEOs from various sectors (about 35), we know tech is there. Following that, there will be a panel discussion (probably by sector). NIST & White House are interested in the tech sector coming together to create standards re: cybersecurity. Refer to SLSA. Also [SCIM](https://github.com/microsoft/scim) (supply chain integrity model) that Microsoft is spearheading, getting ready to move into OpenSSF ~September, intend it to be an open source project. SLSA is focused on evidence/policy. SCIM is more focused on data layer, collect supply chain information. 23 | * Alpha-Omega: A Proposal for Improving Security Quality of Open Source at Scale (Michael Scovetta) - [https://docs.google.com/document/d/1u7Ps18dzu9M-HF7ZHTK6VB5jLaVJvnw6uq3o7qw5yGE/edit](https://docs.google.com/document/d/1u7Ps18dzu9M-HF7ZHTK6VB5jLaVJvnw6uq3o7qw5yGE/edit) 24 | * TAC election in September 25 | * [RFC] - Vuln Disclosure WG’s “Guide to coordinated vulnerability disclosure for open source software projects” [guide ](https://github.com/ossf/oss-vulnerability-guide)& [blog ](https://docs.google.com/document/d/1BPCcnaagTLht7vBk6q5AS_KxiGmLDj76uaZb3yg5_Ro/edit?resourcekey=0-JjkQMDZTT_RZ2buk6NTDhw)proposal -------------------------------------------------------------------------------- /process/templates/PROJECT_NAME_sandbox_stage.md: -------------------------------------------------------------------------------- 1 | ## Application for creating a new project at Sandbox stage 2 | 3 | ### List of project maintainers 4 | The project must have a minimum of three maintainers with a minimum of two different organizational affiliations. 5 | * "name, affiliation, GitHub ID" 6 | 7 | ### Sponsor 8 | Most projects will report to an existing OpenSSF Working Group, although in some cases a project may report directly to the TAC. The project commits to providing quarterly updates on progress to the group they report to. 9 | * "name of the group the project reports to: either a Working Group or the TAC" 10 | 11 | ### Mission of the project 12 | The project must be aligned with the OpenSSF mission and either be a novel approach for existing areas, address an unfulfilled need, or be initial code needed for OpenSSF WG work. It is preferred that extensions of existing OpenSSF projects collaborate with the existing project rather than seek a new project. 13 | * "description of the project mission" 14 | 15 | ### IP policy and licensing due diligence 16 | When contributing an existing Project to the OpenSSF, the contribution must undergo license and IP due diligence by the Linux Foundation (LF). 17 | * "yes / no / not applicable. If yes, provide a link to the corresponding GitHub issue." 18 | 19 | ### Project References 20 | The project should provide a list of existing resources with links to the repository, and if available, website, a roadmap, contributing guide, demos and walkthroughs, and any other material to showcase the existing breadth, maturity, and direction of the project. 21 | 22 | | Reference | URL | 23 | |---------------------|-----| 24 | | Repo | | 25 | | Website | | 26 | | Contributing guide | | 27 | | Security.md | | 28 | | Roadmap | | 29 | | Demos | | 30 | | Other | | 31 | -------------------------------------------------------------------------------- /minutes/2021-07-27.md: -------------------------------------------------------------------------------- 1 | # **2021-07-27 Meeting** 2 | 3 | ## Attendance (please add yourself): 4 | 5 | * Ryan Haning (Microsoft) 6 | * Phil Estes (AWS) 7 | * Aeva Black (Microsoft) 8 | * Rao Lakkakula (JPMC) 9 | * Ax Sharma (Sonatype) 10 | * David A. Wheeler (Linux Foundation) 11 | * Sal Kimmich (Sonatype) 12 | * Matt Rutkowski (IBM) 13 | * Kay Williams (Microsoft) 14 | 15 | ## Agenda 16 | 17 | * OSTIF budget vote - [OSTIF Open Source MAP 2021 OpenSSF - Modified for Proposed Grant - Google Docs](https://docs.google.com/document/d/1ZlLoohg8ZSK6Lad538Nq3FqC0ouPRcACOGdea_NqQ6Y/edit#heading=h.5fa2j8dq0uqa) 18 | 19 | An updated proposal was created to demonstrate what OSTIF will do with $60,000. In summary, OSTIF proposes a complete end-to-end review of **Symfony**. The reasoning is as follows: 20 | 21 | * Symfony is used in thousands of applications including nearly all of the popular PHP frameworks. It controls security-critical functions such as permissions and authentication, manages databases, and in many cases handles untrusted file uploads. 22 | * Symfony comes in at #8 on the OpenSSF Criticality Score 23 | * Lastly,[ recent CVEs show classes of bugs that can be minimized with better testing](https://www.cvedetails.com/product/22402/Sensiolabs-Symfony.html?vendor_id=11981), suggesting that there may be incomplete testing that can be improved upon. 24 | * TAC voted and APPROVED, Ryan will send proposal to GB (GB meets next week). 25 | * Supply Chain Security & the EO (Kay Williams) -[EO, SBOM and Supply Chain Integrity.pptx - Google Slides](https://drive.google.com/file/d/1HYUg8tq65ZQWqq6em0QyCymDnala7vjg/view?usp=sharing) 26 | * David’s process for overseeing security work (David A. Wheeler) - “Post-Approval LF Security Funding” (basically, monthly public reports) [https://docs.google.com/document/d/1iIDAWRY_xBatKsbrXUe4iR0a_VTxqYCYJ40ZCrhlOKg/edit](https://docs.google.com/document/d/1iIDAWRY_xBatKsbrXUe4iR0a_VTxqYCYJ40ZCrhlOKg/edit) -------------------------------------------------------------------------------- /TI-reports/2025/2025-Q3-Repos-WG.md: -------------------------------------------------------------------------------- 1 | # 2025 Q3 Securing Software Repositories Working Group 2 | 3 | ## Overview 4 | 5 | **Mission**: Improve security of software repositories (npm, PyPI, RubyGems, ...) by providing a forum for discussion, a maturity model for security roadmaps, and guidance for individual security capabilities. 6 | 7 | **Links**: 8 | - [GitHub repository](https://github.com/ossf/wg-securing-software-repos) 9 | - [Slack channel](https://openssf.slack.com/archives/C034CBLMQ9G) 10 | - [WG meeting docs](https://docs.google.com/document/d/18Y8HxntL2RkcgqoFdhdLpj17e4MOSCdskP1IoDiuP1s/edit?usp=sharing) 11 | 12 | ## Securing Software Repositories Working Group 13 | 14 | ### Purpose 15 | 16 | Improve security of software repositories by providing a forum for discussion, a maturity model for security roadmaps, and guidance for individual security capabilities. These conversations, roadmaps, and guidance help ecosystems learn from each other, which accelerates the deployment of security capabilities. 17 | 18 | ### Current Status 19 | 20 | - [UI/UX support for attestations on software repos](https://github.com/ossf/tac/issues/424) coming along well, a few weeks left on contract 21 | - [Rust Crates now supports Trusted Publishing](https://blog.rust-lang.org/2025/07/11/crates-io-development-update-2025-07/) 22 | - [npm now supports Trusted Publishing](https://github.blog/changelog/2025-07-31-npm-trusted-publishing-with-oidc-is-generally-available/) 23 | - RSTUF participating in summer mentorship program 24 | 25 | ### Up Next 26 | 27 | - Wrap up [UI/UX support for attestations on software repos](https://github.com/ossf/tac/issues/424) 28 | - Support (at least) one more security capability landing 29 | - NuGet trusted publishing? 30 | - RSTUF v1.0.0 release 31 | - Check in on [Sigstore specifications for the conda ecosystem](https://github.com/ossf/tac/issues/472) 32 | 33 | ### Questions/Issues for the TAC 34 | 35 | - None at this time 36 | -------------------------------------------------------------------------------- /minutes/2021-02-23.md: -------------------------------------------------------------------------------- 1 | # **2021-02-23 Meeting** 2 | 3 | ## Attendance (please add yourself): 4 | 5 | * Luke Hinds (Red Hat) 6 | * David A. Wheeler (Linux Foundation) 7 | * Jennifer Fernick (NCC Group) 8 | * Ryan Haning (Microsoft) 9 | * Phil Estes (AWS) 10 | * Rao Lakkakula (JPM) 11 | * Dan Lorenc (Google) 12 | * CRob (Red Hat) 13 | * Vinod Anandan (Citi) 14 | * Matt Rutkowski (IBM) 15 | * Dan Middleton (Intel) 16 | * Nick Ozmore (Veracode) 17 | * Lindsay Gendreau (Linux Foundation) 18 | * Maya Kaczorowski (GitHub) 19 | * Kay Williams (Microsoft) 20 | 21 | ## Agenda: 22 | 23 | * Town Hall review (yesterday’s) 24 | * Overall view is that Town Hall went really really well!! 25 | * Kept time perfectly, participants seemed to be very interested 26 | * Quarterly Town Hall Schedule 27 | * TAC Meeting to Review WG Quarterly Updates 28 | * Final TAC meeting of the quarter 29 | * TAC meeting prior to content due date 30 | * WG, TAC provide content to planning committee for newsletter 31 | * Friday of the two weeks ahead of newsletter 32 | * Example Friday April 16 33 | * Planning committee (including GB, TAC) review content 34 | * Week ahead of newsletter 35 | * Example Week of 4/19 36 | * Newsletter (blog, email, tweet) 37 | * Last Thursday of quarter (January, April, July, October) 38 | * Example 4/29 39 | * Town Hall meeting 40 | * First week of next quarter 41 | * Intellectual Property Policy - Kay 42 | * GB Offsite update 43 | * WG Review and Formalization 44 | * Promote WGs from ‘Incubation’ to ‘Active’ 45 | * See [https://github.com/ossf/tac/blob/main/working-group-lifecycle.md](https://github.com/ossf/tac/blob/main/working-group-lifecycle.md) 46 | * Review and vote on Best Practices, Vulnerabilities, Identifying Security Threats on 3/9 47 | * Review and vote on Digital Identity Attestation, Securing Critical Projects, Security Tooling on 3/23 48 | * Reviews are capped at 20 minutes each, discussion will continue at a future meeting if needed -------------------------------------------------------------------------------- /minutes/2021-09-07.md: -------------------------------------------------------------------------------- 1 | # **2021-09-07 Meeting** 2 | 3 | ## Attendance (please add yourself): 4 | 5 | * David A. Wheeler (Linux Foundation) 6 | * Matt Rutkowski, he/him, CT (IBM) 7 | * Ryan Haning (Microsoft) 8 | * CRob (Intel) 9 | * Phil Estes (AWS) 10 | * Kay Williams (Microsoft) 11 | * Luke Hinds (Red Hat) 12 | * Dan Lorenc (Google) 13 | * Jose Palafox 14 | * Rao Lakkakula (JPMChase) 15 | * Jeff Borek (IBM) 16 | 17 | ## Agenda: 18 | 19 | * Vuln Disclosure WG’s “Guide to coordinated vulnerability disclosure for open source software projects” [guide ](https://github.com/ossf/oss-vulnerability-guide)& [blog ](https://docs.google.com/document/d/1BPCcnaagTLht7vBk6q5AS_KxiGmLDj76uaZb3yg5_Ro/edit?resourcekey=0-JjkQMDZTT_RZ2buk6NTDhw)proposal 20 | * Presentation by CRob 21 | * Have a draft blog post, want to consider it for publication: [https://docs.google.com/document/d/1BPCcnaagTLht7vBk6q5AS_KxiGmLDj76uaZb3yg5_Ro/edit](https://docs.google.com/document/d/1BPCcnaagTLht7vBk6q5AS_KxiGmLDj76uaZb3yg5_Ro/edit) 22 | * [https://github.com/ossf/oss-vulnerability-guide](https://github.com/ossf/oss-vulnerability-guide) 23 | * David: I’ll try to get an LF editor to review, but we can do that in parallel. 24 | * Elections to come 25 | * There’s a charter update to switch to membership dues. This will provide funding to the OpenSSF. 26 | * Kay: When we formed the OpenSSF, there were a lot of financial uncertainties due to the pandemic, so we formed it without requiring member dues. Now that we’ve had a year & things are clearer, we’re switching to requiring member dues. Will have premier membership levels. This also implies changes to the governing board; each premier membership gives a seat on the governing board (GB), the rest of the members vote for reps on the GB (1 rep / 10 member companies, up to 3 reps). We expect some continuity, but there will be some changes. Intend for this complete November. 27 | * TAC elections: GB is supposed to officially ratify the TAC election process, need to do that. We could do that with the current GB, or wait for the new GB. 28 | * TAC members were open to waiting for the new GB. -------------------------------------------------------------------------------- /process/project-lifecycle-documents/maliciouspackages_sandbox_stage.md: -------------------------------------------------------------------------------- 1 | ## Application for creating a new project at Sandbox stage 2 | 3 | ### List of project maintainers 4 | 5 | - Paul McCarty, SourceCodeRED, @6mile 6 | - Caleb Brown, Google, @calebbrown 7 | - Jeff Mendoza, Kusari, @jeffmendoza 8 | 9 | ### Sponsor 10 | 11 | * Securing Critical Projects Working Group 12 | 13 | ### Mission of the project 14 | 15 | The OpenSSF Malicious Packages project aims to establish and maintain a comprehensive, high-quality, open source database of reports documenting malicious packages published on open source package repositories. By collecting, verifying, and sharing these reports in a standardized Open Source Vulnerability (OSV) format, we strive to protect the open source community from increasingly prevalent threats such as typosquatting, dependency confusion, and account takeovers. Our work provides critical data for the security community to improve detection capabilities and develop better defenses against new open source malware. Through collaboration with security researchers, package maintainers, and ecosystem stakeholders, we seek to enhance the integrity and security of the open source supply chain for the benefit of all users. 16 | 17 | ### IP policy and licensing due diligence 18 | 19 | When contributing an existing Project to the OpenSSF, the contribution must undergo license and IP due diligence by the Linux Foundation (LF). 20 | 21 | RE: @steiza Not applicable in the sense that this project has already been operating in the OpenSSF as part of the Securing Critical Projects WG, but the project does have software (as most OpenSSF projects do!) which is licensed under Apache 2.0. 22 | 23 | ### Project References 24 | 25 | | Reference | URL | 26 | |---------------------|-----| 27 | | Repo | https://github.com/ossf/malicious-packages | 28 | | Website | https://github.com/ossf/malicious-packages | 29 | | Contributing guide | https://github.com/ossf/malicious-packages/blob/main/CONTRIBUTING.md | 30 | | Security.md | https://github.com/ossf/malicious-packages/blob/main/SECURITY.md | 31 | | Roadmap | TBD | 32 | | Demos | N/A | 33 | | Other | TBD | 34 | -------------------------------------------------------------------------------- /minutes/2022-10-18.md: -------------------------------------------------------------------------------- 1 | # **2022-10-18 Meeting** 2 | 3 | Attendance (please add yourself): 4 | 5 | 6 | 7 | * CRob (Intel, TAC) 8 | * Bob Callaway (Google, TAC Chair) 9 | * Josh Bressers (Anchore, TAC) 10 | * Dan Appelquist (Snyk) 11 | * Brian Behlendorf (LF/OpenSSF) 12 | * Michael Scovetta (Microsoft) 13 | * Aeva Black (Microsoft, TAC Vice Chair) 14 | * Emily Fox (Apple, CNCF TOC) 15 | * Jory Burson (LF/OpenSSF) 16 | * Luke Hinds (Red Hat, TAC) 17 | * Phil Estes (AWS) 18 | * Arnaud Le Hors (IBM) 19 | * Matt Rutkowski (IBM) 20 | * Dan Lorenc (Chainguard, TAC) 21 | * Jennifer Bly (OpenSSF) 22 | * Álvaro Figueroa (Microsoft) 23 | * Jacques Chester (Shopify) 24 | * Jay White (Microsoft) 25 | * Jamie Magee (Microsoft) 26 | * David Edelsohn (IBM, GTI) 27 | 28 | Regrets: 29 | 30 | 31 | 32 | * Abhishek Arya (Google, TAC) 33 | 34 | Agenda: 35 | 36 | 37 | 38 | * (_10 min max_): Update from **Identifying Security Threats WG** 39 | * [Slide Deck](https://docs.google.com/presentation/d/186Hm6A3YMVfTFQi6vXEsY-1Uwpcx3Xbv-4SHN3mASxw/edit?usp=sharing) 40 | * (_10 min max_): Update from **Security Tooling WG** 41 | * [Slide Deck](https://docs.google.com/presentation/d/1EEl1wW0Qiwauu9e8xDcizcQZB-WwuXulLig0ydv9AHs/edit#slide=id.p) 42 | * [bob]: (question): GTI update? Feedback on WG/project updates? 43 | * [bob]: [technical vision draft](https://github.com/ossf/tac/pull/129) 44 | * Mission statement update (underway by OpenSSF GB subcommittee) 45 | * Visionpr 46 | * Strategy (set of projects, WG, mobilization plan workstreams, etc) 47 | * _Idea_: Explicitly list things that are not in scope (today) 48 | * Aeva: Perhaps use a framing of “The year is 2025, these are the things we’ve accomplished” instead of the abstract list of bullet points 49 | * Jeff Borek: Perhaps list out values that the foundation should exude as we do the things that are listed in the vision 50 | * (5 min max): Holiday Calendar Management 51 | * FYI: Canceling meetings on Nov. 24-25; Dec. 26-30 52 | * Recommend to WG chairs to agenda plan around holiday weeks 53 | * E.g. no big decisions while people are away :D 54 | * Send meeting updates to operations@ 55 | * (2 min max): Slack Apps 56 | * Several installed apps (Coda, Asana, LoopHQ, Lucid, etc etc) not in use to be rm’d 57 | 58 | 59 | -------------------------------------------------------------------------------- /TI-reports/2025/2025-Q4-Repos-WG.md: -------------------------------------------------------------------------------- 1 | # 2025 Q4 Securing Software Repositories Working Group 2 | 3 | ## Overview 4 | 5 | **Mission**: Improve security of software repositories (npm, PyPI, RubyGems, ...) by providing a forum for discussion, a maturity model for security roadmaps, and guidance for individual security capabilities. 6 | 7 | **Links**: 8 | - [GitHub repository](https://github.com/ossf/wg-securing-software-repos) 9 | - [Slack channel](https://openssf.slack.com/archives/C034CBLMQ9G) 10 | - [WG meeting docs](https://docs.google.com/document/d/18Y8HxntL2RkcgqoFdhdLpj17e4MOSCdskP1IoDiuP1s/edit?usp=sharing) 11 | 12 | ## Securing Software Repositories Working Group 13 | 14 | ### Purpose 15 | 16 | Improve security of software repositories by providing a forum for discussion, a maturity model for security roadmaps, and guidance for individual security capabilities. These conversations, roadmaps, and guidance help ecosystems learn from each other, which accelerates the deployment of security capabilities. 17 | 18 | ### Current Status 19 | 20 | - [UI/UX support for attestations on software repos - phase 1 (recommendations) complete](https://github.com/ossf/wg-securing-software-repos/blob/main/docs/attestations-style-guide.md) 21 | - [RSTUF had v1.0.0 release](https://github.com/repository-service-tuf/repository-service-tuf/releases/tag/v1.0.0) 22 | - [NuGet now supports Trusted Publishing](https://learn.microsoft.com/en-us/nuget/nuget-org/trusted-publishing) 23 | 24 | ### Up Next 25 | 26 | - Lots of continued attacks / mitigation discussions 27 | - Phishing maintainers for TOTP (should we move to phishing-resistant MFA?) 28 | - Quarantine / soft-delete as capabilities for dealing with increased malware submissions 29 | - Malware detection capabilities 30 | 31 | ### Package repositories in the news 32 | 33 | - [GitHub's plan for a more secure npm supply chain](https://github.blog/security/supply-chain-security/our-plan-for-a-more-secure-npm-supply-chain/) 34 | - [Open Infrastructure is Not Free](https://openssf.org/blog/2025/09/23/open-infrastructure-is-not-free-a-joint-statement-on-sustainable-stewardship/) 35 | - [The Transition of RubyGems Repository Ownership](https://www.ruby-lang.org/en/news/2025/10/17/rubygems-repository-transition/) 36 | 37 | ### Questions/Issues for the TAC 38 | 39 | - None at this time 40 | -------------------------------------------------------------------------------- /process/project-lifecycle-documents/cve-bin-tool_sandbox_stage.md: -------------------------------------------------------------------------------- 1 | ## Application for creating a new project at Sandbox stage 2 | 3 | ### List of project maintainers 4 | 5 | The project must have a minimum of three maintainers with a minimum of two different organizational affiliations. 6 | 7 | * Terri Oda, non-affiliated, @terriko 8 | * Anthony Harrison, APH10, @anthonyharrison 9 | * Fabrice Fontaine, Orange, @ffontaine 10 | * Sanskar Sharma, Nirmata, @mastersans 11 | * Steve Miller, Intel, @stvml 12 | 13 | ### Sponsor 14 | 15 | * OpenSSF Security Tooling WG 16 | 17 | ### Mission of the project 18 | 19 | The CVE Binary Tool helps you determine if your system includes known vulnerabilities. You can scan binaries for over 400 common, vulnerable components (openssl, libpng, libxml2, expat and others), or if you know the components used, you can get a list of known vulnerabilities associated with an SBOM or a list of components and versions. 20 | 21 | ### IP policy and licensing due diligence 22 | 23 | Project License is GPLv3+ and component list has previously been reviewed by the licensing team at Intel corporation. It has not yet been reviewed by the Linux Foundationn. 24 | 25 | * [SBOM for Python 3.13 in SPDX format](https://github.com/intel/cve-bin-tool/blob/main/sbom/cve-bin-tool-py3.13.spdx) 26 | * [SBOMS in other formats and for other versions of python](https://github.com/intel/cve-bin-tool/tree/main/sbom) 27 | 28 | ### Project References 29 | 30 | The project should provide a list of existing resources with links to the repository, and if available, website, a roadmap, contributing guide, demos and walkthroughs, and any other material to showcase the existing breadth, maturity, and direction of the project. 31 | 32 | | Reference | URL | 33 | |---------------------|-----| 34 | | Repo | https://github.com/intel/cve-bin-tool/ | 35 | | Website | https://cve-bin-tool.readthedocs.io/en/latest/ | 36 | | Contributing guide | https://github.com/intel/cve-bin-tool/blob/main/CONTRIBUTING.md | 37 | | Security.md | https://github.com/intel/cve-bin-tool/blob/main/SECURITY.md | 38 | | Roadmap | https://github.com/intel/cve-bin-tool/milestones | 39 | | Demos | https://github.com/intel/cve-bin-tool/tree/main/presentation | 40 | | Other | | 41 | -------------------------------------------------------------------------------- /minutes/2021-04-06.md: -------------------------------------------------------------------------------- 1 | # **2021-04-06 Meeting** 2 | 3 | ## Attendance (please add yourself): 4 | 5 | * CRob (Red Hat) 6 | * Ax Sharma (Sonatype) 7 | * Dan Middleton (Intel) 8 | * Jennifer Fernick (NCC Group) 9 | * Derek Zimmer (Open Source Tech Improvement Fund) 10 | * David A. Wheeler (Linux Foundation) 11 | * Ryan Ware (Intel) 12 | * Amir Montazery (Open Source Tech Improvement Fund) 13 | * Matt Rutkowski (IBM) 14 | * Carly Driggers (Linux Foundation) 15 | * Luke Hinds (Red Hat) 16 | * Vinod Anandan (Citi) 17 | * Ryan Haning (Microsoft) 18 | * Parris Lucas (GrooveCS) 19 | 20 | ## Agenda: 21 | 22 | * Working Group Reviews 23 | * Security Tooling - Ryan Ware 24 | * Managed Audit Program Proposal - Derek Zimmer 25 | * Process for auditing open source projects. 26 | * Proposing 25 audits on critical projects. “Most critical projects that can be backed by data” 27 | * Take proposals for audits from a network of audit teams and groups. 28 | * Diverse network of teams from around the world (US, EU, Asia) 29 | * Took data from multiple data points (Harvard Research, Criticality Score, etc) 30 | * OSTIF has a large advisory council from experts from around the world 31 | * OSTIF focuses on open source projects, projects that don’t have central resources (banking, expertise) 32 | * Results are security fixes (finding bugs, longevity, explaining how bugs were found, how tooling can be improved as project matures) 33 | * Recognize sponsors on all research 34 | * Google is on board for the project 35 | * Success stories: Audited 16 projects on a budget of $780,000 36 | * Located 26 severe bugs under the program 37 | * Time the review to be most effective (not reviewing something that was already reviewed) 38 | * Gave examples: OpenSSL 1.1.1 and PRNG and Unbound DNS 39 | * Funding: external application process for funding projects imminently 40 | * Prioritize and finalize budgeting requirements 41 | 42 | * **_NOTE: Did not cover the items below due to time constraints - JF mentioned briefly plans for OpenSSF to create process for external parties to apply for OpenSSF funding _** 43 | * Budget Planning Update - Kay Williams 44 | * WG funding 45 | * External proposals 46 | * GB Offsite - OpenSSF decision-making - Jennifer Fernick 47 | * (if time available) Outreach/Conferences - Jennifer Fernick -------------------------------------------------------------------------------- /process/project-lifecycle-documents/openbao_sandbox_stage.md: -------------------------------------------------------------------------------- 1 | ## Application for creating a new project at Sandbox stage 2 | 3 | ### List of project maintainers 4 | 5 | Per [project documents](https://github.com/openbao/openbao/blob/main/MAINTAINERS.md): 6 | 7 | - Dan Ghita, Wallix, @DanGhita 8 | - Jan Martens, Independent, @JanMa 9 | - Nathan Phelps, IBM, @naphelps 10 | - Alex Scheel, GitLab, @cipherboy 11 | 12 | In scoped roles: 13 | 14 | - Dave Dykstra, Fermilab, @DrDaveD; committer for `auth/jwt` 15 | 16 | We also have four moderators with no commit privileges. 17 | 18 | ### Sponsor 19 | 20 | - OpenSSF Security Tooling WG 21 | 22 | ### Mission of the project 23 | 24 | Per [our website](https://openbao.org/): 25 | 26 | - OpenBao exists to maintain and improve a software solution to manage, store, and distribute sensitive data including secrets, certificates, and keys. The OpenBao community will provide this software under an OSI-approved open-source license, led by a community run under open governance principles. 27 | 28 | ### IP policy and licensing due diligence 29 | 30 | - Applicable; OpenBao's [code and core documentation](https://github.com/openbao) are licensed [under the MPLv2](https://github.com/openbao/openbao/blob/main/LICENSE) due to upstream licensing. 31 | - Remaining out-of-core-repo documentation is under the [Creative Commons Attribution v4.0 International License](https://openbao.org/assets/OpenBao-Technical-Charter-Final-2024-05-08.pdf) per organization charter (Section 7.b.iv). 32 | 33 | This will require review and exception approval [from the TAC per charter](https://openssf.org/about/charter/). 34 | 35 | ### Project References 36 | 37 | | Reference | URL | 38 | |---------------------|-----| 39 | | Repo | https://github.com/openbao/openbao/ | 40 | | Website | https://openbao.org/ | 41 | | Contributing guide | https://openbao.org/docs/contributing/, https://github.com/openbao/openbao/blob/main/CONTRIBUTING.md | 42 | | Security.md | https://openbao.org/docs/internals/security/#threat-model, https://github.com/openbao/.github/blob/main/SECURITY.md | 43 | | Roadmap | https://github.com/openbao/openbao/issues/569 | 44 | | Demos | n/a | 45 | | Other | https://insights.lfx.linuxfoundation.org/foundation/lfedge/overview/github?project=openbao&repository=&routedFrom=Github | 46 | -------------------------------------------------------------------------------- /TI-reports/2025/2025-Q2-Repos-WG.md: -------------------------------------------------------------------------------- 1 | # 2025 Q2 Securing Software Repositories Working Group 2 | 3 | ## Overview 4 | 5 | **Mission**: Improve security of software repositories (npm, PyPI, RubyGems, ...) by providing a forum for discussion, a maturity model for security roadmaps, and guidance for individual security capabilities. 6 | 7 | **Links**: 8 | - [GitHub repository](https://github.com/ossf/wg-securing-software-repos) 9 | - [Slack channel](https://openssf.slack.com/archives/C034CBLMQ9G) 10 | - [WG meeting docs](https://docs.google.com/document/d/18Y8HxntL2RkcgqoFdhdLpj17e4MOSCdskP1IoDiuP1s/edit?usp=sharing) 11 | 12 | ## Securing Software Repositories Working Group 13 | 14 | ### Purpose 15 | 16 | Improve security of software repositories by providing a forum for discussion, a maturity model for security roadmaps, and guidance for individual security capabilities. These conversations, roadmaps, and guidance help ecosystems learn from each other, which accelerates the deployment of security capabilities. 17 | 18 | ### Current Status 19 | 20 | - ["Crafting a Package Deletion Policy"](https://repos.openssf.org/package-deletion-policies) published, completing https://github.com/ossf/tac/issues/414. 21 | - ["UI/UX support for attestations on software repos"](https://github.com/ossf/tac/issues/424) funding approved, contractors identified, awaiting SOWs. 22 | - [Rubygems now supports publishing attestations](https://github.com/rubygems/rubygems/pull/8239) 23 | - npm is working on trusted publishing for release "this summer" and our [Trusted Publishing guide](https://repos.openssf.org/trusted-publishers-for-all-package-repositories) has been helpful 24 | - Meetings continue every other week, with async discussions in the Slack channel 25 | - Repository Service for TUF (RSTUF) has announced 1.0.0 release candidates 26 | 27 | ### Up Next 28 | 29 | - Project kickoff: "UI/UX support for attestations on software repos" 30 | - Continue supporting landing security capabilities in software repositories! 31 | - Publish more guidance from community-suggested topics, like: 32 | - Handling pre-compiled binaries vs arbitrary code execution at install-time 33 | - How to shut down a package repository that is no longer being maintained 34 | - Architecture choices and trade-offs for a new package repository being written from scratch 35 | - RSTUF 1.0.0 final releases planned for this summer 36 | 37 | ### Questions/Issues for the TAC 38 | 39 | - None at this time 40 | -------------------------------------------------------------------------------- /minutes/2021-09-21.md: -------------------------------------------------------------------------------- 1 | # **2021-09-21 Meeting** 2 | 3 | ## Attendance (please add yourself): 4 | 5 | * CRob (Intel) 6 | * Kay Williams (Microsoft) 7 | * Ryan Haning (Microsoft) 8 | * Michael Scovetta (Microsoft) 9 | * Luke Hinds (Red Hat) 10 | * Matt Rutkowski, he/him, CT (IBM) 11 | * Jacques Chester (Shopify) 12 | * Jennifer Fernick (NCC Group) 13 | * David A. Wheeler (Linux Foundation) 14 | 15 | ## Agenda: 16 | 17 | * Welcome Jory Burson! 18 | * Jory is our new OpenSSF Project Manager 19 | * [jburson@linuxfoundation.org](mailto:jburson@linuxfoundation.org) 20 | * Project Alpha/Omega pilot program funding request - Michael Scovetta 21 | * See Alpha-Omega proposal: [https://docs.google.com/document/d/1u7Ps18dzu9M-HF7ZHTK6VB5jLaVJvnw6uq3o7qw5yGE/edit](https://docs.google.com/document/d/1u7Ps18dzu9M-HF7ZHTK6VB5jLaVJvnw6uq3o7qw5yGE/edit) 22 | * WG ownership discussion 23 | * Shortlist of critical OSS projects: (5?) 24 | * Owner=Mike 25 | * Reach out to each project. “This is what we’re thinking?” Do you think your project would be amenable to assistance in these areas? 26 | * Which ones? 27 | * **Criticality Project**: top 5 are node, kubernetes, rust, spark, and nixpkgs. 28 | * Other Opinions: openssl? Package managers? CPython? React? 29 | * TAC => Opinions here? 30 | * Might also look at LF/Harvard (Census II) & Census I reports. 31 | * Amir/OSTIF has a list 32 | * Potential Survey / Concept [https://docs.google.com/forms/d/1McOtre139ejQtcb5ZXWIFgzHd9PpGCBC6Ag1MkbAsH4/edit?usp=sharing](https://docs.google.com/forms/d/1McOtre139ejQtcb5ZXWIFgzHd9PpGCBC6Ag1MkbAsH4/edit?usp=sharing) 33 | * Election Process 34 | * How are nominations made 35 | * Central location for self-nominations 36 | * 2 year, overlapping terms to maintain continuity 37 | * GB & Community vote on each election, for whichever seat(s) are being elected (Community or GB seats) 38 | * What is the voting process 39 | * New Incubating Project - SCIM - Kay 40 | * [microsoft/scim: Supply Chain Integrity Model (github.com)](https://github.com/microsoft/SCIM) 41 | * Brainstorming diagram for OpenSSF Reference Architecture to explain what we’re doing and how it all connects 42 | * [https://lucid.app/lucidchart/invitations/accept/inv_6e978645-4904-4a4e-870a-b1dd80907529](https://lucid.app/lucidchart/invitations/accept/inv_6e978645-4904-4a4e-870a-b1dd80907529) -------------------------------------------------------------------------------- /process/project-lifecycle-documents/repository_service_for_tuf_sandbox_stage.md: -------------------------------------------------------------------------------- 1 | ## Application for creating a new project at Sandbox stage 2 | 3 | ### List of project maintainers 4 | 5 | * Kairo Araujo, VMware, kairoaraujo 6 | * Radoslav Dimitrov, VMware, rdimitrov 7 | * Martin Vrachev, VMware, mvrachev 8 | * Lukas Pühringer, NYU, lukpueh 9 | * Konstantinos Papadopoulos, Channable, KAUTH 10 | 11 | ### Mission of the project 12 | 13 | The Repository Service for TUF's mission is to make it easier for repositories to integrate the features of [The Update Framework (TUF)] without requiring TUF expertise or deep changes to the repository service implementation. 14 | 15 | The project provides repository signing functionality with a simple REST API for integration into any repository offering. The system's architecture enables scalability for high-traffic repositories. 16 | 17 | The project was born out of experience developing changes for Warehouse (PyPI) to deliver [PEP 458] and, for the initial roadmap, focuses on providing PEP 458-like repository signing functionality. In future, the Repository Service for TUF will develop to support other TUF architecture patterns including [PEP 480]-like developer signing and more. 18 | 19 | [The Update Framework (TUF)]: https://theupdateframework.io 20 | [PEP 458]: https://peps.python.org/pep-0458/ 21 | [PEP 480]: https://peps.python.org/pep-0480/ 22 | 23 | 24 | ### IP policy and licensing due diligence 25 | 26 | When contributing an existing Project to the OpenSSF, the contribution must undergo license and IP due diligence by the Linux Foundation (LF). 27 | 28 | * "yes [#136](https://github.com/ossf/tac/issues/136)" 29 | 30 | ### Project References 31 | 32 | | Reference | URL | 33 | |--------------------|-----| 34 | | Repo | https://github.com/vmware/repository-service-tuf https://github.com/vmware/repository-service-tuf-api https://github.com/vmware/repository-service-tuf-cli https://github.com/vmware/repository-service-tuf-worker | 35 | | Website | https://repository-service-tuf.readthedocs.io/en/latest/ | 36 | | Contributing guide | https://repository-service-tuf.readthedocs.io/en/latest/devel/contributing.html | 37 | | Roadmap | https://repository-service-tuf.readthedocs.io/en/latest/devel/release.html#roadmap | 38 | | Demos | https://www.youtube.com/watch?v=YFxgbTPYyZE https://youtu.be/IXEJpJ50Aj4?list=PLVl2hFL_zAh_VfsvGMCrkPSS1z2VFFy-r&t=276 | 39 | -------------------------------------------------------------------------------- /process/wg-lifecycle-documents/security_tooling_wg_graduation_stage.md: -------------------------------------------------------------------------------- 1 | ## Working Group graduation application 2 | 3 | ### WG has met all Incubating requirements 4 | * N/A 5 | 6 | ### List of regular contributors 7 | The WG must have at least 5 contributors from at least 3 different organizations attending regularly as recorded in meeting minutes. 8 | * (Chair) Ryan Ware, Individual, @ware 9 | * (Vice-Chair) Ian Dunbar-Hall, Lockheed Martin, @idunbarh 10 | * (Vice-Chair) Josh Bressers, Anchore, @joshbressers 11 | * (Vice-Chair) Mike Lieberman, Kusari, @mlieberman85 12 | * Evan Anderson, Stacklok, @evankanderson 13 | * Hannah Sutor, GitLab, @hsutor 14 | * Nisha Kumar, Oracle, @nishakm 15 | * Scott Moore, Galois, Inc., @thinkmoore 16 | * Daniel Moch, Lockheed Martin, @djmoch 17 | 18 | ### Governance 19 | WG must have documented governance and be able to demonstrate that governance in action. 20 | * [Charter](https://github.com/ossf/wg-security-tooling/blob/main/CHARTER.md) 21 | 22 | WG has met at least 4 times over a period of at least 2 months since becoming incubating 23 | * [2025 Meeting Minutes](https://docs.google.com/document/d/190urQjwvE6DsjZ3Z1vBbNEXsJ--ccC8xHmbe_fYKRHA/edit?tab=t.0) 24 | * [2024 Meeting Minutes](https://docs.google.com/document/d/1bFpHEbbEUf2rWiYXQY7cGg1HrmI9TqwaD8U_3Hi9A8I/edit?tab=t.0#heading=h.v07d658tnyfp) 25 | 26 | ### TI References 27 | The TI must provide a list of existing resources with links to the repository, website, a roadmap, contributing guide, demos and walkthroughs, and any other material to showcase the existing breadth, maturity, and direction of the project. 28 | 29 | Reference | URL | 30 | |-----------------------|-----| 31 | | Repo | https://github.com/ossf/wg-security-tooling | 32 | | Meeting Agenda | https://docs.google.com/document/d/190urQjwvE6DsjZ3Z1vBbNEXsJ--ccC8xHmbe_fYKRHA/edit?tab=t.0 | 33 | | OSSF Calendar Entry | https://github.com/ossf/wg-security-tooling?tab=readme-ov-file#meeting-times | 34 | | Website | n/a | 35 | | Contributing guide | https://github.com/ossf/wg-security-tooling?tab=readme-ov-file#get-involved | 36 | | Security.md | https://github.com/ossf/wg-security-tooling/blob/main/SECURITY.md | 37 | | Roadmap | https://github.com/ossf/wg-security-tooling/issues/68 | 38 | | Other | [Guide to Security Tools](https://github.com/ossf/wg-security-tooling/blob/main/guide.md) | 39 | -------------------------------------------------------------------------------- /minutes/2021-02-09.md: -------------------------------------------------------------------------------- 1 | # **2021-02-09 Meeting** 2 | 3 | ## Attendance (please add yourself): 4 | 5 | * David A. Wheeler (Linux Foundation) 6 | * Lindsay Gendreau 7 | * Carly Driggers 8 | * Jennifer Fernick 9 | * Ryan Haning 10 | * Kay Williams 11 | * Phil Estes 12 | * Altaz Valani 13 | * Maya K 14 | * Dan Lorenc 15 | * Rao L 16 | * Ben Stoltz 17 | 18 | ## Agenda: 19 | 20 | * OpenSSF Town Hall update (Kay). Feb 22, 10am Pacific. 21 | * Currently we have 44 registered 22 | * PLEASE REGISTER: [https://zoom.us/webinar/register/WN_5iCAH2-ETaGpiI7UQNSMXw](https://zoom.us/webinar/register/WN_5iCAH2-ETaGpiI7UQNSMXw) 23 | * PLEASE HELP GET THE WORD OUT! 24 | * WG leads: Please help fill in the slide deck 25 | * Note, intention is not just outreach but also cross-pollination 26 | * Transition: Lindsay Gendreau -> Carly Driggers 27 | * Finalize TAC election process 28 | * [https://github.com/ossf/tac/issues/15](https://github.com/ossf/tac/issues/15) 29 | * For full details see: [https://docs.google.com/document/d/1RinuQweFgZI5WDlmu7OUl1-Yh57a6LBGEfWPTkdzuD0/edit](https://docs.google.com/document/d/1RinuQweFgZI5WDlmu7OUl1-Yh57a6LBGEfWPTkdzuD0/edit) 30 | * Who is eligible to be nominated: someone with active contributions (commits) 31 | * Who is eligible to vote: 32 | * You have a commit in ossf github repo 33 | * Exception process for contributions that aren’t source control based, at discretion of WG Leads. 34 | * When is vote: 35 | * Sept 2021 36 | * Replace those who step down and draw straws for remaining. 37 | * How many seats: 38 | * 7 (consensus is retain existing size) 39 | * Composition of seats by board vs community 40 | * 4 community; 3 board 41 | * Continuity of chairs 42 | * No special case 43 | * Term lengths: no cap 44 | * Term duration: 2 years 45 | * Role of the TAC and process discussion 46 | * Discuss Charter Template (see discussions in the following TAC issues) 47 | * [https://github.com/ossf/tac/issues/26](https://github.com/ossf/tac/issues/26) (license policy) 48 | * ~~[https://github.com/ossf/tac/issues/13](https://github.com/ossf/tac/issues/13)~~ (lifecycle issue closed) 49 | * [https://github.com/ossf/tac/issues/9](https://github.com/ossf/tac/issues/9) (WG scope and charter issue) 50 | * (Proposed agenda item) Security Threats is creating “Project-Security-Reviews” to capture various security reviews; plan to use CC-BY license for each document per the original technical charter because they’re all documents. Apache-2.0 for code if any. License OK? We know of no issues. -------------------------------------------------------------------------------- /TI-reports/2025/2025-Q1-Repos-WG.md: -------------------------------------------------------------------------------- 1 | # 2025 Q1 Securing Software Repositories Working Group 2 | 3 | ## Overview 4 | 5 | **Mission**: Improve security of software repositories (npm, PyPI, RubyGems, ...) by providing a forum for discussion, a maturity model for security roadmaps, and guidance for individual security capabilities. 6 | 7 | **Links**: 8 | - [GitHub repository](https://github.com/ossf/wg-securing-software-repos) 9 | - [Slack channel](https://openssf.slack.com/archives/C034CBLMQ9G) 10 | - [WG meeting docs](https://docs.google.com/document/d/18Y8HxntL2RkcgqoFdhdLpj17e4MOSCdskP1IoDiuP1s/edit?usp=sharing) 11 | 12 | ## Securing Software Repositories Working Group 13 | 14 | ### Purpose 15 | 16 | Improve security of software repositories by providing a forum for discussion, a maturity model for security roadmaps, and guidance for individual security capabilities. These conversations, roadmaps, and guidance help ecosystems learn from each other, which accelerates the deployment of security capabilities. 17 | 18 | ### Current Status 19 | 20 | - [Central now performs Sigstore Signature Validation](https://central.sonatype.org/news/20250128_sigstore_signature_validation_via_portal/) 21 | - [Posting for technical writer](https://jobs.smartrecruiters.com/LinuxFoundation/744000038830864-openssf-securing-repositories-working-group-technical-writer) to write package yanking guidance is live 22 | - Submitted letter of support to Python Software Foundation's grant request to US National Science Foundation on detecting, flagging, and quarantining malware 23 | - Meetings continue every other week, with async discussions in the Slack channel 24 | 25 | ### Up Next 26 | 27 | - Hire contractor; publish package yanking guidance 28 | - [Funding request: UI/UX support for attestations on software repos](https://github.com/ossf/tac/issues/424) 29 | - Continue supporting landing security capabilities in software repositories 30 | 31 | ### Questions/Issues for the TAC 32 | 33 | - None at this time 34 | 35 | ## RSTUF Project 36 | 37 | ### Purpose 38 | 39 | Provide a service to protect repository index from tampering by distributing them with The Update Framework (TUF) 40 | 41 | ### Current Status 42 | 43 | - Continuing to work towards v1.0 release to run alongside RubyGems and PyPI and sign their repository index 44 | - [Funding approved: 2025 cloud development costs](https://github.com/ossf/tac/issues/417) 45 | 46 | ### Up Next 47 | 48 | - [Security audit with OSTIF](https://github.com/ossf/tac/issues/379) started Feb 3rd 2025 49 | 50 | ### Questions/Issues for the TAC 51 | 52 | - None at this time 53 | -------------------------------------------------------------------------------- /working-group-abilities.md: -------------------------------------------------------------------------------- 1 | # Working Group Abilities 2 | 3 | Established working groups in the OpenSSF are given broad latitude to accomplish their goals. 4 | The TAC aims to only require formal approval in limited cases. 5 | This document outlines some of the explicitly permitted activities and resources made 6 | available to working groups. 7 | 8 | 9 | As per the OpenSSF [charter/FAQ](https://openssf.org/#faq), the TAC is not directly in charge 10 | of sub initiatives. 11 | These are intended to run themselves, and are expected to make most decisions without needing 12 | to ask the TAC for permission. 13 | With this in mind, this document is not exhaustive and will grow over time - it is intended to 14 | outline the processes for some common requests and resources. 15 | 16 | When in doubt, reach out to the TAC with any questions! 17 | 18 | ## Repositories 19 | 20 | We expect that working groups will need to create repositories for code, tools, and other projects. 21 | These should be created in the [ossf](github.com/ossf) organization where possible to simplify 22 | management. 23 | 24 | Working groups can also request new organizations where necessary - reach out to the TAC for 25 | logistics. 26 | 27 | 28 | If any of these projects grow large enough, they can be "spun-off" into separate working groups by 29 | the TAC. 30 | As a general rule-of-thumb, if a sub-project requires its own standing meeting, it might be time to 31 | spin-it-off. 32 | 33 | ## Papers 34 | 35 | As the working groups are intended to be the subject matter experts in their domains, 36 | they should author papers for release through the OpenSSF without review or approval from the TAC. 37 | However, the TAC does ask that drafts be shared as early as possible (hopefully >7 days) for 38 | feedback and awareness. 39 | Drafts can be shared by sending email to openssf-tac@lists.openssf.org. 40 | 41 | Once completed, working groups should work with the Governing Board to communicate, promote, and 42 | market the published papers in accordance with the general OpenSSF communication strategy. 43 | 44 | All papers should still follow open source best practices including transparency in development and 45 | avoiding vendor bias. 46 | 47 | ## Technical Infrastructure 48 | 49 | Working groups are free to use whatever resources they can find, or to solicit help from member 50 | organizations, or to request funding from the OpenSSF Governing Board, through the TAC. 51 | 52 | The TAC asks that working groups keep them informed of what infrastructure they are using for 53 | awareness as we begin the process of collecting formal resources. 54 | -------------------------------------------------------------------------------- /minutes/2020-10-20.md: -------------------------------------------------------------------------------- 1 | # **2020-10-20 Meeting** 2 | 3 | ## Attendance (please add yourself) 4 | 5 | * David A. Wheeler (Linux Foundation) 6 | * Dan Middleton (Intel) 7 | * CRob (Red Hat) 8 | * Ryan Haning (Microsoft) 9 | * Rao Lakkakula (JPMChase) 10 | * Lindsay Mays Gendreau (Linux Foundation) 11 | * Luke Hinds (red hat) 12 | * Maya Kaczorowski (GitHub) 13 | * Dan Lorenc (Google) 14 | * Jennifer Fernick (NCC Group) 15 | * Phil Estes (IBM) 16 | 17 | ## Agenda 18 | 19 | * 10/29 Press Release - Kay 20 | * On track - reviewing with OpenSSF member organizations 21 | * 11/9 Town Hall meeting - Kay 22 | * Announcement ([here](https://docs.google.com/document/d/1TWli38xa4po73YJENJZigLZ5u0fZ-ZsyOSxE6Q2_sPs/edit)) 23 | * Send later today if no concerns 24 | * Get Involved ([https://openssf.org/getinvolved](https://openssf.org/getinvolved)) - Kay 25 | * Draft ([here](https://docs.google.com/document/d/12rDsqWyMZU8F62EEX3V__RISONYU0k0BlWKT23x5p2E/edit#)) 26 | * Update later today if no concerns 27 | * Security Community GB Representative - Jennifer 28 | * Update (Lindsay) 29 | * One system that supports ranked voting is Condorcet Internet Voting Service, [https://civs.cs.cornell.edu/](https://civs.cs.cornell.edu/) - expect voting per contributor (not per organization). More info: [https://civs.cs.cornell.edu/sec_priv.html](https://civs.cs.cornell.edu/sec_priv.html) 30 | * Issues Review 31 | * Assign owners? 32 | * Status? Add all WG meetings to public calendar <[https://github.com/ossf/tac/issues/18](https://github.com/ossf/tac/issues/18)> & Add Meeting Invites to Public Calendar <[https://github.com/ossf/wg-security-tooling/issues/9](https://github.com/ossf/wg-security-tooling/issues/9)> 33 | * Recommend close [https://github.com/ossf/tac/issues/14](https://github.com/ossf/tac/issues/14) (@chrisfer) 34 | * Is license policy clear? [https://github.com/ossf/tac/issues/26](https://github.com/ossf/tac/issues/26) 35 | * Is there remaining action for TAC here: Fill GB Security Community Individual Representative Seat [https://github.com/ossf/tac/issues/22](https://github.com/ossf/tac/issues/22) 36 | * Make an announcement once the submitted list of names is finalized, allowing for voting 37 | * Is `ping @rhaning` sufficient? [https://github.com/ossf/tac/issues/21](https://github.com/ossf/tac/issues/21) 38 | * David: Didn’t TAC want to review each WG charter? Should an issue be created? - David created GitHub issues (issues 29-34), Ryan will assign them to the leads 39 | * Charter for TCs is heavyweight, many WGs only have a few members. Should there be a lighter weight option? Potential topic for next time. -------------------------------------------------------------------------------- /minutes/2022-03-08.md: -------------------------------------------------------------------------------- 1 | # **2022-03-08 Meeting** 2 | 3 | ## Attendance (please add yourself): 4 | 5 | * Bob Callaway (Google, **TAC**, Chair) 6 | * Josh Bressers (Anchore, **TAC**) 7 | * VM (Vicky) Brasseur (Wipro) 8 | * CRob (Intel, **TAC**) 9 | * Jenn Bonner (LF, OpenSSF) 10 | * Brian Behlendorf (LF, OpenSSF) 11 | * Phil Estes (AWS) 12 | * Sudhindra Rao (JFrog) 13 | * Dan Lorenc (Chainguard, **TAC**) 14 | * Aeva Black (Microsoft, **TAC** Vice Chair, OSI Board) 15 | * Justin Hutchings (GitHub) 16 | * Chris Lamb (Reproducible Builds) 17 | * Kai Chen（HUAWEI，GB member） 18 | * Abhishek Arya (Google, **TAC**) 19 | * Jacques Chester (Shopify) 20 | * Jamie Magee (Microsoft) 21 | * Eric Tice (Wipro) 22 | * Luke Hinds (Red Hat, **TAC**) 23 | * Michael Winser (Google, Alpha-Omega) 24 | * Arnaud J Le Hors (IBM) 25 | * Asaf Karas (JFrog) 26 | * Matt Rutkowski (IBM) 27 | * Jeff Borek (IBM) 28 | 29 | ## Agenda 30 | 31 | * [bcallaway] Confirm by vote: Aeva Black (Microsoft) to serve as vice-chair of TAC 32 | * Crob makes the motion. Dan seconds. All in favor. No objections. One abstention (Aeva) 33 | * [CRob] TAC [Issues ](https://github.com/ossf/tac/issues)grooming? Can we get everything dispositioned? 34 | * CRob - action to: triage anything >30d old, comment, close if no reply in 7d 35 | * Dan - update TAC github membership setting 36 | * [Aeva] - Brief update on Project donation / progression processes/documentation 37 | * [https://github.com/ossf/tac/issues/83](https://github.com/ossf/tac/issues/83) 38 | * Bob noted this is a top priority for the TAC to resolve 39 | * Deferred a detailed update to Pyrsia until we have a well-documented and agreed-to process 40 | * [Jory] Playbook / Support Resources for WG & SIFs 41 | * Discussion of common terminology, distinction between Project / WG / SIF 42 | * Aeva proposed fork-lifting def’n from CNCF, then editing as needed. Consensus approval. 43 | * Jory to create a new ‘community’ repo for Aeva to seed with the above. 44 | * [All] - Other WG updates to share with TAC 45 | * Jacques - “securing software repos” proposed WG 46 | * Crob: Vulnerability WG (OSV donation; create CVD guide for helping sec researchers engage with OSS project maintainers (to be announced at Black Hat, tentative plan) 47 | * Aeva: note for future discussion: when an OSSF Tech Initiative wishes to host a service (OSV SaaS), where does that fit in the community processes in #83 ? 48 | * Jacques (securing critical projects); ranking method and outreach to experts to help with ranking 49 | * [Stephen] If time, brief update on Pyrsia 50 | * [Jory] GB general membership election FYI 51 | * Now >30 general members => +2 new board seats -------------------------------------------------------------------------------- /minutes/2022-04-05.md: -------------------------------------------------------------------------------- 1 | # **2022-04-05 Meeting** 2 | 3 | 4 | ## Attendance (please add yourself): 5 | 6 | 7 | 8 | * Bob Callaway (Google, **TAC**) 9 | * Eric Tice (Wipro) 10 | * Jeffrey Borek (IBM) 11 | * CRob (Intel, **TAC**) 12 | * Matt Rutkowski (IBM) 13 | * Stephen Chin (JFrog) 14 | * Dan Lorenc (Chainguard) 15 | * Aeva Black (Microsoft, **TAC**) 16 | * Brian Fox (Sonatype) 17 | * Josh Bressers (Anchore, **TAC**) 18 | * Arnaud J Le Hors (IBM) 19 | * Abhishek Arya (Google, **TAC**) 20 | * Jory Burson (Linux Foundation) 21 | * David A. Wheeler (Linux Foundation) 22 | * Jenn Bonner (Linux Foundation) 23 | * Sarah Novotny (Microsoft) 24 | * Jay White (Microsoft) 25 | * Luke Hinds (Red Hat, **TAC**) 26 | * Steve Chin (JFrog) 27 | * Dustin Ingram (Google) 28 | * Sudhindra Rao (JFrog) 29 | * Melba Lopez (IBM) 30 | * Justin Hutchings (GitHub) 31 | * Jamie Magee (Microsoft) 32 | * Georg Kunz (Ericsson) 33 | 34 | ## Agenda 35 | 36 | 37 | 38 | * [bcallaway] Heads-up: Motion to accept new WG “Securing Software Repositories” will be made at the April 19th TAC meeting 39 | * [jory] Update on housekeeping table 40 | * We’ll convert WG meeting notes in Google docs into GitHub (so they can be kept long-term) 41 | * [Sudhindra Rao] Review and approve [PR 91](https://github.com/ossf/tac/pull/91) - which copies over project approval process from cncf 42 | * [Aeva] looking forward to the discussion 43 | * TAC discussion - there’s a lot of good stuff, but there’s a lot of stuff 44 | * David W: If it’s accepted, and that’s thet TAC’s decision, mark it as DRAFT - the website should clearly show what’s active & what’s not 45 | * David W: I suggest breaking this into smaller chunks so it’s easier to review, then accept little pieces.. This is large & challenging to review all at once 46 | * Recommend NOT using Google docs/Google forms for the process, they can’t be accessed from many places 47 | * Counter-recommendation: GH notification spam can be too noisy. CNCF’s choices to use forms have contextual reason that may or may not apply today. 48 | * Bob: what’s the minimum viable set of policies that we need to reach to merge? 49 | * [Aeva] requesting review on small community-overview doc 50 | * [[DRAFT] initial pass at defining terminology in the readme by AevaOnline · Pull Request #4 · ossf/community (github.com)](https://github.com/ossf/community/pull/4) 51 | * [Jory] OpenSSF Day FYI 52 | * Register: [https://events.linuxfoundation.org/open-source-summit-north-america/features/openssf-day/](https://events.linuxfoundation.org/open-source-summit-north-america/features/openssf-day/) - June 20 53 | 54 | Let Jory/Ops know if you will be there! (or at OSSNA) 55 | -------------------------------------------------------------------------------- /minutes/2022-12-13.md: -------------------------------------------------------------------------------- 1 | # **2022-12-13 Meeting** 2 | **Attendance (please add yourself):** 3 | 4 | 5 | 6 | * Bob Callaway (Google, **TAC Chair**) 7 | * CRob (Intel, **TAC**) 8 | * Josh Bressers (Anchore, **TAC**) 9 | * Arnaud Le Hors (IBM) 10 | * Jacques Chester (Shopify) 11 | * Phil Estes (AWS) 12 | * Jay White (Microsoft) 13 | * Nell Shamrell-Harrington (Microsoft) 14 | * Dustin Ingram (Google) 15 | * Justin Hutchings (GitHub) 16 | * Zach Steindler (GitHub) 17 | * Aeva Black (Microsoft, **TAC**) (they/them) 18 | * Abhishek Arya (Google, **TAC**) 19 | * Dan Lorenc (Chainguard, **TAC**) 20 | * Jennifer Bly (OpenSSF) 21 | * David A. Wheeler (Linux Foundation) 22 | * Daniel Appelquist (Snyk) 23 | * David Edelsohn (IBM, GTI) 24 | * Carlos O’Donell (Red Hat, GTI) 25 | 26 | l 27 | 28 | Regrets: 29 | 30 | 31 | 32 | * Luke Hinds (Red Hat, TAC) 33 | 34 | Agenda: 35 | 36 | 37 | 38 | * _Reminder - No Meeting on December 27, 2022_ 39 | * (_10 min max_): Update from **Securing Software Repos WG** 40 | * Discussions/guidance/policies on malicious projects 41 | * Discussions/guidance/policies on surfacing CVE notifications 42 | * [Proposal for Shared Repository Helpdesk](https://docs.google.com/document/d/1Od9kqd4JIAW1h0vvvkD8NFclxsR8yudOdsZEMT7lBUc/edit#heading=h.mztvqya5xxdj) 43 | * [Principles for Safer Developer Ecosystems](https://docs.google.com/document/d/1OVeSX4OJcuj87AjONNSBY8ECg5bP1q9-Wedb1u23pso/edit#heading=h.n51muv4e1xdc) 44 | * (_10 min max_): Update from **Core Toolchain Infrastructure **- presentation by Carlos O’Donell & David Edelsohn. 45 | * Slide deck: [GTI presentation to the OpenSSF TAC (2022-12-12).pdf](https://drive.google.com/file/d/1Dtyw-dLKtq7w-3TZlP4aa_gXetqWiK6W/view?usp=sharing) 46 | * Established services working group to really understand services needed for components. Working to enumerate the services. 47 | * Have created Big Blue Button service 48 | * Mentioned a talk about securing gcc & glib available here: [https://www.youtube.com/watch?v=b1fO-RLtDME](https://www.youtube.com/watch?v=b1fO-RLtDME) 49 | * [CRob] Funding request proposal for security vuln disclosure coordination lists - Issue [132](https://github.com/ossf/tac/issues/132) 50 | * [CRob] OSS-SIRT [SIG ](https://github.com/ossf/SIRT)Plan for TAC consideration/comments prior to sending to GB. Issue [131](https://github.com/ossf/tac/issues/131) 51 | * [Bob C] 2023 TAC Focus [[slides](https://docs.google.com/presentation/d/1MlEPaoebiHV6G_X2G87cN6a11vv9OC7_zZAOlC0ul48/edit#slide=id.g1809680081f_0_38)] 52 | * Support from CRob, and chat +1’s from Dan, Josh and Abhishek 53 | * If time: Year end update: curl, etc. [Amir, Open Source Technology Improvement Fund, Inc] 54 | 55 | 56 | -------------------------------------------------------------------------------- /process/Technical_Initiative_Lifecycle.md: -------------------------------------------------------------------------------- 1 | 2 | # I. Overview 3 | 4 | This document describes the Open Source Security Foundation (OpenSSF) lifecycle process for Technical Initiatives (TI) which include Working Groups (WG) (non-software and non-specification focused), Projects (developing code or specifications), and Special Interest Groups (SIG). 5 | 6 | The authority that governs this process is as follows: 7 | 8 | The parent organizational structure grants governance to the downward entity in the organizational structure. In turn the receiving Working Group, Project, or SIG reports health, participation, outcomes, statuses, etc up the chain. 9 | 10 | ```mermaid 11 | flowchart TD 12 | A[Governing Board] <--> B[TAC] 13 | B <--> C[Working Group] 14 | B <--> E[Working Group] 15 | C <--> D[Project] 16 | B <--> F[Project] 17 | B <--> G[Project] 18 | E <--> H[Project] 19 | E <--> I[SIG] 20 | ``` 21 | 22 | The process is designed to be flexible to enable a Project to move in and out of a Working Group as deemed appropriate by the TAC. 23 | 24 | A SIG can be developed within a WG or Project to address a specific need. Note that a SIG's primary purpose is not to produce code or specifications (it can produce them as secondary goals, or as experimental POCs). 25 | 26 | # II. Lifecycle 27 | 28 | All Technical Initiatives follow a common lifecycle, with 4 stages: 29 | 30 | - Sandbox - for new efforts within the Foundation seeking to get started out within a community of like-minded contributors 31 | - Incubating - for more mature and organized groups that have participated in the community for some period of time 32 | - Graduated - for mature efforts that have a proven track-record of deliverables and adding value to the community 33 | - Archived - for groups that either are feature-complete and retired, or that no longer has active contributions occurring 34 | 35 | ```mermaid 36 | flowchart LR 37 | A[Sandbox] --> B[Incubating] 38 | B --> C[Graduated] 39 | C --> D[Archived] 40 | ``` 41 | 42 | Each type of TI has equivalent, but slightly different requirements and benefits, depending on their stage in the lifecycle as defined below: 43 | 44 | * [Working Group Life Cycle](working-group-lifecycle.md) 45 | * [Project Life Cycle](project-lifecycle.md) 46 | * [Special Interest Group Life Cycle](sig-lifecycle.md) 47 | 48 | To see what the expected requirements ("Gives") and benefits ("Gets") for a TI to achieve at a given lifecycle stage, refer to the [TI Gives and Gets](https://github.com/ossf/tac/blob/main/process/TI-Gives%2BGets.md) page for more information. Each lifecycle stage has listed what they must do or produce and a list of benefits for each level of maturity in our proceeses. 49 | -------------------------------------------------------------------------------- /process/wg-lifecycle-documents/ai_ml_incubating_stage.md: -------------------------------------------------------------------------------- 1 | ## AI/ML Working Group incubation application 2 | 3 | ### List WG Chairs 4 | 5 | The WG must have a minimum of 1 Chair 6 | 7 | * Mihai Maruseac, Google, mihaimaruseac 8 | * Jautau "Jay" White, Microsoft, camaleon2016 9 | 10 | ### Working Group (WG) has met all Sandbox requirement 11 | 12 | * Applying directly to Incubating, but we have met Sandbox requirements, as 13 | listed below 14 | * Proposal of scope has been reviewed by TAC: [#175](https://github.com/ossf/tac/issues/175) (and [#188](https://github.com/ossf/tac/issues/188) to ensure limited overlap) 15 | * At least 3 interested individuals, from 2 different organizations supporting the proposal. See list of regular contributors in the next section 16 | * 1 TAC sponsor. Originally Dan Appelquist, now Jay White 17 | 18 | ### List of regular contributors 19 | 20 | The WG must have a minimum of 5 contributors from at least 3 different 21 | organizations attending regularly. 22 | 23 | * David A. Wheeler, LF 24 | * David Edelsohn, IBM / AI Alliance 25 | * Emily Fox, Red Hat 26 | * Jautau "Jay" White, Microsoft 27 | * Karen Bennet, ISO 28 | * Marcela Melara, Intel 29 | * Mihai Maruseac, Google 30 | * Newt Tan, University of Glasgow 31 | * Sarah Evans, Dell Technologies 32 | * Yotam Perkal, Rezilion 33 | 34 | and many others 35 | 36 | ### Mission of the Working Group 37 | 38 | The WG must have a charter or mission statement for review by TAC 39 | 40 | * https://github.com/ossf/ai-ml-security/blob/main/CHARTER.md 41 | * https://github.com/ossf/ai-ml-security/blob/main/mvsr.md 42 | 43 | ### Governance 44 | 45 | WG must have documented, initial group governance. 46 | 47 | * https://github.com/ossf/ai-ml-security/blob/main/README.md#wg-leadership 48 | 49 | WG must have met publicly at least 5 times in the last quarter since becoming 50 | Sandbox 51 | 52 | * 2024: https://docs.google.com/document/d/1YNP-XJ9jpTjM6ekKOBgHH8-avAws2DVKeCpn858siiQ/edit 53 | * 2023: https://docs.google.com/document/d/1hEJdr7yXv5tfYpUfn_e7DAUTyvoU6mY0b9eH6EXAHaI/edit 54 | 55 | WG must have defined Contributor Guide 56 | 57 | * https://github.com/ossf/ai-ml-security/blob/main/README.md#how-to-participate 58 | 59 | Reference | URL | 60 | |-----------------------|-----| 61 | | Repo | https://github.com/ossf/ai-ml-security | 62 | | Meeting Agenda | https://docs.google.com/document/d/1YNP-XJ9jpTjM6ekKOBgHH8-avAws2DVKeCpn858siiQ/edit | 63 | | Contributing guide | https://github.com/ossf/ai-ml-security/blob/main/README.md#how-to-participate | 64 | | Security.md | https://github.com/ossf/ai-ml-security/blob/main/SECURITY.md | 65 | | code-of-conduct.md | https://github.com/ossf/ai-ml-security/blob/main/code-of-conduct.md | 66 | -------------------------------------------------------------------------------- /process/wg-lifecycle-documents/securing_critical_projects_incubating_stage.md: -------------------------------------------------------------------------------- 1 | ## Securing Critical Projects Working Group incubation application 2 | 3 | ### List WG Chair(s) and or Vice Chair 4 | 5 | The WG must have a minimum of 1 Chair 6 | 7 | * "Amir Montazery, Open Source Technology Improvement Fund, Inc, Amir-Montazery" 8 | * "Jeff Mendoza, Kusari, Inc, jeffmendoza" 9 | 10 | ### Working Group (WG) has met all Sandbox requirement 11 | 12 | * Applying directly to Incubating 13 | 14 | ### List of regular contributors 15 | 16 | The WG must have a minimum of 5 contributors from at least 3 different 17 | organizations attending regularly. 18 | 19 | * Jeff Mendoza, Kusari 20 | * Amir Montazery, Open Source Technology Improvement Fund, Inc 21 | * Caleb Brown, Google 22 | * David Edelsohn, IBM 23 | * David C Stewart, Intel 24 | * David A. Wheeler, LF 25 | * Randall T. Vásquez, Gentoo/Homebrew/SKF 26 | * Yotam Perkal, Rezilion 27 | 28 | ### Mission of the Working Group 29 | 30 | The WG must have a charter or mission statement for review by TAC 31 | 32 | * https://github.com/ossf/wg-securing-critical-projects/blob/main/MVSR.md 33 | 34 | ### Governance 35 | 36 | WG must have documented, initial group governance. 37 | 38 | * https://github.com/ossf/wg-securing-critical-projects/blob/main/CHARTER.md 39 | 40 | WG must have met publicly at least 5 times in the last quarter since becoming 41 | Sandbox 42 | 43 | * 2024: https://docs.google.com/document/d/1j_efLVDXGoKgfHHZbJtpBxd_Gso1ghHBdK3NfEVc15o/edit?usp=sharing 44 | * 2020-2023: https://docs.google.com/document/d/1GFslP6elYCx27TUitdigDr1gsOItYkL0Vq7hTB9y4Lo/edit#heading=h.n1an2kl9m54e 45 | * https://www.youtube.com/playlist?list=PLVl2hFL_zAh-cAfx6y4k-fODfbHeQzb_O 46 | 47 | WG must have defined Contributor Guide 48 | 49 | * https://github.com/ossf/wg-securing-critical-projects?tab=readme-ov-file#operations 50 | 51 | Reference | URL | 52 | |-----------------------|-----| 53 | | Repo | https://github.com/ossf/wg-securing-critical-projects | 54 | | Meeting Agenda | https://docs.google.com/document/d/1j_efLVDXGoKgfHHZbJtpBxd_Gso1ghHBdK3NfEVc15o/edit?usp=sharing | 55 | | OSSF Calendar Entry | https://www.google.com/calendar/event?eid=MmpuZGJiZjBvaGpqMXVuOGNpYW1jMjgyOGZfMjAyNDA1MjNUMTYwMDAwWiBzNjN2b2VmaHA1aTlwZmx0YjVxNjduZ3Blc0Bn&ctz=America/New_York | 56 | | Website | | 57 | | Contributing guide | https://github.com/ossf/wg-securing-critical-projects?tab=readme-ov-file#operations | 58 | | Security.md | https://github.com/ossf/wg-securing-critical-projects/blob/main/SECURITY.md | 59 | | code-of-conduct.md | https://github.com/ossf/wg-securing-critical-projects/blob/main/code-of-conduct.md | 60 | | Other | | 61 | -------------------------------------------------------------------------------- /minutes/2021-04-20.md: -------------------------------------------------------------------------------- 1 | # **2021-04-20 Meeting** 2 | 3 | ## Attendance (please add yourself): 4 | 5 | * Carly Driggers (Linux Foundation) 6 | * Phil Estes (AWS) 7 | * Xavier Rene-Corail (GitHub) 8 | * Ryan Haning (Microsoft) 9 | * Dan Middleton (intel) 10 | * Dan Lorenc (Google) 11 | * David A. Wheeler (Linux Foundation) 12 | * Rao Lakkakula (JPMChase) 13 | * Jennifer Fernick (NCC Group) 14 | * Kay Williams (Microsoft) 15 | * Matt Rutkowski (IBM) 16 | * Vinod Anandan (Citi) 17 | 18 | ## Agenda: 19 | 20 | * Review Newsletter / Town Hall Content - Ryan/Kay 21 | * Budget Planning Update - Kay Williams 22 | * WG funding 23 | * External proposals 24 | * GB Offsite - OpenSSF decision-making - Jennifer Fernick 25 | * More details once this is formalized - future TAC meeting sometime in May 26 | * Outreach/Conferences - Jennifer Fernick 27 | * If interested in this, please email Jennifer Fernick 28 | * All are welcome 29 | * Scope can include: 30 | * Outreach to security researchers 31 | * Outreach within OSS community 32 | * Outreach to students, junior folks interested in OSS, other geographies/ languages, etc all extremely welcome 33 | * TAC’s view on participants change in employment and continued participation 34 | * OpenSSF Charter says max 2 people per “related company” on TAC 35 | * Roles don’t go with the company, they go with the individual 36 | * Roadmap and Wishlist 37 | * [TAC: OpenSSF Technical Roadmap · Issue #37 · ossf/tac (github.com)](https://github.com/ossf/tac/issues/37) 38 | * Next steps? 39 | * TODO: All TAC members to preread Wishlist below for next meeting \ 40 | [https://docs.google.com/document/d/1yLo713am8_hvU90Lw0YdYBvXhfTjh7Shn4ATXPNX9ic/edit#](https://docs.google.com/document/d/1yLo713am8_hvU90Lw0YdYBvXhfTjh7Shn4ATXPNX9ic/edit#) 41 | * Discussion on this: 42 | * DW presented this technical roadmap listing of ideas 43 | * JF proposed blogging about these topics to inspire people/create a wishlist as an onboarding mechanism for folks interested in getting involved 44 | * DW proposed cutting down the wishlist to a prioritized list of ideas to narrow the scope to top ideas, JF agreed 45 | * We discussed where this could land - possibly planning committee but likely is the scope of the TAC itself so could be done by a subset of the TAC (where it might actually be the set that is the TAC) 46 | * Ways of prioritize items - small group? voting/markup to doc? Future discussion? 47 | * DM also highlighted issue of sustained contributions - having the prioritized projects can help us get headcount from our companies as well to get projects actually completed 48 | * We decided to discuss this next TAC meeting - please preread above to prepare -------------------------------------------------------------------------------- /TI-reports/2025/2025-Q1-Vulnerability-Disclosure-WG.md: -------------------------------------------------------------------------------- 1 | # 2025 Q1 Vulnerability Disclosure WG - Madison Oliver 2 | 3 | ## Overview 4 | TI is progressing as expected. Engagement has remained relatively stable with slight decreases over the last 6 months. We've had external presentations and discussions with the [package url](https://github.com/package-url/purl-spec) community and passed a vote to adopt Advise as a new project. 5 | 6 | ## Vulnerability Dislosures Working Group 7 | 8 | ### Purpose 9 | The OpenSSF Vulnerability Disclosures Working Group seeks to help improve the overall security of the open source software ecosystem by helping mature and advocate well-managed vulnerability reporting and communication. 10 | 11 | ### Current Status 12 | - Typically have 5-6 regular attendees for biweekly full WG meeting, limited additional engagement in the monthly APAC meeting 13 | - [Graduated](https://github.com/ossf/tac/blob/main/process/working-group-lifecycle.md#to-become-graduated). 14 | - [To remain Graduated](https://github.com/ossf/tac/blob/main/process/working-group-lifecycle.md#to-remain-graduated): 15 | - [x] Have received TAC approval of the README.md per Incubating requirements above 16 | - [x] Have met at least 4 times over a period of at least 2 months since becoming Incubating 17 | - [x] Have at least 5 contributors from at least 3 different organizations attending regularly as recorded in meeting minutes. 18 | - [x] Request TAC approval. TAC will vote to approve or provide constructive guidance. 19 | - [x] TAC sponsor monitoring and consultation become optional. 20 | 21 | ### Up Next 22 | - WG Project Board: https://github.com/orgs/ossf/projects/29 23 | - [Project Idea - CVD Guide for OSS Consumers](https://github.com/ossf/wg-vulnerability-disclosures/issues/115) > effort is stagnating and needs to be revived 24 | - [VOTE - Adopt Advise as a Sandbox project for the OpenSSF](https://github.com/ossf/wg-vulnerability-disclosures/issues/152) > vote has passed, Madison needs to create a request for the TAC next 25 | - [Discussions regarding purl implementation in the CVE Program](https://github.com/ossf/wg-vulnerability-disclosures/issues/158) > discussed in the last four meetings with additional activity over the mailing list 26 | - [LF Member Summit](https://events.linuxfoundation.org/lf-member-summit/program/schedule/), March 18-20 > panel of OpenSSF members discussing open source vulnerabilities and how to bridge the gap between discovery and remediation 27 | - [VulnCon 2025](https://www.first.org/conference/vulncon2025/), April 7-10 > many WG members planning to attend with some likely speaking 28 | 29 | ### Questions/Issues for the TAC 30 | - What other areas in the OpenSSF 2025 Roadmap does the TAC see opportunity for the Vulnerability Disclosures working group? Can we support more with CRA guidance? 👀 31 | -------------------------------------------------------------------------------- /process/wg-lifecycle-documents/BEST_practices_wg_graduation_stage.md: -------------------------------------------------------------------------------- 1 | ## Working Group graduation application 2 | BEST Practices Working Group 3 | 4 | ### WG has met all Incubating requirements 5 | * n/a 6 | 7 | ### List of regular contributors 8 | The WG must have at least 5 contributors from at least 3 different organizations attending regularly as recorded in meeting minutes. 9 | - [Christopher "CRob" Robinson*, Intel](https://github.com/SecurityCRob) 10 | - [David A Wheeler, LF/OSSF](https://github.com/david-a-wheeler) 11 | - [Dave Russo*, Red Hat](https://github.com/drusso-rh) 12 | - [Randall T. Vasquez*, The Linux Foundation](https://github.com/ran-dall) 13 | - [Arnaud J Le Hors, IBM](https://github.com/lehors) 14 | - [Christine Abernathy*, F5](https://github.com/caabernathy) 15 | - [Daniel Applequist*, Snyk](https://github.com/Torgo) 16 | - [Georg Kunz, Ericsson](https://github.com/gkunz) 17 | - [Sarah Evans, Dell](https://github.com/sevansdell) - Security Toolbelt SIG Co-Lead 18 | - [John Kjell, TestifySec](https://github.com/jkjell) - Security toolbelt SIG Co-lead 19 | - [Thomas Nyman, Ericsson](https://github.com/thomasnyman) - C/C++ Compiler Guide SIG Lead 20 | - [Nell Shamrell-Harrington](https://github.com/nellshamrell) - Memory Safety SIG Lead 21 | - [Avishay Balter, Microsoft](https://github.com/balteravishay) - Memory Safety SIG Co-Lead 22 | 23 | 24 | ### Governance 25 | Projects have met at least 4 times over a period of at least 2 months since becoming incubating 26 | * [BEST WG Charter](https://github.com/ossf/wg-best-practices-os-developers/blob/main/CHARTER.md) 27 | * [2024 Meeting Notes](https://docs.google.com/document/d/1JY8FREBPCUUFpuv7-4B9EjeS2MLDpel0dbG5DFWrTns/edit) 28 | * [Historic Meeting Notes](https://github.com/ossf/wg-best-practices-os-developers/tree/main/minutes) 29 | 30 | 31 | ### TI References 32 | The TI must provide a list of existing resources with links to the repository, website, a roadmap, contributing guide, demos and walkthroughs, and any other material to showcase the existing breadth, maturity, and direction of the project. 33 | Reference | URL | 34 | |-----------------------|-----| 35 | | Repo | https://github.com/ossf/wg-best-practices-os-developers | 36 | | Meeting Agenda | https://docs.google.com/document/d/1JY8FREBPCUUFpuv7-4B9EjeS2MLDpel0dbG5DFWrTns/edit | 37 | | OSSF Calendar Entry | https://github.com/ossf/wg-best-practices-os-developers#meeting-times | 38 | | Website | https://best.openssf.org/developers | 39 | | Contributing guide | https://github.com/ossf/wg-best-practices-os-developers?tab=readme-ov-file#quick-start | 40 | | Security.md | https://github.com/ossf/wg-best-practices-os-developers/blob/main/SECURITY.md | 41 | | Roadmap | https://github.com/ossf/wg-best-practices-os-developers?tab=readme-ov-file#roadmap | 42 | | Other | | 43 | -------------------------------------------------------------------------------- /TI-reports/2024/2024-Q3-SCP-WG.md: -------------------------------------------------------------------------------- 1 | # 2024 Q3 Securing Critical Projects WG 2 | 3 | ## Overview 4 | 5 | Sub projects continue to run and make progress. Little to no progress on main 6 | initiative of enhancing Critical Project Set with more information. Attendance 7 | is low. 8 | 9 | ## Identifying Critical Projects 10 | 11 | Addition of Metadata to Set: 12 | - Metadata fields roughly scoped and defined. 13 | - Consensus is still hesitant 14 | - Work to enhance set is stalled 15 | 16 | ## Criticality Score 17 | 18 | - Continues to run and recalculate scores 19 | - Updates 1 to 2 times a month 20 | - Tracking 500,000 projects 21 | - Small calculation fixes 22 | 23 | ## Package Analysis / Malicious Packages 24 | 25 | - Ingesting data from Reversing Labs 26 | - Worked through issues with NPM namespacing 27 | - Worked through broken RSS feed from NPM 28 | - Working to OSV team about PURL casing issues 29 | - Working on formal definition of "Malicious Package" 30 | - Example: Is a reputation farming package malicious? 31 | - PR: https://github.com/ossf/malicious-packages/pull/381 32 | - TAC Feedback appreciated, interested in doing a blog post 33 | - Malicious Package counts ~25,000 packages 34 | - 2 crates-io 35 | - 15543 npm 36 |   - 731 nuget 37 | - 8081 pypi 38 |   - 802 rubygems 39 | 40 | ## Purpose 41 | 42 | Open Source Software has long suffered from a "tragedy of the commons" 43 | problem. Organizations large and small make use of OSS every day, but many 44 | projects are struggling for the time, resources and attention they need. 45 | 46 | This is a resource allocation problem - and we can help solve it together. We 47 | need ways to connect critical projects we all rely on with organizations that 48 | can provide them with support. 49 | 50 | [MVSR Link](https://github.com/ossf/wg-securing-critical-projects/blob/main/MVSR.md) 51 | 52 | ## Current Status 53 | 54 | See overview. 55 | 56 | ## Up Next 57 | 58 | Continue to support sub projects. 59 | 60 | ### RE: [Proposal: Funding Critical Projects POC with commercial vendors](https://github.com/ossf/tac/issues/360) 61 | 62 | > Once the TI has agreed to sponsor the effort 63 | 64 | > There also appears to be little community/TI engagement on this. If this effort were ever to move forward, we would want to see broad discussion and collaboration from one of our Technical Initiatives. We suggest taking the idea to the Securing Critical Projects working group or perhaps Alpha-Omega 65 | 66 | SCP WG is happy to serve as a forum for this initiative. We see a roadblock in being able to execute this due to not having a way to request staffing (in addition to funding). Essentially, we wish to be able to propose funding to staff the management to provide: "We are requesting X amount of funding to achieve Y result in Z timeline." 67 | 68 | ## Questions/Issues for the TAC 69 | 70 | Please provide feedback on Malicious Package definition. 71 | See staffing ability request above. 72 | -------------------------------------------------------------------------------- /policies/access.md: -------------------------------------------------------------------------------- 1 | # GitHub Access Management Policy 2 | 3 | ## Teams, not Individuals 4 | 5 | Access to repositories will be granted only to [GitHub teams](https://docs.github.com/en/organizations/organizing-members-into-teams/about-teams#team-visibility), not to individuals. A repo may have any number of teams added to it, with the appropriate access levels. 6 | 7 | ## Team Structure 8 | 9 | Teams will be nested, using parent/child relationships, as needed. A child team will implicitly have any privileges its parent team does, so the most deeply nested team should be the one with the most privileges. 10 | 11 | ### Top-level teams 12 | 13 | Note: this list is intentionally not exhaustive. 14 | 15 | - [TAC](https://github.com/orgs/ossf/teams/tac) 16 | This team is for current TAC members. Individuals should be added or removed from this team to reflect current membership. 17 | - [Staff](https://github.com/orgs/ossf/teams/staff) 18 | This team is for OpenSSF staff members. Individuals on the top-level team are there as a catch-all, but may be moved to subteams as the need arises. 19 | - [PMs](https://github.com/orgs/ossf/teams/pms) 20 | This teams is for PMs, who often need Maintain or Admin access on repos. 21 | - [Marketing](https://github.com/orgs/ossf/teams/marketing) 22 | - [Working Groups](https://github.com/orgs/ossf/teams/working-groups) 23 | This is the parent team for Working Groups. Every WG should have a subteam contained within this one. All WG subteams must start with `wg-` for consistency. 24 | - [SIGs](https://github.com/orgs/ossf/teams/sigs) 25 | This is the parent team for SIGs. Every SIG should have a subteam contained within this one. All SIG subteams must start with `sig-` for consistency. 26 | - [Projects](https://github.com/orgs/ossf/teams/projects) 27 | This is the parent team for projects. Every project (e.g. scorecard, AO) should have a subteam contained within this one. 28 | Teams for individual repositories go under here, which start with `repo-`, but team names may otherwise be unconstrained. 29 | 30 | ## GitHub Org Membership 31 | 32 | Membership in the GitHub org should be freely given - it inherently confers no permissions or privileges, only a badge on the user's profile if they enable it - and it _does_ allow for easier team management. Someone should only be removed from the org in extreme circumstances where their association with OpenSSF would be problematic, and people should be encouraged to remain in the org in perpetuity. 33 | 34 | Individuals are free to choose to be a member of the org or not, but membership is required to be on GitHub teams, which grants privileged access to repositories. 35 | 36 | ## Principle of Least Privilege 37 | 38 | Permission levels should be as high as they need to be, and no higher. 39 | 40 | - There are few settings that justify Admin access over Maintain, so prefer Maintain. 41 | - Explicit Read access has an advantage: users with Read can be assigned to issues and requested as PR reviewers even if they're not the author. 42 | -------------------------------------------------------------------------------- /process/project-lifecycle-documents/gemara_sandbox_stage.md: -------------------------------------------------------------------------------- 1 | ## Application for creating a new project at Sandbox stage 2 | 3 | ### List of project maintainers 4 | 5 | The project has [4 maintainers](https://github.com/revanite-io/sci/graphs/contributors) from 4 different organizations: 6 | 7 | * Eddie Knight, Sonatype, @eddie-knight 8 | * Travis Truman, Independent, @trumant 9 | * Jason Meridth, GitHub, @jmeridth 10 | * Alex Speasmaker, USAA, @speas038 11 | 12 | And one contributor, from a fifth organization: 13 | 14 | * Jennifer Power, RedHat, @jpower432 15 | 16 | ### Sponsor 17 | 18 | Most projects will report to an existing OpenSSF Working Group, although in some cases a project may report directly to the TAC. The project commits to providing quarterly updates on progress to the group they report to. 19 | 20 | * [ORBIT WG](https://github.com/ossf/wg-orbit) 21 | 22 | ### Mission of the project 23 | 24 | The project must be aligned with the OpenSSF mission and either be a novel approach for existing areas, address an unfulfilled need, or be initial code needed for OpenSSF WG work. It is preferred that extensions of existing OpenSSF projects collaborate with the existing project rather than seek a new project. 25 | 26 | * Gemara, currently named "Simplified Compliance Infrastructure (SCI)", is a collection of schema describing data interchange formats for security and compliance activities and a Golang module for producing and consuming data conforming to these formats. The project's mission is to serve as a unifying, integration format between tools and applications that operate in the security and compliance space. SCI is currently used to model the catalog of compliance controls in the OSPS Baseline and in the FINOS Common Cloud Controls and is expected to be adopted by additional tools like darn/darnit, oscal-tempest, etc. 27 | 28 | **_NOTE: due to a naming collision with the existing OpenSSF Supply Chain Integrity WG, if this project is granted Sandbox phase status, it will be renamed Gemara._** 29 | 30 | ### IP policy and licensing due diligence 31 | 32 | When contributing an existing Project to the OpenSSF, the contribution must undergo license and IP due diligence by the Linux Foundation (LF). 33 | 34 | * Gemara is currently licensed under the Apache 2.0 License and requires DCO signoff from all contributors 35 | * We will initiate this process shortly. 36 | 37 | ### Project References 38 | 39 | The project should provide a list of existing resources with links to the repository, and if available, website, a roadmap, contributing guide, demos and walkthroughs, and any other material to showcase the existing breadth, maturity, and direction of the project. 40 | 41 | | Reference | URL | 42 | |---------------------|-----| 43 | | Repo | https://github.com/revanite-io/sci | 44 | | Website | https://www.revanite.io/sci | 45 | | Contributing guide | https://github.com/revanite-io/sci/blob/main/CONTRIBUTING.md | 46 | | Security.md | Once approved for Sandbox phase, we intend to adopt https://github.com/ossf/wg-orbit/blob/main/SECURITY.md | 47 | -------------------------------------------------------------------------------- /process/wg-lifecycle-documents/Vuln_Disc_wg_graduation_stage.md: -------------------------------------------------------------------------------- 1 | ## Working Group graduation application 2 | Vulnerability Disclosures WG 3 | 4 | ### WG has met all Incubating requirements 5 | * n/a 6 | 7 | ### List of regular contributors 8 | The WG must have at least 5 contributors from at least 3 different organizations attending regularly as recorded in meeting minutes. 9 | - [Christopher "CRob" Robinson, Intel](https://github.com/SecurityCRob) 10 | - [Jonathan Leitschuh, Dan Kaminsky Fellowship - HUMAN](https://github.com/JLLeitschuh) 11 | - [Madison Oliver, GitHub Security Lab](https://github.com/taladrane) 12 | - [David A Wheeler, LF/OSSF](https://github.com/david-a-wheeler) 13 | - [Randall T. Vasquez (SKF/Gentoo/Homebrew)](https://github.com/ran-dall) 14 | - [Adolfo García Veytia, Chainguard & OpenVEX](https://github.com/puerco) 15 | - [Andrew Pollock, Google & OSV](https://github.com/andrewpollock) 16 | - [Arnaud Le Hors, IBM](https://github.com/lehors) 17 | - [Art Manion, ANALYGENCE](https://github.com/zmanion) 18 | - [Avishay Balter, Microsoft](https://github.com/balteravishay) 19 | - [Jay White, Microsoft](https://github.com/camaleon2016) 20 | - Jennifer Mitchell, Tidelift 21 | - [Ixchel Ruiz, JFrog](https://github.com/ixchelruiz) 22 | - [Marcus Meissner (SUSE)](https://github.com/msmeissn) 23 | - [Nathan Menhorn, AMD](https://github.com/nathan-menhorn) 24 | - [Nicole Schwartz, ActiveState](https://github.com/NicoleSchwartz/CircuitSwan) 25 | - Oliver Chang, Google & OSV 26 | - [Paulo Flabiano Smorigo (Ubuntu/Canonical)](https://github.com/pfsmorigo) 27 | - Yotam Perkal, Rezilion 28 | 29 | 30 | ### Governance 31 | Projects have met at least 4 times over a period of at least 2 months since becoming incubating 32 | - [Vuln Disc WG Charter](https://github.com/ossf/wg-vulnerability-disclosures/blob/main/CHARTER.md) 33 | - [2024 Meeting Notes](https://docs.google.com/document/d/1AXkapzjZ-SxwcBN7rZeSstkzdapd3sbzfHDxz6A59Ic/edit) 34 | - [Historic Meeting Notes](https://github.com/ossf/wg-vulnerability-disclosures/tree/main#meeting-notes) 35 | 36 | ### TI References 37 | The TI must provide a list of existing resources with links to the repository, website, a roadmap, contributing guide, demos and walkthroughs, and any other material to showcase the existing breadth, maturity, and direction of the project. 38 | Reference | URL | 39 | |-----------------------|-----| 40 | | Repo | https://github.com/ossf/wg-vulnerability-disclosures | 41 | | Meeting Agenda | https://docs.google.com/document/d/1AXkapzjZ-SxwcBN7rZeSstkzdapd3sbzfHDxz6A59Ic/edit | 42 | | OSSF Calendar Entry | https://github.com/ossf/wg-vulnerability-disclosures/tree/main#meeting-times | 43 | | Website | n/a | 44 | | Contributing guide | https://github.com/ossf/wg-vulnerability-disclosures/tree/main#get-involved | 45 | | Security.md | https://github.com/ossf/wg-vulnerability-disclosures/blob/main/SECURITY.md | 46 | | Roadmap | https://github.com/ossf/wg-vulnerability-disclosures/blob/main/README.md#roadmap | 47 | | Other | n/a | 48 | -------------------------------------------------------------------------------- /TI-reports/2024/2024-Q4-Repos-WG.md: -------------------------------------------------------------------------------- 1 | # 2024 Q4 Securing Software Repositories (Repos) WG 2 | 3 | ## Overview 4 | 5 | **Mission**: Improve security of software repositories by providing a forum for discussion, a maturity model for security roadmaps, and guidance for individual security capabilities. 6 | 7 | **Links**: 8 | - [GitHub repository](https://github.com/ossf/wg-securing-software-repos) 9 | - [Slack channel](https://openssf.slack.com/archives/C034CBLMQ9G) 10 | - [WG meeting docs](https://docs.google.com/document/d/1HzA4M4toiExUYQAkuLqimy4EuuunHagUQ7rZKJDb1Os/edit?usp=sharing) 11 | 12 | **Latest News**: 13 | 14 | [Last update June 2024](https://docs.google.com/presentation/d/1PWxTw8yiSnLlClMK0K83hff5XHnkKDkw0OYM0ldWKsk/edit?usp=sharing) 15 | 16 | - Published [Trusted Publishing for All Package Repositories](https://repos.openssf.org/trusted-publishers-for-all-package-repositories) 17 | - Cited by [Rust Crates.io Trusted Publishing RFC](https://github.com/rust-lang/rfcs/pull/3691) 18 | - Also cited by [NuGet Trusted Publishing RFC](https://github.com/NuGet/Home/pull/13673) 19 | - Trusted publishing is a stepping stone for further attestations, see [PEP-0740](https://peps.python.org/pep-0740/) 20 | 21 | - Repository Service for TUF (RSTUF) proof of concept with RubyGems and PyPI 22 | - Working towards v1.0 release 23 | 24 | - Working on [Binary Transparency for Artifact Registries](https://github.com/ossf/wg-securing-software-repos/pull/48) 25 | 26 | ## Securing Software Repositories Working Group 27 | 28 | ### Purpose 29 | 30 | Improve security of software repositories by providing a forum for discussion, a maturity model for security roadmaps, and guidance for individual security capabilities. 31 | 32 | ### Current Status 33 | 34 | - Helping security capabilties move from ecosystem to ecosystem 35 | - Trusted publishing: PyPI -> RubyGems -> NuGet -> Rust Crates 36 | - Signing / provenance / attestations: npm -> Homebrew -> PyPI -> Maven Central 37 | 38 | - Support for [PEP-0740: Index support for digital attestations](https://peps.python.org/pep-0740/) 39 | - CPython + 10k+ Python packages with trusted publishing could be a critical mass for OS package repositories to implement support for in-toto attestations signed by public good Sigstore instance 40 | 41 | ### Up Next 42 | 43 | - Working on [Binary Transparency for Artifact Registries](https://github.com/ossf/wg-securing-software-repos/pull/48) 44 | 45 | ### Questions/Issues for the TAC 46 | 47 | - None at this time 48 | 49 | ## RSTUF Project 50 | 51 | ### Purpose 52 | 53 | Provide a service to protect repository index from tampering by distributing them with The Update Framework (TUF) 54 | 55 | ### Current Status 56 | 57 | - Proof of concept with RubyGems and PyPI 58 | 59 | ### Up Next 60 | 61 | - Working towards v1.0 release 62 | 63 | ### Questions/Issues for the TAC 64 | 65 | - None at this time 66 | 67 | ## Additional Information 68 | 69 | [Tracking ~30 security improvements over ~10 ecosystems over the past 2 years](https://docs.google.com/spreadsheets/d/1JydRQSJ2jTHREmWXXlzlFdhKJ_sY7cORKp_6AI6mRNw/edit?usp=sharing) 70 | 71 | -------------------------------------------------------------------------------- /minutes/2021-01-12.md: -------------------------------------------------------------------------------- 1 | # **2021-01-12 Meeting** 2 | 3 | ## Attendance (please add yourself): 4 | 5 | * Dan Middleton (intel) 6 | * Ryan Haning (Microsoft) 7 | * Phil Estes (Amazon) 8 | * David A. Wheeler (Linux Foundation) 9 | * Dan Lorenc (Google) 10 | * Rao Lakkakula (JPM Chase) 11 | * Maya Kaczorowski (GitHub) 12 | * Altaz Valani (Security Compass) 13 | * Chris Horn (Secure Decisions) 14 | * Jennifer Fernick (NCC Group) 15 | * Kay Williams (Microsoft) 16 | 17 | ## Agenda: 18 | 19 | * Ratify OpenSSF Technical Vision (Ryan/Kay) 20 | * [https://github.com/ossf/tac/pull/47](https://github.com/ossf/tac/pull/47) 21 | * Add clause ‘according to our values’ (Chris Horn) 22 | * Merge final (someone from TAC) 23 | * Draft content for blog, announce email, twitter feed (Kay) 24 | * Share with TAC for review 25 | * Coordinate with Lindsay to add to website (Kay) 26 | * Create a durable URL for values as well 27 | * TAC members to have a conversation in Working Groups 28 | * Integrate vision into readme page (Ryan) 29 | * Ratify Working Group Lifecycle (Ryan/Dan M.) 30 | * [https://github.com/ossf/tac/pull/41](https://github.com/ossf/tac/pull/41) 31 | * Ratified by those present (though approvals already noted in PR) 32 | * TAC Election Process Proposal Update (Lindsay) 33 | * Discuss next meeting when Lindsay is available 34 | * OpenSSF 2021 Roadmap (Kay) 35 | * Feed into 2021 budget process / priorities 36 | * We can build on “wishlist” but obviously cannot do all of them. Wishlist: [https://docs.google.com/document/d/1yLo713am8_hvU90Lw0YdYBvXhfTjh7Shn4ATXPNX9ic/edit](https://docs.google.com/document/d/1yLo713am8_hvU90Lw0YdYBvXhfTjh7Shn4ATXPNX9ic/edit) 37 | * We now need the “middle piece” that selects from the wishlist, building from our vision. Probably should work on that outside this meeting. 38 | * Participants - WG Leads, Ryan, Kay, David 39 | * Both bottom-up & top-down process to identify the list of things to do. Make sure we identify a lead for each one (don’t need to identify everyone who will work on something, but if we can’t find a lead it won’t be done). 40 | * Kay Williams will kick off the process. 41 | * License/CLA discussion (still open?) [https://github.com/ossf/tac/issues/26](https://github.com/ossf/tac/issues/26) 42 | * David & Lindsay talked with Scott Nicolas (LF legal) yesterday, the LF recommends devolving this down to WGs/projects. Concern appears to be that the technical charter was considered “too complex”. 43 | * Scott will draft up “something simpler” for discussion; if people have specific comments on problems with the technical charter, please let us know (at least David & Lindsay) 44 | * “We thought that the project charter was too complex” - let’s provide a list of acceptable (pre-approved) licenses - come up with a “default charter” 45 | * OpenSSF GB - have licensing in OpenSSF charter, with a process for requesting an exception. 46 | * Technical Charter discussed “TSC” & so on, seemed too much. 47 | * Look for “lightweight charter” & GB license policy 48 | * (FYI: SolarWinds Article - sudden hurry) (David) -------------------------------------------------------------------------------- /process/templates/PROJECT_NAME_incubation_stage.md: -------------------------------------------------------------------------------- 1 | ## Project incubation application 2 | 3 | ### Project has met all Sandbox requirement 4 | * "link to sandbox PR if one exists" 5 | 6 | ### List of project maintainers 7 | The project must have a minimum of three maintainers with a minimum of two different organizational affiliations. 8 | * "name, affiliation, GitHub ID" 9 | 10 | ### Mission of the project 11 | The project must be aligned with the OpenSSF mission and either be a novel approach for existing areas, address an unfulfilled need, or be code needed to deliver OpenSSF WG work. It is preferred that extensions of existing OpenSSF projects collaborate with the existing project rather than seek a new project. 12 | * "description of the project mission" 13 | 14 | ### Project adoption 15 | The project should be able to show adoption by multiple parties and the adoption's value to the open source community and/or end users (may include adoption of beta/early versions). 16 | * "description of adoption" 17 | 18 | ### Governance 19 | Project must have met publicly at least 5 times in the last quarter since becoming Sandbox 20 | * Link to public meeting notes (or ideally recordings) 21 | 22 | Projects must have documented, initial project governance 23 | * "link to governance documents/Charter" 24 | 25 | Project must have defined Contributor Guide 26 | * "link to contributor guide" 27 | 28 | Project has attained an OpenSSF Best Practice Badge at "passing" level 29 | * "link to OpenSSF Badge" 30 | 31 | Project is integrated into the OpenSSF Scorecard 32 | * "link to Scorecard output" 33 | 34 | ### IP policy and licensing due diligence 35 | When contributing an existing Project to the OpenSSF, the contribution must undergo license and IP due diligence by the Linux Foundation (LF). This step is only needed for the initial donation and only applicable here, if the project intends to join the OpenSSF Incubation stage. 36 | * "yes / no / not applicable. If yes, provide a link to the corresponding GitHub issue." 37 | 38 | ### Security Baseline 39 | 40 | The project meets all applicable Security Baseline requirements: 41 | * [ ] [Security Baseline - Once Sandbox](https://github.com/ossf/tac/blob/main/process/security_baseline.md#security-baseline---once-sandbox) 42 | * [ ] [Security Baseline - To Become Incubating](https://github.com/ossf/tac/blob/main/process/security_baseline.md#security-baseline---to-become-incubating) 43 | 44 | ### Project References 45 | The project should provide a list of existing resources with links to the repository, website, a roadmap, contributing guide, demos and walkthroughs, and any other material to showcase the existing breadth, maturity, and direction of the project. 46 | 47 | Reference | URL | 48 | |---------------------|-----| 49 | | Repo | | 50 | | Meeting Agenda | | 51 | | OSSF Calendar Entry | | 52 | | Website | | 53 | | Contributing guide | | 54 | | Security.md | | 55 | | Roadmap | | 56 | | Demos | | 57 | | Best Practices Badge | | 58 | | Scorecard integration | | 59 | | Other | | 60 | -------------------------------------------------------------------------------- /minutes/2022-11-01.md: -------------------------------------------------------------------------------- 1 | # **2022-11-01 Meeting** 2 | **Attendance (please add yourself):** 3 | 4 | 5 | 6 | * Michael Scovetta (Microsoft, Alpha-Omega) 7 | * CRob (Intel, TAC) 8 | * Bob Callaway (Google, TAC Chair) 9 | * Sam Ramji (LF/OpenSSF) 10 | * Luke Hinds (Red Hat, TAC) 11 | * Matt Rutkowski (IBM) 12 | * Dan Lorenc (Chainguard, TAC) (have to leave halfway) 13 | * Justin Hutchings (GitHub) 14 | * Aeva Black (Microsoft, TAC vice chair) 15 | * Brian Behlendorf (OpenSSF, LF) 16 | * Aaron Wislang (Microsoft) 17 | * Ashley Pierce (Shopify) 18 | * Brian Fox (Sonatype, GB) 19 | * Jay White (Microsoft) 20 | * Rosaria Carr (Indeed) 21 | * Josh Bressers (Anchore, TAC) 22 | * Abhishek Arya (Google, TAC) 23 | * Dan Appelquist (Snyk) 24 | * David Edelsohn (IBM, GTI) 25 | * Amir Montazery (OSTIF) 26 | * Jamie Magee (Microsoft) 27 | * Jennifer Bly (OpenSSF) 28 | * Jeff Mendoza (Google) 29 | * Betty Li (Shopify) 30 | * Jenny Shen (Shopify) 31 | * Andres Vega (ControlPlane, CNCF TAG-Security) 32 | * David A. Wheeler (Linux Foundation) 33 | * Munawar Hafiz (OpenRefactory) 34 | * Arnaud Le Hors (IBM) 35 | 36 | Regrets: 37 | 38 | 39 | 40 | * 41 | 42 | Agenda: 43 | 44 | 45 | 46 | * (_10 min max_): Update from **Securing Critical Projects WG [[slide](https://docs.google.com/presentation/d/11NWS703qmmMo-UhgtA0emvqu8F-VqP1QVa9yXdVTbxo/edit?usp=sharing)] **(Jeff Mendoza) 47 | * Progress on creating a process to identify and capture set of Critical Projects 48 | * Automation built in to process: Currently working on the automation piece 49 | * OSTIF reviewed current list, identified ~50 audit candidates from “about-100” list 50 | * Criticality score algo changes: [https://github.com/ossf/criticality_score/blob/main/docs/design/milestone_1.md](https://github.com/ossf/criticality_score/blob/main/docs/design/milestone_1.md) 51 | * Jacques leading the renewed outreach work to engage with other foundations & communities. 52 | * (_20 min max_): Update from **AO** [[slide deck](https://docs.google.com/presentation/d/1S0AofJHd7oLPNzfe55p23uzOHL0eiF9EKhU-PJlJRnM/edit?usp=sharing)] (Michael Scovetta) 53 | * Exciting updates to come with annual report 54 | * Process improvements 55 | * Want to make security a part of the “cultural norm” in the receiving organizations - our goal is to help make that change 56 | * How long will engagements take? We don’t know yet, probably >1 year but not 5. We’re open-minded, the emphasis is to create [the lasting change]. Let’s experiment & see what works. 57 | * (20 min max): [Proposal for Shared Repository Helpdesk](https://lists.openssf.org/g/openssf-tac/topic/94560709) (Ashley Ellis Pierce) 58 | * [Proposal for Shared Repository Helpdesk](https://docs.google.com/document/d/1Od9kqd4JIAW1h0vvvkD8NFclxsR8yudOdsZEMT7lBUc/edit?usp=sharing) 59 | * (10 min max): Technical Vision & Prep for Nov 11th Meeting (Sam Ramji) 60 | * [TAC Prep for Strategy Day 11/11/22](https://docs.google.com/presentation/d/1Y7MymeTKhZQimgbkAOw_aFf6VeGv6pvzT0ddVCOB1to/edit?usp=sharing) 61 | * Call for Pre-Reads - please email [sramji@linuxfoundation.org](mailto:sramji@linuxfoundation.org) or [bcallaway@google.com](mailto:bcallaway@google.com) 62 | * Next Town Hall (Jennifer Bly) 63 | 64 | 65 | -------------------------------------------------------------------------------- /TI-reports/2025/2025-Q1-SCP-WG.md: -------------------------------------------------------------------------------- 1 | # 2025 Q1 Securing Critical Projects WG 2 | 3 | ## Overview 4 | 5 | Sub projects continue to run and make progress. Little to no progress on main 6 | initiative of enhancing Critical Project Set with more information. Attendance 7 | is low. 8 | 9 | [2024-Q3 Update](../2024-Q3-SCP-WG.md) 10 | 11 | ## Identifying Critical Projects 12 | 13 | ### Purpose 14 | 15 | Open Source Software has long suffered from a "tragedy of the commons" 16 | problem. Organizations large and small make use of OSS every day, but many 17 | projects are struggling for the time, resources and attention they need. 18 | 19 | This is a resource allocation problem - and we can help solve it together. We 20 | need ways to connect critical projects we all rely on with organizations that 21 | can provide them with support. 22 | 23 | [MVSR Link](https://github.com/ossf/wg-securing-critical-projects/blob/main/MVSR.md) 24 | 25 | ### Current Status 26 | 27 | Discussions on: 28 | - Metadata side: what to add to list 29 | - Ideal north star of next iteration 30 | - Front end / publishing list 31 | 32 | ### Up Next 33 | 34 | TBD, no concrete plans 35 | 36 | ### Questions/Issues for the TAC 37 | 38 | None 39 | 40 | ## Criticality Score 41 | 42 | ### Purpose 43 | 44 | 1. Generate a criticality score for every open source project. 45 | 46 | 1. Create a list of critical projects that the open source community depends 47 | on. 48 | 49 | 1. Use this data to proactively improve the security posture of these critical 50 | projects. 51 | 52 | ### Current Status 53 | 54 | - Continues to run and recalculate scores 55 | - Updates 1 to 2 times a month 56 | - Tracking 500,000 projects 57 | 58 | ### Up Next 59 | 60 | Continue running 61 | 62 | ### Questions/Issues for the TAC 63 | 64 | None 65 | 66 | 67 | ## Package Analysis / Malicious Packages 68 | 69 | ### Purpose 70 | 71 | The Package Analysis project analyses the capabilities of packages available on 72 | open source repositories. The project looks for behaviors that indicate 73 | malicious software: 74 | 75 | - What files do they access? 76 | - What addresses do they connect to? 77 | - What commands do they run? 78 | 79 | The project also tracks changes in how packages behave over time, to identify 80 | when previously safe software begins acting suspiciously. 81 | 82 | This effort is meant to improve the security of open source software by 83 | detecting malicious behavior, informing consumers selecting packages, and 84 | providing researchers with data about the ecosystem. 85 | 86 | Malicious Packages is a collection of reports of malicious packages identified in 87 | Open Source package repositories, consumable via the Open Source Vulnerability 88 | (OSV) format. 89 | 90 | ### Current Status 91 | 92 | - Formal definition of "Malicious Package" merged 93 | - Malicious Package counts (Pull numbers from annual update) (current as 2025-01-17) 94 | - 2 crates-io 95 | - 18158 npm 96 | - 740 nuget 97 | - 8778 pypi 98 | - 807 rubygems 99 | 100 | ### Up Next 101 | 102 | Interested in PyPi data 103 | 104 | ### Questions/Issues for the TAC 105 | 106 | None 107 | -------------------------------------------------------------------------------- /minutes/2021-10-19.md: -------------------------------------------------------------------------------- 1 | # **2021-10-19 Meeting** 2 | 3 | ## Attendance (please add yourself): 4 | 5 | * Jennifer Fernick (NCC Group) 6 | * Justin Hutchings (GitHub) 7 | * Brian Behlendorf (Linux Foundation) 8 | * Arnaud J Le Hors (IBM) 9 | * Phil Estes (AWS) 10 | * CRob (Intel) 11 | * Rao Lakkakula (JPMorgan Chase) 12 | * David A. Wheeler (Linux Foundation) 13 | * Jory Burson (LF) 14 | * Dan Lorenc, 15 | * Kay Williams (Microsoft) 16 | * Jamie Magee (Microsoft) 17 | * Luke Hinds (Red Hat) 18 | * Sergio Rojas 19 | * Ryan Haning (Microsoft) 20 | 21 | ## Agenda: 22 | 23 | * Governing Board meeting, November 5 (Brian Behlendorf) 24 | * Brian Behlendorf: has led Hyperledger & LF Public Health (LFPH) 25 | * We now have $4.5M membership, & Google/Microsoft have separately raised $5M for Alpha-Omega 26 | * Big believer in open meetings (transparency). We’re here to help channel the expertise here, spending the money as efficiently & impactfully as possible. 27 | * LF runs on yearly budget cycles. Typically there’s an annual budget cycle of deciding budget. 28 | * Seek from TAC: guidance on the budget request. WG by WG, as well as TAC, want a sense of “what are the most important things going on & what can be accomplished in 2022 & what resources are needed?” 29 | * Want to know “what would success in 2022 look like?” 30 | * Want to put it into a deck this week & next. LF will try to organize it, but we need the OpenSSF participants to provide the information to be organized. 31 | * We need volunteers, one worry is that the added money will hurt the volunteer energy, we need to ensure volunteering continues 32 | * What needs funding? 33 | * Travel stipends for sending speakers to conferences 34 | * Seed projects 35 | * (Maybe) create a podcast 36 | * Write articles 37 | * Have a way to track conferences/podcasts that we want to go to, & make sure someone’s at some of them 38 | * ½ day workshop (could charge for so it’s self-funding) 39 | * We have a training department at the LF 40 | * Fund some research - get more connections with researchers in the field 41 | * 1/2 day workshops/hands-on around larger events is always possible (like day 0 events around the bigger LF events); I think a lot of people want to learn what all these things really *mean* to them.. SBOMs, signing/validation in CI/CD, etc. 42 | * foundation grant/scholarship, e.g., https://www.iamcybersafe.org/s/scholarships 43 | * Example: https://edscoop.com/cisco-hbcu-cybersecurity-compliance/ 44 | * Sigstore/OSSF - (Luke/Dan) 45 | * Luke Hinds gave an overall summary about sigstore - available at [https://docs.google.com/presentation/d/11bhGNgi4YD41krEi-hx9opWH07Egub7JKHVWymL1-tA/edit](https://docs.google.com/presentation/d/11bhGNgi4YD41krEi-hx9opWH07Egub7JKHVWymL1-tA/edit) 46 | * A big cost is 24-hour coverage for support 47 | * Do we need a TAC vote to include sigstore in OpenSSF? 48 | * Brian: We could split *code* vs. running in operations 49 | * Ryan Haning: Let’s create a GitHub issue for discussion & then voting 50 | * TAC Elections 51 | * Working with Jory & Brian to get that figured out by Nov 5 52 | * If you have concerns/questions/advice, please reach out -------------------------------------------------------------------------------- /process/project-lifecycle-documents/bomctl_sandbox_stage.md: -------------------------------------------------------------------------------- 1 | ## Application for creating a new project at Sandbox stage 2 | 3 | ### List of project maintainers 4 | 5 | The project must have a minimum of three maintainers with a minimum of two different organizational affiliations. 6 | 7 | * "Jonathan Howard", "Lockheed Martin", @jhoward-lm 8 | * "Eddie Zaneski", "Defense Unicorns", @eddiezane 9 | * "Allen Shearin", "Lockheed Martin", @ashearin 10 | * "Ian Dunbar-Hall", "Lockheed Martin", @idunbarh 11 | 12 | ### Sponsor 13 | 14 | Most projects will report to an existing OpenSSF Working Group, although in some cases a project may report directly to the TAC. The project commits to providing quarterly updates on progress to the group they report to. 15 | 16 | * Security Tooling WG - This project was initial developed as an experiment under the Security Tooling WG. 17 | 18 | ### Mission of the project 19 | 20 | The project must be aligned with the OpenSSF mission and either be a novel approach for existing areas, address an unfulfilled need, or be initial code needed for OpenSSF WG work. It is preferred that extensions of existing OpenSSF projects collaborate with the existing project rather than seek a new project. 21 | 22 | * "__bomctl__ is format-agnostic Software Bill of Materials (SBOM) tooling, which is intended to bridge the gap between SBOM generation and SBOM analysis tools. It focuses on supporting more complex SBOM operations by being opinionated on only supporting the NTIA minimum fields or other fields supported by protobom." 23 | * "__bomctl__ started as an action from Secure Open Source Summit 2023 in DC. The action item was to merge existing sbom tooling into a single source for sbom format agnostic tooling to manage relationships between SBOM files. No existing tooling beyond the [protobom](https://github.com/protobom/protobom) work existed that was format agnostic. This lead to __bomctl__ being developed by the Security Tooling WG." 24 | * "__bomctl__ heavily builds on [protobom](https://github.com/protobom/protobom)." 25 | * "[Protobom](https://github.com/protobom/protobom) is a go library for manipulating SBOM data in a schema-agnostic manner" 26 | * "__Bomctl__ is a CLI that handles movement, operations, and caching of SBOM files and will allow linkages between SBOM files" 27 | 28 | ### IP policy and licensing due diligence 29 | 30 | When contributing an existing Project to the OpenSSF, the contribution must undergo license and IP due diligence by the Linux Foundation (LF). 31 | 32 | * "TBD" 33 | 34 | ### Project References 35 | 36 | The project should provide a list of existing resources with links to the repository, and if available, website, a roadmap, contributing guide, demos and walkthroughs, and any other material to showcase the existing breadth, maturity, and direction of the project. 37 | 38 | | Reference | URL | 39 | |---------------------|-----| 40 | | Repo | https://github.com/bomctl/bomctl | 41 | | Website | https://github.com/bomctl/bomctl | 42 | | Contributing guide | https://github.com/bomctl/bomctl/blob/main/CONTRIBUTING.md | 43 | | Security.md | https://github.com/bomctl/bomctl/blob/main/SECURITY.md | 44 | | Scorecard Report | https://securityscorecards.dev/viewer/?uri=github.com/bomctl/bomctl | 45 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/approved_project_onboarding.yml: -------------------------------------------------------------------------------- 1 | name: Approved Project Onboarding 2 | description: Onboarding of an approved OpenSSF Project 3 | title: "[Proposed Project]: " 4 | labels: "proposed-project" 5 | body: 6 | - type: markdown 7 | attributes: 8 | value: 9 | Please fill out the information below, to complete the project formation. 10 | 11 | - type: input 12 | id: approval_pr 13 | attributes: 14 | label: Approval Pull Request 15 | description: Please provide the link to the merged approval PR 16 | placeholder: PR Link 17 | validations: 18 | required: true 19 | 20 | - type: input 21 | id: project-common-name 22 | attributes: 23 | label: Project Common Name 24 | description: What is the common name of your project? 25 | placeholder: Awesome Project 26 | validations: 27 | required: true 28 | 29 | - type: textarea 30 | id: description 31 | attributes: 32 | label: Description 33 | description: Please provide a description of your project. 34 | validations: 35 | required: true 36 | 37 | - type: textarea 38 | id: mission-statement 39 | attributes: 40 | label: Mission Statement 41 | description: The mission statement should be a single sentence statement that begins with the words "The mission of the project is to..." and is followed by the primary purpose of the project or primary goal of the project. 42 | placeholder: The mission of the project is to... 43 | validations: 44 | required: true 45 | 46 | - type: dropdown 47 | id: category 48 | attributes: 49 | label: Category 50 | description: Select the category for your project. 51 | options: 52 | - Sandbox 53 | - Incubating 54 | - Graduating 55 | validations: 56 | required: true 57 | 58 | - type: input 59 | id: parent-project 60 | attributes: 61 | label: Parent Project / Working Group 62 | description: What is the parent project or working group for this project? 63 | placeholder: Example Working Group 64 | validations: 65 | required: true 66 | 67 | - type: input 68 | id: website 69 | attributes: 70 | label: Primary Website/Domain 71 | description: What is the primary website or domain for this project? 72 | placeholder: https://example.com 73 | 74 | - type: input 75 | id: repository-url 76 | attributes: 77 | label: Repository URL 78 | description: What is the URL of the project's repository? 79 | placeholder: https://github.com/example/project 80 | validations: 81 | required: true 82 | 83 | - type: input 84 | id: expected-announcement-date 85 | attributes: 86 | label: Expected Announcement Date (If Known) 87 | description: What is the expected announcement date for this project? 88 | 89 | - type: dropdown 90 | id: license 91 | attributes: 92 | label: Primary Open Source License 93 | description: Select the primary open source license for your project. 94 | options: 95 | - Apache-2.0 96 | - MIT 97 | - Community Data License Agreement 98 | validations: 99 | required: true 100 | -------------------------------------------------------------------------------- /minutes/2021-12-14.md: -------------------------------------------------------------------------------- 1 | # **2021-12-14 Meeting** 2 | 3 | ## Attendance (please add yourself): 4 | 5 | * Phil Estes (AWS) 6 | * Abhishek Arya (Google) 7 | * CRob (Intel) 8 | * Justin Hutchings (GitHub) 9 | * David A. Wheeler (Linux Foundation) 10 | * Jenn Bonner (Linux Foundation) 11 | * Luke Hinds (Red Hat) 12 | * Arnaud J Le Hors (IBM) 13 | * Steve Taylor (DeployHub) 14 | * Sudhindra Rao (JFrog) 15 | * Stephen Chin(JFrog) 16 | * Josh Bressers (Anchore) 17 | * Jamie Magee (Microsoft) 18 | * Christopher Crone (Docker) 19 | * Jory Burson (Linux Foundation) 20 | * Laura MacLeod (Microsoft) 21 | * Teodor Voinea (Microsoft) 22 | * Aeva Black (Microsoft) 23 | * Audrey Mendez-Pratt (Microsoft) 24 | * Georg Kunz (Ericsson) 25 | * Jennifer Fernick (NCC Group) 26 | * Matt Rutkowski (IBM) 27 | * Michael Winser (Google) 28 | * Brian Behlendorf (LF) 29 | * Yotam Perkal (Rezilion) 30 | * Jason Kratzer (Mozilla) 31 | * Tracy Ragan (DeployHub) 32 | * Jeff Mendoza (Google) 33 | * Yoav Landman (JFrog) 34 | * Jeff Borek (IBM) 35 | * Dan Lorenc (Chainguard) 36 | * Abhishek Arya (Google) 37 | * Rao Lakkakula (JP Morgan Chase) 38 | * Ryan Haning (Microsoft) 39 | 40 | ## Agenda: 41 | 42 | * Election Process Update 43 | * Election Officials (must be eligible to vote & not running for a position): Ryan Haning (Microsoft), David A. Wheeler (LF), Stephen Chin (JFrog) 44 | * Announce self nomination of candidates 45 | * Complication: The charter says GB elects 4, community elects 3. Ryan looked at old notes & believe _intent_ was GB elects 3, community elects 4. Brian B. will research, talk with GB, get back to TAC about this. 46 | * BB response: indeed, GB agreed with 3, community elects 4. 47 | * Jory & Jenn to prepare election forms & email the group; election officials to help answer questions of eligibility/participation, Staff to answer questions of election process 48 | * Pyrsia, a Decentralized Package Network. (Stephen Chin, JFrog). Draft proposal here: [https://docs.google.com/document/d/1gg6cAWXKiG--ioZ20xMGV5fBkSNCbJ92KuKukHkmQeg/edit](https://docs.google.com/document/d/1gg6cAWXKiG--ioZ20xMGV5fBkSNCbJ92KuKukHkmQeg/edit) 49 | * [Component Detection](https://github.com/microsoft/component-detection) - (Jamie Magee, Microsoft) \ 50 | build-time scanning tool to detect dependencies in a codebase 51 | * MIT license 52 | * Many transitive dependencies detected, but there are some gaps, e.g., gradle 53 | * Everything with a checkmark in graph creation support transitive dependencies: [https://github.com/microsoft/component-detection/#feature-overview](https://github.com/microsoft/component-detection/#feature-overview) 54 | * Future plans? 55 | * Laura MacLeod: Adding more detectors. We’ve been focusing more on Microsoft ecosystems. Currently working to add Python poetry (already support pip) 56 | * Just wanted to see “how we could help” 57 | * Do you capture hashes? 58 | * Rely on package manager information. Go & pip do support commit-level references, so in those cases we’ll pick it up & share it on. 59 | * See “An Analysis of the SSC Landscape” by Aeva Black, [https://docs.google.com/document/d/1KT5QPCgVx_8UFIKv8-0k9GYjfcL3uvHmK4COOEGq_UQ](https://docs.google.com/document/d/1KT5QPCgVx_8UFIKv8-0k9GYjfcL3uvHmK4COOEGq_UQ) 60 | * FYI: Great MFA Distribution Project is actively working to contact projects for sending MFA tokens -------------------------------------------------------------------------------- /process/sig-lifecycle-documents/MEMORY_SAFETY_sandbox_stage.md: -------------------------------------------------------------------------------- 1 | ## Creation of a new Special Interest Group (SIG) at Sandbox stage 2 | 3 | ### Proposed focus, intent, goals, and/or deliverables 4 | 5 | Our Motivation, Objective, and Scope are outlined in the [README of our repo](https://github.com/ossf/Memory-Safety/blob/main/README.md) 6 | 7 | Our original deliverable was revised language for Stream 4 of the OpenSSF's Mobilization plan. Our revised language for Stream 4 is [here](https://github.com/ossf/Memory-Safety/blob/main/docs/revised-stream-4-language.md). 8 | 9 | We also established [common definitions of memory safety terms](https://github.com/ossf/Memory-Safety/blob/main/docs/definitions.md) to refer to in our work. 10 | 11 | Our in progress deliverables include: 12 | * [Best Practices - Memory-Safe By Default Languages](https://github.com/ossf/Memory-Safety/blob/main/docs/best-practice-memory-safe-by-default-languages.md) 13 | * [Best Practices - Non-Memory-Safe By Default Languages](https://github.com/ossf/Memory-Safety/blob/main/docs/best-practice-non-memory-safe-by-default-languages.md) 14 | * [The Memory Safety Continuum](https://github.com/ossf/Memory-Safety/pull/20) 15 | 16 | ### List SIG Lead(s) 17 | * [Nell Shamrell-Harrington](https://github.com/nellshamrell) (Microsoft, Rust Foundation) 18 | * [Avishay Balter](https://github.com/balteravishay) (Microsoft) 19 | 20 | ### List of interested individuals 21 | The SIG have a minimum of 3 members with 2 different organizational affiliations. 22 | * Jay White, Microsoft 23 | * Gabriel Dos Reis, Microsoft, [GabrielDosReis](https://github.com/GabrielDosReis) 24 | * Charles Palmer, IBM Research, Dartmouth 25 | * David Edelsohn, IBM 26 | * Andrew Fryer, [Andrew-Fryer](https://github.com/Andrew-Fryer) 27 | * Justin Cappos, NYU, [JustinCappos](https://github.com/JustinCappos) 28 | * Andrew Lilley Brinker, Mitre, [alilleybrinker](https://github.com/alilleybrinker) 29 | * Joshua J. Drake, [jduck](https://github.com/jduck) 30 | * Chris de Almeida, IBM, [ctcpip](https://github.com/ctcpip) 31 | * Jordan Harband, TC39, [ljharb](https://github.com/ljharb) 32 | 33 | 34 | ### Governing Body 35 | SIGs may report to an existing OpenSSF Working Group or directly to the TAC as their governing body. The SIG commits to providing the governing body quarterly updates on progress. 36 | * [Best Practices Working Group](https://github.com/ossf/wg-best-practices-os-developers) 37 | 38 | ### SIG References 39 | The SIG should provide a list of existing resources with links to the repository, and if available, website, a roadmap, demos and walkthroughs, and any other material to showcase the existing breadth, maturity, and direction of the SIG. 40 | | Reference | URL | 41 | |---------------------|-----| 42 | | Repo |https://github.com/ossf/Memory-Safety | 43 | | Meeting Agenda |https://docs.google.com/document/d/1RnIzqeKyrOJvs6vQ8xGH6TjZDoEFaGUs1NkAx--v_3Y/edit | 44 | | OSSF Calendar Entry |Not sure how to link this, but there is one! | 45 | | Website | | 46 | | Security.md | | 47 | | Roadmap | | 48 | | code-of-conduct.md |https://openssf.org/community/code-of-conduct/ | 49 | | Demos | | 50 | | Other | | 51 | -------------------------------------------------------------------------------- /minutes/2021-08-10.md: -------------------------------------------------------------------------------- 1 | # **2021-08-10 Meeting** 2 | 3 | ## Attendance (please add yourself): 4 | 5 | * Ax Sharma (Sonatype) 6 | * CRob (Intel) 7 | * Kay Williams (Microsoft) 8 | * David A. Wheeler (LF) 9 | * Dan Lorenc (Google) 10 | * Jennifer Fernick (NCC Group) 11 | * Rao Lakkakula - (JPMC) 12 | * Sal Kimmich (Sonatype) 13 | * Matt Rutkowski (IBM) 14 | 15 | ## Agenda: 16 | 17 | * OpenSSF 2021 Budget Approved (Kay) 18 | * Identifying Security Threats WG - $40K development + $1,600 Azure Credits 19 | * Best Practices WG - $33,100 development + $30K Azure Credits 20 | * Securing Critical Projects WG - OSTIF Proposal - $60K 21 | * There’s about $65K left 22 | * OpenSSF [Allstar](https://github.com/ossf/allstar) [GitHub app](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps) (Securing Critical Projects WG) 23 | * Sets some GitHub security policies, e.g., must have SECURITY.md, etc. It is related to ScoreCards - enforces some of the same things. The name is a play on “scorecard” - if you get a good score you’re an all-star. 24 | * Announcement - blog, email, tweet - coming soon! 25 | * Discuss - OpenSSF response to US Whitehouse EO (Kay) 26 | * fyi - [video for Planning Committee Meeting](https://zoom.us/rec/play/RTdp5X7H067xonXhpirp12adiQsDaB47_V6xFsZDhHT9tOoIU4J7zHX_h1cWFrOdJ7Z64rfc5hu0W7Qu.iDdcgUC2cLd2ctzJ?canPlayFromShare=true&from=share_recording_detail&continueMode=true&componentName=rec-play&originRequestUrl=https%3A%2F%2Fzoom.us%2Frec%2Fshare%2FrtLFGJwiV9a6lyMscgUfnE2bwbzma7vvB6xQyoZysDvXidj0rYUEMh4bvmcxZgXm.zpJTqfFT0HLunFxr) (8/9) 27 | * There’s little time before the next NIST response is due. The Planning Committee won’t try to coordinate a response in that little time, but we’ll share information as individuals prepare their own responses (as individuals choose) 28 | * Identify EO-Critical OSS Projects 29 | * Securing Critical Projects WG 30 | * Generate evidence demonstrating conformance to EO requirements 31 | * Security Best Practices WG / Identifying Security Threats WG? 32 | * Questions 33 | * CRoB: Best Practices WG is trying to create more prescriptive guidance on what developers should do; needs to synergize with tools WG. Would it be better to approach this as a collective project of the OpenSSF as a whole? 34 | * Suggestion: follow publishing immediately with a poll to ask what else readers would like to see 35 | * Suggestion: make this a living document 36 | * CRoB to send out email 37 | * CRoB: OpenSSF Reference Architecture (project for Black Hat) 38 | * Shows interactions between groups and projects. 39 | * David: Suggest paper with diagram 40 | * CRoB: Dynamic graphic allows clicking to repositories with readme for people to learn how to get involved. 41 | * Sal: Make sure people can find points of contact 42 | * Jennifer: Mark things that are collaboration across projects, consider color coding 43 | * David: Make them all hyperlinks - then people can quickly get to the info. There are nits that I think need to be fixed (need to make overlaps bigger to fit info & CHAOSS should be partly outside since it’s really an external project), but I love the approach. 44 | * Next Steps: 45 | * CRoB to move diagram to editable format, share with others. 46 | 47 | ![alt_text](assets/crob_diagram.png "image_tooltip") 48 | -------------------------------------------------------------------------------- /TI-reports/2025/2025-Q2-SCP-WG.md: -------------------------------------------------------------------------------- 1 | # 2025 Q2 Securing Critical Projects WG 2 | 3 | ## Overview 4 | 5 | Sub-projects continue to run and make progress. Malicious Packages project is 6 | attracting interest. Continue discussion on ideas for helping top 7 | projects. Attendance is low. 8 | 9 | [2025-Q1 Update](2025-Q1-SCP-WG.md) 10 | 11 | ## Identifying Critical Projects 12 | 13 | ### Purpose 14 | 15 | Open Source Software has long suffered from a "tragedy of the commons" 16 | problem. Organizations large and small make use of OSS every day, but many 17 | projects are struggling for the time, resources and attention they need. 18 | 19 | This is a resource allocation problem - and we can help solve it together. We 20 | need ways to connect critical projects we all rely on with organizations that 21 | can provide them with support. 22 | 23 | [MVSR Link](https://github.com/ossf/wg-securing-critical-projects/blob/main/MVSR.md) 24 | 25 | ### Current Status 26 | 27 | - Investigation of [Census 3](https://www.linuxfoundation.org/research/census-iii) data 28 | 29 | ### Up Next 30 | 31 | - Investigating what a "light" review/audit would look like. 32 | - An experiment would be 2 person-week (2 eng 1 week) to see if that works, 33 | expect this to be minimum time for any valuable findings 34 | 35 | ### Questions/Issues for the TAC 36 | 37 | None 38 | 39 | ## Criticality Score 40 | 41 | ### Purpose 42 | 43 | 1. Generate a criticality score for every open source project. 44 | 45 | 1. Create a list of critical projects that the open source community depends 46 | on. 47 | 48 | 1. Use this data to proactively improve the security posture of these critical 49 | projects. 50 | 51 | ### Current Status 52 | 53 | - Github enumerator has stopped working. Investigating 54 | - Scoring running with a manual list 55 | - Updates 1 to 2 times a month 56 | - Tracking 500,000 projects 57 | 58 | ### Up Next 59 | 60 | Fix enumerator 61 | 62 | ### Questions/Issues for the TAC 63 | 64 | None 65 | 66 | 67 | ## Package Analysis / Malicious Packages 68 | 69 | ### Purpose 70 | 71 | The Package Analysis project analyses the capabilities of packages available on 72 | open source repositories. The project looks for behaviors that indicate 73 | malicious software: 74 | 75 | - What files do they access? 76 | - What addresses do they connect to? 77 | - What commands do they run? 78 | 79 | The project also tracks changes in how packages behave over time, to identify 80 | when previously safe software begins acting suspiciously. 81 | 82 | This effort is meant to improve the security of open source software by 83 | detecting malicious behavior, informing consumers selecting packages, and 84 | providing researchers with data about the ecosystem. 85 | 86 | Malicious Packages is a collection of reports of malicious packages identified in 87 | Open Source package repositories, consumable via the Open Source Vulnerability 88 | (OSV) format. 89 | 90 | ### Current Status 91 | 92 | - New contributors helping with routine maintenance 93 | - Working on documenting dependency confusion 94 | - Scanning tooling needs to differentiate internal packages/namespaces when generating reports 95 | - Package Analysis big query is not updating, working on bug 96 | 97 | ### Up Next 98 | 99 | - Dependency confusion documentation is top priority 100 | 101 | ### Questions/Issues for the TAC 102 | 103 | None 104 | -------------------------------------------------------------------------------- /minutes/2020-12-15.md: -------------------------------------------------------------------------------- 1 | # **2020-12-15 Meeting** 2 | 3 | ## Attendance (please add yourself): 4 | 5 | * David A. Wheeler (Linux Foundation) 6 | * Maya Kaczorowski (GitHub) 7 | * Dan Middleton (Intel) 8 | * Kay Williams (Microsoft) 9 | * Phil Estes (IBM) 10 | * Jon Zeolla (Seiso) 11 | * Altaz Valani (Security Compass) 12 | * Lindsay Mays Gendreau (Linux Foundation) 13 | * Dan Lorenc (Google) 14 | * Kim Lewandowski (Google) 15 | 16 | ## Agenda 17 | 18 | * OpenSSF Technical Vision 19 | * [https://github.com/ossf/tac/issues/40](https://github.com/ossf/tac/issues/40) 20 | * ~~Draft ([Google Document](https://docs.google.com/document/d/1iw01-grJgGtFQeWTI-LN59vKrJ4sfG6Igvz9pYqrFak/edit#))~~ (superseded by PR: [https://github.com/ossf/tac/pull/47](https://github.com/ossf/tac/pull/47)) 21 | * Reviewed and modified based on feedback from meeting participants 22 | * Next Steps: 23 | * Electronic Vote - due by January 8 24 | * Kay to discuss with Ryan to kick off vote after 1st of the year 25 | * Working Group Lifecycle 26 | * Consider ratifying/merging or otherwise iterating on WG Lifecycle: 27 | * https://github.com/ossf/tac/pull/41 28 | * Next steps: 29 | * Dan Lorenc will send out an email for TAC members to use GitHub to approve (done) 30 | * Dan Middleton will create new issue for discussion of ‘what is a working group allowed to do’ 31 | * Done: [https://github.com/ossf/tac/issues/44](https://github.com/ossf/tac/issues/44) 32 | * Side note - Dan Lorenc will add all TAC members as owners for the TAC repo 33 | * Finalize TAC election process 34 | * https://github.com/ossf/tac/issues/15 35 | * Simplified version of CNCF 36 | * Other approach - each WG lead is member of TAC, makes size of TAC unbounded, creates incentive to restrict new WGs, etc. 37 | * Discussion about # of members - is 7 too big, too small 38 | * Bigger - difficult to coordinate (quorum requirement) 39 | * TAC should be working on oversight, most of the work should be done in the WGs/Projects) 40 | * How do we identify ‘contributors to technical projects’ 41 | * Kubernetes does this by identifying individuals who have had activity on a project (created issue, commented on issue, etc.) 42 | * Another project - ‘measurable contribution’ = ‘commit’ 43 | * Exception process for people have contributed documentation (e.g. for wiki pages) 44 | * Attended x # of meetings, committer 45 | * Next step: 46 | * David/Lindsay to send the proposal to Mike Dolan for review, make sure the rules regarding voting are OK. Potential issue about limitation to x # of members (1 or 2) per organization 47 | * David send email after this call to understand rules, guidelines, issues, constraints. 48 | * One more pass at proposal to accomplish the following: 49 | * Clarify process for identifying ‘contributors of technical projects’ 50 | * Add statement about # of TAC members per organization (David will research) 51 | * Discuss (and possibly vote) at next meeting (January 12) 52 | * Must be filled by February 53 | 54 | Unicode includes a swan, which looks like a goose: 🦢. This is U+1F9A2, accessible in Slack as :swan: . More information here: [https://emojipedia.org/swan/](https://emojipedia.org/swan/). There’s also the Unicode Han characters 'goose' (U+9D5E) and ‘wild goose’ U+9D08, but those can only be understood by those who can read Chinese characters -------------------------------------------------------------------------------- /minutes/2022-09-20.md: -------------------------------------------------------------------------------- 1 | # **2022-09-20 Meeting** 2 | 3 | Attendance (please add yourself): 4 | 5 | 6 | 7 | * Bob Callaway (Google, **TAC**) 8 | * CRob (Intel, **TAC**) 9 | * Josh Bressers (Anchore, **TAC**) 10 | * Jacques Chester (Shopify) 11 | * Abhishek Arya (Google, **TAC**) 12 | * Brian Fox (Sonatype, GB) 13 | * Brian Behlendorf (LF/OpenSSF) 14 | * Luke Hinds (Red Hat, **TAC**) 15 | * Jory Burson (Linux Foundation) 16 | * Dan Appelquist (Snyk, Observer) 17 | * David A. Wheeler (Linux Foundation) 18 | * Jeff Borek (IBM) 19 | * Jay White (Microsoft) 20 | * Arnaud Le Hors (IBM) 21 | * Sarah Novotny (Microsoft) 22 | * Phil Estes (AWS) 23 | * Munawar Hafiz (OpenRefactory) 24 | 25 | Regrets: 26 | 27 | 28 | 29 | * Aeva Black (Microsoft, TAC Vice Chair) 30 | * Dan Lorenc (Chainguard, TAC) 31 | * Luke (need to drop after 30 mins for webinar) 32 | 33 | Agenda: 34 | 35 | 36 | 37 | * ~~(_10 min max_): Update from **GTI [ To be moved to future meeting ]**~~ 38 | * (_10 min max_): Update from **Securing Software Repos WG** 39 | * Jacques: Going well. Representation from many communities, including Java, Python, Node, Cargo (Rust), etc. 40 | * Want to set up a “shared help desk” for MFA reset. Community registries are already swamped, and this is security-sensitive. It’d be nice if MFA reset could be outsourced. 41 | * Bob: What events could be generated on an MFA reset? Are there other events that should be generated? We need to make sure this is as transparent as possible. 42 | * Jacques: We want some events pushed into the transparency log, so that monitors can know what has happened. Already seeing 5 requests/week for a few hundred developers, Python 10 requests/week for a few thousand developers. So about 0.025 requests/package/week is holding for Rubygems & Python. 43 | * David: That’s 25,000/week for 1 million packages! 44 | * Recap of OpenSSF Day EU 45 | * Brian: About ⅓ folks had traveled to Dublin my guess. Attendance less than maybe I would have liked, but had a significant number. Total reach ~240 people. 46 | * Happy with presentations, wide swathe. Ended with discussion with GB chair. 47 | * Was very glad to connect with the European community while we were there. 48 | * Thanks to CRob for being MC again and donning the goose hat once again! 49 | * [CRob] [Reference Architecture](https://lists.openssf.org/g/openssf-tac/topic/93559175#583) thread 50 | * David A. Wheeler: I have some materials I’ll share with CRob 51 | * Doodle meeting invite for those interested in collaborating: [https://doodle.com/meeting/participate/id/eZVoKy2e](https://doodle.com/meeting/participate/id/eZVoKy2e) 52 | * GB Meeting Updates 53 | * TAC will be invited to open-portion of GB meetings 54 | * Governance subcommittee 55 | * Next steps on Project/WG governance 56 | * First round of WG/Project updates are done; feedback / changes? 57 | * Finish housekeeping work (charters, classifying projects against lifecycle, etc) 58 | * SSC - multiple WGs interested 59 | * If the proposed project can work out the “right” WG by itself, great! Otherwise the TAC can help resolve things 60 | * We don’t want to be over bureaucratic [we want to get things done] 61 | * Update [https://github.com/ossf/tac/blob/main/technical-vision.md](https://github.com/ossf/tac/blob/main/technical-vision.md) 62 | * Accuracy, inclusion of efforts since Jan 2021 63 | * Gap analysis 64 | * Funding analysis 65 | * To-be-reviewed? At joint GB/TAC meeting at LF Member Summit? 66 | 67 | 68 | -------------------------------------------------------------------------------- /TI-reports/2024/2024-Q3-AI-ML-WG.md: -------------------------------------------------------------------------------- 1 | # 2024 Q3 AI/ML WG and model signing project 2 | 3 | ## Overview 4 | 5 | We continue our mission to enable security for AI and use AI for security of open source. The community is healthy, but we are seeing multiple similar groups ramping up, so we need to always dedicate time to create interlocks between the groups, share the knowledge and developments, and make sure work is not duplicated. Future launches for model signing and documentation are planned for Q4. We still have a focus on experimentation too. 6 | 7 | ### Recent Updates 8 | 9 | - Some members involved in ASIC (AI Safety Institute Consortium) workstreams 10 | - Discussed [AI supply chain whitepaper](https://research.google/pubs/securing-the-ai-software-supply-chain/) 11 | - Presentation on Scalibr and Tsunami as tool to scan for vulnerabilities 12 | - Seeding discussion on donating Tsunami to the OpenSSF -- decision pending 13 | - Discussion on NIST SP 800-218A standard for GenAI and Dual-Use foundation models and how OpenSSF technologies can be used 14 | - CoSAI, "What's in the SOSS" podcast 15 | 16 | #### Model signing 17 | 18 | - Several demos as the library/CLI progressed 19 | - C2PA presentation from Adobe, with a focus on potential application for model signing 20 | 21 | ### Purpose 22 | 23 | Serve as a central place to collate any recommendation for using AI securely ("security for AI") and using AI to improve security of other products ("AI for security"). 24 | 25 | The model signing project aims to create a cryptographic signing specification for AI models, taking into account difficulties that arise when trying to protect the integrity of large blobs. 26 | 27 | ### Current Status 28 | 29 | We're active and healthy, both in the parent working group and the model signing project. The field evolves fast and we are keeping up to date. 30 | 31 | ### Up Next 32 | 33 | - Document detailing how OpenSSF products can be used to strengthen the AI supply-chain. 34 | - Potentially start a SIG on AI vulnerability disclosure. Need to make sure we have enough specificity to warrant creating the SIG vs merging with the vulnerability disclosure WG. 35 | - Demo model signing library and CLI at the next model signing project meeting. Then, start integrating these with model producers to extract feedback before a release of the model signing library. 36 | - Publication of wheel, followed by playbook to integrate it with ML frameworks and ML model hubs 37 | - Sign with Sigstore or own PKI 38 | - Exploring deeper integrations of model signing with in-toto, witness, C2PA. 39 | 40 | ### Challenges 41 | 42 | - New groups in AI/ML are constantly springing up. We are trying to create tentacles in each of them, and then report back to the working group meetings so that everyone is aware. A constant issue is to make sure we don't duplicate the same work in two separate groups. 43 | - Meeting slot on Monday means several meetings have to be skipped due to US holidays. Might consider moving to another slot if this becomes an issue. 44 | 45 | ### Questions/Issues for the TAC 46 | 47 | We have one TAC member as co-chair and several other TAC members are frequent participants in both the working group and the model signing project. 48 | 49 | We're eager for substantive discussion with TAC and others. 50 | 51 | ## Additional Information 52 | 53 | We are currently in the process of formalizing the lifecycle documents, both for the [working group (sandbox to incubating)](https://github.com/ossf/tac/pull/375) and for the [model signing project (was SIG in previous update)](https://github.com/ossf/tac/pull/347). 54 | -------------------------------------------------------------------------------- /process/sig-lifecycle-documents/security_baseline_sandbox_stage.md: -------------------------------------------------------------------------------- 1 | ## Creation of a new Special Interest Group (SIG) at Sandbox stage 2 | 3 | ### Proposed focus, intent, goals, and/or deliverables 4 | 5 | The goal of this SIG is to evolve [OpenSSF security baseline](https://github.com/ossf/tac/blob/a90b9838739ac18df43197fdd89f045c1a1e4dc3/process/security_baseline.md) for Linux Foundation wide adoption. 6 | 7 | For OpenSSF adoption of the security baseline, there needs to be a home for tracking the adoption, for maintainers to raise issues to refine the security baseline, merge the baseline back to TAC lifecycle, and for OpenSSF to develop the roadmap for the security baseline. It will provide a venue for early adopters to share their reusable code and findings with other maintainers. The pilot adoption builds the foundation for wider adoption of the security baseline in OpenSSF and in Linux Foundation. 8 | 9 | This SIG creates a venue for other participating foundations to help evolve the OpenSSF security baseline into a security baseline that can be applied to a broad range of software-based projects. The group will define the right level of risks that the security baseline is applicable for, the effectiveness measurement of the security baseline, and the adoption path of the security baseline at the minimum. 10 | 11 | Members of this group will be from various Linux foundations and entities outside of Linux Foundation. Reducing duplicate effort and achieving a higher level of security across Linux FOundation participating foundations is one of the goals of the group. 12 | 13 | 14 | ### List SIG Lead(s) 15 | The SIG must have a minimum of 1 Lead 16 | * Eddie Knight, OpenSSF Security Insights lead, Sonatype, GitHub ID: eddie-knight 17 | * Michael Lieberman, OpenSSF GUAC lead, Kusari, GitHub ID: mlieberman85 18 | 19 | ### List of interested individuals 20 | The SIG have a minimum of 3 members with 2 different organizational affiliations. 21 | * Adolfo "Puerco" García Veytia, CNCF kubernetes SIG Release Technical Lead, OpenSSF Protobom, OpenVEX maintainer, Staklock, GitHub ID: puerco 22 | * Justin Cappos, CNCG TUF, in-toto, Uptane, OpenSSF gittuf maintainer, New York University. GitHUb ID: JustinCappos 23 | * David Wheeler, OpenSSF Best Practice Badge maintainer, OpenSSF, GitHub ID: david-a-wheeler 24 | * Dana Wang, OpenSSF security baseline maintainer, OpenSSF, GitHub ID: danajoyluck 25 | 26 | ### Governing Body 27 | SIGs may report to an existing OpenSSF Working Group or directly to the TAC as their governing body. The SIG commits to providing the governing body quarterly updates on progress. 28 | * Security Best Practices Working Group 29 | 30 | CRob and Dana Wang had conversations about this initiative. CRob has agreed to be the sponsor of this SIG and welcome the group to join Security Best Practices Working Group. 31 | 32 | ### SIG References 33 | The SIG should provide a list of existing resources with links to the repository, and if available, website, a roadmap, demos and walkthroughs, and any other material to showcase the existing breadth, maturity, and direction of the SIG. 34 | | Reference | URL | 35 | |---------------------|-----| 36 | | Repo | | 37 | | Meeting Agenda | | 38 | | OSSF Calendar Entry | | 39 | | Website | | 40 | | Security.md | | 41 | | Roadmap | | 42 | | code-of-conduct.md | | 43 | | Demos | | 44 | | Other | [OpenSSF security baseline](https://github.com/ossf/tac/blob/a90b9838739ac18df43197fdd89f045c1a1e4dc3/process/security_baseline.md) | 45 | -------------------------------------------------------------------------------- /minutes/2022-06-14.md: -------------------------------------------------------------------------------- 1 | # **2022-06-14 Meeting** 2 | 3 | Attendance (please add yourself) 4 | 5 | 6 | 7 | * **Josh Bressers (Anchore, TAC)** 8 | * Matt Rutkowski (IBM) 9 | * **CRob (Intel, TAC)** 10 | * **Dan Lorenc (Chainguard, TAC)** 11 | * Eric Tice (Wipro) 12 | * Phil Estes (AWS) 13 | * Jacques Chester (Shopify) 14 | * VM Brasseur (Wipro) 15 | * Jeff Borek (IBM) 16 | * **Luke Hinds (Red Hat, TAC)** - need to leave 30 mins early. 17 | * **Bob Callaway (Google, TAC)** 18 | * Georg Kunz (Ericsson) 19 | * **Aeva Black (Microsoft, TAC)** 20 | * **Abhishek Arya (Google, TAC) - **need to leave 30 min early 21 | * Michael Scovetta (Microsoft, Alpha-Omega) 22 | * Arnaud J Le Hors (IBM) 23 | * Alex Quesada (Wipro) 24 | * Jenn Bonner (LF, OpenSSF) 25 | * Stephen Chin (JFrog) 26 | * Steve Taylor (DeployHub) 27 | * Jory Burson (Linux Foundation) 28 | * Brian Behlendorf (Linux Foundation) 29 | * Jennifer Bly (OpenSSF) 30 | * Jamie Magee (Microsoft) 31 | * Luigi Gubello () 32 | 33 | ## Agenda 34 | 35 | 36 | 37 | * [Jenn Bonner] Suggestion to have a standing TAC agenda item for working group (and/or other project) updates. This would help establish a structure for the TAC to stay apprised of various WG activities at a regular cadence. Use the agenda time slot (5-10 mins) to rotate through all WGs and the special/specific projects like Sigstore, Alpha-Omega and GTI. Perhaps hit 1-2 per meeting. Could record “last update received” in the housekeeping table below. Make sure to give WG chairs and project leads sufficient heads-up when their update is expected to be provided during a TAC meeting. 38 | * (Arnaud’s proposal) Approx 20 TAC meetings per year, rotate so that WG’s/SIF’s/Projects report approximately 4 times per year. Have the report be made available in written format and submitted to TAC. Allows opportunity for TAC to ask questions, or WG to ask TAC for input, as needed. 39 | * Written template 40 | * Anything you want to bring up to the TAC (make sure this is added to the template) 41 | * _TBD_: text-based or slide-based template? 42 | * _TBD_: where to store & distribute reports? (mailing list, github, or a shared drive) 43 | * Cal invites set up to ping WG chairs as a reminder 44 | * There was consensus on the overall goal, cadence based on even distribution over the year, and having written artifacts that can be shared & archived 45 | * **ACTION**: OpenSSF Operations staff (Jenn/Jory) to assist with calendaring, scheduling the WG/SIF reports, and assisting with archiving/distributing the reports. 46 | * [OpenSSF Staff (Brian/Jenn/Jory)] Explore interest in hosting an OpenSSF Day at [Open Source Summit EU ](https://events.linuxfoundation.org/open-source-summit-europe/)in Dublin. Sept 13-16, 2022. 47 | * [brian] Target Date would be Sept 12th 48 | * Several members noted that travel remains off-limits to them by their employer and that they would not be able to attend. Others noted that it would be helpful to have an event in the EU for EU-based participants. 49 | * **ACTION**: Brian and team will pursue the opportunity further; looking to secure either booth space, working space, or other options that would promote more “project collaboration” and not be in competition with the SupplyChain SecurityCon. 50 | * Continue conversation on project criteria & governance 51 | * Brief review of June 3rd meeting 52 | * Update on action items 53 | * Strategy / scoping conversation 54 | * Revisit any parking lot items from 6/3? 55 | 56 | 57 | -------------------------------------------------------------------------------- /process/project-lifecycle-documents/minder_sandbox_stage.md: -------------------------------------------------------------------------------- 1 | ## Application for creating a new project at Sandbox stage 2 | 3 | ### List of project maintainers 4 | 5 | The project has [11 maintaners](https://github.com/stacklok/minder/blob/main/MAINTAINERS.md#maintainers-list) from 2 different companies: 6 | 7 | * Juan Antonio Osorio, Stacklok, @JAORMX 8 | * Jakub Hrozek, Stacklok, @jhrozek 9 | * Radoslav Dimitrov, Stacklok, @rdimitrov 10 | * Don Browne, Stacklok, @dmjb 11 | * Evan Anderson, Stacklok, @evankanderson 12 | * Eleftheria Stein-Kousathana, Stacklok, @eleftherias 13 | * Yolanda Robla Mota, Stacklok, @yrobla 14 | * Luke Hinds, Stacklok, @lukehinds 15 | * Michelangelo Mori, Stacklok, @blkt 16 | * Adolfo García Veytia, Stacklok, @puerco 17 | * Vyom Yadav, Canonical, @Vyom-Yadav 18 | 19 | ### Sponsor 20 | 21 | Most projects will report to an existing OpenSSF Working Group, although in some cases a project may report directly to the TAC. The project commits to providing quarterly updates on progress to the group they report to. 22 | 23 | * [Security Tooling WG](https://github.com/ossf/wg-security-tooling) 24 | 25 | ### Mission of the project 26 | 27 | The project must be aligned with the OpenSSF mission and either be a novel approach for existing areas, address an unfulfilled need, or be initial code needed for OpenSSF WG work. It is preferred that extensions of existing OpenSSF projects collaborate with the existing project rather than seek a new project. 28 | 29 | * Minder is a supply chain security platform to enable teams and organizations to define security policies in a consistent way across multiple supply chain assets. Minder helps project owners proactively manage their security posture by providing a set of checks and policies to minimize risk along the software supply chain, and attest their security practices to downstream consumers. 30 | 31 | Unlike other projects in this space, Minder supports multiple sets of organization policy across different supply chain assets, and allows users to define their own supply chain security rules using policy rules (Rego) and apply them flexibly to assets using selectors (CEL). 32 | 33 | Minder currently supports: repositories on GitHub, builds on GitHub Actions, and artifacts in DockerHub or GHCR.io. Support for GitLab repositories is in progress. 34 | 35 | 36 | ### IP policy and licensing due diligence 37 | 38 | When contributing an existing Project to the OpenSSF, the contribution must undergo license and IP due diligence by the Linux Foundation (LF). 39 | 40 | * Minder is currently licensed under the Apache 2.0 License, with a CLA for contributors. 41 | * We will initiate this process shortly. 42 | 43 | ### Project References 44 | 45 | The project should provide a list of existing resources with links to the repository, and if available, website, a roadmap, contributing guide, demos and walkthroughs, and any other material to showcase the existing breadth, maturity, and direction of the project. 46 | 47 | | Reference | URL | 48 | |---------------------|-----| 49 | | Repo | https://github.com/stacklok/minder | 50 | | Website | https://minder-docs.stacklok.dev | 51 | | Contributing guide | https://github.com/stacklok/minder/blob/main/CONTRIBUTING.md | 52 | | Security.md | https://github.com/stacklok/minder/blob/main/SECURITY.md | 53 | | Roadmap | https://minder-docs.stacklok.dev/about/roadmap | 54 | | Demos | https://www.youtube.com/watch?v=WniqzgNHjJQ (a little dated) | 55 | | Discord Community | https://discord.com/channels/1184987096302239844/1185287949240242258 | 56 | | Other | | 57 | -------------------------------------------------------------------------------- /minutes/2022-09-06.md: -------------------------------------------------------------------------------- 1 | # **2022-09-06 Meeting** 2 | 3 | Attendance (please add yourself): 4 | 5 | 6 | 7 | * Bob Callaway (Google, **TAC**) 8 | * CRob (Intel, **TAC**) 9 | * David A. Wheeler (Linux Foundation) 10 | * Georg Kunz (Ericsson) 11 | * Dan Lorenc (Chainguard, **TAC**) 12 | * Josh Bressers (Anchore, **TAC**) 13 | * VM Brasseur (Wipro) 14 | * Brian Behlendorf (OpenSSF/LF) 15 | * Aeva Black (Microsoft, **TAC**) 16 | * Mike Lieberman (Kusari) 17 | * Arnaud J Le Hors (IBM) 18 | * Brian Fox (Sonatype, GB) 19 | * Jay White (Microsoft) 20 | * Luke Hinds (Red Hat, **TAC**) 21 | * Matt Rutkowski (IBM) 22 | * Melba Lopez (IBM) 23 | * Abhishek Arya (Google, **TAC**) 24 | * Justin Hutchings (GitHub) 25 | * Phil Estes (AWS) 26 | * Jennifer Bly (OpenSSF) 27 | * Munawar Hafiz (OpenRefactory) 28 | * Anne Bertucio (Google) 29 | * Daniel Appelquist (Snyk) 30 | * Jacques Chester (Shopify) 31 | 32 | Note: All TAC members are in attendance! 33 | 34 | ## Agenda 35 | 36 | 37 | 38 | * (_10 min max_): Update from **Supply Chain Integrity WG** 39 | * **Presentation slides: **[https://docs.google.com/presentation/d/10NswyAlE4zvNh0VZXOBBPPN8LcniK8nTaAc9TwjIxfI/edit?usp=sharing](https://docs.google.com/presentation/d/10NswyAlE4zvNh0VZXOBBPPN8LcniK8nTaAc9TwjIxfI/edit?usp=sharing) 40 | * [https://github.com/buildsec/frsca](https://github.com/buildsec/frsca) (collaboration with CNCF’s supply chain security framework) 41 | * Brian: requested follow up with Michael re: github.com/buildsec and homing of FRSCA there vs. under openssf 42 | * (10 min max): Update from Vulnerability Disclosures WG 43 | * [https://github.com/ossf/wg-vulnerability-disclosures](https://github.com/ossf/wg-vulnerability-disclosures) 44 | * Hope to publish 1.0 version of “finder’s guide” by OpenSSF Day 45 | * Carryforward from last agenda: 46 | * Blog Post RE npm best practices - JBly 47 | * Announcements for/during OpenSSF Day (week of Sept. 13) - JBly 48 | * If there’s an announcement we didn’t list, please contact Jennifer Bly! 49 | * TAC involvement in and oversight of the Mobilization Plan - Brian B 50 | * Doc: [SIGs for the Mobilization Plan](https://docs.google.com/document/d/1OlHaO8N7tEvSGkxr_aKdfg4kRwyHyYrgnwmHNQYbq1I/edit#) 51 | * [[ Aeva notes a lack of any notes from what was a very engaged discussion, and writes the following from memory. ]] 52 | * Aeva suggested starting the discussion by comparing this proposal to the final state of PR112 (as opposed to the state of PR112 when the doc was first drafted). Brian gave a verbal summary. Notably, this “pot” is large and represents money not yet provided to the OpenSSF, but “committed” by 53 | * several funding organizations towards the Streams pending specific and sustainable actions by the OpenSSF. 54 | * CRob described the process WG-Vuln has followed with respect to a Stream, and how they are approaching making a request for funding from the pool 55 | * Josh Bressers expressed concern the TAC is meddling in projects. Many spoke up to point out that the GB wishes for the TAC to be more directly involved in technical decisions. Aeva pointed out that funding decisions are technically impactful. 56 | * Justin expressed concern that OpenSSF is 10mo out from a major influx of capital with few successes to show for it, suggested that we may be spread too thin. 57 | * Aeva proposed having a documented workflow for each Stream to follow as it approaches funding requests. Brian offered that he has one in mind, requested help with diagramming it. Aeva offered to work with Brian on workflow visualizations to show incentives and process 58 | * PR112 next steps? 59 | * Deferred to next meeting 60 | 61 | 62 | -------------------------------------------------------------------------------- /process/building-an-open-source-community.md: -------------------------------------------------------------------------------- 1 | # Building an Open Source Community 2 | 3 | In open source software the sustainability and growth of projects significantly depend on the diversity and engagement of their maintainer base. This document aims to underscore the importance of fostering a community with maintainers from multiple organizations, a prerequisite for joining the Open Source Security Foundation (OpenSSF). We will delve into the reasons why this diversity is critical, the benefits it brings, and provide actionable strategies to cultivate such a community. 4 | 5 | 6 | ## Importance of Maintainers from Multiple Organizations 7 | 8 | The OpenSSF sandbox requirement, **Projects must have a minimum of two maintainers with different organization affiliations**, was adopted for the following reasons: 9 | 10 | 11 | ### Project resilience 12 | 13 | A project solely reliant on a single organization for maintenance is vulnerable to becoming neglected or abandoned if that organization shifts its priorities. Diverse maintainer affiliation ensures the project's continuity and resilience in the case of a single organization no longer contributing to a project. 14 | 15 | 16 | ### Including broad perspectives 17 | 18 | Maintainers from different organizations, especially those in different fields, bring a wealth of perspectives and experiences. 19 | 20 | 21 | ### Signaling commitment to the community 22 | 23 | A diverse maintainer base signals to the community that the project is not just relevant to the organization that maintains it. 24 | 25 | 26 | ## How to Get Started? 27 | 28 | You and your project might want to get involved in the open source community but you might not be sure how to start building your community, and look to eventually contribute that project to an open source foundation like the OpenSSF. Luckily there's well trodden paths for this. Here are some common practices that can help you get started: 29 | 30 | 31 | ### Engaging with OpenSSF 32 | 33 | There is no better way to start building a community than to reach out to existing communities and get involved. OpenSSF has a large number of Technical Initiatives (TIs) which you should consider contacting to advertise your project and interest. 34 | 35 | While OpenSSF is financially supported by member organizations participation in OpenSSF is free and open to everyone. 36 | 37 | Practically speaking you should consider the following actions: 38 | 39 | * Post on OpenSSF’s slack (Follow link from: [OpenSSF Get Involved](https://openssf.org/getinvolved/) to introduce yourself and your project 40 | * Attend some of the community teleconferences the Technical Initiatives regularly hold. Check the public calendar at [OpenSSF Get Involved](https://openssf.org/getinvolved/) for schedule and call-in information. 41 | * If you're not sure feel free to reach out to a member of the [TAC](https://github.com/ossf/tac) or an OpenSSF staff member 42 | 43 | You should try to identify the most relevant TIs. A good starting point is the [TAC README page](https://github.com/ossf/tac) where you can find the whole list of TIs with relevant pointers. If you're not sure, that's ok, feel free to attend, introduce yourself and don't hesitate to ask if this might be the right place to find people interested in your project. If you want to get a few minutes to present or demo your project during a call, you can simply go to the TI's meeting notes document and add an item to the next call's agenda along with your name. If it turns out that it's not possible to allocate time for your item that week, you'll be given a chance on a future call. 44 | 45 | TIs make an effort to be inclusive and welcome newcomers. Don't be shy, we don't bite. :-) 46 | -------------------------------------------------------------------------------- /dco.md: -------------------------------------------------------------------------------- 1 | # Developer Certificate of Origin (DCO) 2 | 3 | A [*Developer Certificate of Origin (DCO)*](https://developercertificate.org/) 4 | is an affirmation that the developer contributing the proposed changes 5 | has the necessary rights to submit those changes. 6 | A DCO provides some additional legal protections while being 7 | relatively easy to do. 8 | 9 | The [OpenSSF Charter](https://cdn.platform.linuxfoundation.org/agreements/openssf.pdf) 10 | section 5b requires DCOs. More specifically it says that 11 | "Technical Initiatives will require that all new inbound source 12 | code contributions must also be accompanied by a Developer Certificate 13 | of Origin (https://developercertificate.org) sign-off in the source 14 | code system that is submitted through a TAC-approved contribution 15 | process...". 16 | 17 | Adding a DCO is easy when you create a proposed change in git. 18 | If you use `git commit`, just use its `-s` option. If you're making commits 19 | by hand, just append `Signed-off-by: NAME ` to the commit message. 20 | Note that these are not cryptographic (aka digital) signatures, but 21 | instead a "sign off" saying that the commit complies with the 22 | [Developer Certificate of Origin (DCO)](https://developercertificate.org/). 23 | 24 | The TAC has chosen to implement this DCO requirement by automatically 25 | enforcing DCOs on inbound pull requests across its GitHub organization. 26 | This helps ensure that DCOs are really done. 27 | 28 | If you'd like to enforce DCOs on your non-OpenSSF project on GitHub, you can 29 | go to , 30 | click on "Add to GitHub" on the right, 31 | and then select the repo/org & approve it. 32 | This will add an integration with a GitHub app to enforce the check 33 | (you can see this in a repo under its settings 34 | Integrations / GitHub apps). 35 | If you want to learn more about this probot DCO checker (which is 36 | open source software), see: 37 | . 38 | You can also enable 39 | [GitHub's feature to require signoff of commits made through the web UI](https://github.blog/changelog/2022-06-08-admins-can-require-sign-off-on-web-based-commits/). 40 | 41 | 42 | The email address must be, at the time the commit was created, 43 | a valid email address that can be used to effectively contact 44 | the committer if it is needed. 45 | 46 | Please note that NAME does *not* need to be a legal name. 47 | As explained by [Mike Dolan](https://github.com/cncf/foundation/issues/383#issuecomment-1178254458): 48 | 49 | > The DCO is a representation by someone stating they have the right to contribute the code they have proposed for acceptance into a project. That representation is important for legal purposes and was the community-developed outcome after a $1 billion lawsuit by SCO against IBM. The representation is designed to prevent issues but also keep the burden on contributors low. It has proven very adaptable to other projects, is built into git itself (and now also GitHub), and is in use by thousands of projects to avoid more burdensome requirements to contribute (such as a CLA). 50 | > ... 51 | > The DCO requires the use of a real name that can be used to identify someone in case there is an issue about a contribution they made. A real name does not require a legal name, nor a birth name, nor any name that appears on an official ID (e.g. a passport). Your real name is the name you convey to people in the community for them to use to identify you as you. The key concern is that your identification is sufficient enough to contact you if an issue were to arise in the future about your contribution. Your real name should not be an anonymous id or false name that misrepresents who you are. 52 | -------------------------------------------------------------------------------- /minutes/2022-07-18.md: -------------------------------------------------------------------------------- 1 | # **2022-07-18 “Tiger Team” Meeting** 2 | 3 | [“Tiger Team” meeting focused on the governance discussions and the ask for resources] 4 | 5 | Attendance (please add yourself) 6 | 7 | 8 | 9 | * Brian Behlendorf (LF, OpenSSF) 10 | * Arnaud Le Hors (IBM) 11 | * Aeva Black (microsoft, **TAC**) 12 | * VM (Vicky) Brasseur (Wipro) 13 | * Eric Tice (Wipro) 14 | * Matt Rutkowski (IBM) 15 | * Jenn Bonner (LF, OpenSSF) 16 | * David A. Wheeler (Linux Foundation) 17 | * Jeff Borek (IBM) 18 | * Khahil White (Linux Foundation) 19 | * Bob Callaway (Google, **TAC** Chair) 20 | 21 | Agenda: 22 | 23 | 24 | 25 | * Review PR#112 26 | * Arnaud: we can tease apart asks for marketing and funding from overall governance approach 27 | * Aeva: we don’t have to be specific about the process for these asks 28 | * Review [Proposal for Funding Process](https://docs.google.com/document/u/0/d/12xkEN-8ZWkC21BvEZD1mzjCnGuarJYR32U5gvlh0wS4/edit) 29 | * Brian’s proposal above outlines a tactical structure to allocate funds under the TAC’s control. 30 | * Discussed clarification regarding the $500K outlined in the existing OpenSSF operational budget under TAC’s authority to allocate / delegated authority. TAC leadership not aware that the authority to allocate this funding had been delegated from GB to TAC. 31 | * Note that the budget re-forecast Brian proposed to the GB in late June increases this allocation from $500K to $2M. 32 | * Brian: CY Budget $ funds to be allocated by TAC 33 | * Items under “Technical Development” 34 | * Outsourced Software Development - (unclear how much $? Is left for FY 2022 to be allocated) 35 | * Hosting & Cloud Services - (unclear how much $? Is left for FY 2022 to be allocated) 36 | * Security Audits & Process - (unclear how much $? Is left for FY 2022 to be allocated) 37 | * Brian: The GB has a lot of really busy people, this is the level the GB wants to see. The GB doesn’t want to have to decide for each $50K here, etc. 38 | * Aeva: Here’s what I understand. “OpenSSF Staff is proposing to work closely with the TAC and GB subcommittees to empower the community-elected leadership to oversee the Governing Board's approved Technical Development funding pool, through a yet-to-be-defined process that supports the currently-under-review TAC Governance update.” 39 | * In future, TAC & staff can work together more closely to work out future proposals to the GB. 40 | * Should TAC members be part of the GB Budget subcommittee (currently they only meet quarterly)? Currently that subcommittee primarily focuses on ensuring that dollars are categorized correctly, & consult for operation for accounting. That’s different than what’s being proposed here, where the TAC is more focused on “what should be done” not “is it categorized correctly?” 41 | * Jenn: A process is needed by which the TAC and the technical community can provide input into the future year’s budget. If the budget is approved in November, then in the months preceding, the TAC needs to work with the technical community to determine what the expected budget needs might be, and include those requests in the budget that is proposed to the Board in November. 42 | * Brian: (**ACTION**) OpenSSF Staff will assist in determining and sharing out to this group - what funding has been spent across these categories, and if more funding is approved by the GB, what is remaining to be spent for the remainder of the year. 43 | * Bob: It’s clear that there is an approved budget by the GB, but it isn’t clear that the TAC has the authority to to spend X dollars out of that budget. Need to reset expectations of delegated fiscal authority. 44 | * Aeva: 45 | 46 | 47 | -------------------------------------------------------------------------------- /process/templates/PROJECT_NAME_graduation_stage.md: -------------------------------------------------------------------------------- 1 | ## Project graduation application 2 | 3 | ### Project has met all Incubating requirements 4 | * "link to Incubating PR if exists" 5 | 6 | ### List of project maintainers 7 | The project must have maintainers with a minimum of five different contributors from three different organizational affiliations. 8 | * "name, affiliation, GitHub ID" 9 | 10 | ### Mission of the project 11 | The project must be aligned with the OpenSSF mission and either be a novel approach for existing areas, address an unfulfilled need, or be code needed to deliver OpenSSF WG work. It is preferred that extensions of existing OpenSSF projects collaborate with the existing project rather than seek a new project. 12 | * "description of the project mission" 13 | 14 | ### Project adoption 15 | The project must be able to show adoption by multiple parties, which could be production deployments or substantial use by established open source communities, and demonstrate the value of that adoption to either the end users or the open source community. 16 | * "description of adoption" 17 | 18 | ### Release cadence 19 | The project must be able to show a consistent release cadence. 20 | * "link to releases documentation" 21 | 22 | ### Governance 23 | Projects must have documented project governance and be able to demonstrate that governance in action. 24 | * "link to governance documents" 25 | 26 | Have a defined and documented roadmap and annual goals for the project 27 | * "link to roadmap and goals" 28 | 29 | Project has met at least 4 times over a period of at least 2 months since becoming incubating 30 | * "link to meeting agenda" 31 | 32 | 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. 33 | * "link to policy for (or describe here) software development and release practices" 34 | 35 | Projects should harden their build systems in accordance with the SLSA Framework 36 | * "link to policy for (or describe here) hardened build system" 37 | 38 | ### Security audit 39 | When applicable, projects must have completed a security audit through a third party and addressed audit findings and recommendations. 40 | * "link to results of security audit" 41 | 42 | ### Security Baseline 43 | 44 | The project meets all applicable Security Baseline requirements: 45 | * [ ] [Security Baseline - Once Sandbox](https://github.com/ossf/tac/blob/main/process/security_baseline.md#security-baseline---once-sandbox) 46 | * [ ] [Security Baseline - To Become Incubating](https://github.com/ossf/tac/blob/main/process/security_baseline.md#security-baseline---to-become-incubating) 47 | * [ ] [Security Baseline - Once incubating](https://github.com/ossf/tac/blob/main/process/security_baseline.md#security-baseline---once-incubating) 48 | * [ ] [Security Baseline - To Become Graduated](https://github.com/ossf/tac/blob/main/process/security_baseline.md#security-baseline---to-become-graduated) 49 | 50 | ### Project References 51 | The project must provide a list of existing resources with links to the repository, website, a roadmap, contributing guide, demos and walkthroughs, and any other material to showcase the existing breadth, maturity, and direction of the project. 52 | 53 | Reference | URL | 54 | |-----------------------|-----| 55 | | Repo | | 56 | | Website | | 57 | | Contributing guide | | 58 | | Security.md | | 59 | | Roadmap | | 60 | | Demos | | 61 | | Best Practices Badge | | 62 | | Scorecard integration | | 63 | | Other | | 64 | -------------------------------------------------------------------------------- /minutes/2020-10-06.md: -------------------------------------------------------------------------------- 1 | # **2020-10-06 Meeting** 2 | 3 | ## Attendance 4 | 5 | * [Please add yourself] 6 | * David A. Wheeler, Linux Foundation 7 | * Dan Lorenc, Google 8 | * Michael Scovetta, Microsoft 9 | * Phil Estes, IBM 10 | * Kay Williams, Microsoft 11 | * Luke Hinds, Red Hat 12 | * Xavier Rene-Corail, GitHub 13 | * CRob, Red Hat 14 | * Jennifer Fernick, NCC Group 15 | * Dan Middleton, Intel 16 | * Maya Kaczorowski, GitHub 17 | * Rao Lakkakula, JPMorgan 18 | 19 | (Ryan Haning sends regrets) 20 | 21 | ## Agenda 22 | 23 | * 10/29 Press Release - Kay 24 | * Get Involved 25 | * Each WG and committee has a consistent ‘Description’ 26 | * Repository ‘About’ Description’ 27 | * Related issue: [https://github.com/ossf/tac/issues/16](https://github.com/ossf/tac/issues/16) 28 | * README.md first paragraph 29 | * Descriptions show “at the top” because they are pinned repositories 30 | * Description contains 31 | * 1-3 sentences 32 | * What, why, how (see [planning committee](https://github.com/ossf/gb-planning-committee)) 33 | * Want them by Thursday, October 8 34 | * Description replicated to these locations 35 | * openssf.org website - get involved page 36 | * press release WG and committee overview 37 | * Administrative 38 | * New meeting invite/calendar solution - Kay 39 | * Delay for next quarter? 40 | * Security Community GB Representative Update \ 41 | ([https://docs.google.com/forms/d/e/1FAIpQLSd61bqfR_siMDvWlCC4s3jKxaVAVbOIIrt9_EwDqZ23VPmMlQ/viewform?usp=sf_link](https://docs.google.com/forms/d/e/1FAIpQLSd61bqfR_siMDvWlCC4s3jKxaVAVbOIIrt9_EwDqZ23VPmMlQ/viewform?usp=sf_link)) 42 | * Town Hall Meeting - week of November 9 43 | * Update on consolidation of CII & OpenSSF initiatives (David Wheeler) 44 | * Discuss CII Best Practices badge “home” WG - [https://docs.google.com/presentation/d/1WMwlOecmZSekhZnX-HFsIfHGz5wu1etNYncs_k7jcBo/edit?usp=sharing](https://docs.google.com/presentation/d/1WMwlOecmZSekhZnX-HFsIfHGz5wu1etNYncs_k7jcBo/edit?usp=sharing) 45 | * Working Group Updates (please type them in here) 46 | * Vuln-coordination wg: 47 | * Decided upon 3 objectives to work on; will update readme file with new template and objectives 48 | * Got briefing on CSAF & MITRE standards current states around sharing vuln info (through CVE) and advisories (through CSAF [formerly CVRF]) 49 | * Will reach out to CERT/CC for briefing on [VINCE](https://www.sei.cmu.edu/news-events/news/article.cfm?assetid=641759) vuln coordination tool & open sourcing efforts 50 | * Best practices: 51 | * Organisation: CRob new lead, Xavier co-lead 52 | * Preparation of the release of the EdX course on secure code fundamentals 53 | * OWASP SKF (learning platform): 54 | * upcoming release of the new UI, 55 | * preparing the release of a public infra: this will need funding, 56 | * adding new sources of knowledge (GitHub CodeQL) 57 | * Review remaining PRs / Issues: [https://github.com/ossf/tac/issues](https://github.com/ossf/tac/issues/) 58 | * Propose closing [https://github.com/ossf/tac/issues/7](https://github.com/ossf/tac/issues/7) 59 | * Propose closing [https://github.com/ossf/tac/issues/26](https://github.com/ossf/tac/issues/26) 60 | * [https://github.com/ossf/tac/issues/18](https://github.com/ossf/tac/issues/18) Blocked on [https://github.com/ossf/wg-security-tooling/issues/9](https://github.com/ossf/wg-security-tooling/issues/9) 61 | * [https://github.com/ossf/tac/issues/14](https://github.com/ossf/tac/issues/14) depends on [https://github.com/ossf/tac/pull/27](https://github.com/ossf/tac/pull/27) -------------------------------------------------------------------------------- /TI-reports/2024/2024-Q4-VULN-WG.md: -------------------------------------------------------------------------------- 1 | # 2024 Q4 Vulnerability Disclosure WG 2 | 3 | 4 | ## Overview 5 | The OpenSSF Vulnerability Disclosures Working Group seeks to help improve the overall security of the open source software ecosystem by helping develop and advocate well-managed vulnerability reporting and communication. We serve open source maintainers and developers, assist security researchers, and help downstream open source software consumers. 6 | 7 | The Vulnerability Disclosure Working group is officially a [Graduated-level](https://github.com/ossf/tac/blob/main/process/working-group-lifecycle.md) working group within the OpenSSF > 8 | 9 | 10 | 11 | 12 | ### Key Resources 13 | - [Coordinated Vulnerability Disclosure (CVD) Guides](https://github.com/ossf/oss-vulnerability-guide) 14 | - [Tabletop Exercise Resources](https://github.com/ossf/wg-vulnerability-disclosures/tree/main/docs/TTX) 15 | - [Open Source Vulnerability (OSV) schema](https://github.com/ossf/osv-schema) 16 | - [OpenVEX schema & tools](https://github.com/ossf/OpenVEX) 17 | - [Guide for Open Source Projects to become a CNA](https://github.com/ossf/wg-vulnerability-disclosures/blob/main/docs/guides/becoming-a-cna-as-an-open-source-org-or-project.md) 18 | - [SIREN Mailing List](https://github.com/ossf/wg-vulnerability-disclosures/blob/main/docs/SIREN/siren-FAQ.md) 19 | 20 | ### Sub-groups 21 | - [OpenVEX SIG](https://github.com/ossf/OpenVEX) 22 | 23 | 24 | 25 | ### Leads 26 | - WG - Madison Oliver (Github) & CRob (OpenSSF) 27 | - OpenVEX - Puerco (Stacklock) 28 | - OSV - Oliver Chang (Google) 29 | 30 | ## Activity 31 | ### General Working Group Activities 32 | - Preparation for abstracts for 2025 VulnCon conference - https://www.first.org/conference/vulncon2025/cfp 33 | - Discussion on adoption of Advise software - https://github.com/ossf/wg-vulnerability-disclosures/issues/152 34 | - VEX discussions 35 | 36 | 37 | ### CVD Guides 38 | #### Purpose 39 | - Best practices guides focused on assorted OSS personas explaining how to have more effective coordinated vulnerability disclosure processes. 40 | #### Current Status 41 | - nothing at this time 42 | #### Up Next 43 | - Planning on creating CVD Guide for OSS Consumers document Q4/Q12025 44 | 45 | ### Tabletop Exercises 46 | #### Purpose 47 | - To share best practices on how to plan and run effective cybersecurity tabletop exercises and conducting mock disasters. 48 | #### Current Status 49 | - Ran our TTX at OSS-JP SOSS Community Day 50 | #### Up Next 51 | - 52 | 53 | ### OpenVEX 54 | #### Purpose 55 | - A group dedicated to the transparent sharing of vulnerability data through open formats, like VEX, so that participatants throughout the open source software supply chain have clear signals and better understanding of the impact of security vulnerabilities to the software and components they produce, depend upon, consumer, and deliver. 56 | #### Current Status 57 | - No updates at this time 58 | #### Up Next 59 | - 60 | 61 | ### OSV 62 | #### Purpose 63 | - The OSV schema provides a human and machine readable data format to describe vulnerabilities in a way that precisely maps to open source package versions or commit hashes. 64 | #### Current Status 65 | - No Updates at this time 66 | #### Up Next 67 | - 68 | 69 | 70 | 71 | ## Previous Updates 72 | [June 2024](https://docs.google.com/presentation/d/1hW_Zp46xBoCRsOUtNM8EUwTQpnDU9MssoE0JEqvkkZg/) 73 | [Mar 2024](https://docs.google.com/presentation/d/1uSVAdO0QN8KItM_0sYcwsoNiKytM1Sa0effEPL_fNaw) 74 | -------------------------------------------------------------------------------- /minutes/2020-09-22.md: -------------------------------------------------------------------------------- 1 | # **2020-09-22 Meeting** 2 | 3 | ## Attendance (PLEASE ADD YOURSELF): 4 | * Ryan Haning, Microsoft 5 | * David A. Wheeler, Linux Foundation 6 | * Dan Lorenc, Google 7 | * Luke Hinds (Red Hat) 8 | * Kay Williams, Microsoft 9 | * Dan Middleton, Intel 10 | * Lindsay Mays Gendreau, Linux Foundation 11 | * Phil Estes, IBM 12 | * Chris Ferris (IBM observing) 13 | 14 | ## Agenda 15 | 16 | * Role of TAC (vs. Governing Board, etc.) [dlorenc] 17 | * Goals? 18 | * Principles/Values? 19 | * Interaction with WGs? 20 | * from Mike Dolan: Any actual creation work should be in the Working Groups. The TAC is helpful for establishing and helping coordinate across Working Groups. The Governing Board shouldn’t really impact anything you’re all working on / building unless you want to say do something with a trademark program, request budget for something, or things that don’t involve technical collaboration. My general rule is if a new activity fits into the scope of an existing Working Group, it should be done there, and if not, the TAC is a good place to coordinate where it should go. See: [https://github.com/ossf/foundation/blob/main/Review%20Copy%20Only%20-%20Not%20for%20Execution_OpenSSF%20Participation%20Agreement%20and%20Charter%20(rev.%202020%2009%2011).pdf](https://github.com/ossf/foundation/blob/main/Review%20Copy%20Only%20-%20Not%20for%20Execution_OpenSSF%20Participation%20Agreement%20and%20Charter%20(rev.%202020%2009%2011).pdf) 21 | * Ryan will work out a summary of the various roles & post, perhaps via a chart 22 | * Governing Board TAC Rep - Dan Lorenc is official! 23 | * Security Community Individual Representative - [https://github.com/ossf/tac/issues/22](https://github.com/ossf/tac/issues/22) 24 | * Working Group Updates 25 | * WG leads invited to TAC meetings 26 | * Process for formalizing 27 | * WG Lifecycles: [https://github.com/ossf/tac/issues/13](https://github.com/ossf/tac/issues/13) 28 | * Readme.md updates 29 | * PR: [https://github.com/ossf/project-template/pull/1](https://github.com/ossf/project-template/pull/1) 30 | * WG summaries for 10/29 Press Release 31 | * 10/29 Planning Milestone (Press Release) Items 32 | * Announce GB Seats 33 | * TAC Representative - [https://github.com/ossf/gb-strategy-committee/issues/10](https://github.com/ossf/gb-strategy-committee/issues/10) 34 | * Security Community Individual Representative - [https://github.com/ossf/tac/issues/22](https://github.com/ossf/tac/issues/22) 35 | * Announce OpenSSF, CII, and LF Consolidation - [https://github.com/ossf/tac/issues/25](https://github.com/ossf/tac/issues/25) 36 | * edX course -> Best Practices WG (done) 37 | * Badge program -> Identifying Security Threats WG 38 | * Census, Survey -> Securing Critical Software WG 39 | * LF Security Projects (OpenSSH, OpenBSD, Linux kernel) -> Security Critical Software WG 40 | * “I think we’re all in agreement (in the TAC) at moving these in” 41 | * If something fits within an existing WG, TAC doesn’t need to approve it. 42 | * Funding issues will be discussed at GB separately. 43 | * Action: David Wheeler to propose each to the respective WG (completed 2020-09-22, including notification to the Best Practices WG about the proposed placement of the CII Best Practices badge) and each WG will decide and communicate back to the TAC. 44 | * Announce Technical Initiatives 45 | * Need name, short description (aligned with README.md) 46 | * Marketing/PR will help wordsmith short description 47 | * New ‘Get Involved’ experience 48 | * WGs help needed to create consistent names, descriptions, README.mds 49 | * Review remaining Open Issues: [https://github.com/ossf/tac/issues](https://github.com/ossf/tac/issues/13) -------------------------------------------------------------------------------- /process/wg-lifecycle-documents/Global_Cyber_Policy_WG_sandbox_stage.md: -------------------------------------------------------------------------------- 1 | ## Application for creating a new Working Group at Sandbox stage 2 | 3 | Global Cyber Policy Working Group 4 | 5 | ### List of interested individuals 6 | The WG must have a minimum of 3 interested contributors from two different organizations. 7 | * Arnaud Le Hors, IBM, [lehors](https://github.com/lehors) 8 | * CRob, OpenSSF-LF, [SecurityCRob](https://github.com/SecurityCRob) 9 | * Daniel Appelquist, Samsung, [Torgo](https://github.com/Torgo) 10 | * Georg Kunz, Ericsson, [gkunz](https://github.com/gkunz) 11 | * Christian "fukami" Horchert, OpenSSF-LF, [ ]( ) 12 | * Mirko Boehm, LF-Europe, [ ]( ) 13 | * Mike Bursell, CCC, [ ]( ) 14 | 15 | 16 | ### Mission of the Working Group 17 | The WG must be aligned with the OpenSSF mission and address an unfulfilled need. It is preferred that topics falling with the scope of existing OpenSSF WGs are addressed within the existing wG rather than seek a new WG. 18 | * To provide a forum for our members and the broader community to collaborate on Global Cybersecurity-related legislation, frameworks, and standards, this group will begin with a focus on the EU's CRA legislation, but in the future can expand into other related topics. 19 | * The First three SIGs that will be created will be: 20 | 1.) CRA-Awareness - focused on educational and training materials, research and events that help educate Manufacturers, Stewards, and open source maintainers on obligations, artifacts, and processes they must have in place to comply with the CRA. 21 | 2.) CRA-Community Standards - focused on converting applicable community specifications into internationally-recognized standards. 22 | 3.) CRA-Format, Tooling & Process - focused on data formats, tooling and processes that must be put into place to help Linux Foundation projects be compliant with the CRA. 23 | 24 | ### IP policy and licensing due diligence 25 | When contributing to OpenSSF any existing material for the new WG to work on, the contribution must undergo license and IP due diligence by the Linux Foundation (LF). 26 | * At this time, no new IP/licenses will be transfered to the Linux Foundation. At such time that software or specs are considered to be donated, they will perform the standard LF IP/license review. 27 | * All work products of these groups will be covered under a valid open source license, such as Apache 2.0, Creative Commons 4.0 Attribution International License CC-BY-4.0, or Community Specificiation 1.0 28 | 29 | ### TAC Sponsor 30 | TAC sponsor agrees to attend WG meetings regularly, although they are not required to have a formal role in WG. 31 | * Daniel Appelquist, Samsung, [Torgo](https://github.com/Torgo) 32 | 33 | 34 | ### Working Group References 35 | The WG should provide a list of existing resources with links to the repository, and if available, website and any other material to showcase the existing breadth, maturity, and direction of the WG. 36 | 37 | | Reference | URL | 38 | |---------------------|-----| 39 | | Repo | https://github.com/ossf/wg-globalcyberpolicy/ | 40 | | Website | n/a at this time | 41 | | Security.md | will use OSSF template once repo is created | 42 | | Mailing List | https://lists.openssf.org/g/openssf-wg-globalcyberpolicy | 43 | | GDrive | https://drive.google.com/drive/folders/1FfWXtQTQe1XAOX0R_QaNamyGgKGLRaKW | 44 | | Slack Channel | #wg-globalcyberpolicy | 45 | | SIG mailing lists | CRA Readiness+Awareness - https://lists.openssf.org/g/openssf-sig-cra-readiness | 46 | | SIG mailing lists | CRA Tooling+Process+Formats - https://lists.openssf.org/g/openssf-sig-cra-tooling | 47 | | SIG mailing lists | CRA Spec Standardization - https://lists.openssf.org/g/openssf-sig-cra-standards | 48 | -------------------------------------------------------------------------------- /process/wg-lifecycle-documents/WG_DEI_incubating_stage.md: -------------------------------------------------------------------------------- 1 | ## Working Group incubation application 2 | 3 | ### List WG Chair(s) and or Vice Chair 4 | The WG must have a minimum of 1 Chair 5 | * "name, affiliation, GitHub ID" 6 | #### Co-Chairs 7 | 1. [Marcela Melara](https://github.com/marcelamelara) (Intel) 8 | 2. [Yesenia Yser](https://github.com/Cyber-JiuJiteria) (Microsoft) 9 | 3. [Jay White](https://github.com/camaleon2016) (Microsoft) 10 | 11 | ### Working Group (WG) has met all Sandbox requirement 12 | * "link to sandbox PR if exists" 13 | 14 | #### Mission of the Working Group 15 | The WG must be aligned with the OpenSSF mission and address an unfulfilled need. It is preferred that topics falling with the scope of existing OpenSSF WGs are addressed within the existing wG rather than seek a new WG. 16 | * "description of the WG mission" 17 | * https://github.com/ossf/wg-bear/blob/main/CHARTER.md#1-mission-and-scope-of-the-technical-initiative 18 | 19 | #### IP policy and licensing due diligence 20 | When contributing to OpenSSF any existing material for the new WG to work on, the contribution must undergo license and IP due diligence by the Linux Foundation (LF). 21 | * "yes / no / not applicable. If yes, provide a link to the corresponding GitHub issue." 22 | * Not applicable. 23 | 24 | #### TAC Sponsor 25 | TAC sponsor agrees to attend WG meetings regularly, although they are not required to have a formal role in WG. 26 | * "name of TAC sponsor" 27 | * [Marcela Melara](https://github.com/marcelamelara) (Intel) 28 | 29 | ### List of regular contributors 30 | The WG must have a minimum of 5 contributors from at least 3 different organizations attending regularly. 31 | * "name, affiliation, GitHub ID" 32 | 33 | 1. [Ijeoma Onwuka](https://github.com/Ijeoma-Onwuka) (Scandium) 34 | 2. [Prince Oforh Asiedu](https://github.com/PrinceAsiedu)(Contributor) 35 | 3. [John Kjell](https://github.com/jkjell) (TestifySec) 36 | 4. [Crob](https://github.com/SecurityCRob) (The Linux Foundation) 37 | 5. [Parris Lucas](https://github.com/GrooveCS) (Open Studio Labs) 38 | 39 | ### Mission of the Working Group 40 | The WG must have a charter or mission statement for review by TAC 41 | * Link to the WG charter or mission statement defining its goals. 42 | * https://github.com/ossf/wg-bear/blob/main/CHARTER.md 43 | 44 | ### Governance 45 | WG must have documented, initial group governance. 46 | * Link to initial group governance doc 47 | * In Charter https://github.com/ossf/wg-bear/blob/main/CHARTER.md 48 | 49 | WG must have met publicly at least 5 times in the last quarter since becoming Sandbox 50 | * Link to public meeting notes (or ideally recordings) 51 | * https://www.youtube.com/watch?v=KcynI7BPYEw&list=PLVl2hFL_zAh-5YC3PnIbc14KDEYsgLYBs 52 | 53 | WG must have defined Contributor Guide 54 | * "link to contributor guide" 55 | * https://github.com/ossf/wg-bear/blob/main/CONTRIBUTING.md 56 | 57 | Reference | URL | 58 | |-----------------------|-----| 59 | | Repo | https://github.com/ossf/wg-bear | 60 | | Meeting Agenda | https://docs.google.com/document/d/17j8uN_radgNcY4G8u1Ua8FN__lUL4TeUN0gb-D2TrZ4/edit?tab=t.0#heading=h.9m0zi4b0wnne | 61 | | OSSF Calendar Entry | https://zoom-lfx.platform.linuxfoundation.org/meeting/98853031629?password=a356aa22-ab31-4e2e-a8a0-9ecb45af84bd | 62 | | Website | https://github.com/ossf/wg-bear | 63 | | Contributing guide | https://github.com/ossf/wg-bear/blob/main/CONTRIBUTING.md | 64 | | Security.md | https://github.com/ossf/wg-bear/blob/main/SECURITY.md | 65 | | code-of-conduct.md | https://github.com/ossf/wg-bear/blob/main/code-of-conduct.md | 66 | | roadmap.md | https://github.com/ossf/wg-bear/blob/main/Roadmap.md | 67 | | Other | | 68 | -------------------------------------------------------------------------------- /process/project-lifecycle-documents/SBOMit_sandbox_stage.md: -------------------------------------------------------------------------------- 1 | ## Application for creating a new project at Sandbox stage 2 | 3 | ### List of project maintainers 4 | 5 | * Justin Cappos, NYU, justincappos 6 | * Ian Dunbar-Hall, Lockheed Martin, idunbarh 7 | * Cole Kennedy, TestifySec, colek42 8 | * Marina Moore, NYU, mnm678 9 | * Trishank Kuppusamy, Datadog, trishankatdatadog 10 | 11 | ### Mission of the project 12 | 13 | SBOMit's goal is to provide SBOMs to end users with minimal effort that provide cryptographic validation of the steps performed in the software 14 | supply chain. This differs from other SBOM efforts in that the data in the SBOM is validated cryptographically using [in-toto](in-toto.io) 15 | link metadata and layouts, which provides a strong threat model while providing a robust set of guarantees about the SBOM's accuracy. 16 | 17 | Specific goals include: 18 | 19 | * Maintain compatibility with existing SBOM formats (could generate existing SBOMs), and ideally operable with SPDX, CycloneDX, and similar efforts 20 | * Define use cases and outcomes (end user ux) including machine readable 21 | * Emphasize usability / on-boarding for users. Acknowledged as critical by many stakeholders. 22 | * Cryptographic verification that exactly the steps in the verifiable SBOM were performed 23 | * Threat model of an attacker that can compromise any part of the software supply chain (e.g., Section 2.2 of https://www.usenix.org/system/files/sec19-torres-arias.pdf ) 24 | * Define which pieces of the Verifiable SBOM are cryptographically verifiable 25 | * Be applicable anywhere (not just cloud native)! 26 | * Utilize in-toto delivered bundle for distribution of a single file 27 | * Optionally enabling the capture of reasonable information about the runtime environment of the supply chain steps including pre-build, post-build, and all other portions 28 | * Optionally enabling the capture of the output of scanning tools, etc. that may make inferences. Note that these may be based upon incomplete and / or incorrect information, but surfacing this information may be useful. 29 | * Provide a clear specification that other groups can implement for Verifiable SBOMs 30 | * Provide exemplars of the tooling needed to generate and process Verifiable SBOMs 31 | * Enable users of Verifiable SBOMs to be able to understand clearly what steps were performed, possibly via plug-ins through things like Testify, SLSA, FRSCA, etc. 32 | * Multi-language tooling 33 | 34 | Non-Goals: 35 | * Picking a winning SBOM format (SPDX, CycloneDX, etc.) 36 | * Recursing into components like the packages inside of a container image when the build process does not otherwise do so. 37 | * Knowing that an individual action is actually a good security practice 38 | * Assertions about the quality of the implementation of the tool / security processes describing how the SBOM or artifact came to exist 39 | 40 | 41 | 42 | 43 | ### IP policy and licensing due diligence 44 | 45 | When contributing an existing Project to the OpenSSF, the contribution must undergo license and IP due diligence by the Linux Foundation (LF). 46 | 47 | * See [#191](https://github.com/ossf/tac/issues/191) for LF IP Review 48 | * Our reference implementations will use the Apache 2.0 license 49 | * Our specification uses [Community Specification License 1.0](https://github.com/SBOMit/specification/blob/main/LICENSE.md) 50 | * Our website uses [Creative Commons Attribution 4.0 International](https://github.com/SBOMit/website/blob/main/LICENSE.md) 51 | 52 | ### Project References 53 | 54 | | Reference | URL | 55 | |--------------------|------| 56 | | Repo | https://github.com/SBOMit | 57 | | Website | https://sbomit.dev/ | 58 | | Contributing guide | TODO | 59 | | Roadmap | TODO | 60 | | Demos | N/A | 61 | -------------------------------------------------------------------------------- /minutes/2022-01-25.md: -------------------------------------------------------------------------------- 1 | # **2022-01-25 Meeting** 2 | 3 | ## Attendance (please add yourself): 4 | 5 | * Phil Estes (AWS) 6 | * David A. Wheeler (Linux Foundation) 7 | * Jenn Bonner (OpenSSF, LF) 8 | * Steve Chin (JFrog) 9 | * Sudhindra Rao (JFrog) 10 | * Dan Lorenc (Chainguard) 11 | * Justin Hutchings (GitHub) 12 | * Arnaud J Le Hors (IBM) 13 | * Michael Winser (Google) 14 | * Jacques Chester (Shopify) 15 | * Luke Hinds (Red Hat) 16 | * Ryan Haning (Microsoft) 17 | * Aeva Black (Microsoft, OSI) 18 | * Brian Behlendorf (OpenSSF, LF) 19 | * Matt Rutkowski (IBM) 20 | 21 | ## Agenda: 22 | 23 | * Election Update 24 | * Contact [operations@openssf.org](mailto:operations@openssf.org) with any issues regarding email ballot. 25 | * TAC Candidates: [https://github.com/ossf/tac/blob/main/elections/OpenSSF-TAC-Nominations-2022.pdf](https://github.com/ossf/tac/blob/main/elections/OpenSSF-TAC-Nominations-2022.pdf) 26 | * SCIR Candidates: [https://github.com/ossf/tac/blob/main/elections/OpenSSF-SCIR-Nominations-2022.pdf](https://github.com/ossf/tac/blob/main/elections/OpenSSF-SCIR-Nominations-2022.pdf) 27 | * Our thanks to everyone who is willing to serve! This is extremely competitive, we have some great candidates standing to serve for only a few positions. 28 | * Pyrsia project update (Stephen Chin) - https://pyrsia.io 29 | * Biweekly committee meeting, biweekly architecture meeting, monthly outreach meeting 30 | * See: [https://github.com/pyrsia](https://github.com/pyrsia) 31 | * Goal: creating a system that secures open-source builds and distribution. 32 | * Pyrsia: “Zero-Trust Decentralized Package Network” 33 | * On OpenSSF Slack - #pyrsia-bootstrap 34 | * Dev Tools Working Group 35 | * Ryan Ware has moved to a new company and is no longer able to be the lead of the WG. 36 | * Should we keep this group active or integrate with another WG, etc? 37 | * Wheeler: There’s a fuzzing WG within tools WG that’s pretty active (if we remove tools WG, need to move fuzzing WG & its other work to a new home like the Best Practices or Supply Chain) 38 | * [lhinds] Consider a sandbox stage (and tiers) for projects (what would the criteria look like)? 39 | * CNCF & CD Foundation & Confidential Computing Consortium have tiers 40 | * [governance/project-progression-policy.md at master · confidential-computing/governance (github.com)](https://github.com/confidential-computing/governance/blob/master/project-progression-policy.md) 41 | * Need to identify “what’s the end state” - what are the advantages to all parties? 42 | * Most important task of TAC is to identify these, change over time. 43 | * Don’t want OpenSSF to be dumping ground or heavy-handed, clearly define. 44 | * So next meeting: flush these details out 45 | * Pyrsia would like this formalized too!! 46 | * Working Group / TAC interaction 47 | * Have every WG present, let’s get better oversight 48 | * Aeva: not necessarily “every WG at every TAC meeting”. My proposal is that the TAC have quarterly (or semesterly, as time permits) check-ins with each WG and Project, with the expectation of going into technical depth and creating time for the WG/Project to raise blocking concerns & requests for help 49 | * Aeva: I also suggest having a “community town hall” with representation from every WG/Project” 50 | * [https://github.com/ossf/tac/blob/main/working-group-lifecycle.md](https://github.com/ossf/tac/blob/main/working-group-lifecycle.md) 51 | * Confidential Computing has a TAC mentor for each WG. We should have TAC sponsor for each WG, designated POC who’s there to help, WG leads don’t HAVE to go to sponsor but that’s someone whose job is to help. 52 | * [governance/project-mentors.md at master · confidential-computing/governance (github.com)](https://github.com/confidential-computing/governance/blob/master/project-mentors.md) -------------------------------------------------------------------------------- /process/project-lifecycle-documents/repository_service_for_tuf_incubation_stage.md: -------------------------------------------------------------------------------- 1 | ## Project incubation application 2 | 3 | ### Project has met all Sandbox requirement 4 | * https://github.com/ossf/tac/pull/137 5 | 6 | ### List of project maintainers 7 | 8 | * Kairo Araujo, TestifySec, kairoaraujo 9 | * Radoslav Dimitrov, Stacklok, rdimitrov 10 | * Martin Vrachev, VMware by Broadcom, mvrachev 11 | * Lukas Pühringer, NYU, lukpueh 12 | * Konstantinos Papadopoulos, Channable, KAUTH 13 | 14 | ### Mission of the project 15 | The Repository Service for TUF's mission is to make it easier for repositories to integrate the features of [The Update Framework (TUF)] without requiring TUF expertise or deep changes to the repository service implementation. 16 | 17 | The project provides repository signing functionality with a simple REST API for integration into any repository offering. The system's architecture enables scalability for high-traffic repositories. 18 | 19 | The project was born out of experience developing changes for Warehouse (PyPI) to deliver [PEP 458] and, for the initial roadmap, focuses on providing PEP 458-like repository signing functionality. In future, the Repository Service for TUF will develop to support other TUF architecture patterns including [PEP 480]-like developer signing and more. 20 | 21 | [The Update Framework (TUF)]: https://theupdateframework.io 22 | [PEP 458]: https://peps.python.org/pep-0458/ 23 | [PEP 480]: https://peps.python.org/pep-0480/ 24 | 25 | 26 | ### Project adoption 27 | The project has early adoption (beta version) by the following organizations: 28 | * [PyPI](https://github.com/pypi/warehouse/pulls?q=is%3Apr+PEP458+is%3Aclosed) 29 | * [RubyGems](https://github.com/rubygems/rubygems.org/pull/4167) 30 | 31 | ### Governance 32 | We have a monthly meeting on the first Wednesday of the month. 33 | * The meeting agenda is available [here](https://repository-service-tuf.readthedocs.io/en/stable/devel/contributing.html#meetings) 34 | 35 | Governance 36 | * RSTUF TAC (https://repository-service-tuf.readthedocs.io/en/stable/devel/tac.html) 37 | 38 | Contributor Guide 39 | * https://repository-service-tuf.readthedocs.io/en/stable/devel/contributing.html 40 | 41 | Project has attained an OpenSSF Best Practice Badge at "passing" level 42 | * https://www.bestpractices.dev/en/projects/6587 43 | 44 | Project is integrated into the OpenSSF Scorecard 45 | * https://scorecard.dev/viewer/?uri=github.com/repository-service-tuf/repository-service-tuf-cli 46 | * https://scorecard.dev/viewer/?uri=github.com/repository-service-tuf/repository-service-tuf-worker 47 | * https://scorecard.dev/viewer/?uri=github.com/repository-service-tuf/repository-service-tuf-api 48 | 49 | ### IP policy and licensing due diligence 50 | * This has been completed as per https://github.com/ossf/tac/issues/136. 51 | 52 | ### Project References 53 | The project should provide a list of existing resources with links to the repository, website, a roadmap, contributing guide, demos and walkthroughs, and any other material to showcase the existing breadth, maturity, and direction of the project. 54 | 55 | Reference | URL | 56 | |-----------------------|-----| 57 | | Repo | github.com/repository-service-tuf | 58 | | Meeting Agenda | https://hackmd.io/sSB1pwpDR5Seag0YB-vYMA | 59 | | OSSF Calendar Entry | https://zoom-lfx.platform.linuxfoundation.org/meetings/repository-service-tuf | 60 | | Website | https://repository-service-tuf.readthedocs.io | 61 | | Contributing guide | https://repository-service-tuf.readthedocs.io/en/stable/devel/contributing.html | 62 | | Roadmap | https://repository-service-tuf.readthedocs.io/en/stable/devel/roadmap.html | 63 | | Demos | https://repository-service-tuf.readthedocs.io/en/stable/index.html#mentions | 64 | 65 | --------------------------------------------------------------------------------