Checkmarx (Checkmarx One)
Let AI connect your sources for you
Skip the manual setup — run this in your project and the wizard auto-detects your databases and APIs and connects them to PostHog.
Connect Checkmarx (Checkmarx One) to PostHog to sync your data into the PostHog data warehouse for analysis and modeling.
Enter your Checkmarx One credentials to automatically pull your application security data into the PostHog Data warehouse.
You can generate an API key in Checkmarx One under Settings → Identity and Access Management → API Keys. The tenant name and region are shown in your Checkmarx One URL (for example, a tenant on https://eu.ast.checkmarx.net is in the EU region).
Configuration
| Option | Type | Required |
|---|---|---|
Tenant name | text | Yes |
Region | select | Yes |
API key | password | Yes |
Linking Checkmarx (Checkmarx One) to PostHog
- Go to the Data pipeline page in PostHog
- Click New source and select Checkmarx (Checkmarx One)
- Fill in the required configuration fields
- Click Next, select the tables you want to sync, and then press Import
Supported tables
| Table | Description | Sync method | Incremental field | Primary key |
|---|---|---|---|---|
projects | A Checkmarx One project, the unit that groups scans of a single code repository or component. | Full refresh | — | — |
applications | A Checkmarx One application, a business-level grouping of related projects. | Full refresh | — | — |
scans | A scan run in Checkmarx One, including its status and the engines (SAST, SCA, KICS, etc.) it executed. | Incremental, Full refresh | createdAt | — |
scan_results | Fetched per scan. Incremental syncs pull data for scans created since the last sync (with a 7-day overlap so late-finishing scans and recent triage changes are picked up) | Incremental, Full refresh | scan_created_at | — |
scan_results_summary | Fetched per scan. Incremental syncs pull data for scans created since the last sync (with a 7-day overlap so late-finishing scans and recent triage changes are picked up) | Incremental, Full refresh | scan_created_at | — |
application_rules | Fetched once per row in the applications table | Full refresh | — | — |
sast_predicates_changelog | Fetched once per row in the projects table | Full refresh | — | — |
result_states | The built-in triage states a finding can be assigned, which decode the state column on scan_results. | Full refresh | — | — |
result_statuses | The statuses a finding can carry relative to the previous scan, which decode the status column on scan_results. | Full refresh | — | — |
result_severities | The severities a finding can carry, which decode the severity column on scan_results. | Full refresh | — | — |
custom_states | A triage state defined by your tenant, in addition to the built-in states in result_states. Includes states that have since been deleted, so findings left in one still resolve to a name. | Full refresh | — | — |