Skip to main content
Version: v1

Security

Security problems rarely announce themselves: an API token lands in a commit, a dependency picks up a published vulnerability, a development site sits open on a public URL. This overview is for developers and leads on a project built from Vortex: it shows which check or setting covers each of those risks, and where it runs.

Vortex covers those 3 concerns with the following tools:

  • Secret scanning for committed secrets
  • The dependency audit for vulnerable dependencies
  • Shield for access to non-production environments, described in the following section

The Security Kit module, which adds security-hardening HTTP headers, also ships with the project, but provisioning doesn't install it. Enable it when the project needs it.

Environment access​

Shield puts an HTTP authentication prompt in front of your site. Vortex forces it on in the dev and stage hosted environments, so work in progress never sits on a public URL. It keeps Shield off locally and in CI, where a prompt would only get in the way, 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. Hosted non-production environments run as dev or stage, so set both in each of them: Shield stays on there even when they're missing, and then nobody can get past the prompt.

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

Continuous integration​

Secret scanning and the dependency audit run in the security audit workflow, separate from the build pipeline. A failing audit then never looks like a failing linter, and you can re-run it on its own. The flip side is that the deploy job doesn't depend on the audit, so a failing audit doesn't stop a deployment by itself. To block merges on it, add its check to the repository's branch protection rules as a required status check.

In GitHub Actions, both also upload their findings to the repository's Security → Code scanning tab, which keeps an inventory of the open findings. The workflow attaches every report to the run as the security-findings artifact too. CircleCI has no code scanning destination, so its findings stay in the job log.

➡️ See Code scanning.