Security scan

P2P security scanning gives application teams security feedback from the same workflows they already use for Path to Production.

Security scans look for:

source dependency vulnerabilities using Trivy
image operating system and package vulnerabilities using Trivy
committed secrets and secrets embedded in images using TruffleHog

By default, security findings are reported but do not block the pipeline. You can turn vulnerability and verified secret findings into a hard gate by setting a blocking severity.

Scanner failures, authentication failures, invalid workflow configuration, and malformed ignore files can still fail a workflow while security scanning is enabled.

Scan on P2P stages

Security scanning is built into the main P2P workflows.

Stage	What is scanned	When it runs
Fast Feedback	Source code and built images	On pull requests and pushes, alongside the normal fast feedback jobs
Extended Test	Images promoted to extended test	On main branch extended-test runs, before promotion to prod
Production	Images ready for production deployment	On main branch prod runs, before deployment

If the workflow runs on a pull request and has pull-requests: write permission, P2P updates sticky PR comments with the active findings. The same results are also available in the workflow summary and uploaded artifacts.

Configure scan behaviour

Use security-scan-blocking-severity on the P2P workflow to control whether findings block the pipeline.


jobs:
  fastfeedback:
    uses: coreeng/p2p/.github/workflows/p2p-workflow-fastfeedback.yaml@v1
    with:
      version: ${{ needs.version.outputs.version }}
      security-scan-blocking-severity: high

Available values:

Value	Behaviour
`off`	Report findings without failing the P2P workflow. This is the default.
`low`	Fail the workflow on active findings with severity `low` or higher.
`medium`	Fail the workflow on active findings with severity `medium` or higher.
`high`	Fail the workflow on active findings with severity `high` or higher.
`critical`	Fail the workflow on active findings with severity `critical`.

Verified secrets are treated as critical when blocking is enabled.

The same input is available on:

p2p-workflow-fastfeedback
p2p-workflow-extended-test
p2p-workflow-prod
p2p-workflow-security-scan

Two additional controls are available as escape hatches:

Option	Default	Behaviour
`security-scan-enabled`	`true`	Set to `false` to skip managed security scanning and policy enforcement.
`security-scan-fail-on-non-blocking-findings`	`false`	Set to `true` when you want below-threshold findings to show as failed policy jobs while the overall workflow continues.

Scheduled and ignored findings

Fast Feedback focuses on the current change. To monitor older source history and already deployed images, add a scheduled security scan.

If a finding is accepted risk, record it in .p2p-security-ignore.yaml so it no longer appears as active.