What you will put in place
- Run checks on the revision that will be merged and show failures clearly.
- Introduce a narrow policy in observation mode before enforcing it.
- Separate a security finding from a scanner or infrastructure failure.
Protect the pipeline before giving it more access
Security checks often need repository access and produce sensitive reports. Give the integration only the permissions it needs. Review how pull requests from forks run, which jobs can read secrets, and whether changes to CI configuration receive owner review.
OWASP’s CI/CD Security Cheat Sheet covers the pipeline’s own security, including identity, access, credentials, and build integrity. Use that guidance alongside application scanning; a passing source-code check does not establish that the build system is secure.
- Require review for workflow changes and protect release branches.
- Keep privileged deployment jobs separate from untrusted pull request jobs.
- Use short-lived credentials where supported and set explicit job permissions.
- Restrict report visibility; redact credentials and customer data from logs.
- Record the source revision, tool configuration, and resulting artifact for each check.
Choose checks that fit the change
Map checks to the application’s languages and deployment artifacts. Source analysis, dependency review, secrets detection, infrastructure checks, and image scanning answer different questions. Run the checks that are relevant to the artifacts a pull request can change, and document the paths and languages that are excluded.
Keep the initial scope small enough to review. Check new changes during the pull request and schedule broader baseline reviews separately. Existing risk still needs an owner and a remediation plan, even when the pull request policy focuses on newly introduced issues.
| Check | Useful context | Review output |
|---|---|---|
| Source review | Changed paths, application boundaries, relevant callers | Affected code and impact rationale |
| Dependency review | Lockfile, version, runtime use, available update | Affected package and upgrade decision |
| Secrets detection | File location and credential owner, without exposing the value | Revocation or rotation task |
| Infrastructure review | Target environment and identity permissions | Configuration change and risk owner |
| Container review | Image digest and deploy destination | Affected component and rebuild plan |
Write the gate policy in plain language
A gate needs more than a severity threshold. Define which findings are new, what evidence is sufficient, who can approve an exception, and what happens when the check cannot complete. Make the policy easy for a developer to find from the pull request result.
The example below is a discussion template. Select severity levels, evidence requirements, and review deadlines with your security and engineering owners. Start in observation mode, collect decisions over representative releases, and then require only the checks your team can operate reliably.
Scope: selected production application repositories
Mode: observe, then enforce after pilot review
Require security review when:
- a new high or critical finding meets the agreed evidence criteria
- a change introduces a credential that needs rotation
For every finding:
record revision, affected paths, impact, and remediation owner
For every exception:
record approver, rationale, scope, expiry, and tracking issue
When a check errors or times out:
show CHECK_FAILED; route to the integration owner
use the documented release exception process if needed
Before merge:
required checks must apply to the current merge revisionIllustrative policy text. This is not a vendor configuration file or a production-ready CI workflow.
Give developers a result they can act on
A failed check should link to a concise report with the affected revision, the relevant evidence, and the required next action. Keep infrastructure errors distinct from application findings. A timeout is an incomplete check, not evidence that the change is safe or unsafe.
For suggested patches, preserve the normal review process. Confirm that tests pass, the change preserves application behavior, and the security issue is addressed at the updated revision. If a dependency upgrade or infrastructure change requires coordination, document that dependency instead of treating an automated suggestion as the final answer.
- Use stable finding identifiers so developers can track a result across runs.
- Avoid repeating unchanged comments on every push; link to the latest decision.
- Provide an owner and response path for disputed findings.
- Re-run relevant checks after the branch changes or the merge target advances.
Operate the gate as a production dependency
Assign an integration owner and a fallback process. Monitor completion rate, added wait time, review outcomes, and exception usage. The same dashboard should make it clear whether a quieter week reflects fewer problems or fewer successful checks.
Review the policy periodically with engineers. Expand enforcement when the evidence supports it, and investigate recurring failures before adding more required checks. Keep historical findings in a separate remediation workflow so routine code changes still receive clear decisions.
- Before rollout: permissions reviewed, exclusions documented, pilot owners assigned.
- Before enforcement: result quality assessed, policy agreed, exception process tested.
- Each release: required checks cover the current revision and failures have owners.
- Each review cycle: compare successful coverage, review time, fixes, and exceptions.
References and approach
This guide combines the referenced security guidance with Winfunc’s practical planning recommendations. The examples are starting points to adapt to your application, release process, and risk owners.