High-level security incident response handling process

The goal of this high-level process is to identify what needs to be done for a security response, and who can help making it happen.

1. Awareness
Task	Duration	Who can do it	Notes
Make security team aware	-	Whoever being aware about security issue	Its important to handle the issue properly from the beginning.

2. Identification
Task	Duration	Who can do it	Notes
Analyze report	-	Security response team	Assess incoming reports for validity and potential severity.

3. Assesment
Task	Duration	Who can do it	Notes
Impact evaluation	-	Security response team	Determine the potential impact on users and the project (e.g., data exposure, remote code execution).
Risk categorization	-	Security response team	Assign severity levels (e.g., Critical, High, Medium, Low) using frameworks like CVSS.
Confirm the issue	-	Security response team	Reproduce the issue in a controlled environment to confirm its validity.

4. Containment
Task	Duration	Who can do it	Notes
Prevent further exploitation	-	-	Take immediate action to limit the incident’s impact (e.g., temporarily disabling a vulnerable feature, service)
Communicate internally	-	Security response team	Notify relevant maintainers, sysadmins to coordinate the response

5. Remediation
Task	Duration	Who can do it	Notes
Fix the vulnerability	-	-	Patch the issue in the codebase and thoroughly test the fix
Backport fixes	-	-	Apply fixes to older supported versions, if necessary
6. Disclosure
Task	Duration	Who can do it	Notes
Communicate with reporter	-	Security response team	Notify the reporter of the fix and thank them for their contribution.
Submit CVE	-	Security response team	If applicable, request a CVE ID for tracking and disclosure
Publish security advisory on wiki	-	Security response team	Use previous advisories as template
Publish advisory to mailing list	-	Security response team	Use previous emails as template, GPG sign email!
Publish advisory on forum	-	Security response team	Use previous posts as template, probably makes sense always for remotely exploitable or critical vulnerabilities.