Best Practices

Checklist

Six habits that build trust into a supply chain rather than bolting it on afterwards.

	Practice	Why
1	Verify before installing	Always verify artifact signatures and provenance before installation, not after. Installing can execute code.
2	Pin versions	Use specific, immutable versions for dependencies and base images. A range is not what ships.
3	Keep attestations with artifacts	Store attestations alongside SBOMs and build artifacts so a verdict can be re-checked later.
4	Enforce policy in CI	Fail builds on BLOCK. Require attestations for releases.
5	Review WARN findings	Triage warnings regularly and address root causes rather than muting them.
6	Verify offline before promotion	Re-verify artifacts in air-gapped or offline environments before promoting them.

Policy example

A policy that blocks critical vulnerabilities and warns on missing provenance.

policy.yaml

version: "1"
rules:
  - id: block-critical-vulns
    description: "Block artifacts with critical vulnerabilities"
    when:
      vulnerability:
        severity: "critical"
    action: "BLOCK"

  - id: warn-missing-provenance
    description: "Warn when provenance is missing"
    when:
      attestation:
        type: "provenance"
        present: false
    action: "WARN"

Evaluate it against an artifact before you commit it:

phylax policy evaluate policy.yaml pkg:npm/express@4.18.2

Workflow

1. Discover Search for artifacts and assess risk and provenance.

2. Verify Verify signatures, provenance, and integrity.

3. Attest Generate and store attestations and SBOMs.

4. Enforce Evaluate policy in CI and block risky artifacts.

Recommended rollout

Adopt Phylax in stages, to build confidence and minimise disruption. Skipping to step three is the most common way a check ends up disabled in week two.

1. Start in observe mode

   Collect findings and attestation coverage without blocking anything. Give it long enough to see a normal week, including a dependency bump and a release.

2. Add WARN review

   Triage and fix the issues surfaced as WARN. This is where you learn what your baseline actually looks like, and which findings are noise for your stack.

3. Enforce BLOCK in CI

   Fail builds and releases on BLOCK verdicts, once the baseline is clean enough that a failure means something new happened.

Store attestations with artifacts

Store attestations alongside SBOMs and build artifacts, in your artifact repository rather than only in CI logs. This ensures they travel with the artifact and remain available for audit and verification long after the pipeline that produced them has been garbage collected.

Tighten policy, not the pipeline

When a finding is noisy, the instinct is to add an exception in the pipeline. Put it in the policy instead: policy is versioned, reviewable and applies everywhere, while a pipeline exception is invisible to everyone who is not reading that YAML file.

Related guides

Put this into practice with CI/CD Pipelines, or read Core Concepts for what the verdicts mean.