How is this different from the authorized-pentest-red-team blueprint?

The pentest blueprint stores point-in-time findings and evidence from one authorized engagement. This blueprint is standing, continuous vulnerability management — asset inventory, ongoing scans, and patch status that persists between engagements.

Does RushDB scan for vulnerabilities itself?

No. RushDB stores and connects the asset, vulnerability, and patch data your scanners and asset inventory already produce, so it becomes one queryable graph instead of separate exports.

How does patch status stay current?

Update the VULNERABILITY record’s patched field (or link it to a PATCH record) as remediation completes. The exposure query reflects whatever state is currently stored.

Can this scope to one team or one exposure tier?

Yes. Owner team, exposure tier, and severity are exact where-filters, so a query can scope to exactly the assets one team is responsible for.

How is this different from the transaction-monitoring blueprint?

Both connect standing operational data for continuous querying, but this blueprint tracks asset, vulnerability, and patch state for security exposure, while transaction monitoring tracks financial transactions and accounts for fraud patterns — different domain entities and different relationship types.

rushdb

Blueprint: vulnerability management

Query exposure across assets, not spreadsheets across scanners.

Vulnerability management is a standing, continuous graph problem: which ASSET records have which VULNERABILITY records, which are already patched, which are internet-facing, and which owner_team is responsible for remediation. This blueprint keeps that ASSET-VULNERABILITY-PATCH graph queryable and current as new scans arrive, distinct from a single pentest engagement’s point-in-time, evidence-scoped findings.

A vulnerability and asset risk graph connects ASSET, VULNERABILITY, and PATCH records so security teams can query exposure, such as unpatched critical CVEs on internet-facing systems owned by one team, as a single graph query.

Start free View docs

Exposure questions get answered by reconciling scanner exports by hand.

Asset inventories, vulnerability scans, and patch records often live in separate scanner tools with no shared identity. Answering "which critical CVEs are unpatched on internet-facing ASSET records owned by team X" usually means exporting each tool’s report and joining ASSET, VULNERABILITY, and PATCH data manually before anyone can act on it.

Before

Asset, vulnerability, and patch data live in separate scanner exports
Ownership and exposure context are reconciled by hand for each report
Point-in-time pentest findings and standing vulnerability data are mixed together
Risk queries are one-off spreadsheet joins, not repeatable

With RushDB

Assets, vulnerabilities, patches, and owners are connected Records
Exposure queries run as one filtered graph query
Standing vulnerability data stays distinct from engagement-scoped pentest evidence
New scans update the graph without a manual reconciliation pass

Graph intelligence on ingest

Incoming data becomes queryable graph context.

Scanner output arrives as an ASSET nesting VULNERABILITY entries with severity, patched state, and CVE identifiers. RushDB links each VULNERABILITY to its ASSET on import, and when PATCH records or owner_team data arrive flat from a separate ticketing or inventory tool, suggested-relationship analysis can propose the missing ASSET-PATCH and ownership links.

Normalize as data arrives

As ASSET records arrive from scanner output, RushDB infers types for exposure, owner_team, and severity fields without a schema migration.

Auto-link nested structure

An ASSET nesting its VULNERABILITY entries becomes connected Records automatically, so each CVE stays linked to the asset it was scanned on.

Enrich scattered sources

For PATCH or ownership data imported flat from a separate ticketing tool, suggested-relationship analysis can propose the missing ASSET-PATCH links.

Suggested relationship analysis requires an LLM configured for the project. Suggestions stay in draft form until you approve them, so inferred domain meaning never mutates the graph silently. You can also add explicit relationships through the SDK or API.

Review suggested relationship patterns

Data model

One flexible graph for the workflow.

Start with the payload shape your product already produces. RushDB stores it as Records, infers typed properties, and keeps nested or approved domain relationships queryable.

Schema sketch

Asset exposure payload

One asset write carries its exposure tier, owning team, and any open vulnerabilities from the latest scan.

{
  "assetId": "web-gw-04",
  "exposure": "internet-facing",
  "owner_team": "platform-security",
  "VULNERABILITY": [
    { "cve": "CVE-2026-1234", "severity": "critical", "patched": false }
  ]
}

Working example

Query exposure directly instead of joining exports by hand.

Once assets, vulnerabilities, and patch status are connected Records, exposure questions run as a single filtered traversal.

Input

ASSET web-gw-04
  exposure: "internet-facing"
  owner_team: "platform-security"
  VULNERABILITY: [
    { cve: "CVE-2026-1234", severity: "critical", patched: false }
  ]

Query

{
  "labels": ["ASSET"],
  "where": {
    "exposure": "internet-facing",
    "owner_team": "platform-security",
    "VULNERABILITY": { "severity": "critical", "patched": false }
  }
}

Result

{
  "asset": "web-gw-04",
  "exposure": "internet-facing",
  "unpatched_critical_cves": ["CVE-2026-1234"]
}

TypeScript SDK

Query exposure across the asset graph.

The same graph updates as new scans arrive, so this query stays current without a manual reconciliation step.

from rushdb import RushDB

db = RushDB('RUSHDB_API_KEY')

schema = db.ai.get_schema_markdown({'labels': ['ASSET', 'VULNERABILITY', 'PATCH']}).data

exposed_assets = db.records.find({
    'labels': ['ASSET'],
    'where': {
        'exposure': 'internet-facing',
        'owner_team': 'platform-security',
        'VULNERABILITY': {'severity': 'critical', 'patched': False},
    },
})

Implementation blueprint

Build the vulnerability and asset risk graph.

Use this sequence to keep asset, vulnerability, and patch data connected and queryable as scans update.

01Import ASSET records with exposure and owner_team
02Attach VULNERABILITY records per asset from scanner output, with severity and patched state
03Link PATCH records to the vulnerabilities they resolve
04Update patched state as remediation completes
05Query exposure with exact filters across severity, exposure, and ownership

Build path

Keep exposure, severity, and patched state as typed fields, not scanner-report text.
Link vulnerabilities to the patch that resolves them so remediation status is traceable.
Keep this graph distinct from engagement-scoped pentest evidence — this is standing infrastructure, not a point-in-time report.
Update patched state on remediation instead of leaving resolved vulnerabilities marked open.

Relevant docs

Read the exact primitives behind this pattern.

These links point to the RushDB docs pages that map directly to this blueprint: ingestion, labels, properties, values, SearchQuery, relationships, semantic search, MCP, or deployment.

Search introduction

Filter assets by exposure, ownership, and connected vulnerability severity in one query.

Open docs

Relationships

Connect assets to vulnerabilities and vulnerabilities to the patches that resolve them.

Open docs

Import JSON data

Push asset inventory and scanner output as nested records and let RushDB build the connected graph.

Open docs

How it works

Build the smallest useful workflow first.

Connect assets to their vulnerabilities

Import asset inventory and attach vulnerability records from scanner output as the graph updates.

Track patch status as a relationship

Link each vulnerability to the patch that resolves it, so remediation state is queryable, not just noted in a ticket.

Query exposure directly

Filter by severity, exposure, and ownership in one query instead of joining scanner exports by hand.

Know where it fits.

Standing graph, not a point-in-time report

This blueprint is continuous vulnerability-management data, distinct from the authorized-pentest blueprint’s engagement-scoped findings.

Ownership makes exposure actionable

Connecting assets to an owning team turns a raw CVE list into a query a specific team can act on.

Questions developers ask.

Next step

Start with one focused workflow.

Start free

Related use cases

Explore all use cases

Pentest and red-team evidence

Commit authorized sandbox findings, evidence, and breach-abuse logs to one graph for defensive review.

Explore security validation

Multi-agent incident response

Coordinate a live SaaS incident through shared, durable graph memory.

Explore the incident war room