Shared-database vulnerability detection
One database, many writers — find the writer that doesn't sanitize.
No single service owns the database
In a microservice estate it is common for several services to read and write one shared datastore. One service carefully parameterizes its writes; another, in a different repository, builds a query from untrusted input. That unsanitized write is an injection path into rows every other service implicitly trusts — and because no single repo owns the database, no single-repo scan sees the pattern.
Unify the writers, then trace the taint
VulnGraph links every service that shares a datastore into one graph, then traces taint from any service's user-input source to a shared-database write that lacks verified sanitization. The finding names the originating service, the path, and the shared table — the exact cross-service SQL injection (CWE-89) a per-service scanner cannot assemble.
Beyond injection: poisoned trust
A shared database is also a trust boundary. Data written by one service is read and acted on by others, so an unsanitized write is not only an injection risk but a data-integrity one — poisoned rows propagate to every consumer. VulnGraph reasons about both, because it sees the writers and the readers on the same graph.
Key capabilities
- ✓Shared-datastore linking across services and repos
- ✓Cross-service database-write taint analysis
- ✓Sanitizer-aware SQL injection (CWE-89) path evidence
- ✓Data-integrity / poisoned-trust reasoning