Skip to content

doc: move security information to new repo #2814

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
beckermr merged 1 commit into from
Apr 17, 2026
+3 −122
Merged

doc: move security information to new repo #2814

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
120 changes: 1 addition & 119 deletions SECURITY.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,121 +1,3 @@
# conda-forge vulnerability handling process

This document summarizes and proposes guidelines for handling vulnerabilities reported in
conda-forge's infrastructure.

Security issues and vulnerabilities have expectations and processes that are differ from typical
open source practices:

- Private discussions
- Obfuscation
- Short timeline

This makes it quite hard to be able to understand, learn, or know what to expect from a security
point of view. This document will give you a glimpse on what's happening on the inside, and what
timeline to expect when you report a security vulnerability. It will also serve as a guideline and
task list for conda-forge members on how to handle security related issues.

## Scope

This process applies to _all projects_ governed by conda-forge. This includes:

- conda-forge feedstock machinery
- conda-forge infrastructure and bots
- conda-forge website and documentation

Conversely, this process does NOT apply to the software packaged by conda-forge itself. Please contact the upstream maintainers directly.

## Reporting Vulnerabilities

If you believe you’ve found a security vulnerability in a conda-forge project, please responsibly report it to condaforge+security@gmail.com. conda-forge will try to will respond within 7 days to all new reports.

We are also testing GitHub Private vulnerability reporting, you can try to submit a security advisory on [conda-forge/conda-forge.github.io using this link](https://github.com/conda-forge/conda-forge.github.io/security/advisories/new).

## Coordinated Disclosures

conda-forge follows a [coordinated disclosure][coordinated-disclosure] model where the initial
report and remediation are handled privately, but the completion description is made public once a
patch is available. conda-forge will disclose known vulnerabilities within 90 days by default,
whether a patch is available or not.

## Acknowledgement

conda-forge will work to ensure that security researchers, developers, users, or others who
identify and report vulnerabilities within conda-forge projects receive acknowledgement for their
contribution.

## Vulnerability Triage & Remediation Process

This section describes an example process used by conda-forge to track, remediate, and disclose a
reported vulnerability. This description is both a reference for the conda-forge community and a
guideline for contributors. The actual process may vary depending on the nature of the
vulnerability.

### Roles

This process defines these roles:

- **Reporter** The individual(s) who report the vulnerability
- **Coordinator** A conda-forge core member who facilitates the tracking of the vulnerability
through this process
- **Developer** One or more developers who work on remediating the vulnerability

For the purpose of this document these roles are distinct, in practice, some of these roles may be handled by the same individual. However, the roles should be covered by a minimum of two separate individuals. For example, a Reporter may also fill the Developer role and create the remediation, in this case the Coordinator should be a separate individual.

### Process

The role responsible for each step is noted at the beginning.

- Upon receipt of the initial report:
- **Coordinator**: Respond to the reported and acknowledge receipt of the report in the timeframe
given in the "Reporting Vulnerabilities" section.
- **Coordinator**: Open an issue in the private GitHub repository used for tracking
vulnerabilities across projects
- **Coordinator**: Review the issue for completeness and suitability (triage). If more
information is needed, follow up with the Reporter.
- If the vulnerability is not accepted:
- **Coordinator**: Close the issue
- **Coordinator**: Notify the reporter
- If the vulnerability is accepted, within the relevant repositories:
- **Coordinator**: Open a draft [GitHub Security
Advisory](https://docs.github.com/en/code-security/repository-security-advisories/about-github-security-advisories-for-repositories#about-github-security-advisories)
- Include relevant but sanitized details in the top level comment, which will become public
- Sensitive details and reproductions go in the comments on the draft advisory, which are not
public
- **Coordinator**: Add relevant people to the advisory
- **Developer**: Attempt to replicate the reported vulnerability. Request more information from
the **Reporter** if necessary.
- **Developer**: Work on the [vulnerability fix
PR](https://docs.github.com/en/code-security/repository-security-advisories/collaborating-in-a-temporary-private-fork-to-resolve-a-repository-security-vulnerability#creating-a-temporary-private-fork).
- **Coordinator**/**Developer**: If appliccable, request a
[CVE](https://docs.github.com/en/code-security/repository-security-advisories/about-github-security-advisories-for-repositories#cve-identification-numbers)
from GitHub. The CVE Number will be private until the advisory is published.
- **Developer & Coordinator**: Decide on release and announcement dates and post them the draft
advisory.
- **Coordinator**: Post the release and announcement dates on the conda-forge core chat room and
mailing list.
- **Developer**: Merge the security fix PR
- **Developer**: Release the package and/or deploy the fix as appropriate
- **Developer & Coordinator**: Draft a [blog post](/blog) and other
announcement texts. This can be done in parallel with the previous steps, but consider using a
[private advisory](https://github.com/conda-forge/conda-forge.github.io/security/advisories) for the text.
- **Coordinator**: Publish the security advisory on the announcement date. If applicable, GitHub
will post the CVE to the MITRE database.
- **Coordinator**: Publish the blog post and other announcements (Zulip, Twitter,
etc) as necessary.
- **Coordinator**: Notify the **Reporter** of the releases
- **Coordinator**: Close the issue in the tracking repository

> Notes to Developers
>
> - Be aware that GitHub CI workflows won't run on security forks, so reviewers must test manually
> to avoid a broken CI when the patch is merged to the public repo.
> - Also, vulnerabilities may involve multiple private security forks across different GitHub
> organizations.
> - This may require additional manual steps to include those private forks.

[coordinated-disclosure]: https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.html#responsible-or-coordinated-disclosure

---

> This document is based on the excellent [write-up](https://github.com/jupyter/security/blob/86ec517/docs/vulnerability-handling.md) used by the Jupyter community, [BSD-3 licensed](https://github.com/jupyter/security/blob/86ec517/LICENSE).
Please see the documentation at [conda-forge/security](https://github.com/conda-forge/security).
5 changes: 2 additions & 3 deletions docs/maintainer/knowledge_base.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2334,10 +2334,9 @@ You are also free to download recipes and rebuild them yourself, if you would li
2. Each feedstock can only upload packages for that feedstock. This is enforced by using a cf-staging channel where builds are first sent.
A bot then assesses that the submitting feedstock has permission to build the package it has submitted, and only then will it relay the build to the `conda-forge` channel.
This helps mitigate against a bad actor gaining access to an inconspicuous feedstock and then trying to push a build with malicious code into essential infrastructure packages (e.g., OpenSSL or Python).
3. We have [artifact-validation](https://github.com/conda-forge/artifact-validation) for validating all the conda-forge artifacts uploaded to `anaconda.org`. This validation scans for various security-related items, such as artifacts that overwrite key pieces of certain packages.
4. We have a dedicated [Security and Systems Sub-Team](/community/subteams/#security-subteam) who works hard towards making sure to secure and maintain appropriate access to the credentials and services/systems used by conda-forge.
3. We have a dedicated [Security and Systems Sub-Team](/community/subteams/#security-subteam) who works hard towards making sure to secure and maintain appropriate access to the credentials and services/systems used by conda-forge.

If you have found a security-related issue with conda-forge, please check our [Security Policy](https://github.com/conda-forge/conda-forge.github.io/security/policy)
If you have found a security-related issue with conda-forge, please check our [Security Policy](https://github.com/conda-forge/security/security/policy)
to learn how to report it responsibly.

<a id="significant-changes-to-upstream-projects"></a>
Expand Down
Loading