Applications inherit risk from every third-party package they install. For Drupal, much of that software is managed by Composer, so dependency security should be checked automatically rather than relying on someone to remember a command before release.

What the workflow checks

composer audit --locked --no-interaction compares the exact packages in composer.lock with published security advisories. Using --locked matters: it checks what the build will actually install, not merely the version ranges permitted by composer.json.

composer-audit:
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v7
    - uses: shivammathur/setup-php@v2
      with:
        php-version: "8.3"
        tools: composer:v2
        coverage: none
    - name: Audit Composer dependencies
      env:
        COMPOSER_AUDIT_ABANDONED: report
      run: composer audit --locked --no-interaction

COMPOSER_AUDIT_ABANDONED=report reports abandoned packages without confusing abandonment with a vulnerability. Because the audit command is not marked continue-on-error, a security advisory fails this job.

Responding to a failure

1. Read the advisory and affected-version range.
2. Run composer why package/name to identify the direct dependency.
3. Review safe upgrades with composer outdated.
4. Update the smallest practical dependency set and run tests.
5. If no fix exists, document the exposure and compensating controls.

The weekly schedule is important: a previously safe locked version can receive a new advisory even when the repository has not changed.