[#2885] Split Gitleaks and composer audit into a standalone 'Security audit' workflow.

[AlexSkrypnyk]

Closes #2885

Summary

The lint job in both CI providers also ran the Gitleaks secret scan and composer audit, so a red lint check never said whether the codebase had a style problem or a disclosed vulnerability, and both security checks paid for the full Docker application stack that the other linters need. Both checks now live in a standalone workflow named Security audit - a new .github/workflows/audit.yml in GitHub Actions and a new audit entry under workflows: in CircleCI - each running a single audit job. It triggers on the same pushes, pull requests and tags as the main pipeline, and can also be started by hand via workflow_dispatch.

The new workflow needs no application containers and no installed dependencies: Gitleaks runs straight from its ghcr.io image, and composer audit --locked audits the packages pinned in composer.lock on the bare runner, replacing the in-container composer audit that previously required a built stack. Vortex's own repository does not track composer.lock, so a VORTEX_DEV-fenced step resolves dependencies first; that step is stripped from every consumer site, which commits its lock file.

Being a separate workflow means deploy can no longer declare a dependency on it - GitHub Actions has no cross-workflow needs, and CircleCI has no cross-workflow requires - so deploy/deploy-tags are back to requiring build and lint, and the documentation now points at branch protection required status checks as the way to make the audit block merges and deployments.

Changes

GitHub Actions

• Added .github/workflows/audit.yml (name: Security audit, job audit) carrying the Gitleaks scan under the existing CI_GITLEAKS fence and composer audit --locked, with the VORTEX_CI_GITLEAKS_IGNORE_FAILURE and VORTEX_CI_COMPOSER_AUDIT_IGNORE_FAILURE overrides preserved.
• Mirrored the trigger block of build-test-deploy.yml - same push branches and tags, same pull request branches - and added workflow_dispatch so the audit can be run on demand.
• Removed the Gitleaks and Audit Composer packages steps from the lint job in build-test-deploy.yml; that file is otherwise unchanged.

CircleCI

• Added an audit job and gave it its own audit workflow beside commit, so it runs independently and can be re-run on its own. setup_remote_docker sits inside the CI_GITLEAKS fence, so a project with Gitleaks disabled starts no Docker engine at all.
• Removed the same two steps from the lint job. The commit workflow's job list is untouched, which matters because tests/phpunit/CircleCiConfigTest.php addresses workflows.commit.jobs[3] and [4] positionally.

Installer

• CiProvider::process() now also removes .github/workflows/audit.yml when GitHub Actions is not the selected provider, so CircleCI-only and CI-less projects do not receive an orphan workflow.

Documentation

• Added a Security audit section to the CI overview covering both providers, what the workflow runs, how to start it manually, and a note that it does not gate deploy and should be enforced through branch protection.
• Added a Security audit workflow section to the GitHub Actions page, and listed the audit workflow on the CircleCI page.
• Repointed the Gitleaks, Composer and FAQ pages from the lint job to the security audit workflow, and corrected the claim that a failing audit gates the build.
• Redrew the ASCII lifecycle diagram: Composer audit is gone from the Lint box and the audit appears as its own band below the pipeline, since it is no longer part of it.

Fixtures

• Regenerated installer snapshots. Every CircleCI scenario now carries a -audit.yml removal marker, which is what proves the installer strips the workflow for non-GitHub-Actions projects.

Before / After

BEFORE
──────
┌─ Database, Build, Test and Deploy ──────────────────────┐
│                                                         │
│  lint  (builds the Docker stack, installs dependencies) │
│  ├── code linters (PHPCS, PHPStan, Rector, ESLint…)     │
│  ├── Gitleaks secret scan          ◄── security         │
│  ├── composer audit                ◄── security         │
│  └── composer normalize --dry-run                       │
│                                                         │
│  database ──► build ──► deploy (needs: build, lint)     │
│                                                         │
└─────────────────────────────────────────────────────────┘

AFTER
─────
┌─ Database, Build, Test and Deploy ──────────────────────┐
│                                                         │
│  lint  (builds the Docker stack, installs dependencies) │
│  ├── code linters (PHPCS, PHPStan, Rector, ESLint…)     │
│  └── composer normalize --dry-run                       │
│                                                         │
│  database ──► build ──► deploy (needs: build, lint)     │
│                                                         │
└─────────────────────────────────────────────────────────┘

┌─ Security audit ────────────────────────────────────────┐
│  push · pull_request · tags · manual run                │
│                                                         │
│  audit  (no containers, no installed dependencies)      │
│  ├── Gitleaks secret scan                               │
│  └── composer audit --locked                            │
│                                                         │
└─────────────────────────────────────────────────────────┘

Summary by CodeRabbit

• New Features

  • Added a dedicated security check to CI workflows for secret scanning and Composer dependency audits.
  • Deployments now require successful security checks alongside build and lint checks.

• Documentation

  • Updated CI, Composer, Gitleaks, lifecycle, and FAQ documentation to reflect the separate security workflow.
  • Clarified that linting validates normalized Composer configuration.

[coderabbitai]

Walkthrough

CI security checks moved from lint jobs into dedicated security jobs. The jobs run Gitleaks and locked Composer audits. Deployment workflows now require successful security checks. CI documentation reflects the new job structure.

Changes

CI security workflow

Layer / File(s)	Summary
Dedicated security jobs .circleci/config.yml, .github/workflows/build-test-deploy.yml	Both CI systems add security jobs for Gitleaks scanning and composer audit --locked. Lint jobs no longer run these checks.
Workflow dependency updates .circleci/config.yml, .github/workflows/build-test-deploy.yml	Commit, deployment, and tag-deployment workflows include the security job. Deployments require successful build, lint, and security jobs.
CI documentation alignment .vortex/docs/content/...	Documentation updates describe the dedicated security job, revised job numbering, parallelism, Composer audits, and Gitleaks execution.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Sequence Diagram(s)

sequenceDiagram
  participant CI as CI security job
  participant Gitleaks
  participant Composer
  participant Deployment
  CI->>Gitleaks: Scan repository secrets
  CI->>Composer: Create Composer lock data
  CI->>Composer: Run composer audit --locked
  CI->>Deployment: Report security job status
  Deployment->>Deployment: Require build, lint, and security success

Loading

Suggested labels: Needs review

Poem

A rabbit checks the pipeline bright,
Gitleaks hops through secrets at night.
Composer locks the packages tight,
Deploy waits for checks done right.
CI now guards the garden gate.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	The workflows implement the linked issue by separating Gitleaks and Composer auditing into dedicated security jobs with deployment dependencies updated.
Out of Scope Changes check	✅ Passed	The workflow, documentation, and diagram changes directly support the dedicated security job objective and contain no unrelated changes.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly describes the main change: moving Gitleaks and Composer auditing into a dedicated security workflow.

✨ Finishing Touches 💡 1

🛠️ Fix failing CI checks 💡

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feature/2885-split-security-wf

---

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

📖 Documentation preview for this pull request has been deployed to Netlify:

https://6a726438df44e353b08d52fc--vortex-docs.netlify.app

This preview is rebuilt on every commit and is not the production documentation site.

[github-actions]

Code coverage (threshold: 90%)

  Classes: 100.00% (1/1)
  Methods: 100.00% (2/2)
  Lines:   98.55% (204/207)

Per-class coverage

Drupal\ys_demo\Plugin\Block\CounterBlock
  Methods: 100.00% ( 2/ 2)   Lines: 100.00% ( 10/ 10)

[AlexSkrypnyk]

Code coverage (threshold: 90%)

  Classes: 100.00% (1/1)
  Methods: 100.00% (2/2)
  Lines:   98.55% (204/207)

Per-class coverage

Drupal\ys_demo\Plugin\Block\CounterBlock
  Methods: 100.00% ( 2/ 2)   Lines: 100.00% ( 10/ 10)

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 86.39%. Comparing base (ad15190) to head (71ad2bc).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2886      +/-   ##
==========================================
- Coverage   86.81%   86.39%   -0.43%     
==========================================
  Files         100       93       -7     
  Lines        4846     4688     -158     
  Branches       47        3      -44     
==========================================
- Hits         4207     4050     -157     
+ Misses        639      638       -1     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.