A SAST policy should answer a narrow question at each point in delivery: what risk is serious enough to stop this action? The answer should differ for a pull request, a nightly repository scan, and a production release.
A single gate for every finding usually fails in one of two ways. It blocks routine work with low-signal results, or it becomes advisory because the team has learned to bypass it. Split the policy by workflow, keep pull request checks fast, and reserve deeper analysis for scans that can take longer.
This guide uses “high confidence” to mean a finding that the organization has decided is likely to be valid after considering the scanner’s evidence, code context, and past triage results. Define that threshold in writing. Severity alone is not enough to decide whether a pipeline should fail.
For background on scan signal and triage, read how to reduce false positives in SAST. For pipeline controls beyond code scanning, see the CI/CD security guide.
Start with three gates
Use three policy layers:
| Workflow | Purpose | Default action |
|---|---|---|
| Pull request | Stop new, credible risk before merge | Block the PR |
| Nightly full repository scan | Find risk that needs broader or slower analysis | Create and route work |
| Release | Confirm that the version going to production meets the release standard | Block the release |
The same finding can move through more than one layer. A lower-confidence result may first appear in a nightly scan, then become a release blocker after investigation confirms that it is exploitable.
Pull request gate: fast and focused on changed code
The PR gate should scan the changed files and relevant surrounding code. Its job is to prevent a new serious issue from merging while the author still has context. Do not use it to make developers clear the entire historical backlog.
Block a pull request when it introduces:
- a new high-confidence critical finding;
- a new high-confidence high finding;
- a new finding in changed code that meets a documented policy for sensitive areas, such as authentication, authorization, payment handling, or production infrastructure;
- a previously accepted finding whose code path was changed and needs its risk decision reviewed again.
Keep the scan fast. If a check cannot finish within the normal PR feedback window, run it outside the blocking path until the team can make it faster or narrow its scope.
Compare findings to a baseline on the target branch. A pre-existing finding should not fail a PR unless the PR adds the vulnerable code, changes the affected path, or invalidates the evidence used to accept it. This keeps the gate fair and makes the result actionable.
The review output should give the developer enough information to act:
- the severity and confidence used by the policy;
- the affected file, function, or code path;
- why the finding is new or changed relative to the baseline;
- the available remediation or exception route.
Teams using a scanner in PR workflows can review the relevant developer experience options and AI SAST capabilities. The policy itself should remain tool-independent: it must state the decision criteria even if the scanner or CI system changes.
Nightly scan: trade speed for coverage
Run a full repository scan at least nightly. This is the right place for checks that need more code context, consume more compute, or produce findings that require later triage.
The nightly policy should include:
- the whole repository, not only the current diff;
- lower-confidence findings that do not belong in the default PR block;
- deep data-flow analysis across files or modules;
- dependency and reachability checks;
- re-evaluation of open findings after code, framework, or dependency changes.
Route the result to the responsible team or code owner. Do not treat every nightly finding as a production incident. Set triage service levels by severity and exposure, then use the results to tune the PR policy. A recurring class of verified nightly findings may justify a new PR rule. A recurring false positive should lead to a rule, configuration, or policy change rather than repeated manual dismissal.
Dependency checks need their own decision context. A vulnerable package can be important even when application code has not changed, but a release decision should account for whether the vulnerable component is reachable and whether a fix is available. See dependency scanning for product information and software composition analysis tools for a broader overview.
Release gate: verify the version that will ship
A release gate protects a specific artifact or deployment candidate. It should re-check the policy against the commit, build artifact, and dependency set being released. Do not rely only on a PR result from an earlier revision.
Block a release when any of these conditions is true:
- a critical finding is confirmed exploitable in the release candidate;
- a required exception is unresolved, expired, or missing its approval;
- remediation validation failed after a claimed fix;
- the release cannot provide the scan or review evidence required by the policy.
Remediation validation means checking the proposed fix, not only closing the ticket. Re-run the relevant scan and confirm that the vulnerable path is removed, guarded, or otherwise addressed according to the security review. If the change is a dependency upgrade, confirm that the released dependency graph contains the intended version.
Keep release gates narrower than a full security program. A release should fail for defined, evidence-based conditions. A lower-severity finding that needs follow-up can remain tracked through the normal remediation process unless a documented exposure or compliance requirement elevates it.
Define an exception path before someone needs one
Exceptions are sometimes necessary. They should be temporary decisions with accountable owners, not permanent suppressions hidden in code or scanner settings.
Require every exception to include:
| Required record | What to capture |
|---|---|
| Named owner | The person accountable for the risk and follow-up |
| Expiry date | A date when the exception must be renewed or closed |
| Evidence | Triage notes, affected code or component, exploitability assessment, and compensating controls |
| Security approval | Approval from the designated security reviewer or group |
Also record the finding identifier, repository, affected version or branch, reason for the exception, and the remediation plan. Use a ticket or an approval system that developers and security reviewers can both access.
At expiry, the pipeline should require a new decision. The owner can remediate the issue, renew the exception with updated evidence and security approval, or stop the affected release. Do not silently extend exceptions when a branch is rebased or a dependency version changes.
Measure whether the gate helps or hurts
Security gates need operational metrics. Review them by repository and over time, then investigate changes with the engineering and security teams.
Track at least:
- PR latency: the time added by the security check and the time a blocked PR waits for resolution;
- blocked PR rate: the share of PRs blocked by the policy, separated by finding type and outcome;
- findings introduced and fixed: new findings attributed to a change, and findings resolved in the same period;
- developer override rate: the share of blocks bypassed or exceptions requested, including the reason and final decision.
High PR latency can mean the scan is too broad or unstable. A high blocked PR rate may mean the team is introducing risk, but it can also reveal an overly noisy rule. A high override rate is a policy signal: review whether the rule is poorly scoped, the exception process is too slow, or the team needs clearer remediation guidance.
Do not use a single metric as a success score. A lower blocked PR rate is not useful if developers have stopped reporting or resolving findings. Review the mix of confirmed findings, false positives, exceptions, and remediation time together.
Roll out the policy in stages
Start with a baseline period. Run the proposed rules in advisory mode, collect the findings, and validate which conditions would have blocked a PR or release. Use that data to write the first thresholds and response expectations.
Then enforce the narrowest high-signal PR rules first. Add nightly checks and route their results. Finally, enforce the release conditions after the team has confirmed the evidence, ownership, and exception process work in practice.
Review the policy on a regular schedule and after material incidents, major framework changes, or changes to the delivery process. The goal is a gate developers can understand and security teams can defend: fast feedback for new code, broader analysis outside the PR path, and a clear standard for production releases.
For guidance on placing scanning within a broader delivery workflow, see Corgea AI SAST and the CI/CD security guide.