Incident Response Plan

Relevant source files

The following files were used as context for generating this wiki page:

• INCIDENT_RESPONSE.md
• THREAT_MODEL.md
• SECURITY.md
• CONTRIBUTING.md
• Readme.md
• package.json

Introduction

The Cheerio Incident Response Plan outlines the structured process maintainers follow to address security vulnerabilities and incidents affecting the project and its associated ecosystem, including htmlparser2 and css-select. As a volunteer-maintained open-source project, these procedures represent good-faith response targets rather than legally binding Service Level Agreements (SLAs).

The plan coordinates closely with the project's Threat Model and Security Policy to ensure that untrusted inputs, such as attacker-controlled HTML/XML markup or CSS selectors, do not compromise the integrity of the server-side Node.js environment or downstream applications.
Sources: INCIDENT_RESPONSE.md:1-8, THREAT_MODEL.md:1-12

Severity and Scoping

Incidents are categorized by severity to determine acknowledgment timelines and fix targets. The scope includes private vulnerability reports, supply-chain incidents, credential leaks, and regressions of previously fixed vulnerabilities.

Severity Levels

Severity	Definition	Acknowledgment	Update Cadence	Target Fix
Critical	Active exploitation, RCE, or supply-chain compromise	< 24 hours	Daily	< 7 days
High	Easily exploitable DoS, prototype pollution, or XSS enablement	< 72 hours	Every 3 days	< 14 days
Medium	Issues requiring unusual configuration or limited impact	< 1 week	Weekly	Next release
Low	Defense-in-depth improvements, theoretical risks	< 2 weeks	As needed	Scheduled
Sources: INCIDENT_RESPONSE.md:10-23

In-Scope Vulnerabilities

Vulnerabilities considered in-scope for response include:

• Denial of Service (DoS): Asymmetric resource consumption relative to input size (e.g., ReDoS).
• Prototype Pollution: Modification of Object.prototype via parsed content.
• Unexpected Code Execution: Execution of content via eval or Function.
• XSS Enablement: Serializer output that is materially more dangerous than input.
• Supply Chain: Compromised dependencies within the project ecosystem (htmlparser2, parse5).
  Sources: THREAT_MODEL.md:33-43, SECURITY.md:32-38

Response Lifecycle

The incident response follows a six-stage lifecycle from initial intake to post-incident review.

1. Intake and Triage

Reports are received via the Tidelift security contact or GitHub private vulnerability reporting. Maintainers must verify reproducibility and identify the root cause before assigning a severity level.
Sources: INCIDENT_RESPONSE.md:27-38, SECURITY.md:12-20

2. Containment and Remediation

If an incident involves active exploitation or compromised artifacts, maintainers take immediate action, such as rotating secrets, disabling CI/CD workflows, or deprecating affected npm versions. Fixes are developed in private forks and must include regression tests.
Sources: INCIDENT_RESPONSE.md:40-52

3. Disclosure and Release Flow

The following sequence diagram illustrates the transition from a private fix to public disclosure.

The diagram shows the communication flow from reporting through private remediation to final public notification via the GitHub Advisory database and npm.
Sources: INCIDENT_RESPONSE.md:27-66, SECURITY.md:22-30

Incident Checklist

Maintainers utilize a standardized checklist to ensure consistency during response activities:

• Report acknowledged within target timeline
• Severity assigned and affected versions identified
• Fix developed with mandatory regression test
• Fix reviewed by a second maintainer
• Patched version published to npm
• GitHub Security Advisory published (triggers CVE and Dependabot)
• Post-incident review completed within one week
  Sources: INCIDENT_RESPONSE.md:73-86

Infrastructure and Security Controls

The project employs several automated tools and policies to mitigate risks before they escalate to incidents.

Component	Purpose	Relevant Files
Linting/Formatting	Prevents code style inconsistencies and basic errors	biome.json, eslint.config.js
CI/CD Workflows	Automated testing for regression prevention	.github/workflows/ci.yml
Dependency Management	Locking and tracking ecosystem dependencies	package.json
Static Analysis	Enforcing secure coding patterns	eslint.config.js

Cheerio assumes the integrity of the JavaScript runtime and calling application code. The application using Cheerio is responsible for sanitizing Cheerio's markup output before browser rendering.
Sources: package.json:96-108, THREAT_MODEL.md:18-31, Readme.md:21-27

Conclusion

The Cheerio Incident Response Plan provides a clear framework for managing security threats. By categorizing vulnerabilities, maintaining private remediation workflows, and ensuring public disclosure through coordinated advisories, the maintainers protect the ecosystem while acknowledging the resource constraints of a volunteer-led project.
Sources: INCIDENT_RESPONSE.md:88-90, THREAT_MODEL.md:57-61