Ansible vulnerability management and incident response policy

Purpose 

This policy establishes a structured, repeatable framework for identifying, triaging, remediating, and disclosing security vulnerabilities and incidents across the Ansible ecosystem. It ensures that confirmed vulnerabilities are addressed according to severity and impact, that coordinated disclosure protects users before details become public, and that the project maintains the trust of its community and downstream consumers.

Scope 

This policy applies to the same projects and resources covered by the Ansible security policy. In addition, this policy covers the processes and workflows for the Ansible Security Team’s handling of vulnerability reports, triage, remediation, and disclosure.

Third-party collections or plugins hosted outside the GitHub organizations listed in the security policy are out of scope but are encouraged to adopt compatible practices.

Roles and responsibilities 

Role	Responsibilities
Ansible Security Team	First-line triage of all vulnerability reports; coordination of fixes and disclosure timelines; CVE management; final classification decisions when disputes arise.
Project Maintainers	Develop and validate fixes for vulnerabilities within their components; participate in coordinated disclosure; review and merge security patches.
Release Engineering	Produce and distribute patched releases for some projects; coordinate release timing with disclosure schedules.
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 

For complete details on how to report a vulnerability, what to include in a report, and what qualifies as a reportable vulnerability, see the Ansible security policy.

All reports MUST be submitted by email to: security@ansible.com

Security vulnerabilities and security incidents MUST NOT be reported through any other mechanism, including public GitHub issues, Ansible Forum, or Ansible Matrix groups.

Triage and severity classification 

Triage process 

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

Acknowledge the report according to the response timeline in the Ansible 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 Ansible Security Team follows the Red Hat severity ratings.

Runtime context consideration 

Not all reported vulnerabilities carry equal risk. When prioritizing remediation, the Ansible 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 Automation Hub, container images, Galaxy, PyPI).
For Critical and High severity issues, out-of-band patch releases may be issued outside the regular release cadence.
Release notes MUST reference the associated CVE ID(s) and advisory.

Backporting 

Backports are made according to the Ansible security policy.

Coordinated vulnerability disclosure 

Disclosure model 

The Ansible Security Team follows a Coordinated Vulnerability Disclosure (CVD) model aligned with OpenSSF guidance:

Embargo Period: Vulnerability details remain confidential until a fix is available and released.
Disclosure Timing: Public disclosure occurs simultaneously with or immediately after the availability of a patched release.
Pre-notification: For Critical severity issues affecting widely-deployed components, the Ansible Security Team may provide advance notice to major downstream users under embargo, up to 7 days before public disclosure.

Disclosure types 

Type	When Used
Standard Disclosure	Fix released, advisory published, CVE record updated – all at the same time.
Progressive Disclosure	Pre-notification to select downstream partners under embargo, followed by full public disclosure upon release. Used for Critical and High severity issues with broad ecosystem impact.
Accelerated Disclosure	If evidence of active exploitation emerges, disclosure may be accelerated with available mitigations even before a complete fix is ready.

Researcher coordination 

Reporter recognition is described in the Ansible security policy.
The Ansible 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 Ansible Security Team requests CVE IDs for all confirmed vulnerabilities.
CVE IDs are reserved only after the Ansible Security Team confirms that the report constitutes a genuine vulnerability.
Where Red Hat operates as 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.

Incident response 

Definition 

A security incident is any event indicating that Ansible project infrastructure, build systems, distribution channels, or governance accounts have been compromised or are under active attack. This is distinct from a vulnerability report (a flaw in code) and requires operational response.

Incident response steps 

Contain: Isolate affected systems, revoke compromised credentials, and halt affected release pipelines.
Assess: Determine the scope, impact, and root cause of the incident.
Remediate: Apply fixes, rotate credentials, rebuild affected artifacts from verified sources.
Communicate: Notify affected parties. For incidents affecting released artifacts, issue a public advisory.
Post-mortem: Conduct a blameless post-incident review. Document lessons learned and update this policy if warranted.

Communication 

Advisory distribution 

Security advisories are published through the channels listed in the Ansible security policy.

Policy governance 

Review cycle 

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

A significant security incident or near-miss.
Changes to the project’s CNA status or governance structure.
Material changes to industry standards (for example, OpenSSF guidelines, CVE program rules).

Exceptions 

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

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

For discussion about the EU Cyber Resilience Act and how it applies to the Ansible ecosystem, see the CRA tag on the Ansible Forum. To follow changes and suggest improvements to Ansible security practices, see the infra-and-security tag on Ansible Forum.

Notes 

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