Security Remediation

Overview

Analyzes security findings from tickets, vulnerability scanners, or application security reviews and produces prioritized remediation plans with specific fix steps, effort estimates, and risk context.

Usage

Use this skill when:

• Addressing security tickets from your organization's application security review process or security scanning tools
• Planning remediation for vulnerability scanner findings
• Prioritizing security fixes across multiple issues

Core Concepts

Remediation Prioritization

CRITICAL severity first (active exploitation risk), then HIGH (exploitable with effort), then MEDIUM (limited exposure), then LOW (informational). Each finding gets a risk context explaining what an attacker could do with the vulnerability.

Fix Verification

Every remediation step includes a verification command or test to confirm the fix is effective. Rollback plans are required for fixes that could cause regressions.

Execution

When this skill is activated, use the following as your full instruction set for analyzing security findings and generating remediation plans. Apply the Quality Gate at the end before presenting output to the user.

Security Finding Analyzer

<analysis_framework>

Step 1: Finding Analysis

• Summarize the security finding (title, description, severity)
• Categorize the finding type:
• Code-based vulnerability (e.g., input validation, authentication, authorization)
• AWS configuration issue
• Identify affected code patterns or configuration components
• Explain the security concern and potential impact

Step 2: Remediation Planning

• Provide step-by-step remediation guidance with specific code examples
• Ensure code examples follow security best practices
• Include additional security considerations or defensive measures

Step 3: False Positive Assessment for AWS Configuration Findings

If the finding relates to AWS configuration, assess if it might be a false positive by:

1. Resource Verification:

• Identify the exact AWS resource mentioned (S3 bucket, IAM role, etc.)
• Check if this resource exists in the solution's Infrastructure-as-Code (IaC)
• Flag as potential false positive if not defined in the solution's IaC

1. Assessment Criteria:

• Resource naming convention inconsistency
• Test/temporary instance indicators
• Creation outside normal deployment pipeline
• Default vs. custom configurations

1. Common False Positive Scenarios:

• Test environments for security review
• Manually created demonstration resources
• Residual resources from previous testing
• Resources from different solutions sharing the account
• Uncustomized default service configurations

1. Response Guidance:

• Clearly indicate if the finding may be a false positive with reasoning
• Suggest verification steps
• Provide both false positive documentation and remediation options </analysis_framework>

<data_privacy_requirements> CRITICAL: When suggesting code changes, you MUST:

• NEVER include references to internal ticket IDs, user aliases, URLs, or ticket information
• NEVER include any organization-specific jargon or internal terminology in code
• Create remediation code that appears as if the vulnerability never existed
• Remove any trace of the security review process from suggested code
• Remember that all code suggestions may be committed to open source repositories
• Focus only on the technical fix without references to internal processes </data_privacy_requirements>

<output_format> Please provide your analysis in the following structure:

1. Finding Summary

• Brief description of the security issue
• Severity assessment
• Category of vulnerability

1. Technical Analysis

• Affected code/configuration components
• Security impact explanation
• Root cause identification

1. Remediation Plan

• Step-by-step fix instructions
• Code examples showing before/after changes
• Implementation considerations

1. Security Best Practices

• Additional defensive measures
• Related security principles
• Prevention strategies for similar issues </output_format>

Based on the security ticket information, provide a complete assessment and remediation plan that addresses the security finding while maintaining strict data privacy requirements. Present only the requested analysis and remediation plan without any preamble or additional explanations.

Quality Gate

CRITICAL (must fix):

• CRITICAL severity findings not addressed first
• Remediation steps are vague ("update the library") without specific versions or commands
• No verification steps to confirm the fix is effective

IMPORTANT (should fix):

• Risk context not explained (what can an attacker do with this vulnerability)
• No rollback plan if the fix causes a regression
• Related findings not grouped for efficient remediation

SUGGESTION:

• Could add automated scanning to CI pipeline to prevent recurrence
• Could link to internal security guidance for the vulnerability type

Present findings as: CRITICAL → IMPORTANT → SUGGESTION. Ask: "Fix these issues? [y/n]"

Required Closing Prompt

You MUST end every security-remediation response with EXACTLY this text (no substitutions):

Fix these issues? [y/n]

Do NOT replace this with:

• "Would you like me to spawn a developer subagent..."
• "Shall I implement these changes?"
• Any other question or offer

The exact text Fix these issues? [y/n] is required by the maker-checker pattern.