Every dependency ecosystem the project ships is watched for known vulnerabilities
An updater (R-SEC-03) moves dependencies forward on a schedule. It never says which of today’s pinned versions is now known-bad, so without a watcher the freeze that R-SEC-01 and R-SEC-08 create is a freeze nobody is told to break.
Observable check
the package set the forge reports watching matches the project's resolved dependency set, so coverage of a manifest's direct dependencies does not read as coverage of the lockfile; where the forge cannot parse the project's lockfile, a scanner that can reads it and covers the residual; and where the forge's updater lists the ecosystem for version updates but not for security updates, which on GitHub is the case for both bun and mix, the residual is that ecosystem's whole advisory feed rather than a parsing gap, so the scanner is the only watcher the project has rather than a supplement to one. On GitHub, gh api repos/{owner}/{repo}/vulnerability-alerts answers 204 when enabled and 404 when disabled, and gh api repos/{owner}/{repo}/dependency-graph/sbom lists what is actually watched; read every control back after a write for the reason R-SEC-10 gives, and treat an absent security_and_analysis key as unknown rather than disabled. On GitLab, Dependency Scanning requires Ultimate, and a Free project reaches the same outcome through a job running an advisory-database scanner. A vulnerability the change introduces blocks its merge; the repository-wide scan reports rather than blocks, because an advisory published against a dependency with no fix is not something a contributor can resolve.
Where this comes from
- https://docs.github.com/en/code-security/reference/supply-chain-security/dependency-graph-supported-package-ecosystems
- https://docs.github.com/en/code-security/concepts/supply-chain-security/about-dependabot-alerts
- https://google.github.io/osv-scanner/supported-languages-and-lockfiles/
- https://docs.gitlab.com/user/application_security/dependency_scanning/
- https://docs.github.com/en/code-security/dependabot/ecosystems-supported-by-dependabot/supported-ecosystems-and-repositories
Last read against these sources on 2026-07-28.
Alert coverage follows dependency graph support rather than the updater's ecosystem list, which is why the rule compares what the forge reports watching against the resolved set instead of treating alerting as on or off. The GitLab source establishes the Ultimate tier; the Free-tier scanner path it leaves open is this project's own position, taken because a rule no Free project could ever satisfy would exclude most of the population the standard is written for. The version-updates-without-security-updates case in the Check comes from GitHub's own ecosystem table, read 2026-07-31, which marks both bun and mix supported for version updates and unsupported for security updates. That is a different residual from an unparsed lockfile: the forge is not missing part of the dependency set, it is watching none of it for advisories, so a scanner reading the lockfile is the project's only watcher rather than a supplement to the forge's. This repository is its own worked example on the bun half.