The Vulnerability Scanning Gaps Most RAG Stacks Have

These libraries pull in their own dependency trees, often numerical and ML-adjacent packages that a scanning tool tuned for typical web framework dependencies handles less thoroughly than it handles more common ones. Confirm explicitly that your scanning tool's coverage extends into this part of the dependency graph, rather than assuming it does because it scans everything in your lockfile. Some scanners have genuinely thinner vulnerability databases for less common package ecosystems, and that gap is invisible until you check it directly.

Whatever parses uploaded PDFs, DOCX files, or scraped HTML during ingestion has its own history of parser-level vulnerabilities, since a malformed or maliciously crafted file is a classic way to exploit a parsing library. These libraries deserve the same scanning and patching urgency as your public-facing web server, not the more relaxed treatment an internal batch-processing tool sometimes gets. If your ingestion path accepts files from outside your organization, this deserves particular attention.

A managed vector database shifts responsibility for patching the underlying engine to the vendor. If you're self-hosting instead, that engine is a service you operate and are responsible for scanning and patching, the same as any other database server in your infrastructure. It's easy for a self-hosted vector database to fall outside the scope of a vulnerability management program that was built around a company's more familiar, established services and never explicitly extended to cover it.

Traditional vulnerability scanning looks for known CVEs in software components. It has nothing to say about a retrieval pipeline's exposure to prompt injection through indexed content, since that's an architectural and content-handling risk, not a patchable software defect. This needs a separate, deliberate review of how retrieved content flows into a prompt and whether it's treated as untrusted input, a distinct exercise from running a scanner and reading its report.

Scanning regularly without a committed remediation timeline produces a report nobody acts on with urgency. Federal binding operational directives set concrete remediation windows for known vulnerabilities¹, and adopting a similarly explicit SLA, even an internally set one, gives your team a concrete target instead of an open-ended backlog that critical findings can quietly sit in indefinitely.

A vulnerability marked as an accepted risk for a legitimate reason, no available fix yet, low actual exposure in your specific configuration, still needs a review date, not indefinite silence. Without one, an accepted exception from eighteen months ago sits unreviewed even after the conditions that justified it have changed. Log every exception with an owner and a re-review date, and treat a stale exception the same way you'd treat an overdue patch.

For example, a team accepts a parser vulnerability as low risk because ingestion only handles internal files. Later a customer upload feature ships, and the exception, never re-reviewed, is still marked accepted even though the reason for it no longer holds. A re-review date attached to the exception would have prompted the question, but so would a simple rule: any change to what feeds the parser triggers a review of the exceptions attached to it. Treat a changed ingestion path as an event that reopens old decisions, not only a calendar date.

A scanner finding and an audit finding often describe the same underlying gap from two different angles, a stale dependency and a vendor whose patching practices were never reviewed, for instance, but they tend to land in separate systems that nobody cross-references. Route scan findings that touch access control, vendor risk, or data handling into the same review process your broader security audit uses, so the two efforts reinforce each other instead of quietly duplicating work or missing things the other would have caught.

A shared findings list also makes it obvious when the same root cause is producing more than one symptom, which is easy to miss when scanning and auditing live in separate tools owned by separate people.

Close the common scanning gaps with these checks:

• Confirm your scanner's coverage reaches the embedding and vector database client libraries and their dependency trees.
• Patch ingestion parsers for PDF, DOCX, and HTML with the same urgency as your public-facing web server.
• Add a self-hosted vector database engine to your vulnerability management program, since no vendor patches it for you.
• Review how retrieved content flows into prompts and whether it's treated as untrusted input, since scanners can't check this.
• Log every accepted-risk exception with an owner and a re-review date.
• Route scan findings on access control, vendor risk, or data handling into your security audit process.