Security

Vortex covers 3 security concerns: secrets committed to the codebase (Secret scanning), vulnerable dependencies (Dependency audit), and access to non-production environments (Shield).

Environment access

Shield restricts access to your site by requiring HTTP authentication credentials. Vortex forces Shield on in the dev and stage hosted environments, keeps local development and CI accessible without authentication, and leaves production alone so Shield stays under UI control there. The credentials come from the DRUPAL_SHIELD_USER and DRUPAL_SHIELD_PASS environment variables.

➡️ See Modules > Shield for the full entry, including the overrides that disable Shield for one environment or open the Let's Encrypt challenge path.

Continuous integration

Both scans run in the security audit workflow, which is separate from the build pipeline. That way, a failing audit is never confused with a failing linter and can be re-run on its own. Because it's a separate workflow, it isn't a dependency of the deploy job - a failing audit doesn't by itself stop a deployment. To block merges and deployments on it, add its check to the repository's branch protection rules as a required status check.

In GitHub Actions, both scans also upload their findings to the repository's Security → Code scanning tab. That gives a project an inventory of what's currently open rather than only a sequence of passing and failing builds.

➡️ See Code scanning.