Adding Scaleway to Cartography without rewriting vulnerability management | SubImage
Book a Demo
Book a Demo
Platform<br>Attack Path Analysis<br>Internet exposure → crown jewels
Agentic Vulnerability Remediation<br>Repo-aware agents prioritize real risk and generate exact fixes
CSPM<br>Cloud security posture frameworks
AI Asset Inventory<br>Powered by graph ontology
Company<br>Mission<br>Read our story
Careers<br>Build the future of security
Resources<br>Documentation
Blog
Changelog
Trust Center
Support<br>Get help from the SubImage team
Pricing<br>Pricing
← Back to all posts<br>Adding Scaleway to Cartography without rewriting vulnerability management<br>Jul 21, 2026
engineering<br>vuln-management
by Jérémy Chapeau
How shared graph concepts let a new cloud provider reuse the existing path from a running container to a CVE, fix, source repository, and owner.
I recently added Scaleway support to Cartography. The<br>part I was most curious about was vulnerability management. Cartography already<br>knows how to connect a CVE to a running container, its image, its source<br>repository, and sometimes its owner. Would we have to teach it the same chain<br>again for Scaleway, handling all of its specific data types?
It turned out that all we had to do was model the Scaleway resources correctly.<br>Once the module said that a resource was a container, that it ran a particular<br>image, and that the image came from a particular repository, the existing<br>vulnerability queries could use it.
This is a small example of why we added an ontology to Cartography. It is also a<br>useful way to explain what the ontology does, because “we added an ontology” is<br>otherwise a fairly abstract claim.
Five questions a vulnerability finding should answer
Vulnerability management has been a Cartography use case for a long time. Lyft<br>wrote about using Cartography for vulnerability<br>management<br>in 2020, and we covered container vulnerability management again in a 2023<br>BSidesSF talk.
A scanner gives you a CVE and a package. To do something with the finding, you<br>usually need a few more facts:
Is the affected image running, or is it only sitting in a registry?
Which repository produced the image?
Does the scanner know a fixed package version?
Who owns the relevant code?
The answers cross several data sources. Runtime data comes from the cloud<br>provider or Kubernetes API, often both. Package and fix data comes from the<br>scanner. Image provenance often comes from OCI metadata, and ownership may come<br>from CODEOWNERS. Cartography's job is to put those facts in one graph.
Before the ontology work, queries often followed provider-specific node types.<br>An AWS query might start at an ECSTask, while another cloud would need a<br>different starting point and a different set of relationships. Adding a provider<br>could therefore mean adding another version of the analysis.
The Cartography<br>ontology<br>does not replace those provider-specific nodes. It adds shared concepts to them.<br>A ScalewayServerlessContainer can still contain the fields returned by<br>Scaleway's API while also participating in the more general Container concept.<br>Queries that only care that something is a container can use the shared label.
Scaleway and AWS map to the same graph concepts
The Scaleway integration<br>imports serverless containers, registries, and images. There are two relationships<br>that matter most for this example.
The first is the relationship between a running container and its image. Scaleway<br>configures a container with an image tag, but tags can move. The registry module<br>resolves the tag to a digest and creates RESOLVED_IMAGE, so a query can work with<br>the image that is actually running.
The second is PACKAGED_FROM. The registry module reads OCI metadata and, when<br>the build has recorded its source, connects the image to a code repository.
After those edges exist, the vulnerability path uses data that was already in the<br>graph. Trivy connects CVEs to affected images and packages. It records a fixed<br>package version when one is available. GitHub ingestion can connect a repository<br>to its CODEOWNERS rules and owners.
None of this means Scaleway has a special vulnerability management feature. The<br>Scaleway module describes its resources and how they connect to an image. The<br>vulnerability query works with the shared Container, Image, Package, and<br>CodeRepository concepts.
Following CVE-2024-3094 from a running container to its owner
The diagram below came from the original Cartography draft. It is a schematic of<br>the relationships involved, not customer data or a dump of one tested graph.
The useful shape is the path through it. Starting from a CVE, the graph can lead<br>to an affected image and package. A running container resolves to the same image,<br>which tells us the image is in use. When Trivy has remediation data, the package<br>can also point to a fixed version with SHOULD_UPDATE_TO.
In the other direction, PACKAGED_FROM connects the image to the repository that<br>built it. If the repository is on GitHub and Cartography...