← All features
Threat watchEarly access
Know if a new vulnerability affects you, not just that it exists
I match the packages your code actually uses against public vulnerability advisories, including the GitHub Advisory Database, and CISA’s list of vulnerabilities known to be exploited. When one matches, I look at how your code uses the package, and open a case with the advisory as evidence.
THREAT WATCH
A critical flaw in the YAML parser you use went public an hour ago, and it’s on CISA’s list of exploited vulnerabilities.
billing-api has the affected version but only parses its own config files. The bug can’t be reached from outside.
worker-jobs parses uploaded files with it. That one is exploitable. PR #22 upgrades it, and your tests pass.
Merging now.
I’ll check the deployed version after the deploy, then close the case.
Ask it like this
“Are we affected by the new YAML parser flaw?”“Which services use lodash 4.17?”“Anything known to be exploited in our stack?”“What changed in our dependencies this week?”
How it works
01Know what you runI keep an inventory of the packages and versions in each of your repositories.
02Match against advisoriesI check them against public advisories and CISA’s known-exploited list. Anything known to be exploited is raised to at least high severity.
03Decide if it mattersA matching version isn’t always reachable. I look at how your code uses the package before I bother you.
04Fix and confirmFor the ones that matter, I prepare the upgrade or fix, and check the version that’s actually running after you deploy.
GitHub
SlackGuardrails
- Every case cites the advisory exactly as published, so you can read the source.
- If CISA’s list is unavailable, I keep working and say so.