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,116 @@ | ||||
| # Security Team | ||||
|
|
||||
| The Security Team is the group of people who respond to security reports for the Django framework. | ||||
|
|
||||
| ## 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 security@djangoproject.com | ||||
| - Evaluating and developing fixes for confirmed security issues | ||||
| - Applying, backporting and releasing those fixes as patches and Django releases | ||||
|
Contributor
There was a problem hiding this comment. Technically only a merger and releaser would be able to do this. Perhaps we need to state that at least one merger and releaser needs to be on the team and that this is covered by the Fellows |
||||
| - Communicating with reporters | ||||
| - Communicating with the public about security releases | ||||
| - Communicating with operating-system vendors and other distributors of Django | ||||
|
tim-schilling marked this conversation as resolved.
|
||||
|
|
||||
| ## Membership | ||||
|
Contributor
There was a problem hiding this comment. Should we mention that Fellows are automatically members of the security team and therefore bypass any normal new membership process? Fellows will have been granted the releaser and merger roles and so can (at a minimum) handle the security releases |
||||
|
|
||||
| - Chair: | ||||
| - Co-Chair: | ||||
| - Report triagers: | ||||
| - Steering Council Liaison (must be an active Steering Council member; may be the same as Chair/Co-Chair): Frank Wiles | ||||
| - Other members: | ||||
| - Adam Johnson | ||||
| - Jacob Walls | ||||
| - Jake Howard | ||||
| - 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. | ||||
|
Member
Author
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.
Member
There was a problem hiding this comment. Ah, I misinterpreted "has access to" as "receives emails" 👍
Member
Author
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?
Contributor
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 :-)
Member
There was a problem hiding this comment. As someone who admins a few fairly large Google Workspace organisations, I'm happy to have a poke at resolving this, rather than documenting it.
Member
Author
There was a problem hiding this comment. Sounds good @RealOrangeOne, I think you can work with @thibaudcolas to do that.
Member
There was a problem hiding this comment. Thought I’d responded but I can’t see my comment! This access is very much by design, it’s not an artifact of our Google Workspace setup. Why the access is there I can’t say but I believe historically the president email was added to every group(?) |
||||
|
|
||||
| Every member of the team is encouraged to participate in all aspects of the team, including reviewing security reports, developing fixes and communicating with reporters. The expectations for all team members are as follows: | ||||
|
|
||||
| - Participate in the process for at least one security report a year | ||||
|
|
||||
| ### Role definitions | ||||
|
|
||||
| There are specific roles that have a higher level of expectations: | ||||
|
|
||||
| - **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. The Chair and Co-Chair roles should be re-evaluated annually by the team. | ||||
| - **Report Triagers:** Acknowledge and triage initial reports and communicate with reporters. | ||||
|
|
||||
| #### Report Triager | ||||
|
Contributor
There was a problem hiding this comment. We have Should we have a minimum expectation target here as well so folks applying understand the work involved. For example: I think I would also want members to communicate holidays so we are aware that they are away. There was a problem hiding this comment. Joining at least 1 team meeting per year seems like a suitable check to identify those who are inactive. I like the generic "Participate in the process..." more than "Triage 1 report". |
||||
|
|
||||
| These team members are responsible for acknowledging and triaging reports initially to determine likelihood of security concern and severity. As this is a volunteer role, the Fellows will support the triagers and when necessary, handle the initial triaging. | ||||
|
|
||||
| Every member can adopt and step back as a Report Triager as their schedule allows. | ||||
|
|
||||
| The responsibilities of a Report Triager are as follows: | ||||
|
|
||||
| - Acknowledge report received | ||||
| - Initial assessment | ||||
| - Request help from team/experts if necessary | ||||
| - Progress to resolution | ||||
| - For valid reports, hand-off to team member to own the report | ||||
| - For invalid reports, communicate with reporter | ||||
|
|
||||
| ## 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. | ||||
|
Member
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: | ||||
|
Member
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?
Member
Author
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.
Member
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.
Contributor
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 | ||||
|
Contributor
There was a problem hiding this comment. What does full consensus mean? Everyone but the affected member?
Member
Author
There was a problem hiding this comment. Correct (this wouldn't be my preference, but is what I saw from other Security team documents) |
||||
|
|
||||
| ### Membership requirements | ||||
|
|
||||
| Members should possess some knowledge in most of the following topics: | ||||
|
|
||||
| - Building Django applications | ||||
| - Contributing to Django | ||||
| - Web applications | ||||
| - Web security | ||||
| - Software security | ||||
|
tim-schilling marked this conversation as resolved.
|
||||
| - Software performance | ||||
|
|
||||
| ### 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.
Member
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
Member
Author
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?
Member
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.
Member
Author
There was a problem hiding this comment.
No, there isn't.
Besides the reasons outlined in the description of the PR, no.
Contributor
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? | ||||
|
Contributor
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.
Member
Author
There was a problem hiding this comment. I feel like that may be covered in "What is your history of contributing to Django?" |
||||
|
|
||||
| (TODO: Define cadence of reviewing applications) | ||||
|
Contributor
There was a problem hiding this comment. I think "Applicants are reviewed as part of the team meetings" |
||||
|
|
||||
| ## 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: security@djangoproject.com | ||||
|
Contributor
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` | ||||
|
Member
There was a problem hiding this comment. Just wondering: does the slack channel already exist, or is this proposed?
Member
Author
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.
Member
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.
Member
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.
Member
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.
Member
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.
Member
Author
There was a problem hiding this comment.
Suggested change
Contributor
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.
Member
There was a problem hiding this comment. The DSF Slack is open to anyone who is actively involved with the DSF, if anyone here would like to be in there please let me know! We’re at 65 members currently. I believe most recently-created groups have decided to use it as their primary private comms space. Some also have "public" channels in there. And lots also have a presence on email, Discord, forum, or all of those. |
||||
|
|
||||
| ## 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 | ||||
|
Member
There was a problem hiding this comment. Would this report be another role that the Team Chair/co-Chair should take upon themselves?
Member
Author
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.
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.
I personally feel we can remove platform specific information. We link the security policy docs which has information on reporting. This currently doesn't mention HackerOne but if we want to document this. we should document it there. I don't think we want to have to update this page if we chose to update our reporting process