Dependency EOL and vulnerability dashboard

Context

The dashboard scans every repository in a GitHub organization each hour. It reads the dependency files for JavaScript, Python, Go and C#, compares each package with the latest release, and flags libraries that are outdated or past end of life.

Finding a problem was only half of the job. When a CVE or a runtime end of life needed fixing across many repos, people tracked it in a spreadsheet: they added rows and typed versions by hand, and a row marked complete was treated as fixed even when nobody had checked.

My role

• Main developer since April 2026, with 85 of the 97 commits on the development branch, delivered through 8 pull requests.

What I built

• Remediation campaigns: rules that match a vulnerability ID, an end-of-life runtime, a version range or an unknown version, then mark each repo affected, resolved or regressed after every scan, with a history of each change.
• Storage for campaigns on SQLite and PostgreSQL, plus spreadsheet import so existing trackers could move over.
• Microsoft Entra ID (Azure AD) sign-in in place of GitHub OAuth, user management with roles and a pending-access flow, and an editor role that can only change tracking fields.
• A campaign table built for hundreds of repos: multi-select filters, sorting, bulk edit, a per-repo maintenance-contract flag, and people and project master data with type-ahead.
• Severity badges from the CVSS score of each matched CVE, with the most severe items sorted first.

Decisions

• Let the scan decide when a repo is fixed, instead of trusting a status someone typed.
• Count a version without a patch number, such as 24 or 22.x, as unknown rather than safe, because it does not say which build is deployed.