Remediation Planning
Creates actionable remediation plans for vulnerable Go codebases based on analysis results from previous phases.
Supported Remediation Types
- Dependency Update - Update Go package to fixed version
- Go Runtime Update - Update Go itself (for stdlib vulnerabilities)
- Configuration Change - Disable features, change settings, adjust security controls
- Code Refactoring - Replace vulnerable patterns, add validation, refactor code
- Security Patch - Apply vendor-provided patch files
- Workarounds - Temporary mitigations (timeouts, rate limiting, input validation)
- Infrastructure - Network policies, firewall rules, WAF configuration
- Combination - Multiple remediation types together
The skill automatically determines the appropriate remediation strategy based on CVE details and impact analysis.
When to Use This Skill
Use this skill when:
- Codebase is confirmed or likely affected by a CVE
- Need specific remediation steps beyond "update the package"
- Fixed version exists but need to assess compatibility
- No fixed version available and need workarounds
- Project uses custom build/test commands via Makefile
Implementation Steps
Step 1: Analyze Inputs and Determine Strategy
Required Inputs from Previous Phases:
From Phase 1 (CVE Intelligence Gathering):
- CVE ID, severity, CVSS score
- Affected package/module and vulnerable version range
- Fixed version (if available)
- Vulnerability type and remediation guidance
From Phase 2 (Codebase Impact Analysis):
- Risk level (HIGH / MEDIUM / LOW / NEEDS REVIEW)
- Current package version and dependency type
- Usage locations and functions being called
From Call Graph Analysis (optional):
- Reachability risk level and call chain
- Entry points
From govulncheck (optional):
- Detection result and vulnerable symbols
Decision Tree:
IF risk_level = "LOW":
→ Document findings, recommend monitoring and manual review
IF risk_level = "HIGH" or "MEDIUM":
IF fixed_version EXISTS:
IF affected_package is in go.mod → Dependency Update (Step 2)
ELSE IF affected_package is Go stdlib → Go Runtime Update (Step 2A)
IF fixed_version = null:
IF remediation_guidance has "configuration" → Configuration Change (Step 2B)
IF remediation_guidance has "code change" OR pattern vulnerability → Code Refactoring (Step 2C)
IF remediation_guidance has "patch" → Apply Patch (Step 2D)
ELSE → Workarounds (Step 3)
IF risk_level = "NEEDS_REVIEW":
→ Manual review + defensive workarounds (Step 3)
Step 2: Plan Dependency Update (If Applicable)
Analyze the dependency situation:
-
Understand the dependency relationship:
- Is this a direct or indirect (transitive) dependency?
- If indirect, which direct dependency pulls it in?
- Are there multiple dependency paths to this package?
- What version is currently in use?
-
Assess the update strategy:
For direct dependencies:
- Can we directly update to the fixed version?
- What's the version jump? (major/minor/patch)
- Are there intermediate versions we should consider?
For indirect dependencies:
- Should we update the parent package instead?
- Will updating the parent also fix this issue?
- Is the parent package actively maintained?
- Do we need to explicitly override the version?
- Is a
replace directive necessary (avoid if possible)?
-
Research breaking changes:
- Search for changelog and release notes
- Look for BREAKING CHANGE markers
- Check GitHub issues for migration problems
- Assess semantic versioning signals:
- Major version bump → Expect breaking changes
- v0.x minor bump → May have breaking changes
- Patch version → Should be safe
- Identify specific API changes that affect your code
-
Evaluate compatibility risks:
- Does the fixed version require a newer Go version?
- Are there conflicts with other dependencies?
- What's the blast radius if something breaks?
- Is there test coverage for affected code paths?
-
Plan the update approach:
- Decide on exact version to target
- Determine the update commands to use
- Plan for testing and validation
- Consider gradual rollout strategy
- Prepare rollback plan
Document the chosen approach with specific commands and rationale for the decision.
Step 2A: Plan Go Runtime Update (If Applicable)
Analyze Go runtime update requirements:
-
Determine version requirements:
- What Go version fixes the vulnerability?
- What's the current Go version in use?
- What's the minimum version bump needed?
- Are there multiple affected Go versions with different fixes?
-
Assess project constraints:
- What's the project's minimum supported Go version (from go.mod)?
- Are there compatibility requirements (OS distributions, cloud providers)?
- What Go versions are used in CI/CD pipelines?
- What about developer environments?
- Are there dependencies that constrain Go version?
-
Evaluate upgrade path:
- Can we upgrade directly to the fixed version?
- Should we target a newer Go version for future-proofing?
- Are there intermediate versions to consider?
- What's the official support status of target version?
-
Research breaking changes:
- Review Go release notes for the target version
- Check for deprecated features being removed
- Look for behavior changes in standard library
- Identify new language features that might affect build
- Search for migration guides
-
Plan the migration:
- Decide on target Go version
- Update go.mod minimum version
- Plan testing strategy
- Update build systems and Docker base images
- Update developer documentation
-
Consider alternatives:
- If Go update is too disruptive, can we backport the fix?
- Are there workarounds while planning the upgrade?
- What's the risk of delaying the Go update?
Document the chosen Go version, migration plan, and timeline.
Step 2B: Plan Configuration Changes (If Applicable)
Analyze if configuration-based mitigation is possible:
-
Understand what the vulnerability requires to trigger:
- Does it require a specific feature to be enabled?
- Does it depend on insecure default settings?
- Is it protocol/algorithm-related?
- Does it require network exposure?
-
Evaluate configuration options:
- Review application/library configuration documentation
- Check if security features can be enabled
- Determine if vulnerable features can be disabled
- Consider network-level controls
-
Design configuration changes:
- If vulnerable feature is optional: Disable it
- If secure alternatives exist: Switch to them (e.g., stronger crypto)
- If security controls are available: Enable them
- If network exposure is unnecessary: Restrict access
-
Assess impact:
- Will disabling the feature break functionality?
- Are there dependencies on the current configuration?
- What's the performance/UX impact?
- Is the change reversible?
Configuration types to consider:
- Application config files (YAML, JSON, properties)
- Environment variables
- Command-line flags
- Runtime feature flags
- Web server configuration (nginx, apache)
- Network policies (firewalls, Kubernetes NetworkPolicy)
- Infrastructure as Code (Terraform, CloudFormation)
Document specific configuration changes needed with rationale.
Step 2C: Plan Code Refactoring (If Applicable)
Analyze the vulnerability to determine code changes needed:
Step 2C.1: Identify Vulnerable Code Patterns
-
Review the CVE description:
- What specific code pattern or API usage is vulnerable?
- Is it about how a function is called or what's passed to it?
- Are there examples of vulnerable vs. safe usage?
-
Locate vulnerable code in the codebase:
- Search for the vulnerable function/method calls
- Identify all files and locations where it's used
- Understand the context of each usage
-
Categorize the refactoring type:
- API migration: Old API → new safe API
- Pattern replacement: Unsafe pattern → safe pattern
- Input handling: Add validation/sanitization
- Error handling: Add proper error checks
- Resource management: Add limits/cleanup
- Security controls: Add authentication/authorization checks
Step 2C.2: Design the Refactoring
Based on the vulnerability type, determine the approach:
For unsafe API usage:
- Replace with secure alternative API
- Add security parameters/options to existing calls
- Wrap calls with safety checks
For missing input validation:
- Add validation before vulnerable operations
- Sanitize/escape untrusted data
- Use type-safe APIs where possible
For resource management issues:
- Add resource limits (size, time, count)
- Implement proper cleanup (defer, finally)
- Use safer resource handling patterns
For logic flaws:
- Fix incorrect conditionals/checks
- Add missing security validations
- Correct state management
Step 2C.3: Plan Migration Strategy
-
Find all usage locations:
grep -r "<function-name>" --include="*.go" .
# Or use codebase_search for semantic search
-
Assess each usage:
- Is this usage vulnerable or safe?
- What's the correct replacement?
- Are there edge cases to handle?
-
Create migration examples:
- Document "before" and "after" for each pattern
- Explain why the change is necessary
- Note any behavior changes
-
Estimate scope:
- Number of files affected
- Complexity of changes (simple replace vs. logic rewrite)
- Test coverage available
-
Plan testing:
- Which tests need updates?
- Are new tests needed?
- How to verify the fix works?
Document specific code changes with file paths, line numbers, and refactoring rationale.
Step 2D: Apply Security Patches (If Applicable)
When vendor provides patch files:
-
Obtain the patch:
- Download from vendor security advisory
- Verify patch authenticity and source
- Check patch format (unified diff, git patch, etc.)
-
Review the patch carefully:
- Understand what changes it makes
- Verify it targets the correct vulnerability
- Check for any side effects or breaking changes
- Ensure it's appropriate for your version
-
Apply the patch:
- Test in non-production environment first
- Use appropriate tool (
patch, git apply)
- Handle conflicts if any
- Document what was patched
-
Verify the patch:
- Confirm changes applied correctly
- Run tests to ensure no breakage
- Test the vulnerability is actually fixed
- Document patch source and date
For Go module patches:
- Consider forking the repository
- Apply patch to your fork
- Use
replace directive in go.mod to use patched version
- Document this is temporary until official fix
Alternative: If patch is complex or risky, consider workarounds (Step 3) while waiting for official release.
Step 3: Plan Workarounds (If No Fix Available)
Analyze the vulnerability to design appropriate mitigations:
Step 3.1: Understand the Vulnerability
Ask these questions about the CVE:
-
What type of vulnerability is it?
- DoS, RCE, injection, authentication bypass, information disclosure, etc.
-
What triggers the vulnerability?
- User input, specific API calls, network requests, file operations, etc.
-
What is the attack vector?
- Remote/network-based, local, requires authentication, etc.
-
What resource/capability is affected?
- CPU, memory, network, data confidentiality, system integrity, etc.
-
What conditions must exist for exploitation?
- Specific input patterns, race conditions, particular configurations, etc.
Step 3.2: Identify Mitigation Strategies
Based on vulnerability characteristics, consider appropriate defenses:
For Input-Related Vulnerabilities:
- Validate input size, format, and content before vulnerable code
- Sanitize/escape untrusted input
- Reject known malicious patterns
- Use allowlists instead of denylists where possible
For Algorithmic Complexity / DoS:
- Impose timeouts on operations
- Limit resource consumption (CPU time, memory)
- Add circuit breakers to prevent cascading failures
- Cache results when possible
- Consider simpler/safer algorithms for untrusted input
For Resource Exhaustion:
- Rate limit requests (per user, per IP, globally)
- Set quotas on operations
- Implement backpressure mechanisms
- Monitor and alert on unusual patterns
For Authentication/Authorization Issues:
- Add additional authentication checks
- Restrict network access (firewalls, NetworkPolicies)
- Require multi-factor authentication
- Log and monitor access attempts
For Information Disclosure:
- Redact sensitive data in responses
- Restrict access to affected endpoints
- Add encryption in transit/at rest
- Audit and minimize data exposure
For Code Execution Vulnerabilities:
- Run vulnerable code in sandboxes
- Reduce privileges (principle of least privilege)
- Disable dynamic code execution if possible
- Add integrity checks
Step 3.3: Design Layered Defense
Apply defense-in-depth principles:
- Layer multiple controls - Don't rely on a single mitigation
- Fail securely - If mitigation fails, fail closed not open
- Monitor for exploitation - Add logging/alerting for attack attempts
- Consider degraded functionality - Can you disable features temporarily?
Step 3.4: Evaluate Trade-offs
For each mitigation:
- Effectiveness: How well does it address the vulnerability?
- Impact: Will it break legitimate use cases?
- Performance: What's the overhead?
- Complexity: How difficult to implement and maintain?
- Risk: Could the workaround introduce new issues?
Step 3.5: Document Mitigation Plan
For each workaround, specify:
- What it protects against
- How it works
- Where to implement it (code location, config file, infrastructure)
- Expected impact on functionality/performance
- Monitoring/logging to detect bypass attempts
- When it can be removed (after patching)
Note: Workarounds are temporary defenses, not permanent solutions. Always prioritize updating to a fixed version when available.
Step 4: Create Verification Plan
Design a comprehensive verification strategy:
-
Understand project testing infrastructure:
- Does the project have a Makefile with standard targets?
- What build and test commands does the project use?
- Are there CI/CD pipelines that should be considered?
- What testing levels exist? (unit, integration, e2e)
- Are there performance or security-specific tests?
-
Plan verification layers:
Dependency Verification:
- Confirm the updated version is actually in use
- Verify go.mod and go.sum are correctly updated
- Check for unexpected transitive dependency changes
- Ensure no conflicts were introduced
Build Verification:
- Confirm the project builds successfully
- Check for new compiler warnings
- Verify all target platforms still build
- Test with different Go versions if applicable
Functional Verification:
- Run existing test suites (unit, integration, e2e)
- Focus on code paths that use the updated dependency
- Test edge cases related to the vulnerability
- Consider adding regression tests for this CVE
Security Verification:
- Re-run vulnerability scanners (govulncheck, etc.)
- Confirm the specific CVE is no longer reported
- Check for new vulnerabilities introduced by the update
- Validate security assumptions haven't changed
Regression Verification:
- Test critical user journeys
- Check performance hasn't degraded
- Verify logging and monitoring still work
- Test error handling and edge cases
-
Sequence the verification steps:
- Start with fast, cheap checks (dependency verification)
- Progress to more expensive tests (full test suite)
- End with manual/exploratory testing if needed
- Consider parallel execution where possible
-
Define success criteria:
- What must pass before considering the fix complete?
- What level of test coverage is acceptable?
- How to handle test failures (existing vs. new)?
- What monitoring should be in place post-deployment?
-
Plan for different environments:
- Local development verification
- CI/CD pipeline checks
- Staging environment validation
- Production canary/gradual rollout
Document specific verification commands, expected outcomes, and decision points for handling failures.
Step 5: Generate Remediation Plan Document
Create a comprehensive, context-specific remediation document:
Structure the document based on the remediation type:
-
Executive Summary Section:
- State the CVE and its severity clearly
- Summarize the vulnerability impact on THIS project
- Present the recommended remediation approach
- Highlight urgency and risk levels
- Note any critical dependencies or blockers
-
Detailed Remediation Steps:
Tailor to the remediation type selected:
- For dependency updates: Explain the version change, why this version, compatibility considerations
- For Go runtime updates: Explain version requirements, migration path, compatibility impacts
- For configuration changes: Specify exact changes, why they work, impact on functionality
- For code refactoring: Detail the code changes, locations, before/after comparisons
- For workarounds: Explain each mitigation, why it's effective, limitations
Include:
- Step-by-step instructions (not just commands)
- Rationale for each decision made
- Project-specific context and considerations
- Estimated time and effort
- Prerequisites and dependencies
-
Verification Plan:
- Specific commands appropriate to the project
- Success criteria for each verification step
- What to look for (not just "run tests")
- How to interpret results
- What to do if verification fails
-
Risk Assessment:
Update Risk:
- What could go wrong with this remediation?
- Breaking changes identified
- Dependencies on other changes
- Performance implications
- Rollback difficulty
Not Updating Risk:
- Exploitability in THIS environment
- Actual exposure (reachability, network access)
- Potential impact (data, availability, reputation)
- Likelihood of exploitation
- Compliance implications
-
Implementation Strategy:
- Environment progression (dev → staging → prod)
- Rollout approach (big bang, canary, gradual)
- Monitoring and validation checkpoints
- Rollback triggers and procedures
- Communication plan for stakeholders
-
Timeline and Effort:
- Estimated time for each phase
- Resource requirements
- Critical path items
- Recommended deadline based on risk
-
Supporting Information:
- Links to relevant documentation
- References to CVE advisories
- Related issues or PRs
- Contact information for escalation
Adapt the document structure and depth to:
- Remediation complexity
- Organizational needs
- Audience (technical team, management, security)
- Risk level and urgency
The document should enable someone to execute the remediation plan without additional context.
Return Value
Return structured plan to parent command:
{
"skill": "remediation-planning",
"status": "success",
"input_summary": {
"cve_id": "<from Phase 1>",
"risk_level": "<from Phase 2>",
"reachable": "<from call-graph-analysis or unknown>",
"fixed_version_available": "<true|false from Phase 1>"
},
"remediation_decision": {
"strategy_selected": "<dependency_update|go_runtime_update|configuration|code_refactoring|workaround|combination>",
"reasoning": "<why this strategy based on inputs>",
"priority": "<CRITICAL|HIGH|MEDIUM|LOW based on severity+confidence+reachability>",
"driven_by": {
"primary_factor": "<main decision factor from analysis>",
"confidence_factor": "<confidence level justification>",
"availability_factor": "<fix availability>"
}
},
"remediation_plan": {
"remediation_type": "<type>",
"complexity": "<LOW|MEDIUM|HIGH>",
"fix_available": true,
"requires_code_changes": false,
"requires_go_update": false,
"requires_config_changes": false,
"update_commands": ["go get ...", "go mod tidy"],
"config_changes": [],
"code_changes_summary": "",
"verification_commands": {
"verify": "make verify || go mod verify",
"build": "make build || go build ./...",
"test": "make test || go test ./...",
"vuln_check": "govulncheck ./..."
},
"breaking_changes": [],
"estimated_effort": "15 minutes",
"risk_level": "LOW"
},
"project_context": {
"has_makefile": true,
"available_commands": ["verify", "build", "test"],
"go_version": "1.21",
"dependency_type": "indirect"
}
}
Priority Determination:
Priority should be calculated based on multiple factors:
- CVE severity (CRITICAL/HIGH/MEDIUM/LOW)
- Confidence level of impact assessment
- Reachability of vulnerable code
- Availability of fixes
- Exploitability in the specific environment
- Business criticality of affected systems
Higher priority when: severe + high confidence + reachable + fix available
Lower priority when: low severity + uncertain + not reachable + no immediate fix
Automated Fix Eligibility - Decision Framework:
Evaluate whether to offer automated fix application by considering:
-
Confidence Level:
- HIGH confidence → Automation is safer
- MEDIUM/LOW confidence → Manual review required
-
Remediation Complexity:
- Simple dependency update with no breaking changes → Good candidate
- Multiple steps or code changes → Manual application safer
- Configuration changes with unclear impact → Needs review
-
Risk Assessment:
- Well-tested fix from trusted source → Lower risk
- Affects critical code paths → Manual verification needed
- Breaking changes possible → Requires careful review
-
Project Maturity:
- Strong test coverage → Automation safer
- Limited testing → Manual application with thorough testing
- Active development → Consider coordination
-
Blast Radius:
- Small, localized change → Automation acceptable
- Wide-ranging impact → Manual control preferred
- Affects production systems → Needs careful planning
General principles:
- Only offer automation for high-confidence, low-risk scenarios
- Always provide clear rationale for the decision
- When in doubt, recommend manual application with monitoring
- Automation should never bypass testing and verification
Integration with Parent Command
This skill is called from Phase 4 of /compliance:analyze-cve.
Input Pipeline:
Phase 1 (CVE Intelligence) → CVE profile, severity, affected package, fixed version
Phase 2 (Impact Analysis) → Risk level, current version, usage locations
↓ Optional: Call Graph Analysis Skill → Reachability risk level, call chain
↓ Optional: govulncheck → Detection result, vulnerable symbols
Phase 3 (Report Generation) → Consolidated impact assessment report
Phase 4 (THIS SKILL) → Complete remediation plan based on all inputs
Phase 5 (Fix Application) → Execute remediation using plan from this skill
Output: Complete remediation plan tailored to the specific CVE and project context, including verification strategy, risk assessment, priority determination, and automated fix eligibility decision based on thorough analysis.