In what order should you set up SAST in CI/CD?

Set up SAST in this order: scan the main branch once to learn your baseline, add pull request scans in report mode, fix or suppress the noisy rules, then block only on new findings in changed code. Add a scheduled full scan last. Reversing the order, by gating on day one, is how teams end up disabling the tool.

SAST means static application security testing: analysis of source code without running it. The setup order below works with any scanner that can output SARIF, and it assumes you run it from a CI system.

Why start with the main branch and not the pull request?

Because you need a number before you need a rule. A single full scan of the default branch tells you how many findings exist, which rules produce most of them, and which repositories are worst. Without that baseline, you cannot tell whether a pull request scan is quiet because the code is clean or because the scanner is not seeing the code.

Do this outside the normal pull request flow. Write the results to a file or a dashboard and read them yourself first. Do not open tickets yet.

Step 1: baseline the default branch

Run the scanner once, locally or in a manual pipeline job. Record:

• total findings by severity,
• the five rules with the most hits,
• time to complete the scan,
• languages the scanner actually analyzed, compared with the languages in the repository.

That last line catches a classic failure: a scanner that silently skips half the codebase.

Step 2: wire up pull requests in report mode

GitHub's documentation describes code scanning as analysis that can be triggered when an event such as a push occurs in the repository, or scheduled for specific days and times. Other CI systems have equivalent triggers. For now, trigger on pull requests and do not fail the job.

Output results in SARIF. GitHub describes SARIF as an open standard that code scanning accepts from third-party tools, which means results can show up next to the diff instead of in a separate console that developers forget to open. Keeping the format standard also means you can change scanners later without rebuilding the pipeline.

Mind the cost. GitHub's docs note that code scanning uses Actions, with each workflow run consuming minutes. A scan that takes twenty minutes on every push will be noticed by finance before security.

Step 3: tune before you enforce

Take the top five rules by count. For each, choose one of three outcomes.

1. Fix the code, ideally with one change in a shared helper.
2. Disable the rule, with a written reason, if it does not apply to your stack.
3. Suppress individual findings in a reviewed file in the repository, with a reason and an owner.

Aim for a state where a typical pull request produces no findings that the author calls wrong. That is your readiness test for blocking. If it takes three weeks, take three weeks.

Step 4: gate on new findings in changed code

Now turn on blocking, but narrowly.

• Fail only on new findings, not on the existing backlog.
• Start with high severity and high confidence rules.
• Provide a documented path to override, with a named approver. A gate with no exit gets bypassed in a worse way, such as by deleting the workflow.

The old backlog gets its own plan: a weekly slot for the owning team, or a burn-down by rule. Do not make unrelated pull requests pay for it.

Step 5: add a scheduled full scan

Pull request scans only see what changed. A scheduled full scan catches findings that appear when the scanner's rules or the surrounding code change. GitHub's documentation lists scheduling as a supported option, and it also says alerts close once the code that triggered them is fixed. Send scheduled results to the owning team, not a shared inbox.

Step 6: measure and keep the rule set small

Track findings opened and closed, median time to fix, and the share of findings marked false positive. NIST's Secure Software Development Framework describes its practices as helping reduce the number of vulnerabilities in released software and address root causes. The root-cause part is why a rule that keeps firing should lead to a library or template fix, not a thousand individual patches.

What are the honest limits?

SAST finds patterns it has rules for. It misses logic flaws, such as a missing authorization check that no rule describes. It produces false positives, and someone has to read them. It does not know whether a finding is reachable in production. Pair it with dependency scanning, code review and runtime testing.

What to do

1. Run a baseline scan on the default branch and record the four numbers above.
2. Add a pull request scan in report mode that outputs SARIF.
3. Tune the top five rules, with reasons recorded in the repository.
4. Turn on blocking for new, high-confidence, high-severity findings only.
5. Add a scheduled full scan routed to owners.
6. Review the metrics monthly and retire rules that never produce a real fix.

Quick check

Sources

• GitHub Docs, About code scanning
• NIST SP 800-218, Secure Software Development Framework (SSDF) Version 1.1

Last reviewed: 18 October 2026.