Saltar al contenido principal

Remediation and Fix Verification

Remediation is the process of fixing security vulnerabilities. Plexicus can generate fix PRs automatically (with AI assistance) or allow manual fixes. This guide covers the remediation workflow and verification process.

Remediation Types​

When addressing a finding, you have several options:

Update the vulnerable dependency to a patched version.

  • Best for: Dependency vulnerabilities (outdated libraries, frameworks)
  • Example: lodash@4.17.20 → lodash@4.17.21 (security patch release)
  • Effort: Low (usually a version bump)
  • Verification: Automated test suite runs on the patched version

Upgrade the dependency to a major new version that fixes the issue.

  • Best for: Old dependencies with breaking changes fixed in new major version
  • Example: express@3.x → express@4.x (fixed CORS vulnerability)
  • Effort: Medium (may require code changes for API compatibility)
  • Verification: Full test suite validates compatibility

3. Workaround​

Implement a code-level mitigation without changing the dependency.

  • Best for: Vulnerabilities in core libraries or vendored code
  • Example: Input validation to prevent exploitation of a parsing bug
  • Effort: Medium to High (requires code review and testing)
  • Verification: Write new tests to cover the mitigation

4. No-Fix (Accepted Risk)​

Do not fix. Document the risk and approval.

  • Best for: End-of-life code, false positives, or accepted business risks
  • Effort: Low (documentation only)
  • Verification: Audit trail shows who accepted the risk and when

Creating a Remediation​

Automatic Remediation (AI-Assisted)​

If your plan includes AI remediation:

  1. On the finding detail page, click Create Fix or Generate Remediation

  2. Plexicus analyzes the vulnerability and suggests:

    • Remediation type (Patch, Upgrade, Workaround, etc.)
    • Proposed code changes (with diff preview)
    • Affected files (scoped to minimal changes)
    • Estimated risk level (Low/Medium/High based on scope)

  3. Review the fix:

    • Does the diff look correct?
    • Are dependencies updated safely?
    • Will existing code still work (breaking changes)?

  4. Approve and create PR:

    • Click Create Pull Request
    • Plexicus pushes a branch to your SCM (GitHub, GitLab, etc.)
    • PR title: [Security] Fix CVE-2024-1234 in lodash (auto-generated)
    • PR description includes:
      • Link to original finding
      • Severity and impact
      • Verification status (pending until merged)

Manual Remediation​

If you prefer manual fixes:

  1. On the finding detail page, click Create Issue
  2. An issue is created in your SCM with:
    • Finding details
    • Suggested remediation type
    • Links to references (CVE, advisory, etc.)
  3. Assign to a developer
  4. Developer creates a PR linking the issue
  5. Once PR is merged, mark the finding as Remediated

Remediation Workflow​

Finding Triaged
    ↓
Create Fix (AI or manual)
    ↓
Review PR
    ↓
Merge PR
    ↓
Fix Verification Scan (optional)
    ↓
Finding Resolved ✓

Step-by-Step: AI-Assisted Remediation​

1. Analyze & Generate​

  • AI reads the vulnerable code and dependency tree
  • Plexicus queries vulnerability databases (NVD, GitHub Advisories, etc.)
  • Suggested fix is generated (patch version, upgraded dependency, or code change)

2. Review PR​

  • PR is created in your SCM (GitHub, GitLab, Gitea, etc.)
  • Code review happens in your normal workflow (branch protection, required reviewers, etc.)
  • Plexicus may add automated comments:
    • "Risk Level: Low (only version bump)"
    • "Compatibility Check: No breaking changes detected"
    • "Related Findings: 3 other CVEs in this dependency (all patched)"

3. Merge​

  • PR is merged after approval
  • Finding status changes to Remediated
  • If enabled, Fix Verification scan is triggered

4. Verify (Optional)​

  • Verification scan runs in isolated environment
  • Confirms the vulnerability is no longer detected
  • Results appear in finding detail: "Fix Verified ✓"

Fix Verification (Scale+ Plan)​

Fix Verification is an additional security step that automatically validates whether your fix actually resolves the vulnerability.

How It Works​

After you merge a fix PR:

  1. Automated Scan: Plexicus checks out your branch and runs the same scanner that found the original vulnerability
  2. Comparison: Compares pre-fix and post-fix scan results
  3. Result:
    • ✅ Verified — Vulnerability no longer detected; finding marked resolved
    • ⚠️ Partially Verified — Vulnerability reduced but still present; may need additional fixes
    • ❌ Failed — Vulnerability still detected; fix did not work (check for copy-paste errors, incomplete changes)

When Fix Verification Runs​

  • Automatically — When PR is merged (if configured)
  • On-Demand — Click Verify Fix on finding detail page
  • Scheduled — Nightly verification of all merged fixes

Understanding Verification Results​

ResultInterpretationAction
Verified ✓Fix is effective; vulnerability eliminatedClose finding; mark as Resolved
Partial ✓⚠Fix addressed one instance; others remainUpdate remediation; re-review related findings
Unverified ❓Unable to verify (e.g., network issue, tool timeout)Retry or mark as manually verified
Failed ❌Vulnerability still present after mergeReopen PR; investigate root cause; update fix

Example: Fix Verification in Action​

Scenario: SQL injection vulnerability in a login form

  1. Original finding: SELECT * FROM users WHERE email = ? + user_input
  2. AI suggests: Use parameterized query (prepared statement)
  3. PR created: @app.route('/login', methods=['POST']; query = db.execute("SELECT * FROM users WHERE email = ?", (email,))
  4. PR merged
  5. Fix verification triggered:
    • Scanner re-scans the login endpoint
    • SQL injection no longer detected
    • Finding marked Verified ✓
nota

Fix Verification is available on Scale plan and above. Contact sales if you need to enable it.

Remediation PR Details​

PR Metadata​

Each remediation PR includes:

  • Title: [Security] Fix [FINDING_TYPE] in [COMPONENT]

    • Example: [Security] Fix SQL Injection in login handler

  • Branch Name: security/cve-2024-1234-lodash or fix/finding-abc123

  • Description includes:

    ## Security Fix

    Addresses finding: CVE-2024-1234 SQL Injection
    Severity: High

    ### Changes
    - Updated lodash from 4.17.20 to 4.17.21

    ### Testing
    - All existing tests pass
    - Added test case: testParameterizedQuery()

    ### Verification
    - Fix Verification: Pending (will run after merge)

    See finding: [Link to Plexicus]

  • Labels: security, auto-generated (GitHub), plexicus/fix (GitLab)

  • Assignee: Assigned to PR author (usually the security-responsible dev)

Auto-Remediation Confidence​

When AI generates a fix, it rates confidence:

ConfidenceMeaningTrust Level
High (80–100%)Straightforward patch or upgrade; no breaking changesShip immediately after review
Medium (50–80%)Some risk; may require code adaptationReview carefully; test thoroughly
Low (<50%)Complex fix or unclear contextManual review recommended; consider alternative approach

Remediation Best Practices​

1. Patch Before Upgrading​

  • Security patches (4.17.20 → 4.17.21) are safer than major upgrades (3.x → 4.x)
  • Patch first; only upgrade if patch unavailable

2. Review AI Suggestions Carefully​

  • High-confidence patches: approve quickly
  • Medium/Low confidence: add to code review queue for manual assessment
  • Watch for unintended API changes in upgrades
  • If multiple findings in the same dependency, fix in a single PR
  • Reduces review load and CI/CD runs

4. Test Thoroughly​

  • Run full test suite before merge
  • Automated testing is good; manual QA is better
  • Use Fix Verification (if enabled) to confirm

5. Document Non-Obvious Fixes​

  • Add comments in code explaining the security rationale
  • Include link to finding/advisory in PR description
  • Helps future maintainers understand the decision

6. Track Remediation SLA​

  • Critical findings: Fix within 24 hours
  • High findings: Fix within 1 week
  • Medium: Fix within 1 month
  • Use audit log to track SLA compliance

SBOM & VEX Integration​

Remediation decisions are recorded in your SBOM (Software Bill of Materials) using VEX statements:

  • Fix Released: Vulnerability fixed in new version
  • Fix Not Available: Vendor has not released a patch yet
  • Workaround Available: Mitigation exists; fix not yet deployed
  • Vulnerability Not Affected: Vulnerable component exists, but code path not used

VEX statements are exportable for compliance audits (NTIA, OpenSSF, etc.).

For more details, see SBOM & Compliance.

Handling Unpatched Vulnerabilities​

Situation: A vulnerability exists with no patch available yet (0-day, recent CVE).

Options:

  1. Workaround: Implement input validation, WAF rules, or restrict access

    • Create issue with proposed mitigation
    • Link to CVE advisory
    • Re-triage as "Accepted Risk" with expiration date

  2. Wait for Patch: Create issue marked "Blocked on vendor"

    • Set reminder to check vendor advisory weekly
    • Plan fix for when patch releases

  3. Upgrade Vendor: If stuck on old version, plan migration to supported version

    • Example: log4j 1.x (vulnerable, EOL) → log4j 2.x (maintained)

Troubleshooting Remediation​

"Fix Verification Failed"​

Cause: Vulnerability still detected after merge.

Resolution:

  1. Review the fix in your merged PR — are there typos, incomplete changes?
  2. Check if scanner configuration needs updating (exclude paths, severity thresholds)
  3. Re-run scanner manually to confirm
  4. If unsure, revert PR and try a different fix approach

"AI Generated Code I Don't Trust"​

Cause: Low confidence AI suggestion, or concerns about generated code.

Resolution:

  1. Reject the PR and create manual fix instead
  2. Add feedback: "AI suggestion too aggressive; manual fix preferred"
  3. Use manual remediation for medium/low confidence cases

"PR Conflicts with Main Branch"​

Cause: Codebase changed since fix was generated.

Resolution:

  1. Rebase PR or update branch
  2. Resolve conflicts in your SCM's conflict resolution UI
  3. Re-run Fix Verification to confirm changes still work