CI / CD - AwareXone Docs

Use AXguard as a release gate: fail the job when findings meet your severity threshold.

Code → AXguard audit → High/Critical?
                 ├── Yes → Fix → Re-scan
                 └── No  → Ship

Minimal gate

pip install -e .
axguard audit . --fail-on high --no-banner

Exit 1 when anything at or above the threshold is found
Exit 0 otherwise
--fail-on is available on scan and audit only

Example GitHub Actions job

Pattern used to dogfood AXguard itself (scan runtime packages, not fixtures):

name: axguard
on:
  pull_request:
    branches: [main]
  push:
    branches: [main]

permissions:
  contents: read

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - name: Install AXguard
        run: python -m pip install -e .
      - name: Security review
        run: |
          axguard audit . --fail-on high --no-banner

When dogfooding the AXguard repository, prefer auditing engines and cli only — fixtures/, skills/, commands/, and rules/ intentionally contain vulnerable examples.

Artifacts

Upload .findings/axguard/axguard-report.* as CI artifacts for PR review. HTML reports are read-only and approval-gated for high-risk UI actions.

GitHub App vs Actions

Path	When
Actions + `axguard audit --fail-on`	Simplest required check
GitHub App adapter	Check Runs + PR comment UX (self-hosted webhook)

See GitHub.