ci: add Security Scan stub (zizmor via reusable org workflow)

[crowecawcaw]

What

1. security_scan.yml stub — thin caller for the org's reusable reusable_security_scan.yml (zizmor GitHub Actions static analysis). Mirrors the codeql.yml caller.

2. Fix all high-severity findings so this repo passes the new fail-on-high gate:

unpinned-uses (46) — pinned all third-party actions (actions/*, aws-actions/*, dependabot/*, pypa/*) to full commit SHAs with version comments. Dependabot keeps them current. Internal aws-deadline/*@mainline refs left as-is (intentional central-bump model).

template-injection (8) — moved ${{ github.base_ref }} out of run: blocks in api-change-detection.yml into env: vars referenced as shell $VARS. Behavior-preserving; closes the shell-injection surface.

Suppressed-with-justification (10) — intentional design, not bugs; "fixing" would break working features:

• dangerous-triggers (2): workflow_run in claude_pr_review / on_opened_pr runs from the default branch, so fork PRs cannot alter behavior or secrets.
• bot-conditions (1): canonical Dependabot auto-approve actor check.
• cache-poisoning (7): test-only workflow, deterministic cache keys, no published release artifacts.

After: zizmor --min-severity high reports 0 findings on .github/.

Gate behavior

Inherits the org reusable workflow's fail-on-high gate (findings reported in the run log + PR annotations). Medium/low findings (excessive-permissions, secrets-inherit, artipacked) remain visible but non-blocking — accepted as hygiene follow-up per the org standard.

Depends on

aws-deadline/.github#89 (gate + high fixes in the reusable workflow). Merge that first so reusable_security_scan.yml@mainline resolves with the new behavior.

🤖 Draft — not published for review yet.

[github-actions]

The job-level permissions: block only grants security-events: write. Once any permissions: key is declared, every scope you do not list defaults to none — so contents becomes none here. A security scan almost certainly needs to check out the repository (and the reusable workflow inherits these permissions when called via uses:), so it likely also needs contents: read:

    permissions:
      contents: read
      security-events: write

Without it, actions/checkout in the reusable workflow may fail (definitely on a private repo; behavior on public repos is less predictable). Worth confirming against what reusable_security_scan.yml actually requires.

[github-actions]

The reusable workflow is referenced by the mutable branch ref @mainline rather than a pinned commit SHA. This is the same class of finding that zizmor itself flags (unpinned-uses), so it is slightly ironic in a security-scan stub. Since the target lives in the same org (aws-deadline/.github) the supply-chain risk is lower than a third-party action, and pinning a same-org reusable workflow to a SHA does add maintenance overhead — so this may be an intentional trade-off. Flagging for awareness.

[crowecawcaw]

Intentional

[crowecawcaw]

But I do appreciate the irony

[github-advanced-security]

You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool.

What Enabling Code Scanning Means:

• The 'Security' tab will display more code scanning analysis results (e.g., for the default branch).
• Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results.
• You will be able to see the analysis results for the pull request's branch on this overview once the scans have completed and the checks have passed.

For more information about GitHub Code Scanning, check out the documentation.