Skip to content

Latest commit

 

History

History
109 lines (70 loc) · 8.6 KB

File metadata and controls

109 lines (70 loc) · 8.6 KB

Operational Agreement: Securing Open Source Communities Working Group

0. Important Notice: Please Read This First

It is critical to understand and adhere to the scope, change procedures, and information disclosure level at all times to ensure the safety and integrity of the group. Failure to do so may result in removal for the safety of the individual and the overall group.

Default disclosure levels

  • TLP:AMBER if no other disclosure level is specified.
  • Meeting Agendas and public-facing Meeting Minutes or Notes are TLP:CLEAR.

Please note that secure communication tools cannot un-disclose inappropriate disclosures. Therefore, please keep all discussions and sharing within both group scope and your organization's scope at all times.

Purpose of secure communcation channels

The direct outcomes of this group will be the guidance released at the end of each phase. That said, "why use secure tools if the results can/will become public?" To practice two things:

  • Learn by doing Participants will practice by using the patterns they build, while they build them. This will also help to ensure they work in practice as well as theory.
  • Adjust expectations Too much information is overwhelming and leads to confusion; too little is imprecise and differently confusing. Participants will also build and practice finding the balance between these extrema.

Accounts you will need

This group will be making use of the following tools. Please ensure that you have your handles added the appropriate room(s) and role(s):

  • Github
  • CryptPad
  • Matrix

1. Purpose

This Operational Agreement outlines the guidelines and responsibilities for the Securing Open Source Communities Working Group.

The Security Open Source Communities Working Group is focused on developing secure communication practices and governance structures for open-source projects. We will leverage the CISA Traffic Light Protocol (TLP) to communicate the sensitivity of shared information.

2. Scope

This agreement covers the following:

  • Membership and Participation
  • Communication Tools and Protocols
  • Decision-Making Processes
  • Conflict Resolution
  • Amendment Procedures

3. Membership and Participation

  • Application Process: By invitation only. Any current member can nominate a new member, or contact Quintessence directly if you'd like to participate. Group size will be kept intentionally small, with an exact upper limit of either 15 or an agreed-upon number by the end of Jan 2026.
  • Skills and experiences we're looking for: The working group is currently focused on a small number of individuals that fall into either or both of two categories:
    • Members of leadership in open-source projects and their organizations that have been appointed or elected.
    • A small number of security specialists to lend their expertise and guide the conversation.
  • Responsibilities of Members: Members are expected to:
    • Actively participate in discussions and tasks.
    • Adhere to the TLP guidelines (see Appendix).
    • Respectfully engage with other members.
    • Maintain confidentiality of sensitive information.
    • Properly classify communications with the correct TLP designation.
  • Membership Restrictions:
    • Membership is restricted to active participants and 1-2 chat moderators.
    • Members who violate group scope or guidelines may be removed.
  • Identity Requirements:
    • Members representing well-known open source projects or organizations must use the well-known identity associated with that work. This will be verified by email or similar domain-authoritative mechanism.
    • Members who do not wish to publicly disclose their affiliation must still disclose their affiliation to the group.
      • Members who do not wish to publicly disclose their identity are approved via a simple majority vote of existing members.
  • Removal Code of Conduct violations and not maintaining the communicated information sharing boundaries can both be grounds for removal. The detailed process for COC violations is described in the corresponding document. Information sharing boundaries are considered a severe infraction and we will follow the process for a Permanent Ban as described in the COC document.

4. Communication and Documentation Tools

  • Matrix
  • CryptPad
  • Github

5. Decision-Making Processes

Decisions will generally be made through simple majority, either in meetings or asynchronously in the Matrix channel. Complex amendments to this Operational Agreement will be discussed in meetings and subsequently amended here before major changes are introduced. Any member can request issues to require a vote, either in meetings or in asynchronous chat.

6. Conflict Resolution

Initial disagreements should be addressed directly through respectful communication between the individuals involved. Moderators will also act as mediators to facilitate discussions and guide parties toward a resolution if direct communication proves insufficient.

If the issue cannot be resolved through mediation, it should be documented as needed. Conflicts involving potential violations of the project's Code of Conduct will be addressed according to the enforcement procedures outlined in the Code of Conduct.

7. Amendment Procedures

Complex amendments to this Operational Agreement will be discussed in meetings and subsequently amended here before major changes are introduced.

References

[1] Social Web Information Sharing and Analysis Centre (SW-ISAC): IFTAS. Social Web Information Sharing and Analysis Centre (SW-ISAC). IFTAS, (accessed) Jan 2026 from https://about.iftas.org/library/social-web-information-sharing-and-analysis-centre-sw-isac/
[2] Traffic Light Protocol (TLP) Definitions and Usage: CISA. Traffic Light Protocol (TLP) Definitions and Usage. CISA, (accessed) Jan 2026 from https://www.cisa.gov/news-events/news/traffic-light-protocol-tlp-definitions-and-usage/

Appendix: Traffic Light Protocol (TLP) Explanation [1]

TLP provides a simple and intuitive schema for indicating when and how sensitive information can be shared, facilitating more frequent and effective collaboration. TLP is not a “control marking” or classification scheme. If a recipient needs to share the information more widely than indicated by the original TLP designation, they must obtain explicit permission from the original source.

  • TLP:RED: When should it be used? Sources may use TLP:RED when information cannot be effectively acted upon without significant risk for the privacy, reputation, or operations of the organizations involved. For the eyes and ears of individual recipients only, no further. How should it be shared? Recipients may not share TLP:RED information with any parties outside of the specific exchange, meeting, or conversation in which it was originally disclosed.
  • TLP:AMBER+STRICT: When should it be used? Sources may use TLP:AMBER+STRICT when information requires support to be effectively acted upon, yet carries risk to privacy, reputation, or operations if shared outside of the organization. How should it be shared? Recipients may share TLP:AMBER+STRICT information only with members of their own organization on a need-to-know basis to protect their organization and prevent further harm.
  • TLP:AMBER: When should it be used? Sources may use TLP:AMBER when information requires support to be effectively acted upon, yet carries risk to privacy, reputation, or operations if shared outside of the organizations involved. Note that TLP:AMBER+STRICT should be used to restrict sharing to the recipient organization only. How should it be shared? Recipients may share TLP:AMBER information with members of their own organization and its clients on a need-to-know basis to protect their organization and its clients and prevent further harm.
  • TLP:GREEN: When should it be used? Sources may use TLP:GREEN when information is useful to increase awareness within their wider community. How should it be shared? Recipients may share TLP:GREEN information with peers and partner organizations within their community, but not via publicly accessible channels. Unless otherwise specified, TLP:GREEN information may not be shared outside of the cybersecurity or cyber defense community.
  • TLP:CLEAR: When should it be used? Sources may use TLP:CLEAR when information carries minimal or no foreseeable risk of misuse, in accordance with applicable rules and procedures for public release. How should it be shared? Recipients may share this information without restriction. Information is subject to standard copyright rules.

Version History

5 Jan 2025 - Initial version