Introduction

Red Hat’s vulnerability and incident response plan outlines the Product Security Incident Response team’s (PSIRT) accountability for two key areas. The first is how vulnerabilities are managed for the portfolio, and the second is when to invoke incident response handling for the remediation efforts. The scope for these two areas specifically addresses vulnerabilities within our products, services, and supply chain infrastructure. PSIRT executes this plan and specifies required stakeholder coordination for each function, describing the assessment, remediation, and response functions throughout this process.

Vulnerability workflow and function overview

The workflow for vulnerability management consists of several functions: Assessment, Remediation, and Response. This continuous process allows Red Hat PSIRT to effectively track and remediate vulnerability-based risk in our products, leveraging additional response coordination and processes when necessary to ensure quick and accurate remediation of vulnerabilities in Red Hat products and services.

Assessment focuses on the intake and initial triage of a vulnerability. The objective is to promptly identify and alert all affected parties of Red Hat’s awareness of a vulnerability. This initial process determines any potential effects on Red Hat components and software, assigns a unique Common Vulnerability and Exposures (CVE) number to each vulnerability, establishes an initial severity rating for the vulnerability, and notifies Product Engineering via a triage tracker filed in their issue tracking system. All information and scores are published on Red Hat’s CVE pages and in our VEX data immediately after assessing disclosed or coordinated vulnerabilities unless they are under an embargo. If, at any time during the assessment phase, a vulnerability meets the criteria for an incident, an incident will be declared.

• Key outcomes: Potentially affected products are identified, and software teams are notified. CVE pages and public VEX data are created with an initial status.

Remediation ensures that vulnerabilities are thoroughly and accurately analyzed, affected engineering teams are notified, and development work is appropriately prioritized to address the vulnerability. Remediation tasks conclude once a fix (advisory) is released and security metadata is updated. If, at any time during the remediation phase, a vulnerability meets the criteria for an incident, an incident will be declared.

• Key outcomes: Fixes are released and published in software advisories. Our machine-readable security data, CSAF and VEX, data are updated.

Response is specific to how we communicate with affected stakeholders, such as customers and software teams, during security incidents. This area of focus also ensures we’re responding to compliance obligations and threats to internal tooling used to build software. The workflow for an incident varies depending on the incident level, and the incident level is defined by factors such as media coverage, public concern, vulnerability complexity, severity ratings, and risk to Red Hat customers. Incidents are defined as one of three levels: Minor, Exploit, and Major.

• Key outcomes: Security bulletins are published as needed, and remediation workflows are expedited in addition to the release of security advisories and updated VEX files.

Product lifecycle and support

Support policies

All Red Hat products and services have a defined lifecycle and release schedule where support for security fixes is detailed. Vulnerabilities that Red Hat rates as Critical and Important are fixed in all supported software versions as a general rule. Moderate and Low vulnerabilities are typically fixed in major software releases.

Security advisories

Red Hat security advisories (RHSAs) are used to disclose when a vulnerability is first fixed within a product release; thereafter the fix may and will be included in subsequent Red Hat build advisories (RHBAs) but not explicitly referenced. Fixed vulnerabilities are almost always backported from an upstream development branch of code and will incrementally bump the name-verison-release (NVR) of a package. These package versions will not always align with the upstream version.

All packages and containers adhere to a strict no-regression policy, ensuring that any fix included in an older release is also included in all future releases.

Supporting standards

• Red Hat’s vulnerability disclosure policy defines expectations on how vulnerabilities are reported and managed.
• Expectations within Red Hat’s vulnerability and incident response plan align with the NIST Secure Software Development Framework (SSDF) and practice for “Remediate Vulnerabilities” (RV).
• CSAF/VEX provides machine-readable data to customers and vendors.