Repository navigation
Enable private vulnerability reporting, secret scanning, and push protection #4
Description
This project exists because a supply-chain report went unanswered. Right now there is no private channel to report a vulnerability to this fork.
Current state on this repository:
| Setting | State |
|---|---|
| Private vulnerability reporting | disabled |
| Secret scanning | disabled |
| Secret scanning push protection | disabled |
| Dependabot security updates | disabled |
The last three matter concretely because the release workflow is designed to hold an NPM_TOKEN. A publish credential in a repository with no secret scanning and no push protection is exactly the failure this project criticised upstream for.
Acceptance criteria
- Private vulnerability reporting enabled
- Secret scanning enabled
- Push protection enabled
- Dependabot security updates enabled
- Confirmed that a report submitted through the private channel reaches someone
Minutes of work, and it closes an open hypocrisy. Related: the SECURITY.md task.
Activity
feat(repo): add SECURITY.md, GOVERNANCE.md, MAINTAINERS.yaml and NOTI…
kinlane commentedon Aug 3, 2026
Done. All four enabled today.
Before:
{"dependabot_security_updates":{"status":"disabled"}, "secret_scanning":{"status":"disabled"}, "secret_scanning_push_protection":{"status":"disabled"}}After:
{"dependabot_security_updates":{"status":"enabled"}, "secret_scanning":{"status":"enabled"}, "secret_scanning_push_protection":{"status":"enabled"}}Private vulnerability reporting is on, and
SECURITY.mdin #19 now routes reporters to it as the preferred channel withinfo@apicommons.orgas the alternative.The last box is not ticked, and it should not be ticked until someone has actually sent a test report through the private advisory flow and watched it arrive. Enabling a setting and verifying a channel are different claims, and this project of all projects should not conflate them.
Two settings could not be enabled:
secret_scanning_non_provider_patternsandsecret_scanning_validity_checksboth stayeddisabledafter a successfulPATCH, so they appear to need entitlements this repository does not have. Not blocking, and noted here so the gap is on the record rather than assumed handled.kinlane commentedon Aug 27, 2026
Checked 2026-08-27. All four acceptance criteria are already satisfied on this repository.
The table in the issue body describes a state that no longer exists — all four were turned on at some point after it was filed, and nothing recorded it here.
That last box is the one still genuinely open, and it is the one the issue cares about most: "This project exists because a supply-chain report went unanswered." The channel is live; nobody has sent anything through it. One test report from an account that is not the maintainer's would close this properly. Until then the setting is enabled and the claim is untested — which is a smaller version of the same gap.
Two adjacent notes from today:
NPM_TOKENsitting in a repository without secret scanning is resolved by the settings above. The release path has a separate defect though —release.ymlwas grantingsafe.directoryto upstream's checkout path, so the release job would have failed before it could push. Fixed in fix(repo): release.yml grants safe.directory to the upstream path #74.spotlight-spechad none of these four enabled. All four are on there now, andSECURITY.mdis inspotlight-spec#36.