How the Django Software Foundation Became a CNA

Why the DSF pursued CNA status

Django has a long history of responsible security practices: a dedicated, private security mailing list, clear advisory policies, and predictable security releases. Even so, we relied on external organizations to assign CVE IDs (Common Vulnerabilities and Exposures). This sometimes introduced administrative delays and extra coordination overhead.

Becoming a CNA (CVE Numbering Authority) allows the DSF to:

• Assign CVEs ourselves for vulnerabilities in Django and selected community projects.
• Publish advisories more efficiently and in closer alignment with Django's established release workflow.
• Maintain strong independence in how Django handles security incidents.

The initial exploration

The process began with internal discussions within the DSF Board and Django Security Team. We evaluated:

• Whether our existing security process already met CNA expectations.
• Whether we had the organizational stability to take on long term responsibility for CVE assignment.
• The scope of projects we would cover.
• How to ensure we could meet the operational requirements without overloading volunteers and Django Fellows.

After confirming that our policies were mature and that the administrative workload would be manageable, we initiated the CNA application with MITRE.

Preparing the application

MITRE requires that new CNAs document their security processes and demonstrate that they can meet CNA obligations. Our preparation included:

1. Reviewing and updating the Django Security Policy.

2. Mapping our existing workflows to MITRE's CNA rules, including:

   1. How reports are received.
   2. How vulnerabilities are validated.
   3. How advisories are produced.
   4. How CVEs will be assigned and published.

3. Defining the scope of the CNA:

   1. Django itself as the core product.
   2. A small, clearly bounded set of related ecosystem projects.

4. Ensuring we had private communication channels and documented procedures for confidential handling.

5. Drafting the required procedural documentation for MITRE.

Most of the work here was not about creating new processes but about articulating long standing Django practices in the format MITRE expects.

Training and review

Once our initial documentation was accepted, MITRE scheduled us for CNA onboarding training. This covered:

• CNA rules and responsibilities.
• Required data fields for CVE Records.
• Expectations for coordination with reporters and downstream consumers.
• The publication workflow for CVE Records.

We also completed MITRE's required CNA onboarding exercises. As part of this process, we worked through sample security reports and demonstrated how we would determine CVE assignments, including cases where multiple CVEs may or may not be warranted for a single report.

Approval and onboarding

After MITRE approved our documentation, training, and exercise submissions, the DSF was formally granted CNA status. The announcements steps were:

• MITRE published our CNA scope on the official CNA directory.
• MITRE issued a press release.
• The DSF published a blog post announcing our new CNA status.

Lessons learned

A few procedural insights for other projects considering CNA status:

• If your project already has a mature and documented security process, becoming a CNA is mostly about formalizing what you already do.
• The documentation and validation steps take time. Most delays come from ensuring that all fields conform to the CVE schema. The whole process took about four months.
• The training is detailed and helpful. It clarifies exactly what CNAs are expected to produce and how CVE Records flow through the broader ecosystem.
• It is worth being explicit about scope early. Defining the boundary of responsibility reduces ambiguity later.

What changes for Django users

For most contributors and users, nothing changes. Django will continue to follow its established process for receiving reports, coordinating fixes, and publishing security releases.

The difference is that the DSF can now assign CVE IDs directly, which simplifies coordination and allows us to publish advisories with fewer external dependencies.

Acknowledgments

This work was led by Django Fellows Natalia Bidart and Jacob Walls, with support from the Django Security Team and the DSF Board. We are grateful to MITRE for their guidance during the onboarding process.

If you have questions about Django's CNA scope or security process, contact the Django Security Team.