No composer.lock: dependencies have never been CVE-audited, and `composer audit` exits 0 saying so

[rubenvdlinde]

hrmq ships composer.json but no composer.lock, so its dependencies have never been CVE-audited

Found while enabling the Hydra gates here (#72). gate-4 composer-audit reports:

[gate-4] composer-audit: FAIL — audited NOTHING (composer found no packages)
                                — this is not a clean audit

That wording matters: gate-4 was fixed in .github#135 precisely so that "could not audit" stops being reported as "no CVEs". This is the gate working.

Ran the measurement by hand rather than taking the gate's word for it:

$ composer audit --locked --no-interaction
In AuditCommand.php line 78:
  Valid composer.json and composer.lock files are required to run this command with --locked

$ composer audit --no-interaction
No packages - skipping audit.

$ ls composer.lock
ls: cannot access 'composer.lock': No such file or directory

So there is no lockfile in the repository. Consequences:

1. No dependency is CVE-audited, here or in CI. composer audit has nothing to read, and it exits successfully saying "skipping audit" — an absence that looks exactly like a clean result to anything grepping for a non-zero exit.
2. Builds are not reproducible. Every composer install resolves afresh against the constraints in composer.json.
3. roave/security-advisories cannot do its job. It is a dev-latest constraint whose protection comes from the resolved commit recorded in the lockfile; with no lockfile there is nothing pinned and nothing to go stale — or to protect.

Suggested fix

Commit a composer.lock:

composer update --no-interaction
git add composer.lock

Then composer audit --locked becomes meaningful and gate-4 starts producing a real verdict instead of a refusal.

Note on gate-4's scoping

gate-4 is diff-scoped to composer files per ADR-020, so it correctly reports NOT APPLICABLE on PRs that do not touch them — including #72. It is not currently blocking anything. That is the right behaviour and also why this gap could sit unnoticed: the gate only speaks up on the PR that changes a dependency, and this repo has not had one since the gates were switched on.