Third-party integrations lifecycle administration and automation
Connecting external security tools establishes continuous AppSec visibility. Once onboarded, these integration instances require ongoing administrative maintenance. This post-onboarding reference outlines the available administration channels and explains how to manage instances, rotate API keys and tokens, and understand deletion data retention and purge behavior.
Administration channels matrix (UI, API, and Terraform)
To manage third-party integration instances at scale, administrators can utilize three primary channels: the Tenant UI, the public REST API, and the Terraform Provider. The following matrix maps administrative lifecycle capabilities to their supported channels.
Create integration instance
✓
✓
✓
Manual setups or bulk programmatic deployments
Configure scan types (SAST/SCA)
✓
✓
✓
Scope control based on licensing and tool capabilities
Map projects to repositories
✓
✓
✓
Direct asset linking for unified triage tracking
Enable auto-mapping (future projects)
✓
✓
✓
Zero-touch onboarding for newly created repositories
Rotate credentials / tokens
✓
✓
✓
Scheduled security rotations or emergency revocations
Audit connection and sync health
✓
✓
n/a
Operational monitoring of background polling cycles
Decommission / delete instance
✓
✓
✓
Complete teardown and data purge of retired integrations
UI context-menu actions matrix
All third-party integrations are managed directly from the Settings → Data Sources and Integrations workspace. By searching for your vendor and selecting the integration row, you can right-click to trigger instance-level administrative actions.
The specific actions available on the context menu and the underlying system behavior differ significantly across vendors:
Checkmarx One
Opens the wizard with the credentials step pre-filled Allows modifying scan types (SAST/SCA) and repository mappings
Yes *(Rotate the API key)*
Redirects to the credentials form directly to paste a new key Note: The standard Edit wizard does not support changing credentials, regions, or tenant names
SonarQube / SonarCloud
Directly opens the Select Repositories step to modify project branch mappings
No
The UI edit wizard completely skips the credentials step To rotate credentials, you must use the public REST API PUT endpoint
Snyk
Directly opens the Select Issue Type step (SAST/SCA toggle), then proceeds to repository mapping
No
The UI edit wizard completely skips the credentials step; credentials cannot be modified or updated via the UI
Semgrep
Reopens the onboarding wizard to update active scanner scopes (SAST/SCA) or modify project mappings
No
There is no Rotate API key or credentials action on the context menu Credentials can be updated programmatically
Veracode
Reopens the onboarding wizard to alter application scopes or update repository mappings
No
There is no UI-based credential rotation workflow The UI only supports modifying mapping scopes
Generic AppSec Collector
Opens a simplified form allowing you to update the Collector Name
Yes *(Regenerate credentials)*
Editing the collector name does not invalidate existing keys Regenerated credentials (Token ID and API Token) display only once and must be copied immediately
Instance-level administrative actions
Rotate API keys and tokens
API keys and authentication tokens should be rotated regularly in accordance with your organization's credential-security policies.
Checkmarx and SonarQube: Support a direct Rotate the API key action on the instance's context menu, which opens the configuration wizard directly at the credential step; replace the expired token/key and click Save
Snyk and Semgrep: Rotate by selecting Edit Instance in the console, replacing the Snyk token or Semgrep token, and re-authorizing the connection
Veracode: Edit the instance to input a newly generated Veracode Access Key ID and Secret
Generic 3rd Party AppSec Collector: Access key rotation must be initiated when credentials are lost or compromised; edit the collector instance in Settings, select Regenerate credentials, copy the newly created Token ID and API Token, and update your CI/CD pipeline variables
For programmatic rotations, see Reference A: Programmatic automation and key rotation.
Decommission integrations: the deletion cleanup matrix
When an AppSec integration is retired, deleting the instance halts scheduled polling and removes configuration records. However, Cortex Cloud enforces a distinct, vendor-specific behavioral difference regarding whether previously ingested findings are purged or retained.
Understanding this matrix is vital for compliance auditing, historical reporting, and pipeline engineering.
Checkmarx One
Permanent purge
Deleting the instance permanently purges all ingested findings and Checkmarx-only issues from the Code Weaknesses and Vulnerabilities tables Aggregate issues combining Checkmarx and other scanners (like native tools) persist but strip out Checkmarx-origin logs The Checkmarx column on the AppSec Coverage page resets to Disabled
Semgrep
Permanent purge
All ingested Semgrep SAST and SCA findings are permanently removed from all findings inventory tables Semgrep-only issues are deleted Aggregated issues retain findings from other scanners Policy evaluations and dashboard metrics immediately update to exclude Semgrep telemetry
SonarQube / SonarCloud
Permanent purge
Deleting the integration completely purges all ingested SonarQube findings and derived issues from the Code Weaknesses table
Veracode
Permanent purge
Deleting the instance completely purges all ingested SAST findings and Veracode-only issues from the Code Weaknesses table and repository-level assets
Snyk
Data retention (remains active)
Deliberate retention control: Findings and issues ingested from previous Snyk scans remain active in the system after the integration is deleted The deletion only removes Snyk credentials, scheduled polling configuration, Snyk organization/project mapping records, and CI/CD lifecycle graph entities This ensures historical audit trail integrity
Generic 3rd Party AppSec Collector
Data retention (remains active)
Deleting a custom collector permanently invalidates the associated API credentials and Token ID, disabling future POST uploads However, all findings previously pushed through the collector are retained in the platform and remain fully queryable inside the Code Weaknesses table
Data deletion cleanup details (purge flow)
For integrations that trigger a Permanent Purge upon deletion (Checkmarx, Semgrep, SonarQube, Veracode), the platform automatically executes a cascaded database cleanup job on the polling cycle:
Restore purged data
Because deletion is irreversible, restoring purged findings requires complete reconfiguration of the integration:
Re-add the vendor data source instance under Settings → Data Sources and Integrations.
Provide the credentials and map the target projects/repositories.
Wait for the initial ingestion polling cycle to complete. Initial latency depends on the historical backlog size in your vendor tenant.
Public REST API operations
Use the API workflow for automation, bulk operations, and programmatic credential rotation. For endpoints, schemas, parameters, and error codes, see Reference A: Programmatic automation and key rotation.
GitOps and infrastructure-as-code (IaC)
For modern cloud-native environments, managing security configurations via infrastructure as code (IaC) prevents drift and ensures auditability. The Cortex Terraform provider exposes the cortexcloud_appsec_data_source_instance resource to manage third-party scanner connections declaratively as code. For more information on the Cortex Terraform provider, refer to https://github.com/cortexapps/terraform-provider-cortex.
For Terraform patterns and a declarative resource example, see Reference B: GitOps and infrastructure-as-code (IaC).
Last updated
Was this helpful?