WIP: First draft of a charter for a Security Standing Committee #110
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
manics
reviewed
May 20, 2025
docs/standing-committee-charter.md
Outdated
|
|
||
| ## Mission and Scope | ||
|
|
||
| The **Security Standing Committee** (SSC) is a permanent committee established to oversee and improve the security of Project Jupyter’s software and operations. It replaces the former Jupyter Security Subproject and inherits its mission to provide guidance on security and to coordinate the handling of security issues across all Jupyter projects. The Committee is empowered by the Project Jupyter Executive Council (EC) to define and implement security policies, practices, and response procedures that protect Jupyter’s code, repositories, infrastructure (e.g. web services, DNS), credential stores (password vaults, keys), and users. |
There was a problem hiding this comment.
SSC has two meanings in this doc, it also refers to Software Steering Council.
There was a problem hiding this comment.
Thanks for pointing that out!
rpwagner
commented
May 20, 2025
docs/standing-committee-charter.md
Outdated
Comment on lines
70
to
82
| ## Reporting and Accountability | ||
|
|
||
| The Security Standing Committee is accountable to the Project Jupyter Executive Council and operates under the EC’s oversight. To fulfill this accountability and keep the broader project informed, the Committee will institute regular reporting and communication practices: | ||
|
|
||
| * **Reports to Executive Council:** The Committee will report to the EC on a regular basis (at minimum, **once per year** in a formal written report, and more frequently if requested or if significant issues occur). The annual report to the EC will summarize the Committee’s activities, such as number of vulnerabilities handled (without disclosing sensitive details), major policy changes or initiatives undertaken, audit results, and any resource needs or escalations. Additionally, an EC liaison (the core member who sits on the EC) will provide brief updates during EC meetings as appropriate – for example, after a major incident is resolved, the EC member can brief the Council privately on what happened and lessons learned. This ensures the EC maintains situational awareness of security matters and can exercise oversight. The EC may also invite the Committee to present at an EC meeting or retreat if deeper discussion is warranted. | ||
|
|
||
| * **SSC Liaison and Advisory Role:** The Committee’s representative on the Software Steering Council (SSC) will serve as a conduit for communication between the security team and the technical leadership of Jupyter. In SSC meetings, this representative will **advise the SSC** on security implications of technical proposals and raise any cross-cutting security concerns for discussion. For example, if a JEP under consideration has security impact, the SSC representative from the Security Committee will ensure those issues are articulated. Conversely, if the Security Committee needs broad technical input (say, on the feasibility of a new security feature affecting many subprojects), they can bring it to the SSC via this representative. The Security Committee will **not** have a vote in SSC decisions beyond this representative’s participation (they have one vote on SSC like other standing committee reps), but their advisory voice is crucial. This relationship mirrors how other standing committees interface with technical governance – e.g., a Code of Conduct committee might advise but not dictate technical decisions. The SSC rep is expected to report back to the Security Committee on any SSC decisions or upcoming changes that have security relevance, so the Committee stays informed. In summary, the Committee **reports to the EC and advises the SSC** (rather than formally reporting to SSC) in accordance with Jupyter’s governance structure. | ||
|
|
||
| * **Public Transparency:** While much of the Committee’s sensitive work must be confidential, the Committee will strive to be as open as possible about its non-sensitive activities. It will publish sanitized summaries of its work for the community. For instance, the Committee may maintain a public **Security Committee Log** (on the GitHub repo or Jupyter website) that lists public-facing accomplishments: e.g., “Completed security audit of JupyterHub (report available),” “Published security best practices guide,” “Handled X security reports this quarter (details embargoed),” etc. After a vulnerability is disclosed and fixed, the Committee will often post retrospective details (what was the issue, how it was addressed) to educate users and developers. Community members should have insight into what the Security Committee is doing on their behalf, within the bounds of confidentiality. The Committee will also solicit community input publicly when developing new policies (for example, releasing a draft of a new security policy for comment on the forum). | ||
|
|
||
| * **Metrics and Feedback:** The Committee will track metrics such as number of vulnerabilities reported, average time to fix, and participation in security initiatives, and share these (in aggregate) to demonstrate effectiveness and identify areas for improvement. It will welcome feedback from the community and other governance bodies on its performance. The EC may periodically review the Committee’s effectiveness and can suggest adjustments to its operations or membership if needed. | ||
|
|
||
| By maintaining clear reporting lines and open communication, the Security Standing Committee ensures it remains accountable to the wider Project Jupyter leadership and community, despite the inherently private nature of parts of its work. This accountability aligns with governance best practices for security teams in open-source projects (e.g., having to justify and explain policies to leadership and users, rather than operating opaquely). |
There was a problem hiding this comment.
This section should probably be removed. It's overly prescriptive and gets into specifics about policy, procedure, and reporting that should be handled in a separate document.
rpwagner
commented
May 20, 2025
docs/standing-committee-charter.md
Outdated
|
|
||
| **Core Security Council (Core Members):** The Committee’s core voting members shall consist of **3 to 7 individuals**. These members are appointed by the Executive Council and must be well-known, trusted members of the Jupyter community (e.g. long-standing contributors or maintainers with demonstrated commitment to the project’s welfare). Core members **must not be pseudonymous** – they are expected to participate under their real identities, given the high level of trust and accountability required for handling sensitive security matters (in line with practices of other projects’ security teams, where membership is limited to vetted individuals and confidential discussions are kept to invite-only channels). One of the core members **must also be a sitting member of the Executive Council**. This dual role member will serve as a direct liaison to Jupyter’s top governance, ensuring that the EC is informed of critical security issues and that the Committee’s work aligns with the broader mission of the project. Additionally, per Jupyter’s governance model for Standing Committees, the Security Committee will elect **one of its core members to serve as its representative on the Software Steering Council (SSC)**. (It is possible the EC-appointed member fulfills this role if they also sit on SSC, but if not, another core member will be chosen to represent security interests on the SSC.) The Core Security Council is the formal “Standing Committee Council” for this committee, empowered to make decisions as described in this charter. | ||
|
|
||
| **General Participants (Security Contributors Group):** In addition to the core members, the Committee welcomes a broader group of community participants who are interested in contributing to Jupyter’s security efforts. *Any* community member (including new contributors or outside security researchers) may become a general participant by joining the public discussions (for example, the `jupyter/security` GitHub repository or the Jupyter Discourse security forum) and by adhering to the Project Jupyter Code of Conduct. These participants might help by reporting vulnerabilities, suggesting improvements, writing documentation, developing security tools, or assisting in security issue triage for public issues. Unlike core members, general participants do not need formal appointment; their involvement is based on interest and continued constructive contribution. Pseudonymous participation is permitted in this broader group – contributors may operate under consistent online handles if they wish – **however**, all participants are expected to build trust through responsible behavior and must understand that they will not have access to confidential security reports until/unless they are elevated to the core Council. The open nature of this contributor group echoes the original intent of the Security Subproject to be an inclusive, community-wide effort (“not a closed effort, quite the opposite”). |
There was a problem hiding this comment.
Does there need to be two classes of membership, or should the Security Council have a mechanism for public discussion like officer hours?
|
General feedback on the security call today is that the document is much too verbose currently and needs to be distilled down so it can be reviewed asynchronously in a reasonable amount of time. A lot of the text is background information would could be moved to another document or kept for reference. Also, membership needs to be looked at the most closely, to determine how the members of the core security council are determined. |
|
I pushed a commit that hardwrap thing to make it more readable, also your local git is not configured (properly?) the commits appear as anonymous. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Proposing that the Security Subproject be transitioned to a Standing Committee with a specific charter, clear authority and responsibility, based on other open-source projects.