📊 Dependency Health Dashboard

Managing dependencies across a portfolio of services is one of those problems that's invisible until it isn't. A CVE drops in a commonly used library, and suddenly you need to know which of your fifteen repositories is affected, what version they're running, and how long it will take to patch each one. Without tooling, that question takes hours of manual investigation. With the right tooling, it takes seconds.

The idea is a self-hosted dashboard that integrates with GitHub or GitLab, reads the dependency manifests from each repository — package.json, Gemfile.lock, requirements.txt, go.mod — and builds a normalized view of what every service is running. It layers in vulnerability data from OSV and the GitHub Advisory Database, and license data to flag anything incompatible with your organization's policy (no GPL in commercial products, for example).

The output is a per-service health score and a cross-cutting view of which vulnerabilities affect the most services, so a security engineer can prioritize remediation by blast radius rather than severity alone. The dashboard would also track drift: when one service updates a shared library but others don't, surfacing that drift before it compounds into a compatibility problem during a future integration.

For regulated environments — which is most of my work — this kind of artifact is also evidence for compliance audits. An automatically generated, always-current software bill of materials (SBOM) satisfies an audit requirement that teams currently spend days assembling manually.