Skip to content

fix(security): scan the default branch on push to keep CodeQL current - #280

Merged
parthrohit22 merged 1 commit into
Second-Origin:devfrom
parthrohit22:fix/codeql-stale-default-branch-scan
Aug 8, 2026
Merged

fix(security): scan the default branch on push to keep CodeQL current#280
parthrohit22 merged 1 commit into
Second-Origin:devfrom
parthrohit22:fix/codeql-stale-default-branch-scan

Conversation

@parthrohit22

Copy link
Copy Markdown
Collaborator

Summary

The Code scanning page reports "Warnings detected in 2 configurations" for both language:javascript-typescript and language:python.

Neither is a finding. There are zero open code scanning alerts:

$ gh api repos/Second-Origin/PARTHA/code-scanning/alerts?state=open --jq length
0

Both configurations were simply stale. The last analysis of dev itself was commit 04d8e2b2 on 3 August — 5 days and 37 commits behind the branch head.

Root cause: CodeQL only triggered on pull_request and the weekly cron. A pull_request run analyses refs/pull/N/merge, a throwaway merge ref — it never updates the branch's own stored result. So dev's analysis could only refresh once a week and drifted in between. Confirmed by trigger history:

$ gh run list --workflow=codeql.yml --limit 30 --jq '[.[].event]|group_by(.)|...'
pull_request: 30          # zero push runs — no trigger existed

$ gh api .../code-scanning/analyses?ref=refs/heads/dev
2026-08-03T06:34:11Z /language:javascript-typescript commit=04d8e2b2
2026-08-03T06:34:09Z /language:python              commit=04d8e2b2
2026-07-27T06:41:26Z ...                            # weekly gaps

Every scan on refs/heads/dev is a cron run, exactly 7 days apart.

Linked issue

None — found while reviewing the Security tab.

What changed

Infra — .github/workflows/codeql.yml

  • Added a push trigger for dev and main so the default branch is re-analysed as work lands.
  • Exempted default-branch runs from cancel-in-progress. That result is what the Security tab reports, and cancelling it mid-way through a run of merges would leave the tab stale again — the exact problem this PR fixes. PR runs still cancel, since refs/pull/N/merge and refs/heads/dev are distinct concurrency keys and never collide.
  • Corrected the schedule comment, which still claimed the weekly scan analysed "stale main" because dev was not yet the default. dev is the default branch now, so that note was actively misleading.

No application code, contracts, or schemas changed.

Acceptance criteria completed

  • Root cause identified as staleness, not vulnerabilities (0 open alerts).
  • Default branch re-analysed on every push, not only weekly.
  • Default-branch scans protected from cancellation during merge bursts.
  • Stale workflow comment corrected against real repository state.
  • Weekly cron retained as a backstop for newly-published queries.

Testing performed

Workflow parsed and asserted against its intent (note on: parses as boolean True under YAML 1.1, which the check handles):

triggers           : ['push', 'pull_request', 'schedule']
push branches      : ['dev', 'main']
pull_request       : ['dev', 'main']
schedule           : [{'cron': '17 3 * * 1'}]
concurrency group  : codeql-${{ github.workflow }}-${{ github.ref }}
cancel-in-progress : ${{ github.ref != 'refs/heads/dev' && github.ref != 'refs/heads/main' }}
permissions        : {'security-events': 'write', 'actions': 'read', 'contents': 'read'}
matrix languages   : ['javascript-typescript', 'python']

WORKFLOW VALID

The matrix is asserted to still cover exactly the two languages the Security tab lists, and security-events: write is asserted present since without it the analysis cannot upload results.

Honest limit: a workflow trigger can only be proven by GitHub executing it. The definitive evidence is a push-event CodeQL run appearing on refs/heads/dev once this merges, refreshing both configurations to the new head SHA. I cannot produce that locally and am not claiming it.

Screenshots

Not applicable — no UI change.

Security and data considerations

Improves security posture: the Security tab currently reflects code from 37 commits ago, so a vulnerability introduced since then would not appear until the next Monday cron. This closes that window to a single push.

permissions are unchanged and remain least-privilege (security-events: write only on the analyze job, contents: read at workflow level). No secrets, egress, auth, or owner-scoping changes. Scan frequency rises from weekly to per-merge on the default branch, which is well within GitHub's included CodeQL allowance for this repository.

Dependencies and blocked work

None.

Scope changes or remaining work

None.

Contributor checklist

  • Follows the branch naming and commit conventions
  • Targets dev
  • Verified locally with the commands above
  • No secrets, .env, dist/, or generated artifacts committed
  • No applied migration edited
  • Docs/behaviour claims match real repository state

The Code scanning page reported warnings detected in 2 configurations for
both language:javascript-typescript and language:python. Neither was a
finding: there are zero open code scanning alerts. Both configurations were
simply stale, last analysed at 04d8e2b on 3 August, 37 commits behind dev.

CodeQL only ran on pull_request and the weekly cron. A pull_request run
analyses refs/pull/N/merge, which never updates the branch's own result, so
dev's analysis could only refresh once a week and drifted between crons.

Add a push trigger for dev and main so the default branch is re-analysed as
work lands. Exempt default-branch runs from cancel-in-progress: that result
is what the Security tab reports, and cancelling it during a run of merges
would leave it stale again. PR and push runs use distinct refs, so they
never cancel each other.

Also corrects the schedule comment, which still claimed the weekly scan
analysed stale main because dev was not yet the default branch. dev is the
default branch now.
@parthrohit22
parthrohit22 merged commit 319870a into Second-Origin:dev Aug 8, 2026
9 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant