v1.37.0

- betterleaks v1.6.1 to v1.7.0 in the per-PR Secret Leak Check (#110).
  412 rules, up from 325. Validated before pinning: the org base config and the
  audit [extend] overlay parse on both versions, and scans of three real repo
  trees are byte-identical with no findings on either.
- actions/setup-node 6.4.0 to 7.0.0 (#106), actions/setup-python 6.3.0 to 7.0.0
  (#107), github-actions group (#109). Checked against the two breaking changes
  that matter here: no shared workflow uses registry-url or NODE_AUTH_TOKEN, and
  none uses pull_request_target or workflow_run.
- workflow-template reusable pins synced to v1.36.0 (#104).
- docs: why ref creation is exempt from the workflow rule (#108).

chore(secret-leak): bump betterleaks v1.6.1 to v1.7.0 (#110)

Upstream release tracked in the operations tracker.

v1.7.0 grows the default ruleset from 325 rules to 412 (87 new detectors, 187
now carrying validation), and the generic rule starts filtering
public-by-design credentials that reach no sensitive data. There is no
config-schema change, and scan times drop across the board.

The risk in this bump is not the schema, it is the 87 new detectors: this
workflow gates pull requests across every enrolled repo, so a version that
starts reporting new findings fails everyone's CI at once. Verified before
pinning, comparing v1.6.1 against v1.7.0:

  * the canonical org base config parses on both
  * the audit [extend] overlay (base + disabledRules) parses on both
  * scans of three real repo trees produce byte-identical coverage and no
    findings on either version

Pinned to the index digest, matching the previous pin, so the reference stays
valid on non-amd64 runners.

chore(secret-leak): bump betterleaks v1.6.1 to v1.7.0 (#110)

Upstream release tracked in the operations tracker.

v1.7.0 grows the default ruleset from 325 rules to 412 (87 new detectors, 187
now carrying validation), and the generic rule starts filtering
public-by-design credentials that reach no sensitive data. There is no
config-schema change, and scan times drop across the board.

The risk in this bump is not the schema, it is the 87 new detectors: this
workflow gates pull requests across every enrolled repo, so a version that
starts reporting new findings fails everyone's CI at once. Verified before
pinning, comparing v1.6.1 against v1.7.0:

  * the canonical org base config parses on both
  * the audit [extend] overlay (base + disabledRules) parses on both
  * scans of three real repo trees produce byte-identical coverage and no
    findings on either version

Pinned to the index digest, matching the previous pin, so the reference stays
valid on non-amd64 runners.

v1.36.0: Security Suite scanner config single source of truth

- reusable-secret-leak-check: config resolution (repo-local .betterleaks.toml /
  .github/.betterleaks.toml -> centralized fetch -> built-in), new config-repo /
  config-ref inputs.
- Canonical .betterleaks.toml base; pinact config deduped to the root .pinact.yml;
  betterleaks/default.toml removed; pinact/dependabot.yml drop-in header.
- Scheduled workflow-template pin sync (#100) + pin sync to v1.35.0 (#101).

refactor(secret-leak): delete duplicate betterleaks/default.toml; dep…

…endabot drop-in header (#103)

- Delete betterleaks/default.toml. Its ruleset is now the single canonical
  .betterleaks.toml base; the weekly org audit's one divergence (disabling
  generic-api-key) is expressed as a generated [extend] overlay on the audit
  side. Update the stale "Org default.toml" note in reusable-secret-leak-check.yml
  to name the canonical base. betterleaks/ now holds only the pre-commit example.
- pinact/dependabot.yml: rewrite the header as a drop-in config. The Backstage
  scaffolder now fetches this file into repos, so it should not read as copy-me
  instructions; adoption and merge guidance stay in docs/github-actions-pinning.md.

GATED: merge only after the weekly audit (geolonia-operations) stops fetching
betterleaks/default.toml. Deleting it before that lands would 404 the audit's
config fetch.

v1.35.0

- betterleaks v1.5.0 -> v1.6.1 (Security Suite scanner) (#99)
- harden sync-team-access workflow template (explicit perms + secrets) (#98)
- github-actions group bump (4 updates) (#97)

chore(betterleaks): bump v1.5.0 -> v1.6.1 (#99)

Update the pinned betterleaks image digest in the reusable Secret Leak
Check workflow and the matching pre-commit example rev.

v1.6.1 highlights:
- Expr replaces CEL as the expression runtime (existing CEL configs
  still accepted for compatibility).
- Faster cold start (lazy regex/tokenizer init) and a smaller binary.
- Rule specificity for more accurate generic-rule suppression.
- Adds a config command; crypto dependency bump.

The org default.toml uses only regex/path allowlists (no CEL/Expr
expressions), so the runtime migration does not affect it.

Digest sha256:7a43a20d... resolved from the v1.6.1 tag on ghcr.io.

feat(techdocs): allow AWS account ID via vars, not just secrets (#95)

Reusable workflows don't auto-inherit secrets (only vars), so the AWS
account ID was the one setting forcing every caller to keep a secrets:
block (or secrets: inherit, which zizmor flags). An account ID is a
non-sensitive identifier, so read it from the vars context too:

  ...|| vars.AWS_ACCOUNT_ID || vars.TECHDOCS_AWS_ACCOUNT_ID

Back-compat: secrets are still tried first, so existing callers are
unaffected. Callers that set the org/repo variable can now drop the
secrets: block entirely (down to permissions: + uses:).

Closes #94

feat(techdocs): allow AWS account ID via vars, not just secrets (#95)

Reusable workflows don't auto-inherit secrets (only vars), so the AWS
account ID was the one setting forcing every caller to keep a secrets:
block (or secrets: inherit, which zizmor flags). An account ID is a
non-sensitive identifier, so read it from the vars context too:

  ...|| vars.AWS_ACCOUNT_ID || vars.TECHDOCS_AWS_ACCOUNT_ID

Back-compat: secrets are still tried first, so existing callers are
unaffected. Callers that set the org/repo variable can now drop the
secrets: block entirely (down to permissions: + uses:).

Closes #94

feat: fail the Security Suite on error-severity findings (TODO 2) (#93)

Previously zizmor was fully warn-only, so a PR could 'pass' the suite with a
zizmor error. Make the report job the single gate: it now exits 1 on any
error-severity condition (a hard-gate fail/error, or a zizmor error-severity
finding), after posting the summary comment so the result stays visible.

- report job: track SUITE_FAILED in the two [!CAUTION] branches, exit 1 at the
  end; update the zizmor callout to say error-severity findings block.
- zizmor step keeps continue-on-error (still emits annotations + counts); the
  report job decides blocking. Warnings/notices (and warn-only pinact) never
  block; bumblebee/betterleaks already block via their own jobs.
- docs: add a 'What blocks a PR' table to security-suite.md.

Note: once released, this blocks any repo that still has a zizmor error
(org-wide) until hardened (see #87 / infra-cdk#152 for the pattern).