Auto-fix PRs

PrismSec's auto-fix feature is the core of its agentic capabilities. When a fixable vulnerability is detected, PrismSec automatically opens a fix pull request with secure code changes, an explanation of the issue, and a link to the original finding.

This eliminates the manual work of researching, writing, and testing security fixes — developers simply review and merge.

How Auto-Fix Works

When PrismSec detects a vulnerability that can be fixed automatically:

1. Analysis — PrismSec analyzes the vulnerable code and determines the secure alternative
2. Code generation — A fix is generated using context-aware code transformation
3. Validation — The fix is validated to ensure it doesn't break functionality (e.g., syntax checks, type checks)
4. PR creation — A new branch is created with the fix, and a PR is opened against the original branch
5. Developer review — Developers review the fix, approve, and merge

Once the fix PR is merged, PrismSec re-scans the original PR and marks the finding as Fixed.

What Auto-Fix Supports

Not all vulnerabilities can be fixed automatically. PrismSec supports auto-fix for:

SAST Vulnerabilities

| Vulnerability Type | Auto-Fixable | Example Fix | |--------------------|--------------|-------------| | SQL Injection | Yes | Replace string concatenation with parameterized queries | | Command Injection | Yes | Replace shell string interpolation with argument arrays | | Path Traversal | Yes | Add path normalization and validation | | Hardcoded Credentials | Yes | Move to environment variables | | Weak Cryptography | Yes | Replace deprecated algorithms with secure alternatives | | XSS (some cases) | Partial | Escape output or use safe DOM methods | | Insecure Deserialization | No | Requires architectural changes | | Authentication Bypass | No | Requires business logic understanding |

Secret Detection

| Secret Type | Auto-Fixable | Example Fix | |-------------|--------------|-------------| | Hardcoded API keys | Yes | Move to environment variables, add to .env.example | | Database credentials | Yes | Replace with config file or env var references | | OAuth tokens | Yes | Move to secure secret storage | | Private keys | Yes | Remove from code, reference key file path instead |

Dependencies (SCA)

| Dependency Issue | Auto-Fixable | Example Fix | |------------------|--------------|-------------| | Known CVE with safe upgrade | Yes | Update version in package.json, requirements.txt, etc. | | Breaking API changes | No | Requires code changes to adapt to new API | | Deprecated package | Partial | Suggest replacement package, but migration may require manual work |

IaC & Misconfiguration

| Misconfiguration | Auto-Fixable | Example Fix | |------------------|--------------|-------------| | Public S3 bucket | Yes | Add acl = "private" or remove public access block | | Missing encryption | Yes | Add encryption configuration | | Weak IAM policy | Partial | Suggest least-privilege policy, but may require review | | Missing security group rules | No | Requires understanding of network requirements |

Example Auto-Fix PR

Finding: SQL Injection

Original code (vulnerable):

def get_user(user_id):
    query = f"SELECT * FROM users WHERE id = {user_id}"
    return db.execute(query)

Auto-fix PR changes:

def get_user(user_id):
-   query = f"SELECT * FROM users WHERE id = {user_id}"
-   return db.execute(query)
+   query = "SELECT * FROM users WHERE id = %s"
+   return db.execute(query, (user_id,))

PR description:

🔒 [PrismSec] Fix: SQL Injection in get_user()

This PR fixes a Critical SQL injection vulnerability detected by PrismSec.

**Issue:**
The original code constructed SQL queries using string interpolation, allowing
an attacker to inject malicious SQL commands by manipulating the `user_id` parameter.

**Fix:**
Replaced string interpolation with parameterized queries. The database driver
now handles escaping and sanitization automatically, preventing SQL injection.

**Testing:**
- Syntax validated ✓
- Type checks passed ✓
- No breaking changes detected ✓

**Related Finding:**
https://app.prism-sec.com/findings/abc123

---
Generated by PrismSec | Learn more: https://prism-sec.com/docs

Finding: Hardcoded Secret

Original code (vulnerable):

const stripe = require('stripe')('sk_live_abc123xyz');

Auto-fix PR changes:

- const stripe = require('stripe')('sk_live_abc123xyz');
+ const stripe = require('stripe')(process.env.STRIPE_SECRET_KEY);

Files changed:

• src/payments.js — Replace hardcoded key with environment variable
• .env.example — Add STRIPE_SECRET_KEY= placeholder

PR description:

🔒 [PrismSec] Fix: Hardcoded Stripe API Key

This PR removes a hardcoded Stripe secret key from the codebase.

**Issue:**
A Stripe API key was hardcoded in `src/payments.js`. If this code is pushed
to a public repository or accessed by unauthorized users, the key could be
used to make fraudulent charges.

**Fix:**
- Moved the API key to an environment variable (`STRIPE_SECRET_KEY`)
- Added a placeholder entry to `.env.example`
- The key must now be set in your deployment environment

**Action Required:**
1. Set `STRIPE_SECRET_KEY` in your production environment variables
2. Rotate the exposed key in your Stripe dashboard

**Related Finding:**
https://app.prism-sec.com/findings/def456

---
Generated by PrismSec | Learn more: https://prism-sec.com/docs

Reviewing Auto-Fix PRs

Before merging an auto-fix PR, review:

1. Code changes — Verify the fix is correct and doesn't break functionality
2. Test coverage — Ensure existing tests still pass (PrismSec runs CI checks if configured)
3. Context — Confirm the fix makes sense for your application's architecture

When Auto-Fix Doesn't Apply

Some vulnerabilities require human judgment or architectural changes that PrismSec cannot automate:

• Business logic flaws — E.g., missing authorization checks
• Complex refactoring — E.g., replacing an insecure library with a different API
• Context-dependent fixes — E.g., deciding which data should be encrypted

For these cases, PrismSec provides a detailed recommendation in the finding, but does not open a fix PR.

Configuring Auto-Fix Behavior

You can control when PrismSec opens auto-fix PRs:

# prismsec.yml
auto_fix:
  enabled: true
  min_severity: high          # Only auto-fix High and Critical findings
  max_prs_per_scan: 3         # Limit to avoid PR noise

See Configuring Scans for details.

Disable Auto-Fix

To disable auto-fix entirely:

auto_fix:
  enabled: false

Findings will still be reported, but no fix PRs will be opened.

Auto-Fix and CI/CD

Auto-fix PRs trigger your CI/CD pipeline just like any other pull request:

• Tests run automatically — Ensures the fix doesn't break existing functionality
• Code review — Developers review the fix before merging
• Status checks — PrismSec re-scans the fix PR to ensure the vulnerability is resolved

Limitations

• Not all vulnerabilities can be fixed automatically — Complex issues require manual intervention
• Fixes may need adjustment — Auto-generated code may not match your team's style or architecture
• Testing is still required — Auto-fix PRs should be tested like any other code change

Auto-fix is a productivity accelerator, not a replacement for developer review.

Next Steps

• Understand SAST capabilities: SAST
• Learn about secret detection: Secret Detection
• Configure scan behavior: Configuring Scans