Skip to main content
Version: v1

Security

This overview is for developers and leads on a project built from Vortex. It shows which check or setting covers each of 3 common risks, and where it runs:

  • Secret scanning catches an API token committed to Git.
  • The dependency audit reports a dependency with a published vulnerability.
  • Shield puts a password prompt in front of a development site on a public URL. The following section describes it.

The Security Kit module, which adds security-hardening HTTP headers, ships with the project, but provisioning doesn't install it, so 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 stays behind the prompt. It forces Shield off locally and in CI, where a prompt would block tests. In production, Shield stays on or off as set on its settings page in the UI.

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 variables in every one of those environments. Without them, Shield stays on and the prompt locks everyone out.

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

PHP settings​

The php container turns off PHP's session upload progress tracking with session.upload_progress.enabled = Off in .docker/config/php/custom.ini. The tracking writes upload request data into PHP's own session storage before Drupal starts, and Drupal never reads that data. File uploads work with the setting off, anonymous uploads included. Drupal's optional upload progress bar requires the PECL uploadprogress extension.

The setting applies wherever the Vortex images run: locally, in CI and on Lagoon. On Acquia, the platform's own PHP settings apply.

Continuous integration​

Secret scanning and the dependency audit run in the security audit workflow, separate from the build pipeline. A failing audit therefore shows up separately from a failing linter, and you can re-run the audit on its own.

The deploy job doesn't depend on the audit, so a failing audit doesn't stop a deployment. To block merges on the audit, add its check to the repository's branch protection rules as a required status check.

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

➡️ See Code scanning.