Security Policy

The Rust Foundation takes the security of the software it maintains seriously. Thank you for taking the time to responsibly disclose any issues you find.

Reporting a vulnerability

If the affected project has its own security policy or private vulnerability reporting process, please follow that project’s instructions. For projects hosted on GitHub, for example, this may include a “Report a vulnerability” button on the Security tab of the affected repository. 

If the project does not provide its own reporting instructions, you do not have a GitHub account, the issue is not specific to one repository or project, or if you are unsure where to report an issue, please send an email to security@rustfoundation.org. You are not required to report the same vulnerability through multiple channels.

We aim to acknowledge reports within two business days. Once we have confirmed a report as a security issue, we will keep you informed of progress towards a fix and announcement. Reports we determine to be out of scope or not security issues, we will make a best effort to provide a timely single reply explaining that situation.

Please use a descriptive subject line, and please do not open a public issue, discuss the vulnerability in a public forum, or open a pull request containing a fix before the issue has been disclosed.

You may also report a vulnerability anonymously, or report it to a national Computer Security Response Incident Team (CSIRT) instead of, or in addition, to reporting it to us. If you believe we have misjudged a report, tell us and we may take another look. You can also raise your concern of a misjudgment with a CSIRT, independently of us.

Project-specific Security Policies

Projects covered by this policy may maintain their own security policies and vulnerability reporting procedures. Where a project-specific security policy exists, that policy may define the project’s preferred reporting mechanism, triage process, and disclosure practices. The project-specific security policy must be consistent with the applicable requirements of this policy, including escalation to the Rust Foundation of vulnerabilities or incidents that may trigger reporting obligations.

External reporters of vulnerabilities are not responsible for determining whether a vulnerability or incident is reportable under the Cyber Resilience Act (CRA) or for separately notifying the Foundation when they have followed the project’s designated reporting process. That coordination is the responsibility of the project and Foundation. 

Scope

This policy covers all repositories in all organizations under the Rust Foundation’s GitHub Enterprise account, including any organization or repository added in the future. This includes source code, build and release tooling, GitHub Actions workflows and other CI configuration, infrastructure-as-code, and published artifacts produced from those repositories, including crates we publish to crates.io.

The current public organizations under the Rust Foundation’s GitHub Enterprise Account are:

This policy covers any code under the direct purview of the Rust Foundation, even if not listed above.

When a repository publishes its own security policy, that policy governs how vulnerabilities in it are reported and handled. This policy is the default for repositories that do not have one, and states the Rust Foundation’s own commitments as an organization.

The following are outside the scope of this policy:

  • Vulnerabilities in the Rust language, compiler, standard library, Cargo, crates.io, docs.rs, and other Rust Project software. These are maintained by the Rust Project and are not within the scope of this policy, and should not be reported to the Rust Foundation. Please report them to the Rust Project according to Rust’s security policy.
  • Crates published to crates.io by parties other than the Rust Foundation or another project in scope of this policy. These are maintained by their own authors; see the RustSec Advisory Database. Please contact security@rustfoundation.org for potential help in contacting the owners of those crates.
  • Vulnerabilities in third-party hosted services the Foundation uses but does not operate. Please report those to the vendor. If you believe that Rust Foundation data, accounts, or systems at such a vendor may be affected, that would be in scope and thus please contact security@rustfoundation.org.

When reporting, please keep in mind:

  • Archived repositories and other software explicitly designated as unsupported may no longer receive security fixes. Security issues with continuing consequences for users, downstream projects or Foundation-operated systems may nevertheless be reported so that we can assess whether notification, mitigation or another action is appropriate.
  • Generally, repositories or components explicitly marked experimental, examples, testing, prototype, or unreleased are not treated as shipping software for security purposes. Exceptions to this could include non-stable code that are actually known to be used in production (e.g., nightly releases). Non-security issues belong in the repository’s normal issue tracker.
  • Findings from automated (e.g., AI) scanners without a demonstrated impact, and reports generated by automated tooling without human verification, may be closed without detailed analysis.
  • Missing hardening measures that are not exploitable may be handled as ordinary issues rather than through this process.

Disclosure process

  1. The report is received and assigned a primary handler, who coordinates the fix and release.
  2. The problem is confirmed and all affected versions are identified. Related code is audited for similar problems.
  3. A fix or mitigation is prepared. Fixes for undisclosed vulnerabilities are developed privately rather than in the public repository.
  4. Where a vulnerability is serious and has significant downstream impact, we may notify known downstream consumers and distributors in advance of public disclosure. Individual projects may maintain their own pre-notification lists.
  5. Fixes are released, free of charge, through the ordinary distribution channels for the affected software.
  6. An advisory is published (see below), crediting the reporter unless they prefer otherwise.

We may disclose earlier than planned if there is evidence the vulnerability is being actively exploited, or if it becomes public by other means. We may hold disclosure beyond the availability of a fix only where publishing would materially increase risk to users, and only for as long as that remains true. We will not hold disclosure indefinitely – where no fix is possible, we publish the mitigation and its limitations instead.

Public disclosure will be coordinated based on the nature and severity of the vulnerability, whether exploitation is occurring, the availability of fixes or mitigations, the risk created by premature disclosure, and the needs of affected downstream users. Where active exploitation or another immediate risk makes earlier communication appropriate, we may publish mitigations or other actionable information before a complete fix is available while limiting technical detail that would unnecessarily increase the risk. Where appropriate, we will coordinate timing with affected maintainers and downstream projects. 

Advisories and information sharing

Every vulnerability we fix or mitigate is documented in a public security advisory once disclosed. Advisories are published as GitHub Security Advisories on the affected repository, identify affected and fixed versions, impact, and any available mitigation, and are assigned a CVE identifier.

For crates published to crates.io, we also file an advisory to the RustSec Advisory Database, cross-referenced to the CVE, so that it is surfaced by tools such as cargo-audit, cargo-deny and other tooling based on RustSec. 

Where the underlying problem originates in a dependency or an upstream project, we report it to that project’s maintainers and coordinate disclosure with them. Where a vulnerability is likely to recur in comparable software elsewhere, we notify those maintainers where we can identify them.

Reporting to authorities

Maintainers and contributors are encouraged to report vulnerabilities, cyber threats, incidents, and near misses voluntarily to a national CSIRT or to the European Union Agency for Cybersecurity (ENISA) under Article 15 of Regulation (EU) 2024/2847. Doing so creates no additional obligation for the person reporting, and we will not treat it as an adverse act. If you would prefer the Foundation to file on your behalf, contact us at the address above and we will.

When we become aware of an actively exploited vulnerability in software covered by this policy, or of a severe incident affecting infrastructure we provide for its development, we report it to the relevant authorities and inform affected users of the issue and of any steps they can take. Reporting a vulnerability to us in good faith does not result in a report about you to any authority. The reporting obligation applies only where there is evidence that a vulnerability is being exploited by a malicious actor.

Receiving security updates

Security advisories for covered repositories are published on the Security tab of the repository concerned, and are available through GitHub’s advisory feeds and API. Advisories for crates are additionally available through the RustSec Advisory Database and the tooling built upon it.

Advisories of significant or broad impact may additionally be announced on the Rust Foundation blog and/or #security-chat on Zulip.

Regulatory basis

This document is the Rust Foundation’s cybersecurity policy for the purposes of Article 24(1) of Regulation (EU) 2024/2847 (the Cyber Resilience Act), which applies to open-source software stewards. The Foundation is not a manufacturer under that Regulation: it does not place products with digital elements on the EU market, does not affix the CE marking, and does not issue EU declarations of conformity. Nothing here discharges the obligations of anyone who incorporates this software into a product they place on the market.

Internal operating procedures supporting this policy are maintained separately and are available to market surveillance authorities on request.

Nothing in this policy creates a warranty or a service level commitment, or varies the disclaimers in the licences under which our software is distributed.

Comments on this policy

Suggestions for improving this policy are welcome at security@rustfoundation.org.