Offensity
External Attack Surface Management- Overview
- Setup
- Data & mappings
- Operations & API
- Changelog
Brinqa connector for Offensity — External Attack Surface Management
(EASM) / external vulnerability scanning. It discovers an organization's external domains and the
vulnerabilities found across them, and maps them onto the Brinqa unified data model as Site
assets, Violation Definitions, and Violations. The asset is the domain (UDM Site);
subdomains roll up onto it as an attribute, and violations target the domain. Scan profiles and
reports are read internally to build the domain inventory and exposure; they are not emitted as
objects.
The connector retrieves, from the Offensity reporting API:
- External domain inventory and exposure — the enabled scan profiles and the infrastructure of
the latest successful report per profile: subdomains, resolved IP addresses, open ports, services
and versions, CPEs, and detected technologies, aggregated onto one
Siteper registrable domain. - 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 affected URLs, 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 |
|---|---|---|
| Site | Yes | Site |
| Violation Definition | Yes | Violation Definition |
| Violation | Yes | Violation |
Model relationships
For detailed steps on how to view the data retrieved from Offensity in the Brinqa Platform, see How to view your data.
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 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:
Site— incremental. With a token, the connector pagesreports/?status=successonce, newest-first, keeping only reports whosecompleteddate is at or aftersinceand stopping as soon ascreatedfalls a full scan-duration before it — so only the scan profiles actually rescanned in the window get their infrastructure re-fetched. 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.Violation DefinitionandViolation— the consolidatedissues/feed is not date-filterable, sosinceis 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 the two models via a local transaction-scoped store, so enabling both does not double 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.
Attribute mappings
Expand the sections below to view the mappings between the source and the Brinqa data model attributes:
Site
| Source Field Name | SDM Attribute |
|---|---|
| "<subdomain> <tech> <version>" from wappalyzers | TECHNOLOGIES (custom, multi) |
| constant ASSET_CATEGORY_DOMAIN | CATEGORIES |
domain | NAME |
domain (lowercase) | UID |
| latest report completed across the domain's profiles | LAST_SCANNED |
| per port "<subdomain> <port>/<p_type> <service> — <ver>" | SERVICES (custom, multi) |
| per subdomain "<subdomain> <port>/<p_type>" | OPEN_PORTS (custom, multi) |
scanprofiles[].subdomains[].subdomain for the domain | SUBDOMAINS (custom, multi) |
| sync time | LAST_CAPTURED |
union of ips[].ip + ports[].ip across subdomains | IP_ADDRESSES (multi) |
union of ports[].cpe | CPE_RECORDS (multi) |
The custom exposure attributes (OPEN_PORTS/SERVICES/TECHNOLOGIES) are subdomain-encoded —
each value is prefixed with its subdomain — so per-subdomain attribution survives the rollup to a
single Site. IP_ADDRESSES/CPE_RECORDS are kept plain for correlation. Skipped: TLS
certificates and DNS. No normalized STATUS is emitted — liveness is governed by the
LAST_CAPTURED lifecycle. A subdomain with no live infrastructure contributes nothing.
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 |
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 |
|---|---|
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 URL(s) on the subdomain (from affected_urls, verbatim) | URL (multi) |
the subdomain's parent domain (subdomain → domain, apex fallback) | TARGETS |
vulnerability_id (natural key, verbatim) | TYPE |
| vulnerability_id + "\ | UID |
Targeting & status: TARGETS is a pure subdomain → domain rollup (no IP resolution) — every
affected host is already named in affected_subdomains, so no raw-IP targets are emitted. 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.
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).
Site
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
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
Changelog
The Offensity connector has undergone the following changes:
| Version | Description | Migration Steps |
|---|---|---|
| 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 |