[dekelattias-orca]

Why

The floating v1 tag is what this repo's README tells users to pin to, but nothing moves it — it has to be done by hand after each release.

In orcasecurity/shiftleft-sast-action that step was missed on four consecutive releases and v1 sat on a February build for nine months, until a customer noticed their workflows were not picking up fixes. This repo is currently in sync (v1 -> 9cceca83 = v1.0.6, Nov 2024), so this is preventative, not a fix. It has not released in two years, which cuts both ways: drift is unlikely, but it would also go unnoticed for a long time.

Same fix as orcasecurity/shiftleft-sast-action#26.

Change

Adds .github/workflows/update-major-tag.yml, which re-points the major tag at the newest release:

• release: released — moves v1 to the published vMAJOR.MINOR.PATCH tag automatically. released does not fire for pre-releases, so a pre-release can never move v1.
• workflow_dispatch — moves it on demand; optional tag input, falls back to the latest release. Passing an older tag rolls v1 back.

Guards: a concurrency group so two releases published close together can't race on the force-push; tags that aren't vMAJOR.MINOR.PATCH are skipped with a warning; the major is derived from the release tag, so a future v2 works unchanged.

The tag stays annotated. Needs contents: write. The only action used is actions/checkout, pinned to the same SHA already used by this repo's other workflows.

Verification

YAML parses and the tag-resolution logic was exercised locally. The workflow itself has not been executed — workflow_dispatch only appears once the file is on the default branch, and the release path needs a real release. After merging, run it once manually from the Actions tab: it will be a no-op on content, but it proves contents: write is sufficient and that no tag ruleset blocks the force-push.

Caveat

If a ruleset is ever added over refs/tags/v*, this push will fail unless the ruleset grants the workflow a bypass. There's a comment in the file to make that easy to trace.

[orca-security-eu]

Orca Security Scan Summary

Status	Check	Issues by priority
Passed	Secrets	0   0   0   0	View in Orca
Passed	Vulnerabilities	0   0   0   0	View in Orca

[guydanko-orca]

CI fix: container_scan_job

Failure:

│ zlib    │ CVE-2026-4738    │ 1.3.2-r1          │ 1.4-r0        │ CRITICAL │ ... │ FAILED │
│ Vulnerabilities of critical severity with fix available │ HIGH     │ FAILED │
Orca Built-in - Container Image Vulnerabilities Policy | FAILED
SCAN RESULT: FAILED (due to policy violations)

Root cause: test-container-action.yaml scans the floating upstream image alpine:3, which currently ships zlib 1.3.2-r1 with a fixable critical CVE, so the built-in policy fails. This PR only adds a release/dispatch workflow and doesn't touch the scanned image; the previous run of this test (2026-05-11, fix/non-root-apk-install) also failed.
No fix needed on this PR: failure comes from upstream alpine:3, not this change. Clears on re-run once alpine:3 picks up zlib 1.4-r0, or by changing the test workflow.
Verified: read the failed job log for run 42478338082; confirmed the test scans alpine:3 and the PR diff only adds .github/workflows/update-major-tag.yml.
Prevention: Don't gate PR tests on scan results of floating upstream images; pin a digest or don't fail the job on policy violations.

[guydanko-orca]

LGTM. Matches the workflow merged in orcasecurity/shiftleft-sast-action#26.

[dekelattias-orca]

CI fix: container_scan_job

Failure:

│ zlib │ CVE-2026-4738 │ 1.3.2-r1 │ 1.4-r0 │ CRITICAL │ 9.4 │ FAILED │
│ Vulnerabilities of critical severity with fix available │ HIGH │ FAILED │
POLICY SUMMARY
Orca Built-in - Container Image Vulnerabilities Policy | FAILED
IMAGE SCAN SUMMARY [alpine:3]
SCAN STATUS: COMPLETED
SCAN RESULT: FAILED (due to policy violations)
VULNERABILITIES BY SEVERITY:
[TOTAL: 1 | CRITICAL: 1 | HIGH: 0 | MEDIUM: 0 | LOW: 0 | UNKNOWN: 0]

Root cause: container_scan_job scans the floating alpine:3 tag, and the current alpine:3 ships zlib 1.3.2-r1, which is affected by CVE-2026-4738 (critical, CVSS 9.4, fixed in 1.4-r0). The built-in container image vulnerabilities policy fails on a critical with a fix available, so the job exits non-zero. The CVE is in the upstream base image, not in anything this branch changes.

No fix needed on this PR: this PR adds only .github/workflows/update-major-tag.yml, which triggers on release: released and workflow_dispatch — it does not run on pull_request and cannot influence container_scan_job. Nothing here touches the Dockerfile, the scanned image, or the policy. A rebase or re-run will not clear it either: it clears when alpine:3 picks up zlib >= 1.4-r0 upstream, or when the test's scan target is pinned//the policy expectation is adjusted. That is a separate change and should not be bundled into this one.

Verified: read the failed job log for run 42478337986; confirmed the same workflow's previous run (May 2026, fix/non-root-apk-install) also failed, so this is not specific to this branch; confirmed the four sibling PRs applying the identical workflow all pass CI (orcasecurity/shiftleft-secrets-action#17, orcasecurity/shiftleft-sca-action#7, orcasecurity/shiftleft-iac-action#58, orcasecurity/shiftleft-sast-action#27).

Prevention: Pin the scan target in test workflows to an image digest so base-image CVE drift surfaces on a deliberate bump instead of failing unrelated PRs.