Skip to content
Notifications
Clear all

Guide: Integrating vulnerability scans from our external scanner

2 Posts
2 Users
0 Reactions
1 Views
(@kevinr)
Trusted Member
Joined: 1 week ago
Posts: 48
Topic starter   [#4952]

Hey folks, I've been neck-deep in a project to pipe external vulnerability scan data into Vision One, and let me tell you, it's a game-changer for getting a unified view. We use a couple of different scanners (one for web apps, another for infra), and having those results flow automatically into Vision One's XDR workflow has really tightened up our response times.

I wanted to share our approach, focusing on the integration pattern rather than vendor-specific code. The core idea is using Vision One's Workbench and its open APIs. Here's a simplified breakdown of our process:

* **The Trigger:** Our external scanner finishes a scheduled scan and dumps a JSON report to a secure cloud storage bucket (S3 in our case).
* **The Orchestrator:** A lightweight Python service (could be a scheduled script, Lambda, etc.) picks up the new report. This is where the ETL mindset kicks in.
* **Data Transformation:** The script maps the scanner's findings to Vision One's "sighting" model. The key fields we map are:
* Asset identifier (IP/hostname)
* Vulnerability CVE ID
* Severity (translated to Vision One's levels)
* Discovery timestamp
* **The Ingestion:** We POST this transformed data to the Vision One `POST /v3.0/sightings/vulnerability-sighting` API endpoint.
* **The Payoff:** Once in Vision One, these sightings pop up in Workbench. We've automated a playbook that correlates them with existing endpoint data, assigns risk scores, and creates alerts for the nastiest, most exploitable ones.

A couple of tips from the trenches:
* Start small. Integrate one scanner and one severity level first to validate the pipeline.
* Pay attention to rate limits on the Vision One API—batch your requests if you have a lot of findings.
* The real magic isn't just ingesting the data; it's building Vision One playbooks that automatically group sightings from *different* scanners on the same asset.

For anyone looking to do this, the Vision One API documentation is pretty solid. The biggest lift is usually that mapping/transformation step to make the external data fit the sighting schema. Happy to nudge anyone in the right direction if you're starting a similar project!

- Kev



   
Quote
(@adrianm)
Trusted Member
Joined: 1 week ago
Posts: 50
 

That's a really clean pattern. Thanks for sharing the high-level flow. I'm in the middle of setting up something similar, and your point about mapping to the "sighting" model is super helpful. That data transformation step is where I've been stuck.

Could you say a bit more about how you handle the translation of scanner severity levels into Vision One's? Our web app scanner uses its own 1-5 scale, and I'm not sure if a direct mapping is the best approach.


still learning


   
ReplyQuote