DevOps Workflows

This page is a guide for practical scenarios you can run with magebean-cli.

Baseline-driven security means: create a baseline, then continuously diff new scans against it using a policy, and keep evidence artifacts.

When code is merged: run a scan + baseline diff and publish artifacts

GitHub Actions

Runs after changes land on main. Adapt commands to your real magebean-cli interface.

# .github/workflows/magebean-merge-scan.yml
name: magebean-merge-scan

on:
  push:
    branches: [ "main" ]

jobs:
  magebean:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Install magebean-cli
        run: |
          # download magebean.phar (or composer install)
          # chmod +x magebean.phar

      - name: Scan (produce artifacts)
        run: |
          ./magebean.phar scan             --config magebean.yml             --output-json artifacts/magebean.json             --output-html artifacts/magebean.html

      - name: Diff vs baseline (policy evaluation)
        run: |
          ./magebean.phar baseline:diff             --baseline baselines/prod.json             --current artifacts/magebean.json             --fail-on "critical,high"

      - name: Upload artifacts
        uses: actions/upload-artifact@v4
        with:
          name: magebean-main-evidence
          path: artifacts/

Every week: run a scheduled scan and keep evidence artifacts (drift monitoring)

GitHub Actions

Scheduled scan that uploads artifacts. Adjust cron and retention strategy for your needs.

# .github/workflows/magebean-weekly-scan.yml
name: magebean-weekly-scan

on:
  schedule:
    - cron: "0 9 * * 1"  # weekly Monday 09:00 UTC
  workflow_dispatch:

jobs:
  magebean:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Install magebean-cli
        run: |
          # install magebean

      - name: Scan (produce artifacts)
        run: |
          ./magebean.phar scan             --config magebean.yml             --output-json artifacts/magebean.json             --output-html artifacts/magebean.html

      - name: Diff vs baseline (optional)
        run: |
          ./magebean.phar baseline:diff             --baseline baselines/prod.json             --current artifacts/magebean.json             --fail-on "critical,high"

      - name: Upload artifacts
        uses: actions/upload-artifact@v4
        with:
          name: magebean-weekly-evidence
          path: artifacts/

When deploying: run a release gate to stop policy-breaking releases

GitHub Actions

Gate the deploy: run the scan first, stop the pipeline if policy fails.

# .github/workflows/magebean-release-gate.yml
name: magebean-release-gate

on:
  workflow_dispatch:
  push:
    tags: [ "v*" ]

jobs:
  gate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Install magebean-cli
        run: |
          # install magebean

      - name: Scan + policy gate
        run: |
          ./magebean.phar scan             --config magebean.yml             --output-json artifacts/magebean.json             --output-html artifacts/magebean.html

          ./magebean.phar baseline:diff             --baseline baselines/prod.json             --current artifacts/magebean.json             --fail-on "critical,high"

      - name: Upload artifacts (release evidence)
        uses: actions/upload-artifact@v4
        with:
          name: magebean-release-evidence
          path: artifacts/

  deploy:
    needs: gate
    runs-on: ubuntu-latest
    steps:
      - name: Deploy
        run: |
          # deploy steps here

Notes

Scope boundary

This is not penetration testing, not a compliance certification audit, and not a 24/7 SOC. The goal is to operate baseline-driven checks in DevOps to produce signal + evidence.

Remediation (fixing code/config) is handled by your maintenance/dev team or a separate remediation sprint.

Implementation note

Baseline-driven security needs explicit ownership: decide who can approve baseline changes and accepted risks. Start simple (file-based baseline + review), then migrate to a console model later if needed.