Add draft of security team charter. #56
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||||
|---|---|---|---|---|---|---|---|---|
| @@ -0,0 +1,93 @@ | ||||||||
| # Security Team | ||||||||
|
|
||||||||
| ## Scope of responsibilities | ||||||||
|
|
||||||||
| The security team is responsible for [Django’s security policies](https://docs.djangoproject.com/en/dev/internals/security/). This includes: | ||||||||
|
|
||||||||
| - Reviewing security reports via [email protected] | ||||||||
| - Evaluating and patching confirmed security issues | ||||||||
|
There was a problem hiding this comment. Maybe we could separate this into two bullets, to reflect the different responsibilities (based on current experience). How about:
Suggested change
|
||||||||
| - Communicating with reporters | ||||||||
| - Communicating with the public about security releases | ||||||||
| - Communicating with operating-system vendors and other distributors of Django | ||||||||
|
|
||||||||
| ## Initial membership | ||||||||
|
|
||||||||
| - Chair: | ||||||||
| - Co-Chair: | ||||||||
| - Report triagers: | ||||||||
| - Steering Council Liaison (must be an active Steering Council member; may be the same as Chair/Co-Chair): Carlton Gibson | ||||||||
| - Other members: | ||||||||
| - Adam Johnson | ||||||||
| - Carlton Gibson | ||||||||
| - Jacob Walls | ||||||||
| - Jake Howard | ||||||||
| - James Bennett | ||||||||
| - Mariusz Felisiak | ||||||||
| - Markus Holtermann | ||||||||
| - Michael Manfre | ||||||||
| - Natalia Bidart | ||||||||
| - Paul McMillan | ||||||||
| - Sarah Boyce | ||||||||
| - Shai Berger | ||||||||
| - Simon Charette | ||||||||
|
|
||||||||
| Note: The DSF Board President has access to the security mailing list, but does not otherwise participate in the team’s activities. This is mentioned for the sake of transparency. | ||||||||
|
There was a problem hiding this comment. The DSF president is the Google org admin which means they have access to everything. That includes the security mailing list. There was a problem hiding this comment. Ah, I misinterpreted "has access to" as "receives emails" 👍 There was a problem hiding this comment. I wonder if we should mention that this is a by-product of the Google org set up in the charter? There was a problem hiding this comment. FYI the president does receive every email just like the Security Team do. Unclear how that changes things :-) |
||||||||
|
|
||||||||
| ### Role definitions | ||||||||
|
|
||||||||
| - Chair / Co-Chair: Responsible for coordinating the group, scheduling meetings, renewing the group’s membership, and ensuring that the group’s activities align with its scope and responsibilities. | ||||||||
|
There was a problem hiding this comment.
Question: The security team doesn't have meetings at the moment. Everything we do is fairly reactive based on reports. What do you imagine these meetings containing? More strategic process improvements? What cadence do you imagine? There was a problem hiding this comment. I think these meetings would be reactive, not regularly scheduled. Everything within this charter can be done async from what I can see, so I wouldn't expect meetings unless something new crops up that requires one. There was a problem hiding this comment. AFAIK we never had meetings as such; and as far as reactive actions go -- I'd imagine it the triager's responsibility to make sure that reports are properly handled, at least up to the point where either the report is dismissed or a patch is ready (especially, as the common practice is to ask reporters to verify the patches -- so this still falls under "communicate with them"). So the responsibilities I see remaining open are:
There was a problem hiding this comment. I think it would be valuable to have some form of scheduled meetings: not for handling individual reports, but for meta-level discussions. For example, we have ongoing topics like defining a unified view of security reports (and agreeing on the tooling for it), refining our documented policies and canned responses, handling AI-generated reports, and coordinating CNA work. For example, the Ops team's have monthly meetings and those have been quite useful for the Fellows, both to surface cross-cutting issues and to keep momentum on shared tasks. |
||||||||
| - Report triagers: These team members are responsible for acknowleding and triaging reports initially to determine likelyhood of security concern and severity. | ||||||||
|
There was a problem hiding this comment. Suggestion: How many people do you imagine wanting as explicit "Report triagers"? I realise the goal is to take the initial triage work from the Fellows, but I wonder if this could be resolved across all members, rather than needing named roles. This is the majority of the work, so I wonder hat everyone else is doing There was a problem hiding this comment. As many that helps the team be sustainable I imagine. How many would be needed if each person is spending 1 hour per week? There was a problem hiding this comment. Security reports don't arrive on a predictable cadence, so I'm not sure this is a useful way to talk about the work. Over the past three months (July-August-September 2025), I count eight members of the team who've been first to post something in response to a newly-received report. If I push it back to six months (going back to April), it's ten members out of thirteen in your list of the current roster. Some people are more active at this than others, of course, and to some extent it's unpredictable just owing to lots of people living in different time zones and on different schedules. But if there's a need to formalize something, perhaps formalizing some sort of "on call" setup, with a schedule where people are expected to check at least once in a given time period and post the initial response if nobody else has, would be more productive, since the important thing for the security team is not having people put in a flat amount of work per week, but rather ensuring that any given report receives a first analysis within a certain time after being received. Though I think that's something which doesn't require formal role assignments and should be worked out in the team itself so that it can be flexible. There was a problem hiding this comment. There's two separate roles here, that this discussion conflates IMO:
While many of us have done initial assessment, I think a lot less of us have engaged with reporters -- I haven't checked methodically, but this is my sense of things, and I know that personally I'm much more likely to behave this way. Also (as I wrote above), even when we do make the initial response, we've learned to trust the Fellows to follow up and make sure the report is resolved -- and if we want to relieve the Fellows of this burden, then I do think a Triager role is warranted. There was a problem hiding this comment. I agree with Shai that there are two related but distinct responsibilities: acknowledging incoming reports and performing the initial internal triage. Often the same person does both, and historically this has usually been a Fellow (an ad-hoc, implicit approach so far). Whatever structure we decide (dedicated triagers, rotating on-call, or shared across the team), the Fellows would appreciate having it documented so expectations are clear. Importantly, the Fellows have expressed need fr more support from the rest of the team (whether through general participation or assigned roles) to handle these two initial tasks more proactively. (Many thanks to Shai and Simon, who have already been notably involved in this area.) There was a problem hiding this comment. Do we need a dedicated role for this? Works without that since ... ever?? There was a problem hiding this comment. I tried answering this in the "Creating report triager role" section on the description of the PR. There was a problem hiding this comment. I wonder if the need here isn't better expressed by "The Fellows need more support handling initial reports and we either need more security team members, or existing members to be more active, or likely a bit of both". I'm not sure about a half-member role 🤔 There was a problem hiding this comment. I agree with Carlton and have commented along the same lines above. I would just add that the proposed Triager role was discussed and is intended as a compromise to help some existing members feel more comfortable, so that initial report tasks do not come as unexpected or extra work. Personally, I would prefer a single type of member with everyone committing to all responsibilities, but this approach perhaps may help smooth the transition... |
||||||||
|
|
||||||||
| ## Future membership | ||||||||
|
|
||||||||
| The team does not have a fixed size. The team decides when new members are needed. New members are chosen from a list of volunteers. If there are no qualified volunteers the team will place an advertisement on the Django website. | ||||||||
|
There was a problem hiding this comment. Actually, historically, members were added not so much in response to the team feeling more people were needed, but when someone in the team thought some specific volunteer might be a good fit to add. |
||||||||
|
|
||||||||
| Members must opt-in to remain on the team on an annual basis. They may also leave for any reason. | ||||||||
|
|
||||||||
| Members can also be removed by: | ||||||||
|
There was a problem hiding this comment. Question: Due to the nature of the team, keeping it reasonably small (or at least, not larger than it needs to be) is a useful feature. Should there be some kind of expectation around how active someone is on the team being a pre-cursor for keeping their place? There was a problem hiding this comment.
I agree in principle, but I think this should be something the team discusses and decides. I'm fine with that occurring here, just letting you know that I'm not the one to drive that. There was a problem hiding this comment. I think not -- there's a couple of people who've been on the team for a very long time, and have specific expertise which is of great value even if they only join discussions about once a year. There was a problem hiding this comment. I fully appreciate the value of long-standing members and their institutional knowledge. At the same time, from the Fellows' perspective, it would be very valuable that all/most team members participate in acknowledging incoming reports and performing the initial triage. Whether that requires a metric or something else, I'm not entirely sure (but very open to keep talking about this). As an additional thought, if we want to consider role distinctions, one approach could be to create a title or label for members with continuity and institutional memory rather than a separate triager role. This would help make the actual active staffing more visible and support realistic planning and distribution of work, while preserving expertise and knowledge within the team. |
||||||||
|
|
||||||||
| - Becoming disqualified by the Code of Conduct working group | ||||||||
| - A vote of the Steering Council | ||||||||
| - The full consensus of the rest of the Security Team | ||||||||
|
There was a problem hiding this comment. What does full consensus mean? Everyone but the affected member? |
||||||||
|
|
||||||||
| ### Membership requirements | ||||||||
|
|
||||||||
| Members should possess some knowledge of the following topics, but not necessarily all of them. | ||||||||
|
There was a problem hiding this comment. Nit: Given the scope, experience in all of these is pretty handy, not just some. There was a problem hiding this comment. I sort of agree, I would also include "Software performance" since a good chunk of the reports we get are about "Potential DoS on due to poor performance on ". Proposal:
Suggested change
|
||||||||
|
|
||||||||
| - Building Django applications | ||||||||
| - Contributing to Django | ||||||||
| - Web applications | ||||||||
| - Web security | ||||||||
| - Software security | ||||||||
|
There was a problem hiding this comment.
Suggested change
|
||||||||
|
|
||||||||
| ### How to join | ||||||||
|
|
||||||||
| Any person can volunteer to join the security team by submitting a Google Form (TODO: Create link). The team/WG will vote (50%+1) to approve/deny new members; the team/WG will directly vote on new Chair/Co-Chairs. | ||||||||
|
There was a problem hiding this comment. I do not think the security team should have a standing application form. If new members are added only when needed, and the need does not arise very often, a continually-open application form has multiple problems:
So this should instead define that the team will, when the team decides, open up applications for new members, but that at other times there will be no standing application/volunteer form. There was a problem hiding this comment. Huge +1 from me. I think keeping the security team as invite-only has a lot of benefits. The noise we get from reports alone at the moment is enough - if "Can I join" is added to that it'll get unwieldy There was a problem hiding this comment. Can you both consider the value added by allowing people from outside our typical networks to lend their support please? There are Django community members who have jobs in the security world that may be interested in helping and have beneficial and/or different skillsets that you're unlikely to invite because your circles don't overlap. My assumption here is that there's benefit in increasing the diversity of thought/background/skills. I could [easily] be wrong [in my assumption, it happens often 😁]. The logistical challenges you both present are real, but surmountable in my opinion. Though if the value isn't there, we definitely shouldn't take those challenges on. There was a problem hiding this comment. The thing with a security team is that "larger" is not automatically "better", because more people means more difficulty coordinating and more difficulty managing access to sensitive information. And people who work in security tend to be aware of that, so will expect that the Django security team is likely to be kept on the small side and recruit when needed rather than be constantly taking in new members (in fact, I'd expect an always-open process to bring more people in to the security team would actually be seen as a red flag by a lot of people who do security professionally). Is there some sort of specific target size that the SC/DSF Board have in mind for this team that's not coming through in this discussion? Is there some other reason why, despite getting negative feedback multiple times, this application/recruiting process keeps getting pushed in these drafts? There was a problem hiding this comment.
I suspect it's the history I noted above: The Security Team is one of the last places, maybe even the very last, where there is no process of open application, and the only way to get in is by invitation from an existing member. I don't think @tim-schilling is trying to make the team larger, but to make it more diverse. And we do have a problem here, similar to the one we had in the old Core -- as one obvious example, the only way women ever got in the team has been as Fellows. I don't really have solutions. But I'm not sure the balance we have now between the different requirements is the right one. There was a problem hiding this comment.
No, there isn't.
Besides the reasons outlined in the description of the PR, no. There was a problem hiding this comment. This (and other items in this proposal) are the distilled processing of direct requests from the Fellows. While the Fellows are responsible for "Monitoring security reports and ensuring security issues are acknowledged and responded to promptly" (see call for applicants), we still need help and a supporting Security Team. I understand that an ever-growing security team does not scale, and I agree that is not the goal. For me, the goal is twofold:
We could define a schema where, while the daily (or weekly or monthly) active members are under 5, the application form (or whichever process) is open. When we reach that sweet spot, we close it. If we find we are lacking expertise on a given topic, we may reopen with a more tailored focus, etc. In summary, I would keep the item in place but adjust the wording to note that the application may be open or closed at times depending on the team's needs. This could be revisited monthly during the proposed team's regular calls (as mentioned in previous PR items). I would also define somewhere what an "active" member is because, while I fully value the historical capital, the Fellows need more hands-on members in the team to help with the bulk of the report management work that may not necessarily require refined security expertise until later in the process. |
||||||||
|
|
||||||||
| The application should include the following: | ||||||||
|
|
||||||||
| - Why do you want to join the team? | ||||||||
| - What is your history of using Django as a developer? | ||||||||
| - What is your history of contributing to Django? | ||||||||
| - What security experience do you bring that would be helpful to the team? | ||||||||
|
There was a problem hiding this comment. I would request that applicants can prove their existing involvement with Django, either via DSF membership, affiliation with an existing WG or team, or being a Django patch author, etc. |
||||||||
|
|
||||||||
| (TODO: Define cadence of reviewing applications) | ||||||||
|
|
||||||||
| ## Budget | ||||||||
|
|
||||||||
| No budget is required at this time. This will be reviewed at least annually. | ||||||||
| Any changes to the budget may be requested from the board. | ||||||||
|
|
||||||||
| ## Comms | ||||||||
|
|
||||||||
| The team has discussions in two places: | ||||||||
|
|
||||||||
| 1. Formal and sensitive discussions on the mailing list: [email protected] | ||||||||
|
There was a problem hiding this comment. It's OK to start off with this but we have very very recently agreeing to leave the mailing list purely to receive reports and that team-internal conversation would happen in a report-centralized place which will likely be GH. |
||||||||
| 2. Informal and team discussions on the DSF Slack in the private channel `#security-team` | ||||||||
|
There was a problem hiding this comment. Just wondering: does the slack channel already exist, or is this proposed? There was a problem hiding this comment. I guess it's a proposal then? I thought it did, but things are getting muddied in my brain. There was a problem hiding this comment. Is there even a need for a Slack channel for the security team? For the things the team handles, the fewer places that contain the information, the better. There was a problem hiding this comment. I think it's more important to document what the team is doing here or wants to do than to propose a change. IMO, I'd leave it to them to expand and agree on adding Slack. This was an oversight based on what other Teams/WGs are doing. There was a problem hiding this comment. How does one join the DSF Slack? 👀 It was only recently I learned it existed. I don't think it's part of the team onboarding process. There was a problem hiding this comment. I had no idea there was a Slack team at all. That being said, I'd rather have us not add another communication channel, if multiple channels already exists. However, there are indeed discussions on unifying those channels. Also, as already stated, using Slack adds another vector where security information could be exposed. There was a problem hiding this comment. Like @MarkusH , I learned from this suggestion about the existence of a DSF Slack. As noted, the team keeps a private repo on github. Some discussions, and patch preparations, happen there, and there is a current suggestion to move more of the formal communications into it. There was a problem hiding this comment.
Suggested change
There was a problem hiding this comment. I think the security team would benefit from a communication channel with better speed and responsiveness than a mailing list, such as Discord, Slack, Signal, or a similar platform. The DSF Slack feels like the most natural place for this since it is already set up and includes private channels for discussing important and sensitive matters (for example, the Code of Conduct WG discuss their matters in a private channel in the DSF Slack). The Fellows already use their private Slack channel to discuss security issues, so Slack is not unaware of these matters. The Fellows would also benefit from having a shared, private channel with the team members for better and speedy decision making. If we are going to be very strict about the principle that "the fewer places that contain the information, the better," we should also consider how email providers themselves could already be compromising Django security. 🤷 Using Slack or another similar platform would centralize discussion while maintaining confidentiality and speed of coordination, I'm +1 to adding such thing. |
||||||||
|
|
||||||||
| ## Reporting | ||||||||
|
|
||||||||
| The team has two responsibilities in regards to reporting to the Board and the Steering Council: | ||||||||
|
|
||||||||
| 1. Use [Django Release Announcements thread](https://forum.djangoproject.com/t/django-release-announcements/655/96) on the Forum to report security releases | ||||||||
| 2. An annual report summarizing the team's activity, areas of concern, considerations for the future and any other relevant topics | ||||||||
|
There was a problem hiding this comment. Would this report be another role that the Team Chair/co-Chair should take upon themselves? There was a problem hiding this comment. Yes, that would be very likely, though I don't think it has to be formalized. If someone else on the team wanted to produce it, I think that'd be agreeable. Though if I were wondering what the status of the report was, I'd reach out to the chair/co-chair. |
||||||||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This could be understood in two ways:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, it sounds like we may need to flesh this section out a bit further then. I will need some help with that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point! In practice we do get reports through security@, HackerOne, and occasionally public tickets. Tim, I'm happy to help going thru those details.
Furthermore, not everyone on the team currently has HackerOne access or follows it, so there's an uneven and awkward split in who sees what (some people has access to both (mailing list and hackerone), some only to hackerone and some only to the mailing list). It would be useful to spell out that all team members should have access to, and share responsibility for, all sources to avoid gaps and spread the work more evenly.