Skip to Content

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: off

The 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 worker

Use 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.