Skip to content

chore(#511): relax release-gated semgrep to fail-on-ERROR#521

Merged
atlas-apex merged 1 commit into
devfrom
chore/GH-511-semgrep-fail-on-error
Jun 6, 2026
Merged

chore(#511): relax release-gated semgrep to fail-on-ERROR#521
atlas-apex merged 1 commit into
devfrom
chore/GH-511-semgrep-fail-on-error

Conversation

@atlas-apex

Copy link
Copy Markdown
Collaborator

Summary

  • Stops the release-gated Security Scan reding clean releases on pre-existing low-severity lint — the scan (semgrep r/bash, added in [Feature] Release-gated security scan on the framework repo itself (dog-food the Shield pipeline) #487) failed its first real run on the v2.3.0 tag with 0 ERROR + 4 WARNING, because SEMGREP_FAIL_SEVERITY was WARNING. It runs post-merge on the tag so it didn't block v2.3.0, but it would red every future release until the 4 findings are cleaned up.
  • Flips the default to ERROR in both places — the framework's own .github/workflows/security-scan.yml and the adopter golden-path template golden-paths/pipelines/security.yml. The existing fail logic already supported both modes, so this is purely a threshold change.
  • WARNING stays advisory, not silenced — medium findings are still surfaced in the step summary; only ERROR (high) fails the gate. Teams wanting stricter gating set SEMGREP_FAIL_SEVERITY=WARNING (template) or pass fail_on_severity: WARNING (framework workflow input).
  • Chose option (a) over (b) (fix/suppress the 4 findings) — a freshly-added gate shouldn't pin releases to a moving target, and the same relaxation benefits every adopter who hits their own pre-existing WARNINGs. Recorded in AgDR-0063-semgrep-severity-policy.

Testing

  1. python3 yaml.safe_load on both workflow files → parse clean.
  2. Confirmed both now set SEMGREP_FAIL_SEVERITY to ERROR and the existing FAIL_SEV branch logic handles ERROR-only correctly (lines ~163 / ~127).
  3. markdownlint clean on the new AgDR.
  4. A real validation is the next release-tag run going green — can't trigger a release from a PR; called out for post-merge confirmation (matches the ticket's AC).

The 4 pre-existing r/bash WARNING findings remain as ordinary, non-release-blocking debt and can be cleaned up in a follow-up.

Closes #511


Glossary

Term Definition
SEMGREP_FAIL_SEVERITY Threshold at/above which a semgrep finding fails the CI job (WARNING = medium, ERROR = high).
Release-gated scan A security scan that runs on the release tag push (post-merge) rather than on every PR.
Advisory finding A finding surfaced in the step summary that does not fail the job.
AgDR Agent Decision Record — ApexYard's lightweight ADR capturing the why + alternatives for a decision.

- Set SEMGREP_FAIL_SEVERITY default ERROR (was WARNING) in both the framework's
  .github/workflows/security-scan.yml and the adopter golden-path template
  golden-paths/pipelines/security.yml
- WARNING (medium) findings stay advisory in the step summary; only ERROR fails
- Stops a clean release reding on pre-existing low-severity bash lint (the 4
  WARNING findings that red the v2.3.0 release scan); they remain trackable debt
- Decision recorded in AgDR-0063-semgrep-severity-policy

Closes #511

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

@atlas-apex atlas-apex left a comment

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review: PR #521

Commit: 76196a91dcfa1963df484cb1c8f880bd926030f5

Summary

Flips the default SEMGREP_FAIL_SEVERITY from WARNING to ERROR in the framework's release-gated scan (.github/workflows/security-scan.yml) and the adopter golden-path template (golden-paths/pipelines/security.yml), documents the policy inline, and records the decision in AgDR-0063-semgrep-severity-policy.md. WARNING (medium) findings stay advisory in the step summary; ERROR (high) still hard-fails. Resolves the v2.3.0 release going red on 0 ERROR + 4 pre-existing WARNING findings (#511).

Checklist Results

  • ✅ Architecture & Design: N/A (CI config + AgDR)
  • ✅ Code Quality: Pass
  • ✅ Testing: Pass
  • ✅ Security: Pass
  • ✅ Performance: N/A
  • ✅ PR Description & Glossary: Pass
  • ✅ Summary Bullet Narrative: Pass
  • ✅ Technical Decisions (AgDR):Pass (AgDR-0063 ships in this PR)
  • ✅ Adopter Handbooks: N/A (no handbook triggers in diff)

Issues Found

None blocking.

Threshold-change consistency (the key verification): Confirmed the existing two-branch fail-logic handles ERROR-only mode correctly in both files:

  • security-scan.yml:161-167if FAIL_SEV=WARNING fails on WARNING>0 OR ERROR>0; elif FAIL_SEV=ERROR fails only on ERROR>0.
  • security.yml:128-132 — same structure: WARNING mode fails on WARNING+ERROR>0; ERROR mode fails only on ERROR>0.

With 0 ERROR + 4 WARNING, the ERROR branch does not fire → job passes. The flip is consistent with the pre-existing logic; no logic change was needed, only the env default. Both the framework input override (fail_on_severity) and the template env override remain functional escape hatches for stricter gating.

Security posture: This relaxes the gate for medium severity only; high-severity (ERROR) findings still block. WARNING is surfaced, not silenced. The AgDR documents the accepted tradeoff. Sound default for a freshly-added release gate — agree with option (a) over (b).

Suggestions

  • nit: the PR body uses "reding"/"red" as a verb in a couple of bullets — stylistic only, no change required.
  • The 4 pre-existing r/bash WARNINGs are correctly tracked as non-blocking debt for a follow-up; consider filing a tracking ticket so they don't drift.

Verdict

APPROVED

Pre-existing shellcheck/style warnings in untouched embedded script blocks were treated as out of scope for this PR, per the change's intent. The post-merge release-tag-green validation is the right call given a release can't be triggered from a PR.


🤖 Reviewed by Rex (Code Reviewer Agent)
📌 Reviewed commit: 76196a91dcfa1963df484cb1c8f880bd926030f5

@atlas-apex atlas-apex merged commit 2422927 into dev Jun 6, 2026
3 checks passed
@atlas-apex atlas-apex deleted the chore/GH-511-semgrep-fail-on-error branch June 6, 2026 10:18
@atlas-apex atlas-apex mentioned this pull request Jun 6, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants