Scheduled CI workflows run on the default branch, so supported older versions are skipped unless you add them on purpose. Either check out each release branch inside the scheduled job, or keep an SBOM per released version and rescan those. The second option is lighter and works across tools.
Why old versions get missed
Customers often run version 3 while your team develops version 5. A vulnerability in a library used by version 3 matters to them. A nightly scan of the main branch will never mention it.
GitHub documents that scheduled workflows run on the default branch using its latest commit (events reference). GitLab, by contrast, lets you pick a target branch or tag per schedule (pipeline schedules), so one schedule per supported branch is possible there.
Two approaches
| Approach | How | Best when |
|---|---|---|
| Branch matrix | The scheduled job loops over supported branches, checks each out and scans it | Few supported branches, source available |
| Stored SBOM per release | Rescan saved inventories nightly | Many releases, or shipped binaries and images |
Steps for the branch matrix
- Keep a small file listing supported branches, such as release/3.x and release/4.x.
- In the scheduled workflow, read that file and build a matrix from it.
- Check out each branch by name in its own job.
- Run the same scan and policy on each.
- Name results by branch so alerts show which version is affected.
- Remove a branch from the file when support ends.
strategy:
matrix:
branch: [main, release/3.x, release/4.x]
steps:
- uses: actions/checkout@v4
with:
ref: ${{ matrix.branch }}
Steps for stored SBOMs
- At each release, save an SBOM tagged with the version.
- Run the nightly match across all supported versions. See rescanning a stored SBOM without rebuilding.
- Group alerts by version and by customer commitments if you have them.
What to do with a hit
A finding on an old branch needs a decision, because the fix may not be a simple upgrade. Backporting a patch takes effort. Options are to patch the branch, tell customers to upgrade, or document why the vulnerable code path is not reachable. Write down which one you chose and why.
Also define your support policy first. Scanning a branch implies you will act on what you find, so scan only what you have promised to support.
Quick check
Should end of life versions be scanned?
Scan what you support. For unsupported versions, publish the end of support date so customers know no fixes are coming.
Which approach is cheaper?
Stored SBOM rescans, because nothing is checked out or built.
Sources
Last reviewed: 19 October 2026.
