GitHub

Before you start

You need admin on the repository to change branch protection, and owner on the organization to install an app across all repositories. Everything up to step 4 works with write access alone.

1. Install the GitHub App

   Install the Phylax GitHub App to enable verification and policy enforcement on your repositories and pull requests.

   Install Phylax for GitHub

   Authorizes Phylax to read your repositories and post checks on pull requests.

2. Choose repositories

   Choose the repositories Phylax can access.

   • All repositories. Phylax is installed across your entire organization, including repositories created later.
   • Selected repositories. Choose specific repositories to enable. You can widen this later without reinstalling.

3. Configure pull request checks

   Add a phylax.yml file to the root of your repository to define verification policy.

   phylax.yml

   version: 1
   project: service-api
   policy:
     require_verified_artifacts: true
     min_trust_score: 70
     block_on_critical: true

   Without this file Phylax still reports a verdict, it just never blocks. That is the recommended way to start: land the app, watch the checks for a week, then turn on enforcement once you know what your baseline looks like.

4. Branch protection

   Require Phylax checks before merging to protected branches.

   • Require status checks to pass: Phylax / Verification
   • Require branches to be up to date before merging

   The check must run once before you can require it

   GitHub only lists a status check in the branch protection settings after it has reported on that repository at least once. Open a throwaway pull request first, let Phylax post its check, then add it as a required check.

   Requiring branches to be up to date is stricter than it sounds: every merge to the base branch forces the pull request to re-run its checks. On a busy repository that is a lot of re-verification, so enable it only where you genuinely need the base to be current.

5. First verification

   Verify your repository on demand from the Phylax CLI.

   phylax repo verify github.com/acme/service-api

6. What happens on a pull request

   1. Scan

   Phylax scans code, dependencies and build artifacts in the PR.

   2. Evaluate

   Artifacts are verified and scored against your policy.

   3. Comment / Check

   Phylax posts a check result and comment with trust signals.

How verdicts map to checks

Phylax reports through the GitHub Checks API, so its three verdicts land on three different check conclusions. This is what decides whether a pull request can merge.

Phylax verdict	Check conclusion	Blocks merge
ALLOW	success	No
WARN	neutral	No. GitHub treats neutral the same as success.
BLOCK	failure	Yes, once the check is required

WARN is deliberately non-blocking. It puts the finding in front of a reviewer without stopping the merge, which is what keeps the check from being switched off the first week it fires on something noisy. If you want warnings to block, set min_trust_score high enough that they come back as BLOCK instead.

Keeping the check quiet

One check that summarises everything is easier to require, and easier to read, than one check per artifact. Phylax posts a single Phylax / Verification check run per commit and puts the per-artifact detail in its body, so branch protection stays a single checkbox no matter how many dependencies a pull request touches.

Next steps

Gate the build as well as the pull request with CI/CD Pipelines, read what the scan actually looks at in Source Repositories, or see Core Concepts for how a trust score is derived.

The Action is open source at praxi-labs/phylax-action.