ci: audit the declared peer ranges against the advisory database - #58
Merged
Conversation
There was a problem hiding this comment.
Pull request overview
Adds a scheduled GitHub Actions workflow that calls the org-wide reusable peer-advisory-drift check to detect when this package’s declared peerDependencies ranges begin admitting versions with newly published security advisories, and to track findings via an auto-managed issue.
Changes:
- Introduces
.github/workflows/peer-advisory-drift.ymlwith a weekly cron + manual dispatch trigger. - Grants
issues: writeandcontents: readso the reusable workflow can manage its tracking issue and read repo metadata. - Delegates execution to
bymaxone/.github/.github/workflows/peer-advisory-drift.yml@v1.
Member
Author
{
"pr": 58,
"localGate": "pnpm typecheck && pnpm lint",
"consecutiveFailures": {},
"flakyReruns": {},
"processedCommentIds": [],
"ci": "14 pass / 0 fail / 0 pending — includes 'Consumer app typecheck: pass'",
"botFindings": "none — Copilot reviewed a64c1d9 and generated no comments",
"lastRebase": "2026-08-01T13:02Z onto origin/main (35811b9) after PR #57 merged at 13:00:07Z",
"resolvedBlocker": "the required check 'Consumer app typecheck' did not exist on this branch until #57 landed the renamed CI job on main; the rebase picked it up",
"paused": false,
"terminated": "2026-08-01T13:04Z — green, mergeable, no open findings; babysit-pr does not merge"
} |
Dependabot audits what is installed here and stays quiet while the declared peerDependencies floors admit a version with a published advisory. Nothing was watching that, and the range does not have to change to become wrong -- the advisory database moves on its own. Weekly call into the shared reusable check, which files a tracking issue and closes it once every range is clear.
Two runs would race over one tracking issue per repository, so the group is deliberately not keyed by github.ref -- that would put a dispatch and a scheduled run in separate groups and leave the race intact. Queue rather than cancel: interrupting a run midway through rewriting that issue is worse than waiting. workflow_dispatch can fire from any branch; auditing an unmerged manifest and writing it to the repository-wide issue would report findings that do not describe what this package declares. Name follows the Title Case every other workflow here uses.
msalvatti
force-pushed
the
ci/peer-advisory-drift
branch
from
August 1, 2026 13:02
a924449 to
a64c1d9
Compare
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds a weekly call into the new shared
peer-advisory-driftcheck (bymaxone/.github#17).What it watches
Dependabot audits what is installed here — the lockfile, our own devDependencies — and stays quiet as long as that is current. It never looks at what consumers are told they can install. A
peerDependenciesfloor below a published advisory says a vulnerable install is supported, and the consumer resolving that range is free to pick the low end.The part that makes this a scheduled job rather than a release-checklist item: the declared range never changes and becomes wrong anyway. The advisory database is what moves. A range that was clean when written starts admitting a vulnerable version the day a new advisory is published — no commit, no PR, nothing to notice.
That is not a hypothetical. It is exactly how this portfolio ended up shipping peer floors below two published NestJS advisories.
What it does
Runs Mondays, files a tracking issue listing each declared range that admits a vulnerable version and the floor to raise it to, rewrites that issue as findings change, and closes it automatically once every range is clear.
No effect on pull requests — it is
schedule+workflow_dispatchonly, so it adds no gate and no PR latency.Order of merge
The reusable workflow has to exist first. This calls
bymaxone/.github/...@v1, so it stays inert until bymaxone/.github#17 is merged and thev1tag is moved to include it. Nothing breaks in the meantime — a scheduled run is the only thing that would resolve the reference.Ready for your review — not merging it.