Offensity

External Attack Surface Management

Overview

Brinqa connector for Offensity — External Attack Surface Management (EASM) / external vulnerability scanning. It discovers an organization's external subdomains and the vulnerabilities found across them, and maps them onto the Brinqa unified data model as Subdomain assets, Violation Definitions, and Violations. Every DNS name is one asset (UDM Site), root domains included — it carries the exposure and is what a violation targets — and the registrable domain above it stays available as the subdomain's DOMAIN attribute for grouping and reporting. Scan profiles and reports are read internally to build the inventory and exposure; they are not emitted as objects.

The connector retrieves, from the Offensity reporting API:

• External host inventory and exposure — the infrastructure of the latest successful report per profile: one Subdomain per discovered host with its resolved IP addresses, open ports, services and versions, CPEs, detected technologies, and the registrable domain it sits under.
• Vulnerability definitions — the vulnerability types behind the findings, with description, remediation guidance, reference links, and Offensity's confidentiality / integrity / availability risk scores banded into a normalized severity.
• Vulnerabilities (violations) — the consolidated issue feed expanded per affected subdomain, so each finding is recorded against the specific host it was observed on, carrying the affected URLs, the port and transport it was observed on, first / last seen dates, resolution state, and the analyst triage state.

TLS certificate and DNS data are available in the API but are deliberately not synced.

Data retrieved from Offensity

Connector Object	Required	Maps to Data Model
Subdomain	Yes	Site
Violation Definition	Yes	Violation Definition
Violation	Yes	Violation

Model relationships

note

For detailed steps on how to view the data retrieved from Offensity in the Brinqa Platform, see How to view your data.

Setup

Connection settings

When setting up a data integration, select Offensity from the Connector dropdown and provide the following:

Setting	Required	Default	Description
API URL	No	https://reporting.offensity.com	Offensity reporting API base URL (e.g. https://reporting.offensity.com)
API token	Yes	—	Offensity API token, sent as the "Authorization: Token <token>" header
Page size	No	100	Maximum number of records to request per page
Parallel requests	No	min(4, cores)	Maximum number of parallel API requests
Max retries	No	5	Maximum number of retries permitted during a request. The default value is 5.
Request timeout (secs)	No	120	Maximum seconds allotted before a request times out. Maximum allowed value 300.
SSL / TLS	No	false	Skip certificate verification

Authentication

The connector authenticates with a static API token issued by Offensity. There is no token exchange — the token is sent as a header on every request.

Endpoint (connection test)

Method	URL
GET	https://reporting.offensity.com/api/v1/

Request Headers

Header	Value
Authorization	Token <api-token>

Usage

Every request to the Offensity reporting API carries the token:

Authorization: Token <api-token>

A non-2xx response (e.g. 401 Invalid token) surfaces Offensity's {"detail": "..."} message via the connector's error handler. The base API path api/v1/ is prepended by the connector.

Sync Behavior

The connector uses a mix of incremental and full syncs depending on the model. It maintains a sync token between runs and receives it as a since timestamp. No Offensity endpoint is queried with a date parameter — where the connector is incremental, it decides client-side which records to process:

• Subdomain — incremental. With a token, the connector pages reports/?status=success once, newest-first, keeping only reports whose completed date is at or after since and stopping as soon as created falls a full scan-duration before it — so only the scan profiles actually rescanned in the window are re-read. Without a token it instead does a targeted latest-report lookup per enabled profile, so the first run of a new connector instance covers everything. An incremental run emits only the hosts it re-read: the platform replaces a synced object with whatever the connector sends, so emitting a host the window skipped would clear the exposure it already had.
• Violation Definition and Violation — the consolidated issues/ feed is not date-filterable, so since is not applied at all: every run pages the complete issue set and re-emits it. The feed is downloaded once per run and shared between every model that reads it via a local transaction-scoped store, so enabling several does not multiply the fetch.

Each model's verdict is restated under its own #### Sync Duration Parameter below.

How to obtain Offensity credentials

Obtain the required credentials (apiToken) from your Offensity administrator or the Offensity admin console, then enter them in the connection settings above.

Data & mappings

Attribute mappings

Expand the sections below to view the mappings between the source and the Brinqa data model attributes:

Subdomain

Source Field Name	SDM Attribute
"<port>/<p_type> <service> — <version>"	SERVICES (custom, multi)
"<port>/<p_type>"	OPEN_PORTS (custom, multi)
"<tech> <version>" from ports[].urls[].wappalyzers	TECHNOLOGIES (custom, multi)
constant ASSET_CATEGORY_DOMAIN	CATEGORIES
ips[].ip + ports[].ip	IP_ADDRESSES (multi)
ports[].cpe	CPE_RECORDS (multi)
same as UID	NAME
scan-profile domain the host sits under; apex fallback	DOMAIN (custom)
subdomain (qualified with domain, lowercase)	UID
sync time	LAST_CAPTURED
the report's completed date	LAST_SCANNED

note

The infrastructure feed only returns live hosts, so it is unioned with the affected_subdomains[] of the issues feed: a host Offensity still reports findings on but no longer resolves would otherwise leave those violations pointing at an asset that does not exist. Such a residual host is emitted with identity only and no exposure — it has none to report. A subdomain that is monitored but was never live is not emitted at all, as it would add an empty asset with neither exposure nor findings. Skipped: TLS certificates and DNS. No normalized STATUS is emitted — liveness is governed by the LAST_CAPTURED lifecycle.

note

DOMAIN is resolved from the scan profiles: a host seeded into a profile takes that profile's domain, and one Offensity discovered on its own resolves to the longest scan-profile domain it sits under — so a multi-label suffix (shop.acme.co.uk) yields acme.co.uk and not co.uk. Only a host under a domain no profile declares at all falls back to guessing the last two labels. It is a plain string, not a reference: nothing needs to exist for the domain it names.

Violation Definition

Source Field Name	SDM Attribute
band of max(confidentiality, integrity, availability)	SEVERITY
description (HTML → plain text)	DESCRIPTION
links[]	REFERENCES
recommendation (HTML → plain text)	RECOMMENDATION
risk_scores.availability (0–10)	RISK_AVAILABILITY (custom, Integer)
risk_scores.confidentiality (0–10)	RISK_CONFIDENTIALITY (custom, Integer)
risk_scores.integrity (0–10)	RISK_INTEGRITY (custom, Integer)
same as SEVERITY	SOURCE_SEVERITY
sync time	LAST_CAPTURED
the band's score	SEVERITY_SCORE
title (falls back to vulnerability_id)	NAME
vulnerability_id	TAGS
vulnerability_id (natural key, verbatim)	UID

note

Severity banding (CVSS-style cutoffs over the 0–10 scale): 0 → None, 1–3 → Low, 4–6 → Medium, 7–8 → High, 9–10 → Critical. Overall = band of max(C, I, A).

Violation

Source Field Name	SDM Attribute
"<port>/<transport>" per affected port	PORTS (custom, multi)
aggregated resolved (any open → active; all resolved → fixed)	SOURCE_STATUS
aggregated resolved (any open → open; all resolved → resolved)	PROVIDER_STATUS
client_status (open / ignore)	CLIENT_STATUS (custom)
max resolved date when the subdomain is fully resolved	LAST_FIXED
min/max over the subdomain's matched locations (issue-level if none)	FIRST_SEEN / LAST_SEEN
sync time	LAST_CAPTURED
the affected subdomain (FQDN)	NAME
the affected subdomain (FQDN)	SUBDOMAIN (custom)
the affected subdomain (FQDN)	TARGETS
the affected URL(s) on the subdomain (from affected_urls, verbatim)	URL (multi)
the port, when the violation resolves to exactly one port / transport	PORT (Integer)
the transport (TCP / UDP), under the same condition	PROTOCOL
vulnerability_id (natural key, verbatim)	TYPE
vulnerability_id + "|" + subdomain (natural composite key)	UID

note

Targeting & status: TARGETS is the affected subdomain itself (no IP resolution) — every affected host is already named in affected_subdomains, so no raw-IP targets are emitted, and the domain above it remains one hop away via Subdomain.DOMAIN. A subdomain's status comes from its matched URL/system locations (an IP location is matched to its subdomain via the issue's consolidated_targets_by_tags); a residual subdomain reachable only via a retired "orphan" IP takes that location's status, and a stale orphan IP never overrides a subdomain's live status. A subdomain with no location at all takes the issue-level status (open when the issue is unresolved — Offensity infers state from resolved, null = open, consistently on every path). No normalized STATUS / STATUS_CATEGORY is emitted — the platform derives those from SOURCE_STATUS / PROVIDER_STATUS and the lifecycle. CLIENT_STATUS is a separate analyst-triage state (open / ignore), captured per issue element; an ignored finding is still open/unresolved, so it is not suppressed.

note

Ports: the port is taken from the affected location itself (sub.example.com:443, https://sub.example.com:443/path), which is per-host and therefore exact, while the transport is named by the issue's consolidated_targets_by_tags[].ports[] and defaults to TCP. Those consolidated ports belong to an IP, which on a shared CDN address fronts many subdomains, so they are used to name the transport of a port the location already proved — and stand in as the port source only for a subdomain that has no location of its own. A location that states no port leaves all three attributes unset rather than having one inferred from the URL scheme. PORT and PROTOCOL are single-valued, so they are populated only when the violation resolves to exactly one port / transport pair; PORTS always carries the complete list.

Operations & API

Operations & API

Expand each connector object to see its operation options, delta-sync behavior, and the API it uses. See connector operation options for how to apply operation options (keys and values are case-sensitive).

Subdomain

Operation options

This object does not support any operation options.

Delta sync

Supported. The connector performs an incremental (delta) sync via the since sync token, filtering on completed.

API

• Type: REST · Endpoint: scan profiles → latest successful report per profile → report infrastructure, plus the consolidated issues feed (for hosts named only by a finding)

Violation Definition

Operation options

This object does not support any operation options.

Delta sync

Not supported. The connector performs a full sync of Violation Definition on every run and applies no incremental date filter.

API

• Type: REST · Endpoint: consolidated issues feed (no server-side date filter → full pull each sync)

Violation

Operation options

This object does not support any operation options.

Delta sync

Not supported. The connector performs a full sync of Violation on every run and applies no incremental date filter.

API

• Type: REST · Endpoint: consolidated issues feed

Changelog

Changelog

The Offensity connector has undergone the following changes:

Version	Description	Migration Steps
3.1.0	New Features - Added a Subdomain asset model — one asset per DNS name, root domains included. Each host Offensity discovers carries its IP addresses, open ports, services and versions, CPEs, detected technologies, and the registrable domain it belongs to. Because different teams commonly own different subdomains of the same registrable domain, findings can now be routed to the team that actually owns the affected host. Improvements - Violations now target the affected subdomain instead of its parent domain. A finding is recorded against the specific host it was observed on rather than being rolled up to the second-level domain, and the domain remains available through the subdomain's Domain attribute. - Violations now record the port and transport they were observed on, so remediation teams can locate the issue on the host. Every affected port is listed, and where a violation resolves to a single port the standard Port and Protocol attributes are populated as well. - The domain-level Site model has been removed. Every name Offensity monitors — root domains and subdomains alike — is now a single Subdomain asset. A root domain previously existed both as a domain and as a host, so a finding on it appeared against two records; there is now exactly one asset per name. Grouping, filtering and per-domain reporting continue to work through the subdomain's Domain attribute. - Per-host exposure is no longer prefixed with the host name to preserve attribution within a domain-wide list — each host now carries its own open ports, services and technologies directly. - Errors from Offensity are no longer buried in its full HTML error page. When a failed request returns a non-JSON body, the reported message is summarised to a single line with the original length noted, so a failure stays legible in the logs instead of spanning dozens of lines per retry. Errors that do carry a JSON message are surfaced verbatim as before. Bug Fixes - A host under a multi-label domain suffix (for example .com.br or .co.uk) that was not seeded into a scan profile resolved to the suffix itself rather than its registrable domain, so its findings were grouped under a domain such as com.br alongside every unrelated host beneath that suffix. Such hosts now resolve to the longest scan-profile domain they sit under.	• Site: the domain-level model has been removed, and every name is now synced by the Subdomain model, which carries the exposure Site used to hold — Action: remove the Site object type from the data integration's sync configuration first, then purge previously synced Site objects. Until the object type is removed, saving the integration fails with Invalid type provided: Site, because the stored configuration still asks the connector for a model it no longer provides
3.0.0	Overview The Offensity connector integrates with Offensity (External Attack Surface Management) to synchronize an organization's external domains, the vulnerabilities found across them, and the definitions of those vulnerabilities. Category: External Attack Surface Management Models	N/A