Scheduled security scan
Fast Feedback focuses on the current change. To keep monitoring older source history and already deployed images, add a scheduled security scan workflow to the application repository.
GitHub requires scheduled triggers to live in the consuming repository, so this wrapper belongs in the application repository rather than in P2P.
name: P2P scheduled security scan
on:
schedule:
- cron: "17 3 * * 1"
workflow_dispatch:
permissions:
contents: read
id-token: write
jobs:
security-scan:
uses: coreeng/p2p/.github/workflows/p2p-workflow-security-scan.yaml@v1
with:
security-scan-blocking-severity: offThe scheduled scan starts:
- a source scan over reachable git history for secrets
- a source dependency scan over the current checked-out source tree
- image scans for the latest images in Fast Feedback, Extended Test, and Production
Scheduled scans are report-only by default. Set
security-scan-blocking-severity to low, medium, high, or critical if
you want the scheduled workflow to fail on findings at or above that severity.
There is no PR comment for scheduled runs because there is no pull request.
Review the workflow summary and the uploaded artifacts instead.
Download security-source-scan-findings for source results and
security-image-scan-reports-<stage>-<github_env> for image results.
By default, scheduled image scans use the image names returned by
make p2p-images. If your repository cannot use that target for scheduled
scans, pass image-names explicitly:
with:
image-names: |
api
workerUse standard P2P image names only. Do not include the registry hostname, stage, environment, or tag.
If a stage has no deployed image tag yet, the image scan for that stage is skipped.
For repositories with multiple P2P projects, set working-directory to the
directory that contains the relevant Makefile. Scheduled scans use that
directory when running make p2p-images, and image scans read the ignore file in
that directory as well as the repository-root ignore file.