Catch Security Vulnerabilities at PR Time

Most security scanning happens after the merge — when the cost of fixing is highest. Here is how shifting security analysis to pull request time changes the economics of vulnerability remediation.

The Security Scanning Timing Problem

Security scanning has traditionally followed a scheduled model: scan the main branch nightly, produce a report, and assign findings to developers. This works for catching vulnerabilities that have been in the codebase for weeks or months, but it is poorly suited to the moment when risk is actually introduced.

Consider a typical security finding lifecycle with scheduled scanning:

1. Developer writes code with a hardcoded API key in a configuration file.
2. The PR is reviewed and merged. The reviewer does not notice the key in a file that is typically ignored during review.
3. The nightly scan runs. It flags a "Hardcoded Secret" finding in the new commit.
4. A security ticket is created. It is assigned to the developer who wrote the code — but they have already moved on to a different task.
5. Days or weeks later, the developer returns to the finding, removes the secret, and opens a fix PR.

The vulnerability existed in production for days or weeks. The developer had to context-switch back to old code. And the fix went through review again — costing the same reviewer overhead as the original change.

Now consider the same scenario with PR-time security analysis:

1. Developer writes code with a hardcoded API key.
2. The PR is opened. Within seconds, CodeDig scans the diff against 200+ security rules and flags the hardcoded secret in the PR comment.
3. The reviewer sees the finding before approving. They request a change.
4. The developer fixes the secret before merging. The vulnerability never reaches production. No ticket, no context-switch, no follow-up scan.

Why PR-Time Scanning Is Faster and Cheaper

The difference is not just timing — it is context. When a security finding is surfaced at PR time, the developer who wrote the code still has full context on the change. They know why they wrote the line, what alternatives they considered, and where the value should be stored instead.

When a finding is surfaced days later, the developer has to: - Re-read the code to understand what they were doing - Remember or re-discover the correct remediation - Open a new branch and PR - Go through review again

Fixes that take 5 minutes at PR time can take 30 minutes or more after a context-switch.

What CodeDig Scans For

CodeDig's security scanning covers 200+ rules across multiple categories:

OWASP Top 10: - SQL injection in dynamically constructed queries - Cross-site scripting in user-facing output - Broken access control in API endpoints - Sensitive data exposure in logs and error messages - XML external entity processing in parsers

Secrets and credentials: - Hardcoded API keys, tokens, and passwords - Private key material and certificates - Connection strings with embedded credentials - Environment variable patterns that reveal secret names

Language-specific vulnerabilities: - TypeScript: eval usage, unsafe regex construction, prototype pollution - Python: command injection via os.system/subprocess, unsafe pickle deserialization - Rust: unsafe blocks, transmute misuse, panic paths in library code - Java: deserialization vulnerabilities, path traversal in file operations - Go: race conditions in shared state, unsafe pointer arithmetic - C#: LINQ injection, insecure deserialization, P/Invoke risks

PII and compliance: - Email addresses, phone numbers, and SSN patterns in code - Hardcoded connection strings with database credentials - Cryptographic key material - Logging configurations that may expose sensitive data

How Findings Are Presented

Each security finding in a CodeDig PR comment includes:

• Severity — Critical, high, medium, or low
• Location — Exact file and line number
• Rule — The specific security rule that was triggered
• Description — Why the pattern is dangerous and what risk it introduces
• Suggested fix — Where applicable, a code-level recommendation for remediation

Findings are also summarized in the Check Run so branch protection rules can block PRs with high-severity findings.

Integrating with Your Security Workflow

PR-time scanning does not replace scheduled scans — it augments them. Scheduled scans catch vulnerabilities that have been in the codebase for a long time. PR-time scanning catches new vulnerabilities before they enter the codebase.

The ideal security posture uses both:

• PR-time scanning — Catch new vulnerabilities before merge. Block critical findings from shipping.
• Scheduled scanning — Periodically scan the full repository for dormant vulnerabilities that predate security tooling.
• Dependency scanning — Monitor third-party libraries for known CVEs (separate from CodeDig's scope, but complementary).

The Result: Fewer Security Tickets, Less Context-Switching

Teams that move security analysis to PR time consistently report fewer open security tickets, faster remediation times, and less friction between engineering and security teams. The vulnerabilities either get fixed before they merge, or they never enter the codebase at all.

Scan Your Next PR

CodeDig includes security scanning in every PR analysis. Install the GitHub App and open a pull request to see which vulnerabilities your current review process is missing.