diff --git a/Minutes/2022 Meeting Notes.md b/Minutes/2022 Meeting Notes.md new file mode 100644 index 0000000..c3cfcbb --- /dev/null +++ b/Minutes/2022 Meeting Notes.md @@ -0,0 +1,3371 @@ + +

VulnDisc SIG - OSS-SIRT

+ + +Open Source Software - Security Incident Response Team SIG + +“There will be a lot of human subtleties.” Francis Perron, Aug 2022 + + +_Antitrust Policy Notice_: Linux Foundation meetings involve participation by industry competitors, and it is the intention of the Linux Foundation to conduct all of its activities in accordance with applicable antitrust and competition laws. It is therefore extremely important that attendees adhere to meeting agendas, and be aware of, and not participate in, any activities that are prohibited under applicable US state, federal or foreign antitrust and competition laws. Examples of types of actions that are prohibited at Linux Foundation meetings and in connection with Linux Foundation activities are described in the Linux Foundation Antitrust Policy available at [http://www.linuxfoundation.org/antitrust-policy](http://www.linuxfoundation.org/antitrust-policy). If you have questions about these matters, please contact your company counsel, or if you are a member of the Linux Foundation, feel free to contact Andrew Updegrove of the firm of Gesmer Updegrove LLP, which provides legal counsel to the Linux Foundation. + +

Administrativia

+ + + + +* Meeting + * times: The OSS-SIRT SIG meets weekly on Tuesdays at [9am EST](https://everytimezone.com/convert/eastern_time_mi/9am) on [ZOOM](https://zoom.us/j/94621219538?pwd=dGl2dko0R01kRXFmVlZYWVFwM1FSQT09)! + * Recordings: [https://www.youtube.com/c/OpenSSF/videos](https://www.youtube.com/c/OpenSSF/videos) +* SIG + * Repo: [https://github.com/ossf/SIRT](https://github.com/ossf/SIRT) + * Mailing List: [https://lists.openssf.org/g/openssf-sig-osssirt/topics](https://lists.openssf.org/g/openssf-sig-osssirt/topics) +* Plan for the SIG + * [Google Doc of draft](https://docs.google.com/document/d/1uQcw9Ymy8LEYeXSnEiZduHLYO68h4OUaahB2crGDuVE/) + * Final (TBD) + * Sections + * [Section 1 Notes](https://docs.google.com/document/d/1FNJYG_PqNsb3jsr8wR0AWtFwGBTsLDzrM2ENc3MNCkU/edit?usp=sharing) + * [Section 2 Notes](https://docs.google.com/document/d/1cnGok8fLHE9vmpzx7lgBfD5pQ4DX60vrOPbSjVb-uxY/edit#), more [notes](https://docs.google.com/document/d/11TlK0J2dvDSKxYj1iGOORw9DCxU0kPRuG5i2Ddlp7EQ/edit?usp=sharing) + * Section 3 Notes +* Supporting tools: + * [optional] [Jamboard](https://jamboard.google.com/d/1WlARTXsQZahhvgARnRl_RvP7vbugTb6a3GCZffVaPoA/viewer) + +

Meetings Notes

+ + +

20221213

+ + +

Attendees

+ + +(please **Mark your name is black if you are here,** or add-row name/email/affiliation if joining) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name + Email + Affiliation + Pronouns +
CRob + CRob@intel.com + Intel/OSSF + he/him +
Emily Fox + themoxiefoxatwork@gmail.com + Apple, CNCF TOC + she/her +
Randall T. Vasquez + randall@icloud.com + Gentoo + he/him +
Avishay Balter + avbalter@microsoft.com + Microsoft + he/him +
Jill Moné-Corallo + thejillboss@github.com + GitHub + she/her +
+ + +

Agenda

+ + + + +* Welcome new friends +* Who wants to help out and scribe for us today? +* Collect Opens +* This is our last SIG or section call for 2022. 2023 SIG Meeting [Notes](https://docs.google.com/document/d/1sqj3VWKb2ohcOqk9IlD_Ms-2ics6a02dUiDHB0Z1kxY/edit#heading=h.9m0zi4b0wnne) will be in new doc +* Plan with TAC for review + * YOU can provide feedback via Issue [32](https://github.com/ossf/SIRT/issues/32) +* oss-sec & distros lists rehousing proposal - TAC Issue [132](https://github.com/ossf/tac/issues/132) +* Requirment for Tooling - [https://github.com/ossf/SIRT/issues/30](https://github.com/ossf/SIRT/issues/30) + +

Opens (pending)

+ + + + +* + +

Meeting Notes

+ + + + +* Team Activities + * Team 1 - Problem Space (Randall) + * + * Team2 - ID core services (Art) + * + * Team 3 - Execution (Francis) + +

Nov 29. 2022

+ + +

Attendees

+ + +(please **Mark your name is black if you are here,** or add-row name/email/affiliation if joining) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name + Email + Affiliation + Pronouns +
CRob + CRob@intel.com + Intel/OSSF + he/him +
Jennifer Mitchell + jenn.mitchell@tidelift.com + Tidelift + +
Emily Fox + themoxiefoxatwork@gmail.com + Apple, CNCF TOC + she/her +
Randall T. Vasquez + randall@icloud.com + Gentoo + he/him +
Art Manion + zmanion@protonmail.com + ANALYGENCE + +
+ + +

Agenda

+ + + + +* Welcome new friends +* Who wants to help out and scribe for us today? +* Collect Opens +* SIG & WG comments to plan due by 2Dec2022 so we can then share with TAC - [https://github.com/ossf/SIRT/issues/32](https://github.com/ossf/SIRT/issues/32) + * Engagment [https://github.com/ossf/SIRT/issues/32](https://github.com/ossf/SIRT/issues/32)Model + * 1.4 revolve around Outreach of the Developer communities. However, 2.2 also reloves around Engagement. Seems to be overlap between the two. + * Maintainer summit in january’23 will be doing a survey of ~40 maintainers. There are several security/ossf questions in it that we can benefit from. Need to make task late jan/early feb to assemble and review data + +

Opens (pending)

+ + + + +* + +

Meeting Notes

+ + + + +* + +

Nov 15, 2022

+ + +

Attendees

+ + +(please **Mark your name is black if you are here,** or add-row name/email/affiliation if joining) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name + Email + Affiliation + Pronouns +
CRob + CRob@intel.com + Intel/OSSF + he/him +
Jennifer Mitchell + jenn.mitchell@tidelift.com + Tidelift + +
Emily Fox + themoxiefoxatwork@gmail.com + Apple, CNCF TOC + she/her +
Randall T. Vasquez + randall@icloud.com + Gentoo + he/him +
Art Manion + zmanion@protonmail.com + ANALYGENCE + +
Sandipan Roy + sandipan@redhat.com + Red Hat + he/him +
+ + +

Agenda

+ + + + +* Welcome new friends +* Who wants to help out and scribe for us today? +* Collect Opens +* SIG/WG Business + * Read-out on sub-team activities + * Stream 1 + * Finalizing our plan. Check PR for progress. + * Please review and give feedback on [issue #1](https://github.com/ossf/SIRT/issues/1) + * Emily - add refining personas to section 1 to hone in on who our audiences are. This will help us craft services to address those viewpoints + * Emily - include in 2.2 the reference to the personas and outreach in 1.4/1.3 + * Group- craft mission/vision statement +* Issue 1 +* Section 2.2 - add in persona info from 1.3 to modify as a Milestone: https://github.com/ossf/wg-vulnerability-disclosures/blob/main/docs/personas.md +* Section 2 will include a proposed minimum set of services aligned around +* Early notification system (SIREN Security Incident Response Early Notification) around vulnerabilities in open source. + * Emily has an idea around this. Using a standard vulnerability and suspected vuln system, we can consistently express relevant information about upcoming but embargoed vulns to provide subscribers (FREE) a heads up that SOMETHING is coming. Subscriptions however are usually mailing list based, providing this as an RSS feed or an API call in addition to a static site. Recommend looking at GSD as an initial tool to evaluate as it has some structure to support providing useful information around both suspected and confirmed to include additional useful and relevant information. +* If/when we want to try to estimate distribution/rate of cases: [https://apps.dtic.mil/sti/pdfs/AD1158793.pdf](https://apps.dtic.mil/sti/pdfs/AD1158793.pdf) + +

Opens (pending)

+ + + + +* Mission Statement: https://github.com/ossf/SIRT/issues/21 + +

Meeting Notes

+ + + + +* Team Activities + * Team 1 - Problem Space (Randall) + * Randall explore the FIRST/PSIRT docs + * https://www.first.org/standards/frameworks/psirts/psirt_services_framework_v1.1 + * https://www.first.org/standards/frameworks/csirts/csirt_services_framework_v2.1#7-Service-Area-Vulnerability-Management + * https://www.first.org/standards/frameworks/csirts/csirt_services_framework_v2.1#6-5-Service-Information-security-incident-coordination + * Team2 - ID core services (Art) + * + * Team 3 - Execution (Francis) + * Waiting on more final updates for sec.1 & 2 to finish execution + +

[Temp] Section 3

+ + +Agenda: + + + +* Crob: add awareness on the discussion to the slack channel +* Crob: create a PR for hiring someone +* Services + * assume we’ll have Triage, Comms… rest isn’t clear yet. +* Comms ideas + * Keybase, Signal, Slack … we should document them. + +AIs + + + +1. Crob: Ask about cloud credits to the Board + * talk to randall@icloud.com about what stack we need, and size… sounds like AWS is adapted to Vince +2. randall@icloud.com: Check to launch/install for Vince + * [https://github.com/ossf/SIRT/discussions/8](https://github.com/ossf/SIRT/discussions/8) + * → needs to be packaged, y-ay. + * “Packaging is my middle-name” + * make a repo / fork of it too +3. randall@icloud.com: add testifysec[.]com to the discussion: [https://github.com/ossf/SIRT/discussions/8](https://github.com/ossf/SIRT/discussions/8) +4. Francis Perron: Check Vince for what we would like to be added, assuming some things like “we’ll do triage” and so on +5. Francis Perron: Explore comms as well as the stacks in a Discussion + +

Nov 01, 2022

+ + +

Attendees

+ + +(please **Mark your name is black if you are here,** or add-row name/email/affiliation if joining) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name + Email + Affiliation + Pronouns +
CRob + CRob@intel.com + Intel/OSSF + he/him +
Jennifer Mitchell + jenn.mitchell@tidelift.com + Tidelift + +
Randall T. Vasquez + randall@icloud.com + Gentoo + he/him +
Avishay Balter + avbalter@microsoft.como + Microsoft + he/him +
+ + +

Agenda

+ + + + +* Welcome new friends +* Who wants to help out and scribe for us today? +* Collect Opens +* SIG/WG Business + * Read on sub-team activities +* Ideas on how to utilize this call going forward as we begin to move into acting on the plan + * Randall - use time for updates and things that need collabed on within the SIG. A show & tell + * Francis - use the call for no agenda, assemble to share presentations and proposals for the whole SIG. Move to monthly + * Avishay +1 +* + +

Opens (pending)

+ + + + +* + +

Meeting Notes

+ + + + +* Team Activities + * Team 1 - Problem Space (Randall) + * + * Team2 - ID core services (Art) + * + * Team 3 - Execution (Francis) + * + +

Oct 18, 2022

+ + +

Attendees

+ + +(please **Mark your name is black if you are here,** or add-row name/email/affiliation if joining) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name + Email + Affiliation + Pronouns +
CRob + CRob@intel.com + Intel/OSSF + he/him +
Francis Perron + francisp@google.com + Google LLC + +
Randall T. Vasquez + randall@icloud.com + Gentoo + he/him +
Art Manion + zmanion@protonmail.com + ANALYGENCE + +
Jill Moné-Corallo + thejillboss@github.com + GitHub + she/her +
+ + +

Agenda

+ + + + +* Welcome new friends +* Who wants to help out and scribe for us today? +* Collect Opens +* SIG/WG Business + * Read on sub-team activities +* Review and discuss VOTE - OSS-SIRT staffing mode[ Issue #11](https://github.com/ossf/SIRT/issues/11) +* **We’d like to have plan revisions completed by 01Dec2022 ** +* + +

Opens (pending)

+ + + + +* Slack (re)invitation for zmanion@protonmail.com please? +* + +

Meeting Notes

+ + + + +* Team Activities + * Team 1 - Problem Space (Randall) + * Finalize plan + * First PR merged in, but needs some formatting and typo fixes applied + * Randall will provide an update + * https://github.com/ossf/SIRT/pull/13 + * Team2 - ID core services (Art) + * Expect to be done by next meeting 1 Nov + * Mailing list or communication distro + * [https://github.com/zmanion/SIRT/blob/section2/plan/2.0%20Identify%20Core%20Services%20and%20Processes.md](https://github.com/zmanion/SIRT/blob/section2/plan/2.0%20Identify%20Core%20Services%20and%20Processes.md) + * Met yesterday, moved from google docs to markdown on GitHub, first cut of first draft, there are edits and changes to be made. And Art needs to pull content from the Google doc and then finesse the content/layout. + * + * + * Some less-well-knowns remain + * Staffing model decisions (volunteers, see #11) + * Resource planning for externally driven incidents, expected distribution size/type/frequency + * Team 3 - Execution (Francis) + * Discussion about techs started and went well + * [https://github.com/ossf/SIRT/discussions/8](https://github.com/ossf/SIRT/discussions/8) + * Short of tech stack decision there are several options + * The service selection is contingent upon the output of the surveys + * Instance of events managed by us needs done. + * See + * Proposal to leverage the existing list of “engagements” and rough service outline for the purposes of meeting the DEC 01 2022 due date and refine later (milestone) and integrate the survey results to refine the services. + * SIRT OATH, Ethics commitment, etc. needs added as a milestone, + * Add in Section 3 - hiring of a PM for the coordination of the plan and execution of the SIRT + * Add in Section 3 - Milestone of an ethics commitment/oath/code of engagement conduct created. + * New Goal joint for section 1 and 2 - coordinate foundation and community education and outreach to ensure folks know about the group + * Debian, Gentoo, Homebrew may be receptive to volunteering a person to assist in this. + * Conversation for a later date: + * Folks on the bench - incident responders and commanders + * Advisors - individuals that are experts in their area and may be leveraged by the incident team in completion of the incident resolution. +* **DECIDED: **Voted 4 in favor of a volunteer model with a handful of support staff dtd: TUE OCT 18. On the anniversary of sponsors funding the effort this decision will be revisited. +* Help-wanted for merging all three sections of content + +

Oct 04, 2022

+ + +

Attendees

+ + +(please **Mark your name is black if you are here,** or add-row name/email/affiliation if joining) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name + Email + Affiliation + Pronouns +
CRob + CRob@intel.com + Intel/OSSF + he/him +
VM (Vicky) Brasseur + vm.brasseur@wipro.com + Wipro + she/her +
Francis Perron + francisp@google.com + Google LLC + +
Emily Fox + themoxiefoxatwork@gmail.com + Apple, CNCF TOC + she/her +
Randall T. Vasquez + randall@icloud.com + Gentoo + he/him +
Art Manion + zmanion@protonmail.com + ANALYGENCE + +
+ + +

Agenda

+ + + + +* Welcome new friends +* Who wants to help out and scribe for us today? +* Collect Opens +* SIG/WG Business + * Read on sub-team activities + +

Opens (pending)

+ + + + +* + +

Meeting Notes

+ + + + +* Section Team Activities + * Team 1 - Problem Space (Randall) + * Reorged page during meeting time + * Team2 - ID core services (Art) + * + * Team 3 - Execution (Francis) + * Reviewed goals, setup dependencies withing plan + * [https://github.com/ossf/SIRT/blob/main/plan/3.0%20Execution.md](https://github.com/ossf/SIRT/blob/main/plan/3.0%20Execution.md) +* + +

Sept 19, 2022

+ + +

Attendees

+ + +(please **Mark your name is black if you are here,** or add-row name/email/affiliation if joining) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name + Email + Affiliation + Pronouns +
CRob + CRob@intel.com + Intel/OSSF + he/him +
Francis Perron + francisp@google.com + Google LLC + +
Jennifer Mitchell + jenn.mitchell@tidelift.com + Tidelift + +
Emily Fox + themoxiefoxatwork@gmail.com + Apple, CNCF TOC + she/her +
Randall T. Vasquez + randall@icloud.com + Gentoo + he/him +
Avishay Balter + avbalter@microsoft.com + Microsoft + he/him +
+ + +

Agenda

+ + + + +* Welcome new friends +* Who wants to help out and scribe for us today? +* Collect Opens + * Uncooperative upstream +* SIG/WG Business + * Teams 1 & 2 read-out on activities + * Work on [README.MD](https://github.com/ossf/SIRT/blob/main/README.md) and focus on goals and objectives + * **DECISION NEEDED** - Determine 1yr, 2yr focus for team to build plan for: Volunteer team of responders handling intake/triage/remediation of reports vs. education-focus (teaching projects to “do incidents”) + * Will be emailed out to the group for voting. +* + +

Opens (pending)

+ + + + +* + +

Meeting Notes

+ + + + +* Team Activities - notes docs for each are linked in the Administravia section + * Team 1 + * Identifying problems… need a sync between the problems identified and the services to address them + * Currently focused on where to pull the problems from + * Team2 + * Reworked the services and ordering but realized we need input from group 1 and a decision from the larger group to continue to move forward. + * Team 3 + * - + * meeting scheduled (y-ay) this Friday +* Reminder of the goals of these activities + * Develop a project plan + * Identify specific needs, requirements, pre-requisites, deliverables/outcomes + * Identify resource and financial needs + * Report back to the TAC +* Brian Behlendorf explained that we can reasonably expect program management services and should account for that in our resource needs +* Decision on initial timeline for the group - teach incident management or be the incident management or perhaps both? + * First- the objective of this group and goals + * What is an incident? + * Do we do 10? + * Second- we (OpenSSF) are getting push back from maintainers + * This should be a strong consideration in determining our objectives + * FP - we should be “on-demand”/non-invasive with upstream and not impose ourselves + * Peacetime - education and training + * Incidents take precedence + * If the group has no work, educate educate educate! + * EDU SIG requires helps from this group to provide material so EDU SIG can leverage that in their activities + * Half day training in conferences for instance + * LF has instructional designer that will be a general resource for everyone. + * Randall’s Objective proposal + * SIRT - README - Motivation` + * Historically, Open Source maintainers and end users have depended on a circle of trust to distribute and consume Open Source Software safely. Over the last several years, this concept has proven to be problematic and sub-optimal by itself with the increase of attacks targeting open source maintainers as well as the components they create and maintain. Effectively, these problems have illustrated additional effort and work are required to ensure that both Consumers and End Users of maintainers are consuming Open Source Software safely while still their needs met with the least friction to their overall intent and objective in maintaining their software. As it presently stands, this type of work traditionally is the responsibility of a project's Maintainer group; however, frequently, the Maintainer(s) already lack sufficient resources to address their own needs adequately let alone take on the additional work being asked of them to develop and provide their open source component in secure manner acceptable to anyone using it. Piling on more work to the already stressed pipeline and burdened maintainers often results in Security not being prioritized until a Security issue becomes forefront, which is often too late for a project's Consumers and End Users.` + * This SIRT's motivation is to make available the incident response resources to assist Open Source Software communities, downstream consumers, and vulnerability management ecosystems in addressing their current and upcoming Security issues, vulnerabilities, incidents, and the processes necessary for their execution. We intend to deliver service offerings to projects that provide an additional support arm against incidents, like `log4shell`, which are otherwise not available to these projects. We hope these efforts will assist in addressing critical and time-sensitive Security issues across the Open Source Software communities that participate in the program.` + * Long discussion on pushback from several maintainers as seen in the [#general channe](https://openssf.slack.com/archives/C019M98JSHK/p1663625951737709)l +* Actions: + * Crob: will reach out to Ian to request feedback on our direction + * Crob: will send out decisional vote on year 1 or 2 goals: + * Incident response is our focus + * Education of incident response + * Why-not-both peacetime/ wartime + * All will review the objectives/motivation above prior to the next meeting \ + + +

Sept 13, 2022

+ + +No Full-SIG call today - enjoy OpenSSF Day! + +

Sept 06, 2022

+ + +

Attendees

+ + +(please **Mark your name is black if you are here,** or add-row name/email/affiliation if joining) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name + Email + Affiliation + Pronouns +
CRob + CRob@intel.com + Intel/OSSF + he/him +
Eric Tice + eric.tice@wipro.com + Wipro + +
VM (Vicky) Brasseur + vm.brasseur@wipro.com + Wipro + she/her +
Francis Perron + francisp@google.com + Google LLC + +
Emily Fox + themoxiefoxatwork@gmail.com + Apple, CNCF TOC + she/her +
Randall T. Vasquez + randall@icloud.com + Gentoo + he/him +
Daniel Appelquist + daniel.appelquist@snyk.io + Snyk + he/him +
Jill Moné-Corallo + thejillboss@github.com + GitHub + she/her +
Avishay Balter + avbalter@microsoft.com + Microsoft + he/him +
Mark Menkhus + mark.menkhus@intel.com + Intel + he/him +
+ + +

Agenda

+ + + + +* Welcome new friends +* Who wants to help out and scribe for us today? +* Collect Opens +* Ask Section leads to schedule small group sessions and post that into into the plan sections \ +→ Sections details: [https://github.com/ossf/SIRT/blob/main/plan/](https://github.com/ossf/SIRT/blob/main/plan/) + * 1.0 Understand the problem space + * section lead - Randall + * Section team - CRob, Jill, Art, Jennifer, Emily, JC ([jc.herz@ionchannel.io](mailto:jc.herz@ionchannel.io)), Avishay + * Section meeting time - + * 2.0 Identify core services and processes + * section lead - Art <[zmanion@protonmail.com](mailto:zmanion@protonmail.com)> + * Section team - VMB, Jennifer, CRob, Emily, Randall, JC, Avishay + * Section meeting time - Mondays 15:00 EDT + * 3.0 Execution + * section lead - Francis Perron would like to nominate himself + * Section team - Art, CRob, Emily, JC, Randall + * Section meeting time - + * → Please go on [Slack](https://us01st-cf.zoom.us/web_client/6orpgrb/html/externalLinkPage.html?ref=https://openssf.slack.com/archives/C03FT7B81QD), vote on the schedule in the subthread for Section3 - Francis Perron + +

Opens (pending)

+ + + + +* Technical Advisory Committee (TAC) presentation + * CRob: to present our WG and status + * [deck](https://docs.google.com/presentation/d/1kzvl0HRv4JswPNBCTbrzkfdFyaEf2WtlAc-dO64eAQs/edit) + +

Meeting Notes

+ + + + +* + +

Aug 30, 2022

+ + +

Attendees

+ + +(please **Mark your name is black if you are here,** or add-row name/email/affiliation if joining) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name + Email + Affiliation + Pronouns + GH ID +
CRob + CRob@intel.com + Intel/OSSF + he/him + SecurityCRob +
Eric Tice + eric.tice@wipro.com + Wipro + + +
Francis Perron + francisp@google.com + Google LLC + + +
David A. Wheeler + dwheeler@linuxfoundation.org + Linux Foundation + + +
Emily Fox + themoxiefoxatwork@gmail.com + Apple, CNCF TOC + she/her + TheFoxAtWork +
Randall T. Vasquez + randall@icloud.com + Gentoo + he/him + ran-dall +
Art Manion + zmanion@protonmail.com + ANALYGENCE + + zmanion +
Michael Scovetta + michael.scovetta@microsoft.com + Microsoft + he/him + scovetta +
JC Herz + jc.herz@ionchannel.io + Ion Channel + + +
Mark Menkhus + mark.menkhus@intel.com + Intel + he/him + +
Avishay Balter + avbalter@microsoft.com + Microsoft + he/him + balteravishay +
+ + +

Agenda

+ + + + +* Welcome new friends +* Who wants to help out and scribe for us today? +* Collect Opens +* Conversation & thoughts on organization of plan into 3 parts + * [https://github.com/ossf/SIRT/tree/main/plan](https://github.com/ossf/SIRT/tree/main/plan) +* Ask Section leads to schedule small group sessions and post that into into the plan sections + * 1.0 Understand the problem space + * section lead - Randall + * Section team - CRob, Jill, Art, Jennifer, Emily, JC (jc.herz@ionchannel.io) + * Section meeting time - + * 2.0 Identify core services and processes + * section lead - Art <[zmanion@protonmail.com](mailto:zmanion@protonmail.com)> + * Section team - VMB, Jennifer, CRob, Emily, Randall, JC + * Section meeting time - + * 3.0 Execution + * section lead - Francis Perron would like to nominate himself + * Section team - Art, CRob, Emily, JC, Randall + * Section meeting time - +* (Scovetta) A SIEM for the Open Source Ecosystem ([deck](https://docs.google.com/presentation/d/1xxuHDkrjNOOjbM8ay-OAeKvC6yMs9xML0EgLqSkFknw/edit?usp=sharing)) + * Actions: MS to reach out to package-(feeds,analysis) and securing software repos WG to see what the relationship/tie-in is. + * Suggestion: Get a security review of the implementation + * OSS-SIRT heading away from SOC and more toward opt-in. + * No objections to Scovetta moving ahead, socializing with securing software repos, critical projects WG (home of package-feeds/ pack-analysis) etc. – no “fundamental objections in principle”. + * It’s not clear whether or not it fits in *this* group, but it looks promising - need to have discussion somewhere. +* SIG/WG Business + * **DECISION NEEDED -** Do we reduce THIS call down to every other week to allow more time for collab on smaller teams? + * **DECISION - **on call, team generally agrees, will send to list for formal vote + * Next SIG call - Work on SIG Charter & structure. PRs welcome on our readme.md + * Next SIG Call - How do we solicit more contributors? +* + +

Opens (pending)

+ + + + +* + +

Meeting Notes

+ + + + +* Initial consensus to reduce meeting cadence to every other week, CRob will send out message to the mailing list to confirm +* Michael Scovetta presented the Ossiemilation - an open source SIEM solution + * Focus is on the easy low hanging fruit that is discoverable through automated means + * Microsoft wrote a bunch of scripts to detect these things, and lumped them together. Since not unique to MSFT, makes sense to put it in the foundation. + * It includes event listeners which send to structured logs allowing queries to be executed. + * The use case - a package on the internet appears to be misbehaving. A human or rule reviews the behavior and determines it is/is not a problem. Improving upon the rule set as each query turns up to build a knowledge base for automation. + * How do we resource ecosystems to be self-sustaining - Alpha and Omega can do that. This should be made lighter weight and more efficient for them to respond accordingly. There is a not insignificant amount of work in cleaning up bad projects and users. However it is the responsibility of the package manager. + * For security researchers, who publish non-destructive but maliciously used, we need to track these better. But ultimately up to the package manager terms of use on whether they are in compliance. + * [JC] - Professional drivers on a closed track - is there a possible registration process for security researchers? This is the evil bit, there a problems here for identifying good humans from bad humans. + * This would require more info about who someone else to establish a trusted community + * [DW] its not very clear or you do something deceptive so someone unintentionally installs. Evil for determination of activity. Needs to be more clear. + * Sometimes you need to create packages to test something, but do minimum attack necessary & make it clear. If it’s a sample typosquatting attack from a legit source, it shouldn’t do any damage. If it’s a sample attack to determine if a tool can test it, the description should be VERY clear that this is malicious & should never be installed. Yes, we do need tests, but researchers must take active steps to not hurt others. + * These are published as non-public in some places + * The throughput of this as it exists today is relatively manageable and is largely against two primary language ecosystems in two primary categories + * So what is the ask of this group? Be the humans to review and categorise and own the rules + * What about those event listeners/ scraping GitHub commits? Subscribe to publishing feed. Not scraping the entire universe, rather package manager centric. + * [DW] This looks like package feeds and analysis and would fit in the securing critical projects working group as this is also in their bailiwick of concern + * [TheFox] this group has determined they do not intend to function as a SOCC. rather their function is request-for help based. However the integrity of these rules is paramount, so how is the security of this system intended to be implemented. + * [FP] This group is not mature enough to handle the request at this time. + * [AM] should be a consideration of a sub-group and disagree with maturity to adopt + * [Randall] there are some package managers that have been moving the needle forward. But there are others who would see this as hostile, so that outreach is super important + * [Michael] this is just an extra data point for reporting packages, how is this potentially alienating. Since most things found in this are deletable offenses. + * [Randall] a lot of language ecosystems strive to remain unopinionated. And they rely on the users to make determination of whether to use a package or not + +

Aug 23, 2022

+ + +

Attendees

+ + +(please **Mark your name is black if you are here,** or add-row name/email/affiliation if joining) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name + Email + Affiliation + Pronouns + GH ID +
CRob + CRob@intel.com + Intel/OSSF + he/him + SecurityCRob +
Eric Tice + eric.tice@wipro.com + Wipro + + +
VM (Vicky) Brasseur + vm.brasseur@wipro.com + Wipro + she/her + vmbrasseur +
Madison Oliver + taladrane@github.com + GitHub + she/her + taladrane +
Jennifer Mitchell + jenn.mitchell@tidelift.com + Tidelift + + jenn-mitchell +
Emily Fox + themoxiefoxatwork@gmail.com + Apple, CNCF TOC + she/her + TheFoxAtWork +
Randall T. Vasquez + randall@icloud.com + Gentoo + he/him + ran-dall +
Art Manion + zmanion@protonmail.com + ANALYGENCE + + zmanion +
Jill Mone-Corallo + thejillboss@github.com + GitHub + she/her + thejillboss +
+ + +

Agenda

+ + + + +* Welcome new friends +* Who wants to help out and scribe for us today? +* Collect Opens +* Please add your GH ID so we can get permissions set on repo +* OSS SIEM +* Review possible prototype to divide plan into logical units for small group focus + * [https://docs.google.com/document/d/1uQcw9Ymy8LEYeXSnEiZduHLYO68h4OUaahB2crGDuVE/edit#](https://docs.google.com/document/d/1uQcw9Ymy8LEYeXSnEiZduHLYO68h4OUaahB2crGDuVE/edit#) - Proposed Short Form Final Version + * [https://docs.google.com/document/d/1dlQVjgGn1B-zqJJ3LEO5wCxIDu-EMsVicWIqncXeapM/edit#](https://docs.google.com/document/d/1dlQVjgGn1B-zqJJ3LEO5wCxIDu-EMsVicWIqncXeapM/edit#) + * Modeled after [https://github.com/ossf/education/tree/main/plan](https://github.com/ossf/education/tree/main/plan) +* Proposal 1 + * 1.0 Understand the problem space + * section lead - Randall + * Section team - CRob, Jill, Art, Jennifer + * 2.0 Identify core services and processes + * section lead - Art + * Section team - VMB, Jennifer, CRob + * 3.0 Execution + * section lead - + * Section team - Art, CRob +* Proposal 2 + * Establish an Identity for the SIRT + * “Start the engine” – + * Operate + +

Opens (pending)

+ + + + +* (Scovetta) A SIEM for the Open Source Ecosystem ([deck](https://docs.google.com/presentation/d/1xxuHDkrjNOOjbM8ay-OAeKvC6yMs9xML0EgLqSkFknw/edit?usp=sharing)) +* + +

Meeting Notes

+ + + + +* Broke up the plan into logical chunks for better management of content +* We will agree on the appropriate sections and then divide up into small groups to work collaboratively and fill in content and then reconvene with the larger group to review + * Each section lead will organize a time to meet with folks +* Determined appropriate sections and titles, and assign section leads +* Francis and CRob will move it into GitHub for the groups to collaborate on a PR for. +* Next meeting is to review the proposed structure, after which we will restructure the meetings to allow more time to collaborate +* + +

Aug 16, 2022

+ + +

Attendees

+ + +(please **Mark your name is black if you are here,** or add-row name/email/affiliation if joining) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name + Email + Affiliation + Pronouns +
CRob + CRob@intel.com + Intel/OSSF + he/him +
Eric Tice + eric.tice@wipro.com + Wipro + +
Marta Rybczynska + rybczynska@gmail.com + OSTC + she/her +
VM (Vicky) Brasseur + vm.brasseur@wipro.com + Wipro + she/her +
Francis Perron + francisp@google.com + Google LLC + +
Jennifer Mitchell + jenn.mitchell@tidelift.com + Tidelift + +
Emily Fox + themoxiefoxatwork@gmail.com + Apple, CNCF TOC + she/her +
Randall T. Vasquez + randall@icloud.com + Gentoo + he/him +
Art Manion + zmanion@protonmail.com + ANALYGENCE + +
+ + +

Agenda

+ + + + +* Welcome new friends +* Who wants to help out and scribe for us today? +* Collect Opens +* Staffing and estimates - Francis & Emily + * [https://docs.google.com/document/d/1SXvs_i7ojQ2i-5zU_-GXlsi76KYNva0o583kysY-wtA/edit#](https://docs.google.com/document/d/1SXvs_i7ojQ2i-5zU_-GXlsi76KYNva0o583kysY-wtA/edit#) + * we want to define what + * “engagement” means for us, taking into consideration + * tiering, + * escalations / emergencies, + * we want to estimate how many we should expect for year1, year2, .. + * we want to use these numbers to motivate our staffing requests +* Review plan for logical groupings and select section leaders to facilitate small-group focused calls to flesh out details for plan +* + +

Opens (pending)

+ + + + +* None this week + +

Meeting Notes

+ + + + +* Francis - Reminder that there is a GitHub for submitting issues and tracking the work the group is doing. ([https://github.com/ossf/SIRT/issues/1](https://github.com/ossf/SIRT/issues/1)) +* Staffing and estimates document created by Francis and Emily for engagement discussion ([https://docs.google.com/document/d/1SXvs_i7ojQ2i-5zU_-GXlsi76KYNva0o583kysY-wtA/edit#heading=h.ouw7qmv2vj8c](https://docs.google.com/document/d/1SXvs_i7ojQ2i-5zU_-GXlsi76KYNva0o583kysY-wtA/edit#heading=h.ouw7qmv2vj8c)) +* What are the personas for activity in the sirt? Community Volunteers and Direct staff +* The majority of activities will be done by volunteers +* Support staff as contracted hired individuals that will work to help complete deliverables as given by the Direct Staff +* Avoid people from uploading files to reduce maintenance +* Marta - when do we want to disclose information to the public? What is the estimated public closure time frame? +* SLOs for work to be delivered should be tiered for number of resources, time and other key markers for determining how to work through the process +* Marta - SIRT Skeleton should be discussed with Vulnerability Disclosures group as well +* CRob - Tools like Vince for handling the vulnerabilities as they are determined in the group and governed in the tooling. Several proprietary tools can be discussed also +* Robot.txt file for helping to make onboarding easier. +* Emily - Security.txt doesn’t always have standard fields each time, it might be suggested that we need to have a standardized format or minimum criteria for metadata +* Francis - file that is proposed should be less free form and more standard which is the reasoning behind the Robot.txt file. +* CRob - staffing and splitting up the tasks into smaller groups of actionable teams to accomplish the goals of the group is the next phase. +* Agreement on personas generally accepted by attendees +* CRob - Services and offerings can be a phased approach to which features are provided at which phase +* Art - Work to define scope for the work to assure that we are able to complete the work we can. Clearly prioritize a backlog of issues +* Francis - be aware of resource constraints and work to mitigate what we can +* Emily - Internal assessments and triaging and one for the Requesters breakdown of tiers of services. Triaging and prioritization were the two areas that were considered in the document +* Eric, Art & Randall - Volunteer to help continue documentation and site creation for SIRT +* CRob - how can we move the smaller parts to smaller groups to begin working on deliverables more rapidly. +* CRob - Francis and CRob will take the plan for the SIRT and push it into GitHub to begin working issues and PRs. Breakdown of groups to help work on these tasks will begin. Feedback on breakdown from group welcome +* + +

Aug 09, 2022

+ + +

Attendees

+ + +(please **Mark your name is black if you are here,** or add-row name/email/affiliation if joining) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name + Email + Affiliation + Pronouns +
CRob + CRob@intel.com + Intel/OSSF + he/him +
VM (Vicky) Brasseur + vm.brasseur@wipro.com + Wipro + she/her +
Francis Perron + francisp@google.com + Google LLC + +
Madison Oliver + taladrane@github.com + GitHub + +
Jennifer Mitchell + jenn.mitchell@tidelift.com + Tidelift + +
Emily Fox + themoxiefoxatwork@gmail.com + Apple, CNCF TOC + she/her +
Randall T. Vasquez + randall@icloud.com + Gentoo + he/him +
Art Manion + zmanion@protonmail.com + ANALYGENCE + +
+ + +

Agenda

+ + + + +* Welcome new friends +* Who wants to help out and scribe for us today? +* Collect Opens +* Pick Plan2.0 review back up at item 6.0 in [Plan](https://docs.google.com/document/d/1uQcw9Ymy8LEYeXSnEiZduHLYO68h4OUaahB2crGDuVE/edit#) +* Will want some assistance in cleaning up/finishing our Git readme [file](https://github.com/ossf/SIRT/blob/main/README.md). PRs welcome! + +

Opens (pending)

+ + + + +* Emily: what is an open? + * CRob: an item that is not on the agenda, and you wish to have answered! + * All: thanks for asking! + +

Meeting Notes

+ + +[Reviewing the plan 2.0](https://docs.google.com/document/d/1uQcw9Ymy8LEYeXSnEiZduHLYO68h4OUaahB2crGDuVE/edit#) again. + + + +* Point 6.0 + * Emily: this was from a conversation we had in-person, concerns: + * nowhere is there a mention of training, + * shadowing, + * ethical concerns and sensitive info + * CRob: I’d like us to document the PSIRT process in general here: + * this is how we operate + * this is how we deal with sensitive info + * this is how we deal with ethical topics + * → do we want to transfer this conversation to a dedicated one? + * shadowing + * sensitive info dealing + * +* 7.0 + * 7.2 - compensation + * CRob: this will be part of our proposal (staffing, charge, …) + * Emily: I was reading this as compensation for employers with employees which are contributing to this, or tooling + * CRob: agreed on the incentive, and tooling.. and training. How about a rewards/swag program? + * Vicky: are we talking about staffing (eg: a PgM for air traffic control) or the person doing the work? + * CRob: the latter for this convo + * Emily: I’d highly recommend including support staff in this. The nitty-gritty work here is veeeery helpful. + * Francis: are we the only SIG with this idea here? if not, how about we unify our approach to this? + * CRob: HAHAHAHAHAHA, “unified” - we’re not the only ones + * Art Manion (AM): Is this the SIG’s responsibility to propose a staffing model? (yes) if we propose, making this up on the spot, an LF staff to make coordination support and a list of stable part-time staff handling engagements… how precise are we expected to generate an org structure here? + * CRob: not that precise, but we’ll ask for volunteers to flesh this out (..Art?), → we expect to split this out in smaller groups to fork off work. +* 8.0 - Commitment + * Emily: - + * don’t think we should hardcode a commitment period right now + * shadowing program; is it worth discussing this in year one? + * CRob: + * we’ll essentially be taking year 1 as the documentation/building year + * Vicky: agreed with Emily here! + * we should document the intention though (Aye --all) + * CRob: do we want to add anything to that section? + * all: nopes. +* 10.0 - Outreach program + * Vicky: I’d like us to have some funding here.. we’ll probably end up sharing with other sigs, but having our own may be good to discuss… + * Francis: how about a partial re-imbursement for con participation in the name of OSSF? + * Emily: + * Conference submissions are usually value/merit based so there is no guarantee we can speak at XX amount of conferences + * We could potentially have multiple submissions for a participation, and if only one is elected… do we reward all or just the presenter? + * CRob: what I’d like to do is have a budget for travel for OSSF stuff + * Vicky: we should remove LF events from this, they’re good about getting speakers rewarded… other non-LF events tend to be the ones we should look at here. (flights / hotels). Presenting on behalf of the group is one thing, but also having some kind of scholarship here might be interesting. + * what about adding a scholarship? + * Francis: how about we ask (voluntell) Vicky to think about this further? + * /insert witty smiles +* 11 - commitment to 30 engagements + * E: I’d recommend the removal of values here + * F: what is this number about though? do the writers actually expect us to have this in there?? + * CRob: we’ll finish the plan, show it to them, and they may ask for a number here. + * Randall: as far as volunteers go, we can help with that! + * we have 8 or 9 folks getting ready now. They are all interesting ppl, really! + * CRob: even if we don’t need volunteers to handle coordination, but as trainers as well (+1 from Emily/Francis) + * I’ll put you in touch with the folks. + * Madison Oliver: should we incentivize the individuals or the corporate overlords here? I can’t see an organization volunteering its IR staff to do this as it is written. + * CRob: both.. and yes, this is a funding request as well. + * Emily: re:org-incentives -- depending on their org participation positioning, there may be legal assistance even contributed by orgs, ([ref k8s issue](https://github.com/kubernetes/steering/issues/240)) but we should not be blanket-assuming that “incentives” mean the same thing for all orgs. + * AM: Might be worth it to think about a number of potential engagements we will have to do here, this will influence staffing. We have some science to help here. +* 11.0 - + * VM: while I support removing numbers of engagements from this, I do think we should commit to some sort of incident-related engagement. If only as a proof of concept. We all like gravy. + * AYE --all + * CRob: we’ll wordsmith this, but agreed on the general commitment approach, hopefully engaging with at least one incident. + * VM: this is essentially red/green refactor for our SIRT +* 13 - + * Francis: do we want to differentiate between MPCVD and CVD? not really + * Emily: Is there an assumed expectation that refinement will be fed back to the best practice group? + * Vicky: agreed on this, once they have their CVD guide up there, will they only handle changes/requests? what kind of relationship can we expect on this front? + * Randall: Does this follow the GH guide about CVD? + * CRob: as we assemble the literature, yes, we expect this to be fed in there as part of the references. + +**Next Meeting**: + + + +* Staffing and estimates + * we want to define what + * “engagement” means for us, taking into consideration + * tiering, + * escalations / emergencies, + * we want to estimate how many we should expect for year1, year2, .. + * we want to use these numbers to motivate our staffing requests + +
Action Items
+ + + + +* ✅( Francis Perron ): make a skeleton note doc for the discussion with ’s help: +* TODO(@zmanion@protonmail.com): start thinking about an organizational model for the staffing +* TODO(): start thinking about funding models for the 10.0 section / outreach rewards + +**Special thanks** + +The scribe, Francis, wants to thank “anonymous mink” for fixing all his typos: + +![image](https://github.com/ossf/SIRT/assets/128058721/952bb9c9-8467-4654-89c3-5b99c9965766) + + + +Shoutout to Emily by Vicky as well for the huge contributions to the document and notes! + +

Aug 02, 2022

+ + +

Attendees

+ + +(please **Mark your name is black if you are here,** or add-row name/email/affiliation if joining) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name + Email + Affiliation + Pronouns +
VM (Vicky) Brasseur + vm.brasseur@wipro.com + Wipro + she/her +
Emily Fox + themoxiefoxatwork@gmail.com + Apple, CNCF TOC + she/her +
Marta Rybczynska + rybczynska@gmail.com + OSTC + she/her +
Art Manion + zmanion@protonmail.com + ANALYGENCE + +
Jennifer Mitchell + jenn.mitchell@tidelift.com + Tidelift + +
Madison Oliver + taladrane@github.com + GitHub + she/her +
Randall T. Vasquez + ran.dall@icloud.com + Gentoo/Homebrew + he/him +
Langley Rock + langley.rock@dell.com + Dell + +
+ + +

Agenda

+ + + + +* Welcome new friends + * Art! Who has a new job! Congrats! +* Who wants to help out and scribe for us today? +* Collect Opens +* SIG/WG Business +* + +

Opens (pending)

+ + + + +* None + +

Meeting Notes

+ + + + +* Review of last week’s call + * Finished going through day 2 notes, added clarifications + * Didn’t get through all the updates, need to finish that yet +* Plan 2.0 draft review: + * Working through the comments in the table (therefore there may be fewer notes here) + * Art, who’s new here (welcome!) asks for more clarification on why we decided to remove 2.4 + * In the process, Emily recommended rewording 2.5 to say patches certainly welcome and the SIRT could assist in reviewing (she’s working on suggested rewording) + * 2.6: Marta points out that this is the only place where we mention security advisories + * Should we make these more visible rather than have them a part of a list? + * Also, could we include release notes as an element of this? Help projects write release notes related to security issues + * 2.5/2.6: Emily wonders whether the review/creation/publishing should be factored out from the advisories/release notes/etc + * Agree we should tier these into levels of effort (year 1, year 2) + * However, feel the writing/comms as valuable as coding/reviewing patches + * Some projects don’t have these skills + * Suggestion to separate items that are higher risk (coding/reviewing patches) are separated out and say that those are specifically by request + * Art also suggests that there be some top-level introductory material making it clear we’ll always respect the processes/desires of the project (added to doc; will wordsmith later) + * Randall, as a distro maintainer, recommends making as many things optional as possible (one size doesn’t fit all) + * More a’la carte menu than prix fixe + * Emily has made some suggested edits to the doc on these points, which the group accepted + * 2.6 (newly edited; thanks, Emily!) + * Emily points out it lacks coordination; editing to add that in + * 2.8: Emily asks why we specify “in the wild here” but not elsewhere? + * “In the wild” has a sense of urgency to it; is that sense intentional here? + * Agreement to reduce that sense of urgency here, or specifically mention both “in the wild” situations as well as less urgent ones + * Edited the doc accordingly + * 3.0: Group proposed not hard-coding the criteria here and instead make them a living, publicly available document + * Folks agree that this is the better way to go + * We’d like to help everyone, but we’ll eventually have a list to help us prioritise + * Renamed to triage criteria to better reflect what we’ll do + * 5.0: Toss this to the Education WG? + * Emily: Maybe toss the final version over to this WG, but should provide the content from this WG + * Edu WG can then ensure it’ll be presented and promoted in an accessible manner + * Stopped at 5.0. Will pickup work next week starting at 6.0 + +

Jul 26, 2022

+ + +

Attendees

+ + +(please **Mark your name is black if you are here,** or add-row name/email/affiliation if joining) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name + Email + Affiliation + Pronouns +
Eric Tice + eric.tice@wipro.com + Wipro + +
VM (Vicky) Brasseur + vm.brasseur@wipro.com + Wipro + she/her +
Francis Perron + francisp@google.com + Google LLC + +
Madison Oliver + taladrane@github.com + GitHub + +
Jennifer Mitchell + jenn.mitchell@tidelift.com + Tidelift + +
Matt Rutkowski + mrutkows@us.ibm.com + IBM + he/him +
Emily Fox + themoxiefoxatwork@gmail.com + Apple, CNCF TOC + she/her +
Randall T. Vasquez + randall@icloud.com + Gentoo + he/him +
Deana Shick + deana.shick@intel.com + Intel + she/her +
Brian Behlendorf + + LF/OpenSSF + he/him +
+ + +Agenda + + + +* Welcome new friends +* Who wants to help out and scribe for us today? +* Collect Opens +* SIG/WG Business + * [openssf-sig-osssirt@lists.openssf.org](mailto:openssf-sig-osssirt@lists.openssf.org) - + +

Opens (pending)

+ + + + +* + +

Meeting Notes

+ + + + +* Pickup review of DC Day 2 +[Notes](#heading=h.w0jmqss2q8w5) + * +* Review the changes we proposed to the plan: + * [https://docs.google.com/document/d/1uQcw9Ymy8LEYeXSnEiZduHLYO68h4OUaahB2crGDuVE/edit#](https://docs.google.com/document/d/1uQcw9Ymy8LEYeXSnEiZduHLYO68h4OUaahB2crGDuVE/edit#) + * As you review feel free to fix typos. + * Two columns show changes were made. + * Matt & Eric: unsure on 2.4 clarity on this being a fix note or review. Does it need to be removed or is it separate from subsequent review + * Francis: Review section further in document will potentially be rewritten to cover this + * Review of Pink blocks for points 8 and 9 still pending. Discussion needed to finalize approach +* Mission / Scope for the SIG - initial discussion + * +* Mailing list now open for notifications. If not subscribed email CRob or Francis to be added +* + +GSD: - Rolling Agenda: [https://csaurl.org/gsd-agenda](https://csaurl.org/gsd-agenda) Other quick link [https://csaurl.org/gsd-quick-links](https://csaurl.org/gsd-quick-links) + +

Jul 19, 2022

+ + +

Attendees

+ + +(please **Mark your name is black if you are here,** or add-row name/email/affiliation if joining) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name + Email + Affiliation + Pronouns +
CRob + CRob@intel.com + Intel/OSSF + he/him +
Eric Tice + eric.tice@wipro.com + Wipro + +
Marta Rybczynska + rybczynska@gmail.com + OSTC + she/her +
VM (Vicky) Brasseur + vm.brasseur@wipro.com + Wipro + she/her +
Francis Perron + francisp@google.com + Google LLC + +
Jennifer Mitchell + jenn.mitchell@tidelift.com + Tidelift + +
Matt Rutkowski + mrutkows@us.ibm.com + IBM + he/him +
Langley Rock + langley.rock@dell.com + Dell Technologies + +
Yotam Perkal + yotamp@rezilion.com + Rezilion + +
Jack K + jack at control-plane.io + ControlPlane/nixpkgs + +
Randall T. Vasquez + randall@icloud.com + Gentoo + he/hjim +
+ + +

Agenda

+ + + + +* Welcome new friends +* Who wants to help out and scribe for us today? +* Collect Opens +* Francis has agreed to help co-lead our little group +* Thoughts about last conversations & the plan as written + * Observations about gaps in current plan +* Review + +[May DC Summit Stream 5 notes](#heading=h.xijuq5x784lx) +* “Build versus Buy” debate - do we recommend hiring dedicated to do this IR work, do we recommend a more advisory approach of mentorship, education, or some combination? + * What would a staffed team look like? How couls +* Begin building 2.0 plan & “dividing and conquering” + * Francis is starting to take the plan + our notes and is drafting the [2.0 plan](https://docs.google.com/document/d/1uQcw9Ymy8LEYeXSnEiZduHLYO68h4OUaahB2crGDuVE/) + * We will begin to fill out the details and gaps + * We will be looking for volunteers to lead/facilitate/own some of the goals/sections so that we can parallelize more of our work + +

Opens (pending)

+ + + + +* CRob OOTO 25th July - 1th Aug -** is someone interested in helping lead the meeting on 26th July? - Francis will facilitate and finsih up “DC Day 2 comment review” then talk about Plan2.0 & next steps** +* Patches welcome to help fill our our git [README.md](https://github.com/ossf/SIRT/blob/main/README.md) +* @CRob - get mailing list & slack setup/broadcast +* + +

Meeting Notes

+ + + + +* DC Question 1a + * VM - what channels do we need/what stakeholders do we need to address? + * Eric - define the content and medium for the notification. How broad should this be publicized? Is there a potential for different message based on impact of issue to small or broad community + * Marta - focus on writing the communication and writing to the correct channels. End users will have multiple existing channels and should try leveraging the existing rather than adding yet another channel. + * Jack - So is this the creation of "an" open source incident response team, or creating a framework/advice for projects to model their own incident response teams around? + * Francis - Plan for year one working on best practices, etc, year 2 would be writing patches and doing the fixes to the exposed vulnerabilities + * Langley - Does this already exist with the PCert framework? Is there an overlap or extension? + * CRob - noted that PCert is already planned as a model + * Francis - I agree FIRST offers good frameworks here, but these are definitely geared towards a corporation building a PSIRT. The open source communities will have a very different approach to this, and I do also think it is a place we can actively help by both telling the story of how we build our own, and offer guidance in the future on this. A new "standard" isn't what I have in mind here, but kind of an addendum to the FIRST frameworks. + * Mark - seems like an admirable goal if daunting to approach issues in thousands of projects. When digging into the process the ability to report bugs and practices around it needs help on a projects. Year 1 will have huge impact on Year 2 through defining clearly the processes and best practices to be used + * CRob - using a tool like Vince for communication as an approach moving forward + * Jack - with nixpkgs (the repo for the NixOS distro and other stuff) the actual handling handling security issues isn't really our problem, it's more don't have a place or a workflow to report issues/CVEs as resolved/patched in our releases + * CRob - VINCE might help +* Question 1d + * CRob - should abandoned projects be in the purview of the group in the first few years + * VM - We should acknowledge abandonware and document them, if a list doesn’t exist, and maintain it to help others manage it but not try to take on the governance and maintenance at this time + * Mark - priority should dictate the need to intervene and participate on projects that are widely used and impact to industry is high. + * Francis - may not be part of the SIRT. May be to broad in scope for this group to tackle. + * Matt - point companies/users to automated process or written guidance to help them mitigate projects that have been abandoned that are risks + * Jack - My only thought is how would we classify abandonware vs something that's "feature complete" and maybe there's eyes on the project but since it doesn't have dependencies it doesn't really need changing/updating +* Question 2 + * CRob - already addressed an approach to projects to reach out to for this information. +* Stream 5 Day 2 + * CRob - sharing learning and documenting the processes should be addressed in the plan through blogs, presentations, etc. + * VM - single spot for retrieving this information would be beneficial with appropriate SMS and other notification capabilities. Wise to leverage a pre-existing mechanism if it exists, research on this should be done prior to creating it + * CRob - look at Linux as an example or possible extension as a mechanism for notifications + * Langley - can amber alert/911 notifications be used for the wrong reasons? To disseminate bad information to people + * Randall - build in process and legal due diligence to assure it is secure and validated. Clarify the audience/stakeholder targets + * CRob- maintainers will be interested in patch development information where downstream users may be interested in other information + +
May DC Notes
+ + +

DAY 1

+ + +

6 Questions to Answer

+ + + + +1. We have our ambitious goals, but what is Minimum-Viable-Product - the least we can do to still meaningfully demonstrate the suitability of the solution to the problem as stated? + 1. Formulation of a communication channel egress (messaging out when problems are discovered) tweets are not sufficient + 1. Stakeholder groups - maintainers/project, (MM) consumers/downstream are harder - how can we help make downstreaming comms easier?, + 1. Marta suggest helping WRITE the comms to assist the project that they can use(including how to get updates, how toi mitigate + 2. Matt - who will take advantage of this? As projects age and grow they lose maintainers/knowledge of deps etc[Randall] need to clarify audiences of comms + 2. Ingress (reporting in) - who should be notified? How much information? + 3. Define, solidify, and coach open source projects about responsible disclosure processes and responses. + 4. Abandonware processes, hostile takeover of those projects into the foundation to push the maintenance. This requires deprecating the original fork of the codebase. + 2. [VM] acknowledge issues, but this may be too much for team to manage. Team could start curating list of abandoned projects + 3. This in principle may need to carry forward the licensing and history associated. + 4. Publish a patch to backport into so folks can fix it. + 5. [marl] may be special cases based off of priority + 6. [francis] - interesting problem, but probably MUCH bigger than just us + 7. [matt] if someone takes the time to file an issue and is willing to work with us we can assist with guidance, processes, tools, etc + 8. [eric] - how much of this is “this is abandoned” and fix… or steps to remove dependency on it? - BestPractice may need to set soem guidance on what “shelf life” of projects may be and paths to get remediation + 9. [LeRock] - is there opportunity for partnerships (like with someone like a Blackduck) to provide checks/advise + 5. SIRT of last resort needs to coordinate many of these +2. What research or engagement can we do over the next few months to de-risk the plan? + 6. Discover the failures of previous effort for identity and communication channels to find those maintainers +3. Identification of leaders, both of those in the room and who could be approached. + 7. FIRST, distros, Kernel security, kubes sec (SIG-Security), apache sec, GSD, CNCF Security TAG, +4. Is there an existing vehicle for accepting and managing funds? If not, what should it look like? + 8. +5. What does a “public engagement model” look like for this project, to best tap available contributors, expertise and partners? + 9. +6. Based on the above, are there any important changes to consider to the proposed solution, timing, or budget? + 10. + +

STREAM 5 Day 2 Comments

+ + + + +* Community communications/outreach +* **Share learnings/processes** +* **How do you report?** +* **Notification system/amber alert-style sharing** + * Team sees value in a single channel (RSS, whatever). Are there existing things that already do this? ( distros list, oss-security list ) +* Training & tooling, good practices +* Lack of awareness of the existing central bodies that coordinate response +* A “911” - central place to report to, needs to consider the lack of trust in the US Fed. + * Part of amber-alert idea above + * [LeRock] - have we thought about how this channel could be abused/corrupted + * We’ll certainly need to eval && pentest & threat model any services we formulate +* Fire hot to an appropriate distro to be able to step in and be the cooler head. Need to ensure we scope who is included to ensure it is not convoluted. + * A mitigator of issues between two parties - [eric] how would that get staffed? How do you determine the process, who would you reach out to? How are decisions handled (voting, other?) +* Public embargo versus pre-release fix. + * Continued contested discussion on appropriate to OS projects. Favoring of large corporations being able to staff and give an unfair advantage to vendors over small communities or orgs. A decision needed to be made on how to make forward to set appropriate standards to assure that it was fair and opens the ability for smaller companies to staff and fix issues. Intent to be most inclusive of communities interacted with + * Francis and CNCF TAG Security: Coordination of prerelease and the need for marketing of fixes would be more difficult for the typical smaller project team. + * Vicky: SIG should educate and coordinate with small and medium projects to help them meet the prerelease needs. Coordination with Education SIG would ideal + * Single source of truth and fork of Vince may be a better solution for helping to manage SIG here + * +* When the world is on fire no one reads the documentation + * Providing guidance to a project without training or education can be difficult to consume without the training. Cheatsheet or playbook for helping manage common processes or issue types should be created + * TODO(): check with the Best Practices group who might be working on 1pager versions of docs as well here. +* Registry of a project with a central platform to marry reporting to the maintainers + * Discussion with GitHub or Gitlab for starter project with security primer. + * Vicky: Doesn’t think a registry would be the best idea. Will want to do a broad collaboration with repository providers, not just GitHub. + * Mark: Looking for patterns in GitHub for people that are trying to build projects, discussion around governance and best practices. What are the low hanging fruit areas that can be leveraged in GitHub for security as a minimum of how to make small changes with little cost and higher outcomes. Found that governance artifacts are limited and will look to share a doc on findings + * Madison: Work internally to help with these items happening in next Quarter at GitHub to allow private vulnerability disclosure + * Mark: A number of projects have done some good work on minimum setup patterns. Focus study on patterns for reusability and enabling reporting related to security notifications and monitoring. + * Emily: CNCF maintains a list of maintainers within the foundation. Responses to individuals on a list is not as good as expected. If their is an issue with a commonly used project their was not a good mechanism for discretely contacting project maintainers and users. Consider creating a better path to doing this + * Matt: Apache has a global email for notifications, reporting is done to this email, to maintainers. Experience indicates reporting is done via that email, the project’s private email list or direct email to a maintainer. + * → interested subgroup to think about this: Emily, Eric, Madison + * → talk to the A&O (experience creating virtual teams around security working with OSS project maintainers and foundations), education and best practices subgroup on this as well +* The [Global security database](https://github.com/cloudsecurityalliance/gsd-project) can serve as a starting platform if built correctly to drive reporting and augmenting suspected and confirmed vulnerability. + * Emily: OS project proposal in Cloud Security Alliance that would aggregate vulnerability and issue data from multiple locations as a single point to go for formal information gathering and search to get the most comprehensive information. Needs additional help in assuring the appropriate data is added. Designed to use CVE structure + * +* How do we update and generate tools to automate the creation and discovery of these issues. + * Emily: Part of this may have been about incorrectly reported vulnerabilities +* The openSSF can become the ‘phonebook’ of a given project with documented ways of engagement for them, be the glue to track to it down. + * +* A feed back into the tool chain about this. + * Part of phone book item above related to registry discussion +* SIRT of last resort, drive folks to the foundation based SIRT - establish the hierarchy of incident reporting for projects, foundations, and the SIRT of last resort + * Emily: The discussion was about creation of a response team that can provide assistance to projects with security vulnerabilities. Scope of potential vulnerability would be daunting. Foundation would establish a team for non-security teams can go to for help on issues. If not part of foundation their would be a number to call or team to reach out to for help in these issues. Escalation would be defined for managing issues if one group would not be able to resolve the issue + * Vicky: There are a lot of foundations out their and collaboration not dictation needs to be done to help reuse existing processes or practices. Communication with foundations/groups outside of the LF will be necessary to assure stronger standards and processes for mitigation. https://flossfoundations.org/foundation-directory/ + * Matt: A lot of organizations that own OSS are private and their will be legal boundaries to overcome. +* Map out those cases and discuss these, to allow for clear mapping of this. +* Mutations of coding patterns for incident response. + * +* Value of exercises and war games. theoretical/table top exercises can be useful. + * +* Ask maintainers how do they want to be supported when notified of a zero day + * Francis: Discover and explore what we want to do as a service +* “Zero day” training for devs; “Zero day” training for security researcher approaching OSS +* SIRT of last resort as “SIG” under vuln disc +* Document how OSSF will handle reports & escalations + * Matt: Assure all OSSF projects have a security.md file and maintainers understand OSSF procedures. Should be first-in-line for any process “testing” + * See min. Security.md that should be propagated to all coding projects: [https://github.com/ossf/allstar/blob/main/SECURITY.md](https://github.com/ossf/allstar/blob/main/SECURITY.md) + +

July 12, 2022

+ + +

Attendees

+ + +(please **Mark your name is black if you are here,** or add-row name/email/affiliation if joining) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name + Email + Affiliation +
CRob + CRob@intel.com + Intel/OSSF +
Eric Tice + eric.tice@wipro.com + Wipro +
Marta Rybczynska + rybczynska@gmail.com + OSTC +
VM (Vicky) Brasseur + vm.brasseur@wipro.com + Wipro +
Francis Perron + francisp@google.com + Google LLC +
David A. Wheeler + dwheeler@linuxfoundation.org + Linux Foundation +
Madison Oliver + taladrane@github.com + GitHub +
Jennifer Mitchell + jenn.mitchell@tidelift.com + Tidelift +
Matt Rutkowski + mrutkows@us.ibm.com + IBM +
Emily Fox + themoxiefoxatwork@gmail.com + Apple, CNCF TOC +
Brian B. + + OSSF, LF +
+ + +

Agenda

+ + + + +* Welcome new friends +* Collect Opens +* Continue plan review at #4 keeping the following items in mind: + * **Do we agree with these items? ** + * **What is missing? ** + * **Do we feel the estimates are realistic/achievable?** + * **Do we have volunteers to focus on each effort? Are their people not here we need to recruit/engage with?** + +

Opens (pending)

+ + + + +* + +

Meeting Notes

+ + + + +* [Vicky] - #4 a bit too prescriptive at this point, probably not as part of plan, but needs defined +* [David] - We do not have infinite resources, we need some criteria to gate our resources. Need eligibility criteria. It’s okay if the details aren’t in the plan, but we need criteria somewhere because we don’t have infinite resources. +* [CRob] - criteria/severity should be put into operational docs/playbooks, another meeting to me scheduled to focus specifically around the criteria for triaging and potential introduction to a tiered service level based on criteria met. +* [David] - the criteria will need to be updated as the group learns more (e.g., “this kind of vulnerability isn’t really a big deal, but that kind which seems less important is actually more important”). +* [Emily] - need to provide options for tiering services, thresholds for escalations, etc +* Convo around #5 it infra +* [David] - embargoed (secret) vs. non-embargoed (non-secret) infra/processes- we want to minimize the # of people/infra we need to maintain to protect against strong attackers. +* [Emily] - regardless of what path we go down we’ll need SOME comms/infra (even if it is recommendations vs. services provided) +* [Marta] - short guides for emergency situations +* [Emily] - merge #6 & 7 - should have no specific funding/compensation requirements; should be nothing that precludes the foundation from also staffing contract, will need to be flexible +* [Eric] - need focused conversations/documentation around legalities, etc +* [Vivky] - once we get to talking to lawyers about this, we should not “reinvent the wheel”, there most likely is existing materials we can leverage +* [David] - LF projects like kernel & kubes +* [Francis] details around contract lengths will vary, job changes - new employer not supporting +* [Emily] - kubernetes has a gradual process to “promote” people into DOING IR after a period of time once they’ve gotten XP - Kubernetes has a SIG Security and an entire process about dealing and managing with vulnerabilities as they come in, they even have a tiered team member structure that provides a path of education, training, and familiarity.” +* AR - we will review prior art to see lengths of commitment times and how project generally handled time frames for “graduation” +* Group agreement on #9 +* #10 - Eric synergy with EDU SIG, [Vicky] - this is “table stakes” (we MUST do this) +* [David] outreach is clearly needed. At least some should probably be contacting specific OSS projects. We’ll need to build trust for projects to reach out to us when they have a serious problem - building trust is a human challenge, not a tech challenge. +* [Vicky] re: 30 IRs 1st year - “wow, I love a stretch goal” - perhaps tweak to “launch and deliver services” +* [Brian] - suggest that team has capability to handle capacity of multiple new IRs at once +* [Francis] suggests leaving it in (30 or). It is a lofty goals +* [Eric] set goal for year2 once we’ve learned more +* Change “emergency incidents” to “engagements” +* Group agrees that metrics and reporting for year1. David would like to see “Success stories” +* FOLLOW UP IN SLACK - **[Emily Fox](https://app.slack.com/team/U02ST15THDL)** [1:26 PM](https://openssf.slack.com/archives/C03FT7B81QD/p1657733190463739) + * [@Christopher Robinson](https://openssf.slack.com/team/U01V4K5JFKK) wanted to drop this here per our discussion in the meeting yesterday: Kubernetes Security processes: [https://github.com/kubernetes/committee-security-response](https://github.com/kubernetes/committee-security-response). + * [Security Release Process](https://github.com/kubernetes/committee-security-response/blob/main/security-release-process.md) is probably the most relevant, and [SRC Oncall](https://github.com/kubernetes/committee-security-response/blob/main/src-oncall.md) has some more details of the specific workflows Kubernetes uses. All of these can be beneficial as a starting point for bootstrapping OSS-SIRT processes around this. +* + +(source: [https://openssf.org/oss-security-mobilization-plan/](https://openssf.org/oss-security-mobilization-plan/) ) + + + +1. ⊲ Define eligibility criteria to utilize those services. This could be based upon things like: + * Criticality of the open-source project + * Criticality of the vulnerability (based on CVSS score or other metrics) + * Whether or not there exists evidence of in-the-wild exploitation of the vulnerability + * Whether the maintainers feel equipped to write the patch + * Whether or not the project already has such resources available + * Complexity of the associated coordinated vulnerability disclosure process ⊲ Select the IT and communications infrastructure necessary to deliver these services, and make a plan for its deployment, operational availability, and security assurance. +2. ⊲ Augment a playbook/guidance document directed at open-source maintainers that gives generically useful guidance about what to do in the event of a cybersecurity emergency (e.g.: critical vulnerability is reported) to offer clear instructions on how & when to get our support. +3. ⊲ Define contractual expectations (including vetting process and ethics agreement) and necessary skills/experience that will be required of each “firefighter”/incident responder. +4. ⊲ Design an engagement model for “firefighters”/incident responders, which addresses things such as: + * Compensation/funding model + * Legal/contractual details + * On-call rotation logistics / how we ensure adequate service availability +5. ⊲ Recruit our initial cohort of incident responders for a minimum commitment period of 2 years. +6. ⊲ Document publicly an operational model for this service including: + * Commitments that will be upheld by each “firefighter”/incident responder, including preventing premature disclosure.   + * “How-to” guides for those maintainers/developers wishing to engage with us + * Service-level agreements + * Communication channel +7. ⊲ Perform outreach to relevant developer communities to educate them about this new service, including through the creation of a dedicated information webpage, as well as through conference presentations, webinars, “office hours,” media interviews, and speaking with leaders and industry groups involved in OSS development. +8. Launch and deliver services for up to 30 emergency incidents. +9. Define and report on key metrics to understand our success and impact in year 1. +10. Maturing Coordinated Vulnerability Disclosure (CVD) + * Working with the OpenSSF Best Practices WG to educate open source developers on good CVD practices (such as the Guide to coordinated vulnerability disclosure for open source software projects) + * ⊲ Educate security researchers about effective ways to report to and engage with open source maintainers (forthcoming OSSF Guide to coordinated vulnerability disclosure for security researchers engaging with open source software projects) + * ⊲ Ensure vulnerabilities, including malicious hijacks, injections, and sabotages, are properly documented using tools like CVE and communicated clearly in advisories including automatable identification of affected components. + * ⊲ Advocate for use of CVD tools such as CERT-CC's VINCE tool that allows researchers reporting vulnerabilities and software maintainers a neutral, secure place to exchange vulnerability information. + * + + COSTS: + + + ⊲ 24/7/365 First-line/triage/program management support:   + + + 1 Project Manager + + + 3 On-call triage / security incident handlers + + + 4 staff x $300k/yr = $1.2M/yr ⊲ Service start-up costs including legal, IT infrastructure, web design, outreach: + + + 1 Program lead: 300k/yr + + + Outsourced/contracting for legal, IT, design: $250k   + + + Outreach/marketing: $250k + + +⊲ Funding for retaining 10-20 security experts (as appropriate) + +⊲ Maturing Coordinated Vulnerability Disclosure (CVD) • 8 staff to cover technical work and content development: $3M + +Engagement model to be developed with partner organizations. For the first year, we will look for zero-cost incentives. However this may be a place where further funding is determined to be required to hit first year goals. To be conservative here, we will budget 750k as a reserve for such incentives. + +⊲ Total: $2.75M + +

+ + +

Attendees

+ + +(please type name/email/affiliation) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Name + Email + Affiliation +
CRob + CRob@intel.com + Intel/OSSF +
Eric Tice + eric.tice@wipro.com + Wipro +
Harimohan Rajamohanan + harimohan.rajamohanan@wipro.com + Wipro +
Marta Rybczynska + Mailing list info: rybczynska@gmail.com + OSTC +
VM (Vicky) Brasseur + vm.brasseur@wipro.com + Wipro +
Francis Perron + francisp@google.com + Google LLC +
David A. Wheeler + dwheeler@linuxfoundation.org + Linux Foundation +
Josh Dembling + josh.dembling@intel.com + Intel +
Madison Oliver + taladrane@github.com + GitHub +
Jennifer Mitchell + jenn.mitchell@tidelift.com + Tidelift +
Arnaud J Le Hors + lehors@us.ibm.com + IBM +
Matt Rutkowski + mrutkows@us.ibm.com + IBM +
+ + +

Agenda

+ + + + +* Intros +* Review plan Stream 5 & 6 + * [https://openssf.org/oss-security-mobilization-plan/](https://openssf.org/oss-security-mobilization-plan/) + * Francis Perron scribe today (thank you!) +* Craft SIG mission/vision & scope + +

Summary of the discussion

+ + + + +* In general, we all agreed Stream 5 & 6 was a good overall basis for the SIG, with agreements: + * for year 1 of the SIG: + * SubGoal 1: document the problem space + * SubGoal 2: identify a core set of services we want to offer as a SIG + * SubGoal 3: Improve comms between maintainers and researchers + * SubGoal 6: Provide assistance with patch submission and advisories + * SubGoal 7: coordinate downstream communication of undisclosed info + * For Later, to be clarified as well: + * SubGoal 4: provide SME-as-a-Service for reviewing / vetting vulns + * SubGoal 5: provide reviewing of patches before disclosure + * SubGoal 8: provide assistance to maintainers wishing to determine impact and validity of vulns they see in the wild +* Action Items: + * ~~: clean up notes~~ + * CRob: check with the Education SIG for “legal education” material + +

Notes

+ + + + +* Review Stream 5&6: Goals for first year: are they appropriate? edit/remove anything? Any gaps? + * Starting on [p31 of the mobilization plan](https://8112310.fs1.hubspotusercontent-na1.net/hubfs/8112310/OpenSSF/OSS%20Mobilization%20Plan.pdf?hsCtaTracking=3b79d59d-e8d3-4c69-a67b-6b87b325313c%7C7a1a8b01-65ae-4bac-b97c-071dac09a2d8) + * [SubGoal 1](#bookmark=kix.qs5s99a0h0m1): Document the problem space + * **Agreement** + * [SubGoal 2](#bookmark=kix.soe393hxorzk): Based upon the research above, identify a core set of services (year 1) that we would offer maintainers to resolve these problems + * **Agreement** + * [SubGoal 3](#bookmark=kix.ak83arg1t3pl): Improving comms between maintainers and researchers + * **Agreement** + * MR: Verify that we survey and check our proposals and approaches with major OSS communities. + * VM: Let’s make sure we verify with major OSS orgs/foundations to see if they’re interested in joining in with feedback as well. + * David A. Wheeler: Use phrases like “organizations and individuals” - not just “companies” + * [SubGoal 4](#bookmark=kix.lg5dslg944yz): staffing a team of SME to vet / triage vulns for maintainers + * VM: Noble thought, but it’ll be hard to implement… I’m sure everybody would love to have this superhero, but we’ll need to make sure we think about this before going forward so we don’t oversubscribe ourselves here. + * DW: How about we label this as _Experimental_; it’s never been tried before. If we label this as an experiment, we’ll have a positive outcome regardless of success + * JD: Interesting concept, but also feels like a lofty goal. Having dealt with this externally and internally, having a common set of tools to support OSS and security vulns and such. This feels like a basic service: education and framework. It could easily become a service we just throw bodies at. + * ET: We should ensure we set very clear and precise SLAs on this if we do it. + * DW: the vetting wasn’t originally intended to be to triage a gazillion problem, the goal was to have an SME help out with a known problem dealt with by maintainers + * CRob: we’ll change it! + * DW: the original didn’t have anything about triage. things like Log4J, shellshock… they understand their software, but have no cybersecurity experts to talk to. First, second fixes didn’t work… we want to ensure that the maintainers can get access to an expert to help. + * CRob: + * PM-hat-on: it’ll be nigh-impossible that within 12 months we will be able to provide rapid expertise to maintainers. How about we do not commit to this on year 1? + * We don’t even know if projects actually want this? we need a survey to check with maintainers if they care about this. + * my feel here is that we, as a stream, are better off documenting these processes than staffing a desk. + * DW: Fair. I mostly want to raise this to the group for discussion. + * **Decision** for the group: + * **VM: plz longer timeframe** + * **All: _agreed_ on vetting** + * [SubGoal 5](#bookmark=kix.21gb4hs35o1y): Reviewing proposed patches before they become publicly available + * VM: Let’s see how things are working for us before committing to this in year 1, and we need to make sure this is worthwhile + * ET: if anything, we agree this should be in the best-practices (recommendations) for any project, + * CRob: with Alpha and Omega, we’ll be engaging with lots of projects, with Office Hours setup… maybe we could do a talk about security code review or similar. + * **agreed on this not being an objective for year 1** + * ALH: maybe we could do this only if requested by the maintainers? not for everything + * [SubGoal 6:](#bookmark=kix.12o38zjv3col) help maintainers submit patches to reduce collateral impact + * CRob: suggestion - VINCE as a coordination platform, we could advocate for it, and extend it with CSAF + * VM: are you suggesting we spin up our own instance? or extend the current one? I’d recommend the latter. + * CRob: agreed on helping VINCE develop, but it sounds possible to have the OpenSSF run their own instance. It is currently run by CERT/CC (gov association). We may wish to host a DMZ-friendly version (neutral space). + * MR: if we become a hub for coordination, maybe we’ll conflict with other hubs and become yet-another “spoke” in the wheel of coordination…? + * CRob: true… but VINCE seems to be the one central thing now. + * DW: if we go down that road, we’ll probably want to do a security audit of whatever tool we agree on. + * CRob: agreed vehemently here. Maybe also get a best practices badge, etc. If we have a tool/platform, want to make sure it’s a good one. + * FP: is this a goal we want to pursue year-1? + * cRob: sounds good! + * FP: Do we want to clarify our role to include coordination and submission? + * CRob: I like this. + * VM: coordination implies we have staffing that does this + * CRob: we’re not there yet, but the plan has budget for staffing this + * VM: in the final plan, we should re-order these to have coordination before recruiting + * [SubGoal 7](#bookmark=kix.6etnvab8jt53): Coordinating confidential communications (as appropriate) with downstream affected projects to assist in a risk-mitigating approach to security patch deployment + * MO: I think it’d be highly beneficial, if anything. + * All: **agreed** + * [SubGoal 8:](#bookmark=kix.gbazlmjuga3g) Helping to evaluate and suggest steps to take if maintainers receive reports of in-the wild exploitation of novel vulnerabilities in an open source project + * CRob: suggested not for year-1, but we could provide documentation and framework / best-practices for maintainers on steps to take here + * MR: Reflecting on my experience, it’d be helpful to provide repro-environments if we can as we have budget here. + * JD: agreed with CRob +* High level discussion on core values here: + * MO: lots of folks new to coordination have legal questions, especially around geo… I don’t know how we could communicate this kind of info to maintainers, but I’m sure they’d find this useful + * CRob: Education WG meeting tomorrow, I’ll bring this up… don’t know if we’ll ever have lawyers on the calls, but providing resources may be good. + * MO: good place to start indeed. + * JD: agreed, providing guidance would be great + * FP: how about we split the SIG plan around Doc/Best-Practices offerings vs tactical + * CRob: we do have a plan for staffing yes + * JD: we do want to make sure whatever service we offer it is actually “wanted”. + * FP: what’s the timeline? + * CRob: minimal guidance provided on this, but we should probably have the plan sometime in the Fall (EOQ3), revised and edited and ready to be presented to the board. + * ALH: Have you seen Brian’s plan sent to the broader SIG group? I did not see this SIG… + * CRob: in the coming weeks, we’ll be aligning all of this, and Stream5 should align with the vuln disclosure space. Stream 6 may also be included. There will be alternate WS with SBOM and all these magical acronyms. + * ALH: we expect the Brian Plan to include this SIG? + * CRob: not really, but we will be putting our part of the plan, to be added/joined to it. It’ll be staggered… some of Stream6 is already moving, and other things like Stream8 might not happen until later. If we’re good and ready, we can independently move forward. + * ALH: yes, it does feel like there’s a lot of administrative overhead at the moment with the streams and WGs and WSs and … + * CRob: yes. + +

Next Meeting

+ + +(developed during meeting) + + + +1. Define eligibility criteria +2. TODO(CRob): create a 2.0 document with the ideas we discussed here +3. + +

Review Plan

+ + +First Year (6 to 18 Months) Goals & Costs + +GOALS: + + + +11. (SubGoal 1) ⊲ Understand and document the problem space, through discussing our proposal with a representative set of open-source developers and security incident responders, especially those with experience managing the disclosure and remediation of high impact vulnerabilities in open-source software. +12. (SubGoal 2) ⊲ Based upon the research above, identify a core set of services (year 1) that we would offer maintainers to resolve these problems. This likely includes some minimum subset of assisting with: • Ensuring secure communications between maintainers and researchers when receiving vulnerability reports and/or proof-of-concept exploit code + * (SubGoal 3) Communicating with security researchers and negotiating disclosure timelines + * (SubGoal 4) Vetting experts and offering security expertise to help maintainers understand the vulnerability & its impact • Writing proposed software patches to remediate identified vulnerabilities (only when specifically requested by maintainers) - **_experimental_** + * (SubGoal 5) Review proposed fixes before they are public to see if they fully resolve the reported vulnerability •  + * (SubGoal 6) Helping maintainers create and publish software patches and security advisories in a way that will minimize the likelihood of widespread vulnerability exploitation + * (SubGoal 7) Coordinating confidential communications (as appropriate) with downstream affected projects to assist in a risk-mitigating approach to security patch deployment + * (SubGoal 8) Helping to evaluate and suggest steps to take if maintainers receive reports of in-the wild exploitation of novel vulnerabilities in an open source project +13. ⊲ Define eligibility criteria to utilize those services. This could be based upon things like: + * Criticality of the open-source project + * Criticality of the vulnerability (based on CVSS score or other metrics) + * Whether or not there exists evidence of in-the-wild exploitation of the vulnerability + * Whether the maintainers feel equipped to write the patch + * Whether or not the project already has such resources available + * Complexity of the associated coordinated vulnerability disclosure process ⊲ Select the IT and communications infrastructure necessary to deliver these services, and make a plan for its deployment, operational availability, and security assurance. +14. ⊲ Augment a playbook/guidance document directed at open-source maintainers that gives generically useful guidance about what to do in the event of a cybersecurity emergency (e.g.: critical vulnerability is reported) to offer clear instructions on how & when to get our support. +15. ⊲ Define contractual expectations (including vetting process and ethics agreement) and necessary skills/experience that will be required of each “firefighter”/incident responder. +16. ⊲ Design an engagement model for “firefighters”/incident responders, which addresses things such as: + * Compensation/funding model + * Legal/contractual details + * On-call rotation logistics / how we ensure adequate service availability +17. ⊲ Recruit our initial cohort of incident responders for a minimum commitment period of 2 years. +18. ⊲ Document publicly an operational model for this service including: + * Commitments that will be upheld by each “firefighter”/incident responder, including preventing premature disclosure.   + * “How-to” guides for those maintainers/developers wishing to engage with us + * Service-level agreements +19. ⊲ Perform outreach to relevant developer communities to educate them about this new service, including through the creation of a dedicated information webpage, as well as through conference presentations, webinars, “office hours,” media interviews, and speaking with leaders and industry groups involved in OSS development. +20. Launch and deliver services for up to 30 emergency incidents. +21. Define and report on key metrics to understand our success and impact in year 1. +22. Maturing Coordinated Vulnerability Disclosure (CVD) + * Working with the OpenSSF Best Practices WG to educate open source developers on good CVD practices (such as the Guide to coordinated vulnerability disclosure for open source software projects) + * ⊲ Educate security researchers about effective ways to report to and engage with open source maintainers (forthcoming OSSF Guide to coordinated vulnerability disclosure for security researchers engaging with open source software projects) + * ⊲ Ensure vulnerabilities, including malicious hijacks, injections, and sabotages, are properly documented using tools like CVE and communicated clearly in advisories including automatable identification of affected components. + * ⊲ Advocate for use of CVD tools such as CERT-CC's VINCE tool that allows researchers reporting vulnerabilities and software maintainers a neutral, secure place to exchange vulnerability information. + * + + COSTS: + + + ⊲ 24/7/365 First-line/triage/program management support:   + + + 1 Project Manager + + + 3 On-call triage / security incident handlers + + + 4 staff x $300k/yr = $1.2M/yr ⊲ Service start-up costs including legal, IT infrastructure, web design, outreach: + + + 1 Program lead: 300k/yr + + + Outsourced/contracting for legal, IT, design: $250k   + + + Outreach/marketing: $250k + + +⊲ Funding for retaining 10-20 security experts (as appropriate) + +⊲ Maturing Coordinated Vulnerability Disclosure (CVD) • 8 staff to cover technical work and content development: $3M + +Engagement model to be developed with partner organizations. For the first year, we will look for zero-cost incentives. However this may be a place where further funding is determined to be required to hit first year goals. To be conservative here, we will budget 750k as a reserve for such incentives. + +⊲ Total: $2.75M + +**Do we agree with these items? ** + +**What is missing? ** + +**Do we feel the estimates are realistic/achievable?** + +**Do we have volunteers to focus on each effort? Are their people not here we need to recruit/engage with?** + +Working Mission/Vision for our Charter + +Establish the OpenSSF Open Source Security Incident Response Team + + + +![image](https://github.com/ossf/SIRT/assets/128058721/da51b963-01c6-4ea4-8b4b-2ee511a1afed) + + +

REFERENCES

+ + +May WH Committee Notes + + + +* [https://docs.google.com/document/d/12cvhxwUTYwXB3JmouoqVmD-jSFEReaNTdfmW5P8ZXGM/edit#heading=h.dvjl5qihat49](https://docs.google.com/document/d/12cvhxwUTYwXB3JmouoqVmD-jSFEReaNTdfmW5P8ZXGM/edit#heading=h.dvjl5qihat49) + +OSSF Mobilization Plan + + + +* [https://8112310.fs1.hubspotusercontent-na1.net/hubfs/8112310/OpenSSF/White%20House%20OSS%20Mobilization%20Plan.pdf?hsCtaTracking=3b79d59d-e8d3-4c69-a67b-6b87b325313c%7C7a1a8b01-65ae-4bac-b97c-071dac09a2d8](https://8112310.fs1.hubspotusercontent-na1.net/hubfs/8112310/OpenSSF/White%20House%20OSS%20Mobilization%20Plan.pdf?hsCtaTracking=3b79d59d-e8d3-4c69-a67b-6b87b325313c%7C7a1a8b01-65ae-4bac-b97c-071dac09a2d8) + +FIRST PSIRT Services Framework + + + +* [https://www.first.org/standards/frameworks/psirts/psirt_services_framework_v1.1](https://www.first.org/standards/frameworks/psirts/psirt_services_framework_v1.1) + +FIRST PSIRT Services Maturity Guide + + + +* [https://www.first.org/standards/frameworks/psirts/psirt_maturity_document](https://www.first.org/standards/frameworks/psirts/psirt_maturity_document) + +FIRST Guidelines and Practices for Multi-Party Vulnerability Coordination and Disclosure + + + +* [https://www.first.org/global/sigs/vulnerability-coordination/multiparty/guidelines-v1.1](https://www.first.org/global/sigs/vulnerability-coordination/multiparty/guidelines-v1.1) + +OSSF CVD Guide + +Kubernetes Security Processes + + + +* [https://github.com/kubernetes/committee-security-response](https://github.com/kubernetes/committee-security-response) +* [Security Release Process](https://github.com/kubernetes/committee-security-response/blob/main/security-release-process.md) is probably the most relevant, and [SRC Oncall](https://github.com/kubernetes/committee-security-response/blob/main/src-oncall.md) has some more details of the specific workflows Kubernetes uses. All of these can be beneficial as a starting point for bootstrapping OSS-SIRT processes around this. + +