Synqly Adds JupiterOne Integration for Asset Visibility

We are announcing a new JupiterOne integration now live within the Synqly ecosystem. Security and IT vendors building on Synqly can connect directly to JupiterOne and give their OEM customers access to device inventory and software inventory data drawn from JupiterOne’s asset graph, without carrying the engineering cost of building and maintaining that connector on their own.

JupiterOne is a cyber asset attack surface management platform that ingests data from more than two hundred sources into a single graph of assets and the relationships between them. Rather than asking a security team to reconcile separate inventories from cloud providers, endpoint tools, identity systems, and code repositories, JupiterOne resolves all of it into one queryable model, so a laptop, a cloud instance, and the software installed on both show up as connected entities rather than disconnected records. Readers who want more background on the platform itself can visit the JupiterOne website.

With the JupiterOne integration live, OEM customers building their product on Synqly can query devices and software inventory records from a customer’s JupiterOne graph through one consistent API, rather than learning JupiterOne’s own query language and access model from scratch. The query devices capability supports filtering by hostname, IP address, MAC address, operating system name, and first seen or last seen time, which lets a product ask JupiterOne exactly which assets it needs rather than pulling the entire graph and filtering client side. The query software inventory capability works the same way, filtering by device, package name, package vendor, and package version, so a product can answer a specific question, such as which devices are running a named package, without building that logic itself.

The integration also supports writing data back into JupiterOne, not only reading it. A product can create a device record, create device records in bulk, and create a software inventory record for a device already tracked in JupiterOne’s graph, along with retrieving the labels already applied to assets in the inventory. Together, these operations give a security or IT product the pieces it needs to keep a customer’s JupiterOne graph current from its own detections, while still treating JupiterOne as the source of truth for asset context that other tools in the customer’s stack already rely on. Full configuration and setup instructions for this integration live in the JupiterOne Assets Configuration Guide on the Synqly documentation site at docs.synqly.com/guides/provider-configuration/jupiterone-assets-setup, and we are not restating capabilities beyond what is documented there.

This is JupiterOne’s first integration within the Synqly ecosystem. Full details on the JupiterOne integration, including supported operations and schema mappings, live on the JupiterOne integration partner page. For hands on setup instructions, the JupiterOne Assets Configuration Guide at docs.synqly.com/guides/provider-configuration/jupiterone-assets-setup walks through provider configuration from start to finish.

This JupiterOne integration is part of Synqly’s Assets Unified API, which already connects OEM products to asset inventory and configuration management platforms including Axonius, ServiceNow CMDB, and Tenable Cloud. The problem that category solves is a familiar one for any security vendor that has tried to answer a simple question, such as which devices in a customer’s environment are missing a critical patch, and found that the answer depends on reconciling data from three or four separate inventory systems that were never designed to talk to each other. A CAASM platform like JupiterOne exists precisely to do that reconciliation once, and the JupiterOne integration gives OEM products a way to draw on that already reconciled view instead of attempting the same reconciliation work a second time downstream.

For a product team evaluating whether to build a JupiterOne connector in house, the calculus is straightforward. Building it means learning JupiterOne’s API and data model, handling authentication, and maintaining that code as JupiterOne’s platform evolves, all for a single integration among the dozens a modern security product is expected to support. Connecting through Synqly means shipping JupiterOne support alongside every other Assets provider Synqly already supports, and picking up new asset management platforms as Synqly adds them, without a repeat engineering effort each time. That difference tends to matter most for smaller product and engineering teams, where every week spent on connector maintenance is a week not spent on the detection and response work that actually sets a security product apart.