SentinelOne

SentinelOne is the EDR / endpoint-protection source. The integration pulls agents (endpoints), threats, the installed-application inventory, and application-risk CVE data, cross-references each machine with Intune, and writes everything into MongoDB. It follows the shared integration lifecycle.

• Router: app/api/v1/endpoints/sentinelone.py, mounted at /api/v1/sentinelone
• Client: src/vulnmgmt/integrations/sentinelone/client.py (SentinelOneClient)
• Config collection: sentinelone_config (keyed by tenant_id)

Authentication

SentinelOne uses an API token plus your management console URL. The client builds its API base from the console URL and sends the token as an ApiToken authorization header:

Authorization: ApiToken <api_token>
Base URL: <console_url>/web/api/v2.1

Config fields (SentinelOneConfig):

Field	Meaning
api_url	Management console URL, e.g. https://usea1-partners.sentinelone.net
api_token	SentinelOne API token (JWT)
enabled	Whether the integration is active

Env seeding (_seed_sentinelone_config in app/main.py) reads SENTINELONE_CONSOLE_URL and SENTINELONE_API_TOKEN and inserts the default tenant config on startup. test-connection calls GET /system/status.

What the sync pulls

The background _run_sync pulls four things and reconciles them against Intune (it builds a lookup of Intune devices by lowercased device name so S1 records inherit the Intune device UUID and owner):

Data	Source call	Written to
Agents / devices	get_agents(limit=1000)	sentinelone_devices
Threats	get_threats (paginated, 1000/page)	sentinelone_threats
Installed apps	/installed-applications (cursor pagination)	inventory_items (source=sentinelone)
App risk + CVEs	get_application_risks + get_application_cves	sentinelone_app_risks and vulnerabilities

Details worth knowing:

• Devices capture OS, agent version, site/group, active/infected/decommissioned flags, serial, last-active date, and the matched intune_device_id. Agents no longer returned by the API are deleted (stale cleanup).
• Installed apps go into the shared inventory_items collection tagged source="sentinelone" so CVE-to-device matching and the Software rollup work for S1 machines too. For a machine matched to Intune, the row uses the Intune device UUID and the Intune owner’s email/name; unmatched machines fall back to the S1 agent id. (Because apps are keyed on the S1 agent_id, the device-detail views can list a machine’s apps regardless of the effective id.)
• Application risk / CVEs — the sync reads which apps carry CVEs and upserts per-app risk rows into sentinelone_app_risks, and upserts the CVE records into the main vulnerabilities collection (tagged source="sentinelone") so they appear in the vulnerability list without manual research. Both sub-steps are best-effort (non-fatal on failure).

After writing, the sync calls rebuild_applications so S1 software joins the Software inventory rollup.

Routes

Method	Path	Purpose
POST	/api/v1/sentinelone/config	Save credentials for the tenant
GET	/api/v1/sentinelone/config	Get config (token redacted)
DELETE	/api/v1/sentinelone/config	Remove config + synced data
POST	/api/v1/sentinelone/test-connection	Live credential test
POST	/api/v1/sentinelone/sync	Start a background sync
GET	/api/v1/sentinelone/sync-status	Poll sync status
GET	/api/v1/sentinelone/stats	Summary counts + OS / mitigation breakdowns
GET	/api/v1/sentinelone/devices	List synced agents (search / active / infected filters)
GET	/api/v1/sentinelone/threats	List synced threats
GET	/api/v1/sentinelone/apps	Installed apps aggregated by name
GET	/api/v1/sentinelone/device/{agent_id}	One agent + its threats + apps
GET	/api/v1/sentinelone/device-by-name/{computer_name}	Same, matched by hostname

/sync is a no-op guard if a sync is already running. See the overview for the lifecycle these routes share.