[#2125] Added support for Composer 2.9.0 automated security audit.

Author: AlexSkrypnyk

.circleci/config.yml

@@ -280,6 +280,10 @@ jobs:
               COMPOSER_MEMORY_LIMIT=-1 composer --ansi install --prefer-dist"
             docker compose exec $(env | cut -f1 -d= | sed 's/^/-e /') -T cli bash -c "yarn install --frozen-lockfile"
 
+      - run:
+          name: Audit Composer packages
+          command: docker compose exec -T cli composer audit || [ "${VORTEX_CI_COMPOSER_AUDIT_IGNORE_FAILURE:-0}" -eq 1 ]
+
       - run:
           name: Validate Composer configuration is normalized
           command: |

.github/workflows/build-test-deploy.yml

@@ -274,6 +274,10 @@ jobs:
             COMPOSER_MEMORY_LIMIT=-1 composer --ansi install --prefer-dist"
           docker compose exec $(env | cut -f1 -d= | sed 's/^/-e /') -T cli bash -c "yarn install --frozen-lockfile"
 
+      - name: Audit Composer packages
+        run: docker compose exec -T cli composer audit
+        continue-on-error: ${{ vars.VORTEX_CI_COMPOSER_AUDIT_IGNORE_FAILURE == '1' }}
+
       - name: Validate Composer configuration is normalized
         if: ${{ matrix.instance == 0 || strategy.job-total == 1 }}
         run: docker compose exec -T cli composer normalize --dry-run

.vortex/docs/.utils/variables/extra/ci.variables.sh

@@ -30,6 +30,9 @@ VORTEX_CI_COMPOSER_VALIDATE_IGNORE_FAILURE=0
 # Ignore `composer normalize` failures.
 VORTEX_CI_COMPOSER_NORMALIZE_IGNORE_FAILURE=0
 
+# Ignore `composer audit` failures.
+VORTEX_CI_COMPOSER_AUDIT_IGNORE_FAILURE=0
+
 # Ignore PHPCS failures.
 VORTEX_CI_PHPCS_IGNORE_FAILURE=0
 

.vortex/docs/content/drupal/composer.mdx

@@ -226,6 +226,23 @@ specifies key configurations for Composer's behavior in the project.
   This setting specifies which Composer plugins are allowed to run. It's a
   security measure to prevent the execution of untrusted code from third-party
   plugins. Each plugin needs to be explicitly allowed to ensure it can execute.
+- [`audit`](https://getcomposer.org/doc/06-config.md#audit): Introduced in
+  Composer 2.9.0, this setting controls automatic security auditing of
+  dependencies during `composer install` and `composer update`. **Vortex**
+  enforces security best practices with the following configuration:
+  - `block-insecure` (default: `true`): Blocks installation of packages with
+    known security vulnerabilities unless explicitly ignored. This ensures
+    security issues are addressed before deployment.
+  - `abandoned` (default: `report`): Shows warnings for abandoned packages
+    without failing the build. Allows visibility into package maintenance status
+    while not blocking installations.
+  - `ignore` (default: `{}`): Empty object ready for adding assessed and
+    documented vulnerability exceptions. Use this to explicitly allow specific
+    CVE/GHSA advisories that have been reviewed and accepted.
+  - See
+    [Composer Security Auditing](../workflows/development#composer-security-auditing)
+    for comprehensive guidance on configuration options, ignoring specific
+    advisories, running audits, and best practices.
 - [`discard-changes`](https://getcomposer.org/doc/06-config.md#discard-changes):
   When set to `true`, any local changes made to the dependencies (packages under
   version control like Git) are discarded without prompting when you run

.vortex/docs/content/workflows/development.mdx

@@ -80,7 +80,7 @@ file to `.data/db.sql` and run `ahoy import-db`.
 
 See [Drupal > Provision](../drupal/provision) for more details.
 
-## Environment Variable Updates
+## Environment variable updates
 
 To update environment variables in your local development environment:
 
@@ -305,6 +305,118 @@ Composer Patches v2.x automatically generates a `patches.lock.json` file that co
     composer update --lock
     ```
 
+### Composer security auditing
+
+Composer 2.9.0 introduced automatic security auditing that checks your dependencies for known security vulnerabilities and abandoned packages. This feature helps you maintain a secure codebase by alerting you to potential issues during package installation and updates.
+
+#### Configuration Options
+
+Configure audit behavior in your `composer.json` under the `config` section:
+
+```json
+{
+    "config": {
+        "audit": {
+            "abandoned": "report",
+            "block-insecure": true,
+            "ignore": {
+                "CVE-2024-1234": "The affected component is not in use in our application.",
+                "GHSA-xxxx-yyyy-zzzz": "Mitigated by additional security measures."
+            }
+        }
+    }
+}
+```
+
+**Available Options:**
+
+- **`block-insecure`**: Controls whether packages with security vulnerabilities block installation
+  - `true` (**Vortex** default): Blocks installation/update of vulnerable packages unless ignored
+  - `false`: Shows warnings but allows installation to proceed
+- **`abandoned`**: Controls how abandoned packages are handled
+  - `report` (**Vortex** default): Shows abandoned packages as warnings but doesn't fail
+  - `fail`: Audit command fails with non-zero exit code
+  - `ignore`: Skips abandoned packages in audit reports
+- **`ignore`**: Ignores specific security advisories by CVE or GHSA identifier (empty by default)
+
+#### When to Use `block-insecure: false`
+
+**Vortex** sets `block-insecure` to `true` by default to enforce security best practices. However, you may want to set it to `false` when:
+
+- You need flexibility to evaluate vulnerabilities on your timeline
+- No secure version is immediately available
+- The vulnerability doesn't affect your specific use case
+- You're in active development and need uninterrupted workflow
+
+Keep it `true` (Vortex default) when:
+
+- Working on production sites with strict security requirements
+- Your deployment process can handle blocked installations
+- You want to enforce immediate action on security vulnerabilities
+- Your team has resources to quickly address security issues
+
+:::warning Vortex Security-First Philosophy
+
+**Vortex** adopts a security-first approach by setting `block-insecure: true` as the default. This prioritizes safety in automated deployments by preventing vulnerable packages from being installed without explicit review.
+
+If you need to override this setting for backwards compatibility, you can modify the `audit.block-insecure` configuration in your project's `composer.json` file. However, we strongly recommend addressing vulnerabilities by updating packages or using the `ignore` configuration for assessed exceptions, rather than routinely disabling security blocking.
+
+This approach ensures security issues are explicitly acknowledged and reviewed before being accepted into your codebase.
+
+:::
+
+#### Ignoring Specific Advisories
+
+When you've assessed a vulnerability and determined it doesn't affect your project, you can ignore it:
+
+```json
+{
+    "config": {
+        "audit": {
+            "ignore": {
+                "CVE-2024-1234": "Component is not used in our implementation.",
+                "GHSA-xxxx-yyyy-zzzz": "Patched via custom security fix."
+            }
+        }
+    }
+}
+```
+
+:::tip Document Your Decisions
+
+Always include reasons when ignoring advisories into your Git commit messages. This helps your team understand why a vulnerability was deemed acceptable and makes it easier to review these decisions in the future.
+
+:::
+
+#### Running Audit Command
+
+Check your dependencies for security issues manually:
+
+```bash
+# Audit all installed packages
+composer audit
+
+# Audit only production dependencies (exclude dev)
+composer audit --no-dev
+
+# Audit packages from lock file (faster)
+composer audit --locked
+
+# Control abandoned package behavior
+composer audit --abandoned=ignore  # Skip abandoned packages
+composer audit --abandoned=report  # Show but don't fail
+```
+
+##### CI/CD Integration
+
+**Vortex** automatically runs `composer audit` as part of the CI/CD pipeline to
+check for security vulnerabilities during builds.
+
+By default, audit failures will cause the CI build to fail. You can control this
+behavior using a repository variable `VORTEX_CI_COMPOSER_AUDIT_IGNORE_FAILURE`
+set to `1`. When this variable is set to `1`, the audit step will run but won't
+fail the build if vulnerabilities are found.
+
 ## Resetting the codebase
 
 To reset the local environment, use the `ahoy reset` command. This command will

.vortex/docs/content/workflows/releasing.mdx

@@ -47,6 +47,7 @@ Code goes "up" (from lower to higher environments) while database goes "down" (f
 This means that the production database is the primary source of truth - it's what code is applied to. When performing a release, you are applying a new version of code to a database within a specific environment.
 
 To ensure that code changes work correctly with real data structures, the following process is followed in lower environments:
+
 1. Database is copied from a higher environment to a lower one (e.g., production → stage → development)
 2. Code is deployed to that environment to be tested against the copied database
 3. Testing is performed to ensure everything works correctly
@@ -136,9 +137,11 @@ gitGraph
 Below are the typical steps to perform a release using git-flow. See [cheat sheet](https://danielkummer.github.io/git-flow-cheatsheet/) for a quick reference on git-flow commands.
 
 1. **Start Release**
+
    ```bash
    git flow release start X.Y.Z
    ```
+
    Creates a `release/X.Y.Z` branch from `develop`. It is recommended to push
    the branch to remote.
 
@@ -148,9 +151,11 @@ Below are the typical steps to perform a release using git-flow. See [cheat shee
    - Release notes preparation
 
 3. **Finish Release**
+
    ```bash
    git flow release finish X.Y.Z
    ```
+
    - Merges release branch to `main`
    - Tags the release
    - Merges back to `develop`
@@ -159,6 +164,7 @@ Below are the typical steps to perform a release using git-flow. See [cheat shee
 4. **Deploy to Production**
    - **Tag-based hosting:** Deploy the tag directly
    - **Branch-based hosting (e.g., Lagoon):** Manually sync to `production` branch
+
      ```bash
      git push origin main:production
      ```
@@ -190,12 +196,14 @@ During installation, you can choose between Calendar Versioning (CalVer), Semant
 - `Z` = Hotfix/patch version (no leading zeroes)
 
 #### Why CalVer
+
 - **Release frequency transparency**: When you have multiple releases per month, dates make it easy to identify when a release happened
 - **Intuitive tracking**: Stakeholders can immediately understand "this is from January 2025" vs memorizing version numbers
 - **Natural progression**: No ambiguity about major vs minor changes - just the chronological order
 - **Marketing alignment**: Easier to communicate to non-technical audiences ("our Q1 2025 release")
 
-#### Examples:
+#### Examples
+
 - ✅ Correct: `25.1.0`, `25.11.1`, `25.1.10`, `25.10.1`, `9.12.0`
 - ❌ Incorrect: `25.0.0` (no month 0), `2025.1.1` (full year), `25.01.0` (leading zero), `01.1.0` (leading zero in year)
 
@@ -210,12 +218,14 @@ Learn more: [CalVer.org](https://calver.org/)
 - `Z` = Hotfix/patch version (no leading zeroes)
 
 #### Why SemVer
+
 - **Breaking change communication**: Major version bump signals incompatible API changes
 - **Dependency management**: Package managers can enforce compatible version ranges
 - **Developer expectations**: Well-understood convention in the development community
 - **Predictable upgrades**: Minor versions add functionality, patches fix bugs
 
-#### Examples:
+#### Examples
+
 - ✅ Correct: `0.1.0`, `1.0.0`, `1.0.1`, `1.0.10`
 - ❌ Incorrect: `0.1` (missing patch), `1` (missing minor and patch), `1.0.01` (leading zero)
 
@@ -263,6 +273,7 @@ Your project includes a `docs/releasing.md` file that serves as the canonical re
 - **Release procedures** - Custom workflows specific to your project
 
 You can extend this file with:
+
 - **Detailed release procedures** - A comprehensive outline of _what_ actions to take during releases:
   - Steps to create and finish releases
   - Steps to deploy to production
@@ -279,6 +290,7 @@ You can extend this file with:
 **Deployment Markers**: When configured, **Vortex** automatically creates deployment markers in New Relic when releases are deployed to your environments. These markers help correlate performance changes, errors, and other metrics with specific releases.
 
 **Benefits**:
+
 - Visualize before/after release performance
 - Correlate errors with specific deployments
 - Track deployment frequency

.vortex/docs/content/workflows/variables.mdx

@@ -446,6 +446,14 @@ Default value: `UNDEFINED`
 
 Defined or used in: `CI config`
 
+### `VORTEX_CI_COMPOSER_AUDIT_IGNORE_FAILURE`
+
+Ignore `composer audit` failures.
+
+Default value: `UNDEFINED`
+
+Defined or used in: `CI config`
+
 ### `VORTEX_CI_COMPOSER_NORMALIZE_IGNORE_FAILURE`
 
 Ignore `composer normalize` failures.

.vortex/docs/cspell.json

@@ -9,6 +9,7 @@
     "words": [
         "Asciinema",
         "Diffy",
+        "GHSA",
         "NRAK",
         "REDIS",
         "Runsheet",

.vortex/installer/tests/Fixtures/install/_baseline/.github/workflows/build-test-deploy.yml

@@ -256,6 +256,10 @@ jobs:
             COMPOSER_MEMORY_LIMIT=-1 composer --ansi install --prefer-dist"
           docker compose exec $(env | cut -f1 -d= | sed 's/^/-e /') -T cli bash -c "yarn install --frozen-lockfile"
 
+      - name: Audit Composer packages
+        run: docker compose exec -T cli composer audit
+        continue-on-error: ${{ vars.VORTEX_CI_COMPOSER_AUDIT_IGNORE_FAILURE == '1' }}
+
       - name: Validate Composer configuration is normalized
         if: ${{ matrix.instance == 0 || strategy.job-total == 1 }}
         run: docker compose exec -T cli composer normalize --dry-run

.vortex/installer/tests/Fixtures/install/_baseline/composer.json

@@ -84,6 +84,10 @@
             "pyrech/composer-changelogs": true,
             "tbachert/spi": true
         },
+        "audit": {
+            "abandoned": "report",
+            "block-insecure": true
+        },
         "discard-changes": true,
         "platform": {
             "php": "__VERSION__"