Pulp Vulnerability Management Policy¶

Purpose¶

This policy establishes a structured, repeatable framework for identifying, triaging, remediating, and disclosing security vulnerabilities and incidents across the Pulp project ecosystem.

It ensures that confirmed vulnerabilities are addressed according to severity and impact and that coordinated disclosure protects users before details become public.

Scope¶

This policy applies to the same projects and resources covered by the Pulp Security Policy.

In addition, this policy covers the processes and workflows for the Pulp Security Team's handling of vulnerability reports, triage, remediation, and disclosure.

Roles and responsibilities¶

Role	Responsibilities
Pulp Security Team	First-line triage of all vulnerability reports; Coordination with Red Hat Product Security
Red Hat Product Security	Create CVE; Define coordinated disclosure plan; Publish relevant security advisories; General process supervision
Red Hat Project Maintainers	Develop and validate fixes for vulnerabilities within their components; review, merge, release and publish security patches
Community, including Security Researchers	Report vulnerabilities through designated private channels; adhere to coordinated disclosure timelines
Users	Monitor advisories; apply patches within recommended timelines; report regressions

Vulnerability reporting¶

How to report¶

All reports MUST be submitted by email to: pulp-security@redhat.com

Security vulnerabilities MUST NOT be reported through any public or insecure method, including but not limited to: Public GitHub issues, Pull Requests, Pulp Discourse, Pulp Matrix, Public forums or social media.

What to include¶

When submitting a report, provide the following details:

Title (required): Clear, descriptive summary
Reporter details (optional): Your name/handle and affiliation
Impacted project (required): Ideally link to the GitHub project
Vulnerability description (required): Technical details of the issue
Affected versions (required): Known affected version(s), and ideally all affected versions
Reproduction steps (required): Minimal example to reproduce the issue
Impact assessment (required): Potential exploit scenarios and severity
Suggested fix (optional): Proposed remediation, if any
Disclosure status (required): Whether and where this has been shared elsewhere

What to report¶

Report if you have:

Discovered a potential security vulnerability
Found an issue but are uncertain about its security impact
Identified vulnerabilities in dependencies not yet addressed

What NOT to report¶

The following do not qualify as security vulnerabilities:

Automated scanner output
General support or usage questions (use Pulp Discourse)
Requests for help updating to newer versions
Bugs without security implications

Bugs that have no security impact should be filed through the public issues tracker of the respective GitHub project.

Triage and severity classification¶

Triage process¶

Upon receipt of a legitimate vulnerability report, the Pulp Security Team will:

Acknowledge the report per the response timeline in the Pulp Security Policy
Validate the report by reproducing the issue or confirming the technical basis
Classify severity using the framework below
Assign the issue to the appropriate project maintainers for resolution
Open a private tracking issue for internal coordination

Severity levels¶

Severity classification follows a risk-based model considering exploitability, impact, and exposure. The Pulp project follows the Red Hat severity ratings.

Runtime context consideration¶

Not all reported vulnerabilities carry equal risk. When prioritizing remediation, the Pulp Security Team will consider:

Whether the vulnerable code path is actually reachable at runtime in typical deployments
Whether the affected component is loaded in production versus only present as an unused dependency
The attack surface exposure (internet-facing vs. internal-only components)

This approach aligns with emerging industry guidance that static CVSS scores alone are insufficient for prioritization, and that runtime context can reduce actionable findings significantly.

Remediation process¶

Fix development¶

Embargoed fixes are developed in private branches or forks to prevent premature disclosure
All security patches undergo peer review by at least one other maintainer with relevant domain knowledge
Patches are tested against the reproduction steps from the original report and validated against regression test suites

Release and distribution¶

Security fixes are distributed through the project's normal release channels (such as PyPI and Quay)
For Critical and High severity issues, out-of-band patch releases may be issued as soon as possible
Release notes MUST reference the associated CVE ID(s) and advisory

Backporting¶

Security fixes MUST be backported to all actively supported release branches affected.

Release branches not marked as supported SHOULD NOT be expected to receive security backports.

Coordinated vulnerability disclosure¶

Disclosure model¶

The Pulp project follows an internal Red Hat disclosure model. In general:

Embargo Period: Vulnerability details remain confidential to Red Hat until a fix is available and released
Disclosure Timing: Public disclosure occurs simultaneously with or immediately after the availability of a patched release

Researcher coordination¶

Reporter recognition is described in the Pulp Security Policy
The Security Team coordinates disclosure timing with the reporter
Reporters are asked to refrain from public disclosure until the agreed-upon date

CVE Management¶

CVE assignment¶

The Pulp Security Team requests CVE IDs for all confirmed vulnerabilities
CVE IDs are reserved only after the Pulp Security Team confirms that the report constitutes a genuine vulnerability
Where the Pulp project operates as or under a CVE Numbering Authority (CNA), CVE records are published within 24 hours after the associated security advisory goes public, but never before

CVE record requirements¶

Published CVE records MUST follow the CVE record format as defined by the CVE program.

Dispute resolution¶

If a reporter or third party disputes a CVE classification or rejection:

Acknowledgment of the dispute within 3 business days
Decision or extension request within 5 business days
If extended, final decision within reasonable business expectation of the extension
Unresolved disputes may be escalated to the relevant root CNA or MITRE

Communication¶

Advisory distribution¶

Security advisories are published through Red Hat Product Errata and MUST be linked in the appropriate project's release notes.

Policy governance¶

Review cycle¶

This policy MUST be reviewed annually and updated as needed, or if triggered by:

A significant security incident or near-miss
Changes to the project's CNA (CVE Numbering Authority) status or governance structure
Material changes to internal or industry standards (for example, CVE program rules)

Exceptions¶

Any exception to this policy requires written approval from the Pulp Security Team lead and MUST include:

Justification for the exception
Risk assessment of the deviation
Compensating controls in place
Expiration date for the exception

Notes¶

The key words "MUST", "MUST NOT", and "SHOULD" in this document are to be interpreted as described in RFC 2119.