Skip to content
Open
Changes from 9 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
117 changes: 117 additions & 0 deletions active/security.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,117 @@
# 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
- Evaluating and developing fixes for confirmed security issues
- Applying, backporting and releasing those fixes as patches and Django releases
Comment thread
tim-schilling marked this conversation as resolved.
Outdated
Comment thread
tim-schilling marked this conversation as resolved.
Outdated
- Communicating with reporters
- Communicating with the public about security releases
- Communicating with operating-system vendors and other distributors of Django
Comment thread
tim-schilling marked this conversation as resolved.
Outdated
Comment thread
tim-schilling marked this conversation as resolved.
Outdated
- Maintaining the DSF's status as a CVE Numbering Authority (CNA) and casting votes (or abstaining) in CNA elections
Comment thread
tim-schilling marked this conversation as resolved.

## Membership
Comment thread
tim-schilling marked this conversation as resolved.

- Chair:
Comment thread
tim-schilling marked this conversation as resolved.
Outdated
- Co-Chair:
Comment thread
tim-schilling marked this conversation as resolved.
Outdated
- 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
Comment on lines +24 to +34
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thought: As part of formalizing the charter, should we pre-seed the triagers role with those interested? Currently it looks like the team is incredibly understaffed despite that (probably) not being the case.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree we should fill this but I don't think it's a requirement for merging (as we need to keep the list up-to-date anyway)


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.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Question: Why?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The DSF president is the Google org admin which means they have access to everything. That includes the security mailing list.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, I misinterpreted "has access to" as "receives emails" 👍

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we should mention that this is a by-product of the Google org set up in the charter?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FYI the president does receive every email just like the Security Team do. Unclear how that changes things :-)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you @jefftriplett for the clarifying comment. I think it would be a good idea to capture this valuable information in the charter, how about something like:

Suggested change
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.
Note: The DSF Board President has access to the security mailing list for governance oversight and legal accountability purposes. This is a longstanding practice and is mentioned for the sake of transparency.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @jefftriplett , that helps understand a lot. But still, the current wording, and even @nessita 's suggestion, don't explain the discrepancy between the mailing list and other team communication channels. I'm not sure it can be done very concisely, and since this is just a side note, it shouldn't get out of hand.

I tried to come up with something that's still short, and more concrete than "governance oversight and legal accountability", and failed. So I'm +0.5 on the suggestion.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We recently adjusted the Fellow's contractual language to read... "designated reporting channels and ensure they are acknowledged and handled promptly" on the off chance that it helps to reword it.

Maybe this?

Note: The DSF Board President has access to the designated reporting channels for governance oversight and legal accountability. This is a longstanding practice, noted here for transparency.

That drops "mailing list," which is more of a designated reporting channel, vs. adopting Slack, Signal, or something else for internal communications. I think governance-wise, we just want to know that messages that are being reported/incoming are getting handled, and something is going out on the off chance that everyone quiet quits, and the rest we already outlined.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, thank you both. I like this a lot.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Resolved by 9c1f116


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.
Comment thread
tim-schilling marked this conversation as resolved.
Outdated
- **Report Triagers:** Acknowledge and triage initial reports and communicate with reporters.

#### Report Triager
Comment thread
tim-schilling marked this conversation as resolved.

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.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thought: Should there be some kind of expected tenure for the Report Triager role? My thinking being that if people are free to rotate "as schedule allows", it may not be explicit when they do, so the entire team could step back assuming the rest of the team can pick things up.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Although I like the idea, I don't think we need to define a process here as Fellows would fill this role if we ever had a whole team step back


The responsibilities of a Report Triager are as follows:
Comment thread
tim-schilling marked this conversation as resolved.

- 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
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could this be a tiny bit looser and allow for the same triager to progress it?

Copy link
Copy Markdown
Member Author

@tim-schilling tim-schilling Apr 22, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- For valid reports, hand-off to team member to own the report
- For valid reports, hand-off to a team member to own or retain yourself to progress

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One important consequence of this definition, which I think should be highlighted, is that each report is to have a more-or-less formal designated owner, at each point since its first acknowledgment. This is, as far as I'm aware, not how we do things now, and keeping it real requires a more formal process of managing reports (e.g. so long as reports are actually handled on the mailing list, it's very hard to ascertain who the owner of each report is, and if all reports are actually owned).

Note, I'm not at all opposed to this -- I'm sure it would make it much easier to verify that things are not falling between cracks -- but to be effective it also requires tooling, and while such tooling has been discussed on the team, this is very much a work-in-progress.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, as this should be a living document, I think we should just say "Optionally engage in the progress to resolution" so that we explicitly say a triager can still help in the creation of fixes/reviewing of fixes for the reports they triaged.
Processes around ownership we can add later once we actually have a proper process and tooling to support this (of course there is an informal process that the Fellows track things).

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tend to agree -- but note that this takes all the teeth out of the "Responsibility" language (see https://github.com/django/dsf-working-groups/pull/56/changes#r3110503550 -- that's a resolved comment on Line 55 in the current version).

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ownership/responsibility is still an open issue AFAICT

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- For valid reports, hand-off to team member to own the report
- For valid reports, state reasoning/opinion and whether wish to engage further in the progress to resolution (e.g. create a PR to resolve the issue)

Perhaps something like this

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe I have resolved this in 9c1f116
Please make a concrete suggestions if not

- 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.
Comment thread
tim-schilling marked this conversation as resolved.
Outdated

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:
Comment thread
tim-schilling marked this conversation as resolved.
Outdated

- 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
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does full consensus mean? Everyone but the affected member?

Copy link
Copy Markdown
Member Author

@tim-schilling tim-schilling Oct 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct (this wouldn't be my preference, but is what I saw from other Security team documents)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is too strong and we should remove it. May I ask where did you see this?

Copy link
Copy Markdown
Member Author

@tim-schilling tim-schilling Apr 22, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I pulled this from the accessibility team's requirements. https://github.com/django/dsf-working-groups/blob/main/active/accessibility.md?plain=1#L87

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I couldn't find what I thought was a security team document. It had to be the accessibility team charter since I was using that as inspiration for this one.

Copy link
Copy Markdown
Member

@shaib shaib Apr 22, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm with @nessita -- we don't need this; if a member of the security team is so troublesome that most (even not all) of the rest of the team want to remove them, it is better to require the involvement of the Steering Council.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After writing the above, I saw that @nessita was actually suggesting only the removal of the "full consensus" requirement. I disagree.

Copy link
Copy Markdown
Member Author

@tim-schilling tim-schilling Apr 22, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@shaib If you're suggesting we remove this line entirely and only allow the CoC and SC to remove a member, I don't think you're in alignment with @nessita. She believes (and I agree) that a smaller group of members who agree to remove a person should be sufficient. In https://github.com/django/dsf-working-groups/pull/56/files#r3124348422 it outlines it as "A vote (50%+1) of the existing team members"

Edit: I wrote the above before I saw the edits and follow-up. Whoops! Sorry to reiterate your conclusion.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right.


### 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
Comment thread
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.
Comment thread
tim-schilling marked this conversation as resolved.
Outdated

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?
Comment thread
tim-schilling marked this conversation as resolved.
Outdated

(TODO: Define cadence of reviewing applications)
Comment thread
tim-schilling marked this conversation as resolved.
Outdated

## 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
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I subscribe to the later suggestion above, that we shouldn't include our tools for accepting reports in the charter.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@shaib this is more describing how the team communicates with each other, less on how reporters communicate with the team. Teams and working groups that have an email list have listed them in this section of their charters.

2. Informal and team discussions on the DSF Slack in the private channel `#security-team`
Comment thread
tim-schilling marked this conversation as resolved.
Outdated
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Slack channel is named security-private (minor FYI).

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Much like there's a public channel for the steering council, should there be a public one for the security team too? That way there's a single entrypoint for security-related conversations that don't necessarily need to be in the private team-only channel?

(Perhaps bikeshedding a little here).

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's leave that out for now: every new channel causes more fragmentation.


Comment thread
tim-schilling marked this conversation as resolved.
Comment thread
tim-schilling marked this conversation as resolved.
## 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
Comment thread
tim-schilling marked this conversation as resolved.
Outdated
2. An annual report summarizing the team's activity, areas of concern, considerations for the future and any other relevant topics
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would this report be another role that the Team Chair/co-Chair should take upon themselves?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.