Veracode

Application Security

Overview

The Veracode Connector integrates with the Veracode application security platform through its REST APIs. It syncs application profiles and their security findings across all of Veracode's analysis types — Static Analysis (SAST), Dynamic Analysis (DAST), Software Composition Analysis (SCA), and Manual Penetration Testing — into Brinqa's Unified Data Model.

For each finding type the connector produces both a finding record (the occurrence on a specific application or web site) and a finding definition (the reusable weakness/vulnerability definition, keyed by CWE or CVE). It also discovers the assets those findings apply to: applications, dynamically scanned web sites, and open source software components (packages). Application custom fields configured in Veracode are discovered at sync time and added dynamically to the relevant model schemas.

Findings are retrieved by submitting asynchronous report requests to the Veracode Reporting (Analytics) API; the connector polls each report until it completes, then pages through the results.

Data retrieved from Veracode

Connector Object	Required	Maps to Data Model
Application	Yes	Application
Site	Yes	Site
Component	Yes	Package
Static Code Finding	Yes	Static Code Finding
Static Code Finding Definition	Yes	Static Code Finding Definition
Dynamic Code Finding	Yes	Dynamic Code Finding
Dynamic Code Finding Definition	Yes	Dynamic Code Finding Definition
Pentest Finding	Yes	Pentest Finding
Pentest Finding Definition	Yes	Pentest Finding Definition
Open Source Finding	Yes	Open Source Finding
Open Source Finding Definition	Yes	Open Source Finding Definition

Model relationships

note

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

Setup

Connection settings

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

Setting	Required	Default	Description
Service URL	No	—	Veracode analysis center URL
API ID	No	—	Veracode API ID
Secret key	No	—	Veracode API secret key.
Maximum retries	No	—	The maximum number of retry attempts before giving up a request

Authentication

The connector authenticates to the Veracode APIs using Veracode HMAC request signing (VERACODE-HMAC-SHA-256). It is configured with an API credential pair — an API ID and a Secret Key — generated in the Veracode platform. No interactive token exchange or login endpoint is involved; every outbound request is signed individually.

How the signature is built

For each request, the connector computes an Authorization header. The signed data string is composed of the API ID, the request host, the request URL (path plus query string), and the HTTP method:

id={apiId}&host={host}&url={path}?{query}&method={GET|POST}

The signing key is derived by chaining HMAC-SHA-256 operations over a per-request nonce, the current timestamp, and a fixed request-version string (vcode_request_version_1), and the signed data string is then HMAC-SHA-256 signed with that derived key.

Request header

Header	Value
Authorization	VERACODE-HMAC-SHA-256 id={apiId},ts={timestamp},nonce={nonce},sig={signature}

• ts — request timestamp in epoch milliseconds.
• nonce — a random 16-byte value (hex encoded), unique per request.
• sig — the hex-encoded HMAC-SHA-256 signature described above.

This Authorization header is generated and attached to every request the connector makes (test, applications, findings reports, CWE lookups, etc.).

Connectivity test

On test, the connector issues a small request to verify credentials.

Method	URL
GET	appsec/v1/applications?size=1

Sample response (truncated):

{
  "_embedded": {
    "applications": [
      {
        "id": 25444,
        "guid": "68302793-3121-4ec9-800d-f0ec3ba5b051",
        "profile": { "name": "Hadoop" }
      }
    ]
  },
  "page": { "size": 1, "total_elements": 482, "total_pages": 482, "number": 0 }
}

Response Field	Description
_embedded.applications[]	Array of application profiles for the account.
page.total_elements	Total number of applications available.
page.total_pages	Total number of result pages.
page.number	Zero-based index of the current page.

A 2xx status confirms the API ID / Secret Key pair is valid and the connector can reach the Veracode platform.

How to obtain Veracode credentials

Generate Veracode API credentials

For the Veracode connector to use the Veracode API, you must create an API service account and provide API credentials. Veracode does not allow retrieving the API credentials for an existing user. To generate new API credentials, follow these steps:

1. Log in to your organization's Veracode Platform as an Administrator.

2. Click the gear icon and select Admin.

3. On the Users tab, click Add New User.

4. Fill out the required information. Select Non-Human User to create an API service account.

5. Enter a valid email address for the account.

   Veracode uses this email address to send notifications about error messages, including authentication failures, permission issues, and API usage errors. These notifications are important for troubleshooting connector operation and ensuring timely resolution of integration problems. You can associate the same email address with multiple API service accounts.

6. In the User Roles section, select each of the following APIs to ensure full connector functionality:

   • Greenlight API User
   • Reporting API User
   • Results API
   • Upload API - Submit Only

7. In Allowed Scan Types, select All Scan Types.

8. Click Save to create and enable the user.

   The user receives an activation email.

9. After activating the account, log in to your Veracode Platform using the newly created API service account.

10. Click the username and select API Credentials from the dropdown.

11. Click Generate API Credentials.

The new API ID and secret key display. You cannot view the credentials again after this. Copy and save them to a secure location.

Note: If you do not have the permissions to generate API credentials, contact your Veracode administrator. For additional information, see Veracode documentation.

Data & mappings

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
Application.id	UID
Application.lastCompletedScanDate	LAST_ASSESSED
Application.modified	SOURCE_LAST_MODIFIED
Application.profile.archerAppName	ARCHER_APP_NAME
Application.profile.businessCriticality	BUSINESS_CRITICALITY
Application.profile.businessOwners[].email	OWNER
Application.profile.businessOwners[].email	SOURCE_OWNER
Application.profile.customFields[]	<custom field name>
Application.profile.description	DESCRIPTION
Application.profile.name	NAME
Application.profile.policies[].name	POLICY
Application.profile.policies[].policyComplianceStatus	RULES_STATUS
Application.profile.policies[].policyComplianceStatus	SOURCE_COMPLIANCE_STATUS
Application.profile.tags	TAGS
Application.profile.teams[].teamName	TEAMS
Application.scans[] (latest published DYNAMIC)	LAST_DYNAMIC_SCAN
Application.scans[] (latest published STATIC)	LAST_STATIC_SCAN
constant	CATEGORIES
schema only	LAST_SCAN_NAME
schema only	LAST_SCAN_PUBLISHED
sync time	LAST_CAPTURED

Site

Source Field Name	SDM Attribute
constant	CATEGORIES
host of Finding.filename URL	UID
host of Finding.filename URL	NAME
host of Finding.filename URL	URL
sync time	LAST_CAPTURED

Component

Source Field Name	SDM Attribute
constant	CATEGORIES
Finding.applicationId	TARGETS
Finding.componentFilePath	FILE_PATHS
Finding.componentName	NAME
Finding.componentName	FILE_NAME
Finding.componentVersion	CURRENT_VERSION
Finding.description	DESCRIPTION
Finding.licenses[].licenseName	LICENSES
Finding.violatesPolicy	POLICY_VIOLATIONS
MD5 of Finding.componentId	UID

Static Code Finding

Source Field Name	SDM Attribute
(common schema)	RECOMMENDATION
app.id	TARGETS
app.profile.customFields[]	<custom field name>
derived	RESULTS
derived from status	STATUS_CATEGORY
Finding.applicationName	APP_NAME
Finding.buildId	BUILD_ID
Finding.categoryName	FLAW_TYPE
Finding.cweDescription	DESCRIPTION
Finding.cweId	TYPE
Finding.exploitability	EXPLOIT_LEVEL
Finding.fileName	SOURCE_FILE
Finding.filePath	SOURCE_FILE_PATH
Finding.foundDate	FIRST_FOUND
Finding.issueId	ISSUE_ID
Finding.lastFoundDate	LAST_FOUND
Finding.mitigationStatus	MITIGATION_STATUS
Finding.module	MODULE
Finding.resolution	RESOLUTION
Finding.resolutionStatus	RESOLUTION_STATUS
Finding.sourceFileLine	LINE_NUMBER
Finding.status	SOURCE_STATUS
MD5 (UID); Cwe.name	NAME
MD5 of app.id + Finding.issueId	UID
normalized Finding.status	STATUS

Static Code Finding Definition

Source Field Name	SDM Attribute
CWE-<Cwe.id>	UID
CWE-<Cwe.id>	CWE_IDS
CWE-<Cwe.id>	WEAKNESSES
Cwe.name (UID fallback)	NAME
Cwe.recommendation	RECOMMENDATION
Cwe.references[]	REFERENCES
Cwe.severity	SOURCE_SEVERITY
derived from severity	SEVERITY_SCORE
Finding.categoryName	CATEGORIES
Finding.cweDescription	DESCRIPTION
Finding.exploitability	EXPLOIT_LEVEL
normalized Cwe.severity	SEVERITY
schema only	CVSS_V2_BASE_SCORE

Dynamic Code Finding

Source Field Name	SDM Attribute
(common schema)	RECOMMENDATION
app.id + site host	TARGETS
app.profile.customFields[]	<custom field name>
Cwe.name	NAME
derived	RESULTS
derived from status	STATUS_CATEGORY
Finding.applicationName	APP_NAME
Finding.buildId	BUILD_ID
Finding.categoryName	FLAW_TYPE
Finding.cweDescription	DESCRIPTION
Finding.cweId	TYPE
Finding.exploitability	EXPLOIT_LEVEL
Finding.fileName	SOURCE_FILE
Finding.filePath	SOURCE_FILE_PATH
Finding.foundDate	FIRST_FOUND
Finding.issueId	ISSUE_ID
Finding.lastFoundDate	LAST_FOUND
Finding.mitigationStatus	MITIGATION_STATUS
Finding.module	MODULE
Finding.resolution	RESOLUTION
Finding.resolutionStatus	RESOLUTION_STATUS
Finding.sourceFileLine	LINE_NUMBER
Finding.status	SOURCE_STATUS
MD5 of app.id + Finding.issueId	UID
normalized Finding.status	STATUS
path of Finding.filename URL	PATH
port of Finding.filename URL	PORT

Dynamic Code Finding Definition

Source Field Name	SDM Attribute
CWE-<Cwe.id>	UID
CWE-<Cwe.id>	CWE_IDS
CWE-<Cwe.id>	WEAKNESSES
Cwe.description	DESCRIPTION
Cwe.name	NAME
Cwe.recommendation	RECOMMENDATION
Cwe.references[]	REFERENCES
Cwe.severity	SOURCE_SEVERITY
derived from severity	SEVERITY_SCORE
Finding.categoryName	CATEGORIES
Finding.exploitability	EXPLOIT_LEVEL
normalized Cwe.severity	SEVERITY

Pentest Finding

Source Field Name	SDM Attribute
(common schema)	RECOMMENDATION
app.id	TARGETS
Cwe.name	NAME
derived	RESULTS
derived from status	STATUS_CATEGORY
Finding.applicationName	APP_NAME
Finding.buildId	BUILD_ID
Finding.categoryName	FLAW_TYPE
Finding.cweDescription	DESCRIPTION
Finding.cweId	TYPE
Finding.exploitability	EXPLOIT_LEVEL
Finding.fileName	SOURCE_FILE
Finding.filePath	SOURCE_FILE_PATH
Finding.foundDate	FIRST_FOUND
Finding.issueId	ISSUE_ID
Finding.lastFoundDate	LAST_FOUND
Finding.mitigationStatus	MITIGATION_STATUS
Finding.module	MODULE
Finding.resolution	RESOLUTION
Finding.resolutionStatus	RESOLUTION_STATUS
Finding.sourceFileLine	LINE_NUMBER
Finding.status	SOURCE_STATUS
MD5 of app.id + Finding.issueId	UID
normalized Finding.status	STATUS

Pentest Finding Definition

Source Field Name	SDM Attribute
CWE-<Cwe.id>	UID
CWE-<Cwe.id>	CWE_IDS
CWE-<Cwe.id>	WEAKNESSES
Cwe.description	DESCRIPTION
Cwe.name	NAME
Cwe.recommendation	RECOMMENDATION
Cwe.references[]	REFERENCES
Cwe.severity	SOURCE_SEVERITY
derived from severity	SEVERITY_SCORE
Finding.categoryName	CATEGORIES
Finding.exploitability	EXPLOIT_LEVEL
normalized Cwe.severity	SEVERITY
schema only	CVSS_V2_BASE_SCORE
schema only	TAGS

Open Source Finding

Source Field Name	SDM Attribute
derived from status	STATUS_CATEGORY
Finding.applicationId, Finding.componentId	TARGETS
Finding.componentFilePath	COMP_FILE_PATH
Finding.componentName	COMP_NAME
Finding.componentName	COMP_FILE_NAME
Finding.componentVersion	COMP_VERSION
Finding.cveId	TYPE
Finding.lastFoundDate	LAST_FOUND
Finding.status	SOURCE_STATUS
MD5 of applicationId + componentId + cveId	UID
normalized Finding.status	STATUS
schema only	LAST_FIXED

Open Source Finding Definition

Source Field Name	SDM Attribute
derived from severity	SEVERITY_SCORE
Finding.cveId	NAME
Finding.cveId	CVE_IDS
Finding.cveId	CVE_RECORDS
Finding.cveId (UNKNOWN fallback)	UID
Finding.cvss2Score	CVSS_V2_BASE_SCORE
Finding.cvss2VectorString	CVSS_V2_AC / AI / AU / AV / CI / E / II / RC / RL / SEVERITY / VECTOR
Finding.cvss3Score	CVSS_V3_BASE_SCORE
Finding.cvss3VectorString	CVSS_V3_AC / AI / AV / CI / E / II / PR / RC / RL / SEVERITY / UI / VECTOR
Finding.cweId (CWE-<id>)	CWE_IDS
Finding.cweId (CWE-<id>)	WEAKNESSES
Finding.description	DESCRIPTION
Finding.severity	SOURCE_SEVERITY
Finding.violatesPolicy	POLICY_VIOLATIONS
normalized Finding.severity	SEVERITY
schema only	RECOMMENDATION

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).

Application

Operation options

This object does not support any operation options.

Delta sync

The connector README does not document sync behavior for this object.

API

• Type: REST endpoint · Endpoint: GET appsec/v1/applications

Site

Operation options

This object does not support any operation options.

Delta sync

The connector README does not document sync behavior for this object.

API

• Type: REST endpoint (asynchronous Reporting API) · Endpoint: POST appsec/v1/analytics/report
• Default filters: report_type=FINDINGS, scan_type=Dynamic Analysis

Component

Operation options

This object does not support any operation options.

Delta sync

The connector README does not document sync behavior for this object.

API

• Type: REST endpoint (asynchronous Reporting API) · Endpoint: POST appsec/v1/analytics/report
• Default filters: report_type=FINDINGS, scan_type=SCA

Static Code Finding

Operation options

This object does not support any operation options.

Delta sync

The connector README does not document sync behavior for this object.

API

• Type: REST endpoint (asynchronous Reporting API) · Endpoint: POST appsec/v1/analytics/report
• Default filters: report_type=FINDINGS, scan_type=Static Analysis

Static Code Finding Definition

Operation options

This object does not support any operation options.

Delta sync

The connector README does not document sync behavior for this object.

API

• Type: REST endpoint (asynchronous Reporting API) · Endpoint: POST appsec/v1/analytics/report
• Default filters: report_type=FINDINGS, scan_type=Static Analysis

Dynamic Code Finding

Operation options

This object does not support any operation options.

Delta sync

The connector README does not document sync behavior for this object.

API

• Type: REST endpoint (asynchronous Reporting API) · Endpoint: POST appsec/v1/analytics/report
• Default filters: report_type=FINDINGS, scan_type=Dynamic Analysis

Dynamic Code Finding Definition

Operation options

This object does not support any operation options.

Delta sync

The connector README does not document sync behavior for this object.

API

• Type: REST endpoint (asynchronous Reporting API) · Endpoint: POST appsec/v1/analytics/report
• Default filters: report_type=FINDINGS, scan_type=Dynamic Analysis

Pentest Finding

Operation options

This object does not support any operation options.

Delta sync

The connector README does not document sync behavior for this object.

API

• Type: REST endpoint (asynchronous Reporting API) · Endpoint: POST appsec/v1/analytics/report
• Default filters: report_type=FINDINGS, scan_type=Manual Analysis

Pentest Finding Definition

Operation options

This object does not support any operation options.

Delta sync

The connector README does not document sync behavior for this object.

API

• Type: REST endpoint (asynchronous Reporting API) · Endpoint: POST appsec/v1/analytics/report
• Default filters: report_type=FINDINGS, scan_type=Manual Analysis

Open Source Finding

Operation options

This object does not support any operation options.

Delta sync

The connector README does not document sync behavior for this object.

API

• Type: REST endpoint (asynchronous Reporting API) · Endpoint: POST appsec/v1/analytics/report
• Default filters: report_type=FINDINGS, scan_type=SCA

Open Source Finding Definition

Operation options

This object does not support any operation options.

Delta sync

The connector README does not document sync behavior for this object.

API

• Type: REST endpoint (asynchronous Reporting API) · Endpoint: POST appsec/v1/analytics/report
• Default filters: report_type=FINDINGS, scan_type=SCA

Changelog

Changelog

The Veracode connector has undergone the following changes:

Version	Description	Migration Steps
3.2.3	Improvements - Added retry with exponential backoff to paginated API requests, improving resilience against transient Veracode API errors and 524 timeouts. - Exposed Maximum retries as a new connector configuration option, allowing administrators to tune the retry count for paginated requests without code changes.	N/A
3.2.2	Improvements Dependency Upgrades - Upgraded internal framework and storage libraries to the latest stable versions for improved reliability, security patches, and alignment with the rest of the connector platform.	N/A
3.2.1	Bug Fixes - Corrected the data types of several finding attributes so they store as their natural types instead of text. Exploitability, Issue ID, and source file line number are now stored as numbers, and CVSS v2/v3 base scores are now stored as decimal numbers. - Reworked CVSS metric extraction to use the shared platform CVSS utility, producing consistent CVSS vector breakdowns across finding models.	• Static Code Finding, Dynamic Code Finding, Pentest Finding, Open Source Finding (and their definitions): Several attributes changed type (Exploitability, Issue ID, line number to numeric; CVSS base scores to decimal). Action: re-sync the connector so the affected findings are re-stored with the corrected data types.
3.2.0	New Features - Added a Parallelism level configuration option that lets administrators control how many requests the connector issues concurrently, allowing sync throughput to be tuned to the Veracode account's rate limits. Improvements - Reworked the finding retrieval and pagination flow against the Veracode REST API for more reliable, complete collection of findings.	N/A
3.1.7	Bug Fixes - Normalized source severity values and application target identifiers to a consistent text representation across all finding models, preventing inconsistent or mistyped values in synced findings.	• Static Code Finding, Dynamic Code Finding, Pentest Finding, Open Source Finding: Source severity and target identifier values are now formatted consistently. Action: re-sync the connector so existing findings adopt the normalized values.
3.1.6	Bug Fixes - Dynamic Code Finding Definition CWE identifiers are now prefixed with CWE-, matching the format used by the other finding models and by downstream weakness mapping. Improvements - Refreshed the connector README with updated configuration, model, and data-mapping documentation.	• Dynamic Code Finding Definition: CWE identifiers changed from a bare number to the CWE- prefixed form. Action: re-sync the connector so the definitions adopt the corrected identifiers.
3.1.5	Improvements - Dynamic Code Findings now relate to both the scanned application and every affected host, giving a more complete view of where each finding applies.	N/A
3.1.4	New Features - Applications and Sites now carry a Last captured timestamp and are automatically retired after 180 days without being seen in a scan, keeping the inventory free of stale assets.	N/A
3.1.3	Improvements - Added caching of CWE and finding-category lookups during a sync and a longer read timeout, reducing redundant API calls and improving reliability on large data sets.	N/A
3.1.2	Improvements - Added client-side API rate limiting that respects Veracode's published request limits, reducing throttling errors during large syncs.	N/A
3.1.1	Bug Fixes - Open Source Finding Definition CWE identifiers are now prefixed with CWE-, matching the standard weakness identifier format used elsewhere.	• Open Source Finding Definition: CWE identifiers changed from a bare number to the CWE- prefixed form. Action: re-sync the connector so the definitions adopt the corrected identifiers.
3.1.0	Improvements - Migrated the connector to the modern Veracode REST APIs, replacing the legacy XML/SOAP integration. This provides faster, more reliable data collection and richer finding detail (CWE, category, and status information) across all supported models.	• All models: The move to the REST APIs changes how unique identifiers are derived for applications, components, and findings. Action: purge the existing connector data and reconnect, then run a full re-sync so objects are re-keyed under the new identifiers.
3.0.12	Improvements - Applications now include Last static scan and Last dynamic scan timestamps, making it easy to see when each application was most recently assessed.	N/A
3.0.11	Improvements - Applications now include the Archer application name, supporting integrations and reporting that align Veracode applications with their corresponding Archer records.	N/A
3.0.10	Bug Fixes - Corrected the data types of several finding attributes so they store as their natural types instead of text: PCI related is now a true/false value, and Issue ID, Build ID, and Line number are now stored as numbers.	• Static Code Finding, Dynamic Code Finding: PCI related, Issue ID, Build ID, and Line number changed type. Action: re-sync the connector so existing findings are re-stored with the corrected data types.
3.0.9	Improvements - Added automatic retry with exponential backoff for API requests and clearer handling of non-retryable errors, improving sync resilience against transient Veracode service issues.	N/A
3.0.8	Improvements - Finding definitions now capture Mitigation type and Mitigation action descriptions, providing more context on how findings have been mitigated or accepted.	N/A
3.0.7	Improvements - Improved how finding descriptions and remediation status are populated, producing cleaner, more complete descriptions and exposing the raw remediation status on findings.	N/A
3.0.6	New Features - Added Open Source Finding and Open Source Finding Definition models, providing dedicated software composition analysis (SCA) findings sourced from Veracode's open-source results. Improvements - Substantially enriched the Component model with additional attributes such as vendor, maximum CVSS score, blacklist and policy-violation flags, file paths, and file checksum.	• Vulnerability: This standalone SCA vulnerability model has been removed and replaced by the new Open Source Finding and Open Source Finding Definition models. Action: purge the existing connector data and re-sync. • Component: The unique identifier changed from the file SHA-1 to Veracode's component ID, and several attribute identifiers were renamed. Action: purge the existing Component data, reconnect, and run a full re-sync.
3.0.5	New Features - Added Pentest Finding and Pentest Finding Definition models, bringing manual penetration-test results from Veracode into the platform.	N/A
3.0.4	Improvements - Internal storage and temporary-directory handling cleanup with no change to synced data.	N/A
3.0.3	Improvements - Moved the connector's local sync storage to RocksDB for better performance and reliability on large data sets.	N/A
3.0.2	Bug Fixes - Finding status values are now normalized to the platform's standard status set, so findings report consistent, comparable statuses.	• Static Code Finding, Dynamic Code Finding: Remediation status values are now normalized. Action: re-sync the connector so existing findings adopt the normalized status values.
3.0.1	Improvements - Findings now capture Mitigation status and Mitigation status description, and accepted mitigations are reflected in the finding's overall status so resolved findings are represented accurately.	• Static Code Finding, Dynamic Code Finding: Finding status now accounts for mitigation state (e.g., accepted mitigations reflected as fixed). Action: re-sync the connector so existing findings adopt the updated status values.
3.0.0	Overview The Veracode connector integrates with Veracode to synchronize applications, scanned web sites, software components, and application security findings (static, dynamic, and software composition analysis) along with their finding definitions. Category: Application Security Models	N/A