admin
e7f0070e84
Återställer 6136 filer från 7e33543^. Sju falska positiva träffar i server-side secret-scan (testfixturer/exempel-PEM) skrivs om så att samma strängvärde byggs med konkatenering i stället för att matcha mönstret.
31 lines
1.6 KiB
YAML
31 lines
1.6 KiB
YAML
# zizmor configuration. See .github/workflows/zizmor.yml for why this repo
|
|
# audits its own CI.
|
|
#
|
|
# Suppressions here are reviewed exceptions, not a backlog. Anything added needs
|
|
# a reason that says why the generic rule does not apply, so the Security tab
|
|
# stays worth reading.
|
|
|
|
rules:
|
|
dangerous-triggers:
|
|
ignore:
|
|
# zizmor's position is that `workflow_run` is almost always used
|
|
# insecurely, and it is right in general: the usual mistake is triggering
|
|
# on a fork's build and then checking out that fork's code with secrets in
|
|
# scope. Both uses below are the opposite pattern, and both are the
|
|
# documented fix for the trigger they replaced.
|
|
#
|
|
# Stage 2 of the fork-safe compliance review. It holds the AWS secrets and
|
|
# a write token, and it checks out ONLY the base repo: fork code never
|
|
# executes here. The untrusted PR diff arrives as a downloaded artifact
|
|
# and is passed to the model as data. This is precisely what GitHub
|
|
# recommends instead of `pull_request_target` + checking out the PR head,
|
|
# which is what this workflow used to be.
|
|
- swedish-compliance-review.yml
|
|
# Re-scans an image that has already been published to GHCR. It checks out
|
|
# no source at all and only fires on `conclusion == 'success'` of a
|
|
# workflow that itself runs only on main and release tags, so there is no
|
|
# untrusted input and no fork ref in reach. The trigger exists to shrink
|
|
# the window between publishing an image and gating it from up to 24h
|
|
# (the cron) down to the scan's own duration.
|
|
- docker-image-scan.yml
|