Mend.io
Application Security- Overview
- Setup
- Data & mappings
- Operations & API
- Changelog
The Mend connector (formerly WhiteSource) integrates with the Mend software composition analysis (SCA) platform. It uses the Mend Organization API to discover the products and projects in an organization and to retrieve the open source libraries, security vulnerabilities, and policy alerts associated with them.
The connector synchronizes the following models:
- Application — Mend products.
- Code Project — Mend projects.
- Package — open source libraries (inventory) found in projects.
- Open Source Finding / Open Source Finding Definition — security vulnerabilities affecting libraries.
- Violation / Violation Definition — non-security policy and quality alerts (e.g. high severity bugs, new versions, multiple library versions, policy rejections).
Data retrieved from Mend
| Connector Object | Required | Maps to Data Model |
|---|---|---|
| Application | Yes | Application |
| Code Project | Yes | Code Project |
| Package | Yes | Package |
| Open Source Finding | Yes | Open Source Finding |
| Open Source Finding Definition | Yes | Open Source Finding Definition |
| Violation | Yes | Violation |
| Violation Definition | Yes | Violation Definition |
Model relationships
For detailed steps on how to view the data retrieved from Mend in the Brinqa Platform, see How to view your data.
Connection settings
When setting up a data integration, select Mend from the Connector dropdown and provide the following:
| Setting | Required | Default | Description |
|---|---|---|---|
| Server URL | No | — | Mend Server URL |
| API Key | No | — | Organization API Key |
| User Key | No | — | Mend user key |
| Parallelism | No | — | Number of data requests made in parallel. |
Authentication
Mend uses a token-based authentication model. Rather than a header bearer token, every request carries an organization API key (orgToken) and a user key (userKey) inside the JSON request body. There is no separate login/token-exchange call — the credentials are sent on every API request.
All requests are HTTP POST to a single endpoint, with the operation selected by the requestType field in the body.
Endpoint
| Method | URL |
|---|---|
| POST | {Server URL}/api/v1.4 |
The default {Server URL} is https://app.whitesourcesoftware.com.
Request Headers
| Header | Value |
|---|---|
Content-Type | application/json |
Request Body
Every request merges the configured credentials with the operation-specific parameters. The connectivity test uses the getAllProducts operation:
{
"requestType": "getAllProducts",
"orgToken": "<organization API key>",
"userKey": "<user key>"
}
Sample Response
{
"products": [
{
"productId": 68777,
"productName": "Demo Product",
"productToken": "1979719a550043a8afe4c65a0f686eaa8514d17e508b4597bca7ab8c398467b6"
}
]
}
Response Fields
| Field | Description |
|---|---|
productId | Numeric identifier of the product. |
productName | Display name of the product. |
productToken | Token used to scope subsequent product-level calls. |
How the credential is used
The orgToken and userKey are not exchanged for a session token. Instead they are injected into the body of every subsequent request (getOrganizationProductVitals, getProductProjectVitals, getAllProjects, getProjectInventoryReport, getProjectAlertsByType, getProjectTags, etc.) alongside the relevant productToken / projectToken to scope the call.
Sync Behavior
The connector supports incremental (delta) syncs. It maintains a sync token between runs and applies it as an incremental timestamp filter, so each run re-processes only the records that changed after the previous sync. The initial run retrieves the complete data set; later runs are incremental. The specific timestamp field applied to each object is documented under that object's Sync Duration Parameter.
How to obtain Mend credentials
Generate Mend.io API keys
For the Mend.io connector to access the Mend.io API, you must provide API keys. To do so, follow these steps:
-
Log in to your organization's Mend.io account as an administrator.
-
Click the User profile and then click Profile from the dropdown.
-
Click the User Keys tab, then locate the User Keys and Product Tokens sections on the page.
-
Copy the User Key and paste it into the User Key field of the integration configuration.
-
Copy the Product Token and paste it into the API Key field of the integration configuration.
If multiple product tokens are listed, select the token associated with the product you're integrating with Brinqa. This may depend on your specific use case or the particular data you need to access.
Note: If you do not have the permissions to create API keys, contact your Mend.io administrator. For additional information, see the Mend.io documentation.
Attribute mappings
Expand the sections below to view the mappings between the source and the Brinqa data model attributes:
Application
| Source Field Name | SDM Attribute |
|---|---|
APP- + Vital.id | UID |
Constant (Application) | CATEGORIES |
Vital.creationDate | SOURCE_CREATED_DATE |
Vital.lastUpdatedDate | SOURCE_LAST_MODIFIED |
Vital.name | NAME |
Code Project
| Source Field Name | SDM Attribute |
|---|---|
Constant (Project) | CATEGORIES |
CP- + Vital.id | UID |
getProjectTags response (key:value) | TAGS |
Product.productId | PRODUCT_ID |
Product.productName | PRODUCT_NAME |
Vital.creationDate | SOURCE_CREATED_DATE |
Vital.lastUpdatedDate | SOURCE_LAST_MODIFIED |
Vital.name | NAME |
Package
| Source Field Name | SDM Attribute |
|---|---|
| Accumulated product identifiers | APPLICATIONS |
| Accumulated project identifiers | PROJECTS |
Constant (Package) | CATEGORIES |
Library.artifactId | ARTIFACT_ID |
Library.coordinates | COORDINATES |
Library.description | DESCRIPTION |
Library.filename (falls back to Library.name) | FILE_NAME |
Library.groupId | GROUP_ID |
Library.keyUuid | UID |
Library.licenses[].name | LICENSES |
Library.name | NAME |
Library.sha1 | SHA_1 |
Library.type | TYPE |
Library.version | CURRENT_VERSION |
Open Source Finding
| Source Field Name | SDM Attribute |
|---|---|
Alert.date | LAST_FOUND |
Alert.library.keyUuid | LIBRARY_ID |
Alert.library.name | LIBRARY_NAME |
APP- + product.productId | PRODUCT_ID |
Constant (open, normalized) | STATUS |
CP- + project.projectId | PROJECT_ID |
| Derived from status | STATUS_CATEGORY |
| Library UUID, APP-+productId, CP-+projectId | TARGETS |
MD5(projectId, libraryUuid, vulnerability.name) | UID |
product.productName | PRODUCT_NAME |
project.projectName | PROJECT_NAME |
Vulnerability.name | TYPE |
Vulnerability.topFix.message (else vulnerability.name) | NAME |
Vulnerability.topFix.message (else vulnerability.name) | TITLE |
Open Source Finding Definition
| Source Field Name | SDM Attribute |
|---|---|
| Derived from normalized severity | SEVERITY_SCORE |
| Parsed CVSS v2 vector | CVSS_V2_AV |
| Parsed CVSS v2 vector | CVSS_V2_AC |
| Parsed CVSS v2 vector | CVSS_V2_AU |
| Parsed CVSS v2 vector | CVSS_V2_CI |
| Parsed CVSS v2 vector | CVSS_V2_II |
| Parsed CVSS v2 vector | CVSS_V2_AI |
| Parsed CVSS v2 vector | CVSS_V2_E |
| Parsed CVSS v2 vector | CVSS_V2_RL |
| Parsed CVSS v2 vector | CVSS_V2_RC |
| Parsed CVSS v2 vector | CVSS_V2_SEVERITY |
| Parsed CVSS v3 vector | CVSS_V3_AV |
| Parsed CVSS v3 vector | CVSS_V3_AC |
| Parsed CVSS v3 vector | CVSS_V3_PR |
| Parsed CVSS v3 vector | CVSS_V3_UI |
| Parsed CVSS v3 vector | CVSS_V3_CI |
| Parsed CVSS v3 vector | CVSS_V3_II |
| Parsed CVSS v3 vector | CVSS_V3_AI |
| Parsed CVSS v3 vector | CVSS_V3_E |
| Parsed CVSS v3 vector | CVSS_V3_RL |
| Parsed CVSS v3 vector | CVSS_V3_RC |
| Parsed CVSS v3 vector | CVSS_V3_SEVERITY |
| Vulnerability references | REFERENCES |
Vulnerability.cvss3_score (when v3) | CVSS_V3_BASE_SCORE |
Vulnerability.cvss3_severity | CVSS3_SEVERITY |
Vulnerability.description | DESCRIPTION |
Vulnerability.name | UID |
Vulnerability.name | NAME |
Vulnerability.publishDate | PUBLISHED_DATE |
Vulnerability.score | CVSS_V2_BASE_SCORE |
Vulnerability.scoreMetadataVector (when v2) | CVSS_V2_VECTOR |
Vulnerability.scoreMetadataVector (when v3) | CVSS_V3_VECTOR |
Vulnerability.severity | SOURCE_SEVERITY |
Vulnerability.severity (normalized) | SEVERITY |
Vulnerability.topFix.fixResolution / fixResolutionText | RECOMMENDATION |
Violation
| Source Field Name | SDM Attribute |
|---|---|
Alert.date | LAST_FOUND |
Alert.directDependency | DIRECT_DEPENDENCY |
Alert.level | LEVEL |
Alert.library.keyUuid | LIBRARY_ID |
Alert.library.name | LIBRARY_NAME |
Alert.type | ALERT_TYPE |
APP- + product.productId | PRODUCT_ID |
Constant (open, normalized) | STATUS |
CP- + project.projectId | PROJECT_ID |
| Derived from status | STATUS_CATEGORY |
| Library UUID, APP-+productId, CP-+projectId | TARGETS |
MD5(alert.type, alert.description) | TYPE |
MD5(projectId, libraryUuid, alertUuid) | UID |
product.productName | PRODUCT_NAME |
project.projectName | PROJECT_NAME |
Violation Definition
| Source Field Name | SDM Attribute |
|---|---|
Alert.description | DESCRIPTION |
Alert.level | SOURCE_SEVERITY |
Alert.level (normalized) | SEVERITY |
Alert.type | NAME |
| Derived from normalized severity | SEVERITY_SCORE |
MD5(alert.type, alert.description) | UID |
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).
Application
Operation options
This object does not support any operation options.
Delta sync
Supported.
API
- Type: REST endpoint · Endpoint:
POST /api/v1.4
Code Project
Operation options
| Option | Type | Default | Description |
|---|---|---|---|
projectTags | Boolean | true | When true, project tags are fetched and attached to the project. |
Delta sync
Supported.
API
- Type: REST endpoint · Endpoint:
POST /api/v1.4
Package
Operation options
| Option | Type | Default | Description |
|---|---|---|---|
nameAsIdentifier | Boolean | false | When true, product/project names (instead of ids) are used as the accumulated relationship targets. |
Delta sync
Supported.
API
- Type: REST endpoint · Endpoint:
POST /api/v1.4 - Default filters:
format=json
Open Source Finding
Operation options
This object does not support any operation options.
Delta sync
Supported.
API
- Type: REST endpoint · Endpoint:
POST /api/v1.4 - Default filters:
alertType=SECURITY_VULNERABILITY(optionalfromDateon incremental sync)
Open Source Finding Definition
Operation options
This object does not support any operation options.
Delta sync
Supported.
API
- Type: REST endpoint · Endpoint:
POST /api/v1.4 - Default filters:
alertType=SECURITY_VULNERABILITY(optionalfromDateon incremental sync)
Violation
Operation options
This object does not support any operation options.
Delta sync
Supported.
API
- Type: REST endpoint · Endpoint:
POST /api/v1.4 - Default filters:
alertTypeinHIGH_SEVERITY_BUG,NEW_MAJOR_VERSION,NEW_MINOR_VERSION,MULTIPLE_LIBRARY_VERSIONS,REJECTED_BY_POLICY_RESOURCE(optionalfromDateon incremental sync)
Violation Definition
Operation options
This object does not support any operation options.
Delta sync
Supported.
API
- Type: REST endpoint · Endpoint:
POST /api/v1.4 - Default filters:
alertTypeinHIGH_SEVERITY_BUG,NEW_MAJOR_VERSION,NEW_MINOR_VERSION,MULTIPLE_LIBRARY_VERSIONS,REJECTED_BY_POLICY_RESOURCE(optionalfromDateon incremental sync)
Changelog
The Mend connector has undergone the following changes:
| Version | Description | Migration Steps |
|---|---|---|
| 3.0.4 | Improvements - Connector-sourced attribute values now take precedence over non-connector data channels (manual edits, bulk imports, UI input) when the platform consolidates records, so WhiteSource data is no longer overridden by lower-priority sources. Bug Fixes - Corrected the data type of timestamp attributes — "Source created date" and "Source last modified" on Application and Code Project, and "Last found" on Open Source Finding and Violation. They are now stored as proper timestamps instead of numeric epoch values, so date-based filtering, sorting, and display behave correctly. | • Application, CodeProject, OpenSourceFinding, Violation: the timestamp attributes above changed from numeric (epoch) values to timestamps. Re-sync the WhiteSource connector to repopulate these records with the corrected types. |
| 3.0.3 | Improvements - Application and Code Project records now use prefixed, namespaced identifiers ( APP- and CP-) so that products and code projects no longer collide with other record types and relationships resolve reliably. Open Source Finding and Violation records now reference these prefixed identifiers when linking back to their parent application and code project. | • Application, Code Project: the unique identifier for these records changed to a prefixed format (APP-/CP-). Purge the existing Application and Code Project records and re-sync the WhiteSource connector so they are recreated with the new identifiers. • Open Source Finding, Violation: the Product ID and Project ID attributes (and the linked targets) now store the prefixed identifiers. Re-sync the WhiteSource connector to repopulate these records with the corrected references. |
| 3.0.2 | Bug Fixes - The "Direct dependency" attribute on Violation records is now stored as a true/false value instead of text, so it can be filtered and reported on as a proper boolean. | • Violation: the "Direct dependency" attribute changed from a text value to a boolean. Re-sync the WhiteSource connector to repopulate Violation records with the corrected type. |
| 3.0.1 | Improvements - Model display names were aligned with Mend's terminology: "CodeProject" is now "Code Project", "OpenSourceFinding" is now "Open Source Finding", "OpenSourceFindingDefinition" is now "Open Source Finding Definition", and the static code analysis models "StaticCodeFinding" / "StaticCodeFindingDefinition" are now "Violation" / "Violation Definition", matching what users see in the Mend console. - Violation records now include an "Alert type" attribute identifying the category of the alert. | • Code Project, Open Source Finding, Open Source Finding Definition, Violation, Violation Definition: these models were renamed. Purge the records for the old model names and re-sync the WhiteSource connector so they are recreated under the new names. |
| 3.0.0 | Overview The WhiteSource connector integrates with Mend (formerly WhiteSource) to synchronize applications, code projects, open source libraries, and the security findings and policy violations associated with them. Category: Application Security Models | N/A |