Add security working group #38
Conversation
|
Thanks @robhudson for getting this started! |
|
Cc @django/django-security-team |
There was a problem hiding this comment.
Thank you @robhudson! See #28 and #36 for related work about using the working group structure for teams. For this charter – I think it’d be good to know more about how you arrived at the wording of the different sections. Whether it’s based on an existing definition of the security team, or derived from the accessibility team work in #34, or something else.
| - Board Liaison (must be an active Board member; may be the same as Chair/Co-Chair): TBD | ||
| - Other members: | ||
| - TBD | ||
| - ... |
There was a problem hiding this comment.
I assume this will be the Security team members as-is?
There was a problem hiding this comment.
This is perhaps a good opportunity to check with the existing members whether they'd like to continue their position.
I think at least for the migration to a WG, we shouldn't switch members too much during the transition.
There was a problem hiding this comment.
We did a round of that at the end of last year, so I don't think we need to do another check-in quite so soon.
| ### Who is eligible to join? Any volunteer, or are there specific requirements? | ||
|
|
||
| Members must have interest in Django security and should have experience with web security concepts, particularly as they relate to Django applications. Prior experience with Django and its security mechanisms (e.g., CSRF protection, XSS protection) is highly recommended. Members should be familiar with the Django [security release process](https://docs.djangoproject.com/en/dev/internals/security/) or willing to learn. | ||
|
|
||
| We welcome contributors with various levels of experience, but due to the sensitive nature of security work, members should demonstrate a track record of responsible security practices. Experience with security vulnerability assessment, analysis, or remediation is a plus. |
There was a problem hiding this comment.
I think this needs to be a little stricter. Because the WG deals with vulnerability reports, I think this needs to retain the "invite only" nature.
Membership takes more than just "experience with web security concepts".
| This working group will focus on security aspects of the Django project. The team will be responsible for addressing security concerns, reviewing vulnerability reports, and providing guidance on security best practices throughout the Django ecosystem. | ||
|
|
||
| The duties of the working group are: | ||
| - Receive, triage, and respond to security vulnerability reports for Django |
There was a problem hiding this comment.
Suggestion: Explicitly mention that other projects under the Django umbrella are in scope.
| - Receive, triage, and respond to security vulnerability reports for Django | |
| - Receive, triage, and respond to security vulnerability reports for Django and associated projects |
| - Monitor the security landscape to proactively identify potential vulnerabilities | ||
| - Help maintain Django's security documentation | ||
| - Develop and maintain security-related packages in the Django ecosystem | ||
| - Provide security advice to Django package maintainers when requested |
There was a problem hiding this comment.
Suggestion: If this is going to be done, I think it should be separate from the vulnerability report address, which is already fairly noisy from spam.
There was a problem hiding this comment.
What's the concern here @RealOrangeOne? I'm not sure I'm seeing the whole picture.
| - Assist with security aspects of the djangoproject.com website | ||
| - Mentor new contributors interested in Django security | ||
| - Run or support security-focused sessions in DjangoCon sprints | ||
| - Chair, Co-Chair and Board Liaison can sign off on security decisions |
There was a problem hiding this comment.
Question: What is a "security decision"?
There was a problem hiding this comment.
Also... sign off... — who's doing that?
WG's get their powers from the Board or (since #36) the Steering Council. (The point being there that the Board doesn't have responsibility for technical decisions.) Security being a technical question, those powers would come from the Steering Council.
DEP 10, however, has explicit mention that the SC may not hold up a release (for example) that the Security Team has approved. That makes sense: the SC aren't going to hold up a security release.
In this sense (at least some) Security Team decisions are not to be signed off even by the body (SC) which extends them their powers (under the WG rubric).
I can imagine other aspects which could be referred back to the SC, at least in principle.
I think all that could do with clarifying.
There was a problem hiding this comment.
If the wording is meant to be that the Chair or Co-Chair approve security releases, I'm not opposed to that, even if just to ensure the WG are wholly aligned on the release.
There was a problem hiding this comment.
For what it's worth, DEP 10 explicitly intended for the security team to have the power to act on its own initiative without needing to consult any other governance body in advance, because sometimes the security team has to get something out the door Right Now. The idea was that the appropriate technical governance body could review after the fact and ask for further action to be taken, but would never be able to prevent security team action or require approval in advance.
|
|
||
| ### Access granting and deployment | ||
|
|
||
| Initial onboarding phase where only Chair and Co-Chair have permissions to access security reports and coordinate responses. After onboarding of 6 months, other group members who have proven their expertise will be granted access to the security issue tracker and response coordination at the discretion of the chair and co-chair. |
There was a problem hiding this comment.
Thought: This seems to separate being on the WG and being involved in vulnerability response. That feels like it creases an "inner circle" in the group, which should probably be avoided.
| Individuals can express interest by opening a PR to this working group repository using a template, adding their names in the list of members along with a brief description of their security experience and motivation to join the group. | ||
|
|
There was a problem hiding this comment.
Issue: I think this needs to remain invite-only.
There was a problem hiding this comment.
Would there be a benefit to having an avenue for community members to register their interest and state their experience to join? I don't think that necessarily means they would be able to join. The Fellowship and CoC work similarly where the membership is tightly controlled and not open.
There was a problem hiding this comment.
There used to be a process to apply to receive advance notification of security releases, which included details and patches. This was intended for packagers/distributors of Django and for some of the largest and potentially highest-impact organizations using Django, to give them a bit more time to prep for a security release and to ensure they didn't get caught by surprise.
But that just attracted way too many low-quality applications from people saying "I am interested in this, please add me to the list", and eventually it was wound down. Now we have a different process where a small list -- which does not have a public application process and is managed entirely by the security team -- of entities (i.e., Linux distros) get full details in advance and there's a public mailing list that gets generic statements that there will be a release on $DATE fixing $NUM issues of $SEVERITY_LEVEL.
I think any sort of "register your interest" would end up the same way, and I don't want to create anything that would give people the expectation they'd be added to the security team eventually if they fill out a form and wait.
|
|
||
| Members join the group for one year term. At the end of this term, they need to opt into staying involved to keep being a member of the group. | ||
|
|
||
| Due to the sensitive nature of security work, members who fail to adhere to responsible disclosure practices or exhibit other concerning behavior may be removed by a vote of the working group (50%+1) or by decision of the Chair and Co-Chair in consultation with the Board Liaison. |
There was a problem hiding this comment.
Issue: I think for the sake of Django's security, this needs to be a little stricter.
| Due to the sensitive nature of security work, members who fail to adhere to responsible disclosure practices or exhibit other concerning behavior may be removed by a vote of the working group (50%+1) or by decision of the Chair and Co-Chair in consultation with the Board Liaison. | |
| Due to the sensitive nature of security work, members who fail to adhere to responsible disclosure practices or exhibit other concerning behavior will be removed by a vote of the working group (50%+1) or by decision of the Chair and Co-Chair in consultation with the Board Liaison. |
| ## Communications | ||
|
|
||
| - Private channel in the DSF slack for internal discussions | ||
| - Encrypted communication channels for sensitive security discussions |
There was a problem hiding this comment.
Thought: This currently happens by email (without PGP). Is there a need to keep this separate.
For context, the Wagtail security team do all discussions in a private Slack channel.
|
|
||
| Sums may be provided for specific activities (e.g. security audits, external consultancy, security tooling, bug bounty programs) subject to approval by the DSF board. | ||
|
|
||
| ## Communications |
There was a problem hiding this comment.
Suggestion: To ease openness, since by definition the group is fairly closed, should there be some kind of discussion minutes / monthly updates from the team? Obviously vulnerability details (even number of reports) can't be included, but other discussions probably can be. That way people outside the WG can get involved in some discussions.
I'm thinking in a similar model to what the current Steering Council do.
|
|
||
| ## Reporting | ||
|
|
||
| We'll maintain a private log of all security reports and their resolutions. Public disclosures will follow Django's established security release process. |
There was a problem hiding this comment.
There's an email history from the list, but otherwise I don't think there's a "log" of reports (besides ones which are published).
|
Echoing a lot of what @RealOrangeOne said about the need to keep the security team private and invite-only. But also expanding on that: perhaps copying a template for another WG is not the best way to go about this, given the significant differences in the security team's operations. And even maybe take a step further back and ask whether this is necessary. What can't we do, today, that we need to do, with the "Django Security Team", that we suddenly could do if it became the "DSF Security Working Group"? I can't think of anything. And philosophically, the technical teams which are concerned with the Django codebase have, I think, tended not to become DSF WGs; DEP 10 envisioned Django's technical teams coordinating with the Technical Board/Steering Council, not with the DSF Board. Accessibility is a bit of an exception because its remit was always a lot broader than just (say) the main Django framework's repository, but the security team's focus has always been narrower in a way that I think doesn't really make sense as a DSF WG. |
|
|
||
| - Conduct periodic security reviews of Django's codebase | ||
| - Monitor CVEs and other security disclosures for relevant vulnerabilities | ||
| - Explore integration of additional security tools in the Django development process |
There was a problem hiding this comment.
How we approached this with the Accessibility Team was to redefine it here with the existing scope with minor adjustments to scope and governance. I think reducing these to what is done today and what is needed to keep Django moving forward may work better for this PR.
The Accessibility Team wasn't redefined as a Working Group to grant it additional powers. Though it did have the nice benefit of formalizing a relationship between it and the Steering Council via a liaison. The main purpose was to define some boundaries and interfaces for people to interact with. It allows for people to know what to expect from the group and what the expectations are being a part of the group. Perhaps this part of the PR discussion should move to #28? |
|
I agree with @ubernostrum and @RealOrangeOne, and would go even further: This suggestion is not a technical change, it is a substantial change in the way the security "sub organization" (to avoid using "team" or "WG") works. IMO, the current way it operates is not perfect, but very far from "broken", and I don't feel the need for a major fix. Looking at the suggested list of duties, I see some that we currently only handle on specific request:
and I think that's ok; I also see some we don't really handle, as a team, at all:
Notably, all of these are things which do not require the care and privacy that we hold in the current Security Team. So, a WG for these, existing alongside the Security Team, might be better. Further, AFAICT none of these require any delegation of authority from the DSF Board or the SC. It can be started in the community, with no formalities, and "upgrade" to a formal WG later, with established membership, if there's a reason. |
The security team already has both Fellows in it, and as much of its "work product" as possible is already publicly recorded. So I'm still trying to figure out what concrete problem you're hoping to solve with this. I'm also a bit worried that it looks like all the feedback you've gotten so far from members of the security team has been negative but it feels like the response is to try to push this forward anyway. |
|
Hi @django/django-security-team, please hold off on further reviews temporarily. The scope in this PR is broader than what is intended for the work coming out of #28. I'd like the opportunity for @jefftriplett and I to work with @robhudson to pare this down to the governance changes and what the security team's scope is today. #28 is not meant to be a significant change to your roles. We'll use the request a review feature from the team when it's ready for input and review. Thank you @RealOrangeOne and @shaib for identifying specific improvements, listing out the duties that are handled and which aren't. That will be helpful in the above effort. @ubernostrum, one of the pieces of feedback the board and the steering council have heard from the Fellows is that each team should have the following:
I hope that clarifies what problem we're trying to solve. Another solution to this problem was to revamp the teams structure to account for these. However, the Working Group definitions already covers all of this and only required some small tweaks to also account for teams. That's why the board and the steering council are moving in this direction. |
While working on the content security policy feature I was looking to see if there was a security working group with the responsibilities proposed here. I also noticed the pull request to supersede the accessibility team to a working group, so I made the assumption that a similar change could be made for the security team. Very much open to suggestions and guidance as I'm not currently involved with other WGs or the security team.