Security Execution in Pull Requests for Scalable Governance

Scope - What This Guide Covers

This guide shows you how to embed security decision-making and remediation directly into your pull request (PR) workflow. You'll learn which security controls belong in PR reviews, how to structure approval gates, and what documentation to capture for audit purposes. This isn't about adding another CI/CD scanner. It's about making security decisions where code changes happen.

Key Concepts and Definitions

Security execution: The process of identifying a risk, making a decision about it, and implementing that decision. It's different from detection.

PR-embedded security: Security controls that run, require decisions, or capture approvals within the pull request lifecycle, not in separate ticketing systems.

Auditable decision trail: A record showing who identified a vulnerability, what decision was made (fix, accept, defer), who approved it, and when the remediation merged. This trail must survive in version control, not just in screenshots.

AI-generated code: Code authored or substantially modified by LLM-based coding assistants. At major software organizations, this now represents 20 to 30 percent of repository commits.

Requirements Breakdown

What Regulations Actually Require

The NIST Secure Software Development Framework mandates documented risk management practices. Section PW.1.3 requires that "security requirements for the software are defined and documented." Section RV.1.1 requires "vulnerability management activities are performed." Neither specifies where these activities happen, you choose the location.

PCI DSS v4.0.1 Requirement 6.3.2 states that code changes must be reviewed before release. The requirement doesn't mandate a separate security review meeting; a documented PR approval satisfies this if your process captures the security assessment.

SOC 2 Type II CC7.2 (Common Criteria for System Operations) requires that system changes are authorized and tested. Your PR approval workflow becomes this authorization mechanism if you structure it correctly.

What Belongs in PR Security Checks

Not everything belongs in the PR workflow. Here's the breakdown:

Run in PR automation:

SAST scans for the changed files
Dependency vulnerability checks
Secret detection
License compliance for new dependencies

Require human decision in PR:

High/critical findings that block merge
New third-party dependencies
Changes to authentication or authorization logic
Cryptographic implementations

Handle outside PR workflow:

DAST (requires deployed environment)
Penetration testing
Threat modeling for new features
Architecture security reviews

Implementation Guidance

Setting Up Decision Gates

Your PR template should include a security checklist. Here's what works:

## Security Review
- [ ] No high/critical SAST findings unresolved
- [ ] New dependencies reviewed and approved
- [ ] Secrets scan passed
- [ ] Authentication/authorization changes reviewed by @security-team

Configure branch protection rules to require specific reviewers for security-sensitive paths. For example, require a security engineer's approval for any PR touching:

/src/auth/*
/config/security/*
package.json or equivalent dependency manifests

Capturing the Audit Trail

Your PR description should document security decisions:

Good PR description:

Fixes SQL injection in user search (SAST-1234)

Security impact: Parameterized all queries in UserController
Risk before: Critical - unauthenticated SQL injection
Testing: Added test cases for special characters, verified with sqlmap

Insufficient PR description:

Fixed security issue

The PR comments become your audit trail. When you accept a risk, document it there:

Accepting SAST finding XYZ-789 (medium severity path traversal)
Rationale: This endpoint requires admin authentication, file paths are allowlisted
Compensating control: Web application firewall blocks ../ patterns
Approved by: @security-lead
Review date: 2024-01-15

Integrating Automated Remediation

Tools like Checkmarx's Remediation Assist can generate fix suggestions directly in the PR. Your workflow should:

Scanner identifies vulnerability
Automation proposes fix as a suggested change
Developer reviews and commits the suggestion, or
Developer writes alternative fix and documents why
Security reviewer approves the approach

This creates a clear chain: detection → proposed solution → developer decision → security approval → merge.

Common Pitfalls

Pitfall: Treating PR Security as Binary Pass/Fail

Don't block every PR with a finding. You need a decision framework:

Critical findings in authentication/authorization: Block merge, require fix
High findings with exploitability: Require security team review, may accept with compensating controls
Medium/low findings: Developer documents decision, security spot-checks

The goal is documented decisions, not zero findings.

Pitfall: No Ownership for Stale PRs with Security Blocks

When a PR sits blocked on a security finding for more than 48 hours, your process has failed. Assign a security engineer as the DRI (directly responsible individual) to either help remediate or make an accept/defer decision.

Pitfall: Security Decisions in Slack, Not in PRs

If your security team discusses a vulnerability in Slack and then approves the PR without documenting the decision there, you've lost your audit trail. The PR must contain the decision rationale.

Pitfall: Ignoring the 81% Problem

Recent data shows 81% of organizations knowingly shipped vulnerable code, and 98% experienced a breach tied to vulnerable code within the last year. Your PR process must make "knowingly shipped" into a documented, approved decision, not an oversight.

Quick Reference Table

Scenario	Required Action	Documentation Location	Approval Level
Critical SAST finding	Block merge until fixed	PR comments + commit message	Security team
New third-party dependency	Risk assessment	PR description	Security team or designated developer
Medium finding with compensating control	Document control	PR comments	Tech lead + security spot check
Authentication logic change	Security review	PR description + review comments	Security team
Low/informational finding	Developer decision	PR comments (optional)	Developer
Secret detected	Block merge, rotate credential	Incident ticket + PR comments	Security team
License compliance issue	Block merge or document exception	PR comments	Legal or designated approver

Your PR workflow isn't just about code review, it's your security execution layer. Configure it to capture decisions, not just detect problems.

Security Execution in Pull Requests