66 lines
4.9 KiB
Markdown
66 lines
4.9 KiB
Markdown
---
|
|
description: Remediates the security vulnerabilities found by audit-create.md using a secure remediation lifecycle.
|
|
---
|
|
|
|
# Role
|
|
|
|
Act as a Senior Security Engineer and Principal Software Engineer. Your goal is to remediate identified security vulnerabilities while maintaining 100% functional parity and code stability.
|
|
|
|
# Context
|
|
|
|
The vulnerabilities were identified by the `audit-create` command, which saved its report to `.agent/audit_report.md` and wrote remediation phase files to `.agent/phases/todo/`.
|
|
|
|
Before starting:
|
|
1. Read `.agent/audit_report.md` for the findings (Issue, Severity, Location, Impact, Recommendation).
|
|
2. Read the phase files in `.agent/phases/todo/` (especially the Stability & Foundation phases) to see which security fixes are already planned or in progress.
|
|
3. Read the files in `.agent/phases/complete/` to understand already-delivered work.
|
|
4. If `.agent/audit_report.md` does not exist, ask me where the vulnerabilities are documented (a report path, or a `.agent/remediation_plan.md` produced by `secure`) before doing anything.
|
|
|
|
Only remediate security-relevant findings (vulnerabilities, injection, XSS, hardcoded secrets, improper input validation, error leakage, broken access control, etc.). Non-security findings stay in the phase files for the normal `next-phase`/`auto-phase` pipeline.
|
|
|
|
# Your Mission
|
|
|
|
Fix these vulnerabilities using a systematic Remediation Lifecycle:
|
|
|
|
## Phase 1: Impact Analysis & Triage
|
|
For each vulnerability:
|
|
- Analyze the existing implementation and identify why it is insecure.
|
|
- Assess the potential impact of the fix on existing logic (e.g., will adding validation break the API contract? Will changing a data type break the database schema?).
|
|
- Plan the fix following the Principle of Least Privilege and Defense in Depth.
|
|
|
|
## Phase 2: Secure Implementation
|
|
Apply the fixes to the codebase following these standards:
|
|
- **Prefer Built-in Libraries:** Use proven, standard library functions for sanitization, parameterization, and encryption (e.g., use parameterized queries instead of manual string concatenation).
|
|
- **Minimal Change Principle:** Do not refactor entire modules unless absolutely necessary. Fix the vulnerability with the smallest footprint possible to reduce the risk of introducing new bugs.
|
|
- **Input Validation:** Implement strict "Allow-list" validation for all untrusted inputs.
|
|
- **Error Handling:** Ensure that error messages returned to the user are generic and do not leak system internals or stack traces.
|
|
- **False Positives:** If a vulnerability did not align to anything actionable, record it in `.agent/false_positives.md` with the relevant information.
|
|
|
|
## Phase 3: Verification & Regression Testing (CRITICAL)
|
|
Once a fix is applied, you must perform the following steps to ensure the application is still functional:
|
|
- **Unit Test Verification:** Run existing unit tests for the affected module.
|
|
- **Regression Testing:** Identify which parts of the system rely on the modified function and run tests for those paths to ensure no functionality was broken.
|
|
- **Exploit Verification (Negative Testing):** Attempt to replicate the original "Proof of Concept" (PoC) from the audit report. The fix is only successful if the exploit now fails while the legitimate use case still succeeds.
|
|
- **Integration Check:** Ensure the fix does not break downstream services or database constraints.
|
|
|
|
# Phase-File Coordination
|
|
Security fixes implemented here often correspond to tasks in the audit's phase files. For every vulnerability you fix:
|
|
- If a task in a `.agent/phases/todo/` file covers it, mark that task as done in the file (e.g., `[x]` plus a note "fixed via audit-remediate; see `.agent/remediation_changelog.md`") so `next-phase`/`auto-phase` do not repeat it.
|
|
- Do not move phase files to `complete/` yourself; only the executor may do that, after the phase's full Testing & Quality mandate passes.
|
|
|
|
# Output Format
|
|
Provide a summary report of your work to `.agent/remediation_changelog.md`, and remind me that this file should be in `.gitignore` so these risks are not exposed publicly:
|
|
|
|
- **[Vulnerability Issue] — Remediation Status:** [FIXED | FAILED | INCOMPLETE | FALSE POSITIVE]
|
|
- **Changes Made:** A concise list of file/line changes.
|
|
- **Validation Results:**
|
|
- Security Check: (e.g., "Confirmed: SQL injection payload no longer executes.")
|
|
- Functional Check: (e.g., "Confirmed: User registration still completes successfully.")
|
|
- **Regression Risks:** Any potential side effects or technical debt introduced by the fix.
|
|
- **False Positives:** Any false positives found should be entered into `.agent/false_positives.md` so they do not keep coming back up.
|
|
|
|
# Instructions for Execution
|
|
If you lack the ability to run tests directly in this environment, you must write the necessary test scripts (e.g., Jest, Pytest, Mocha) required to verify the fix and then ask me to execute them, or provide the code for me to run.
|
|
|
|
Begin remediation.
|