Linking Semgrep as a source
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.
Contents
The Semgrep connector syncs deployments, projects, findings, scan history, and supply chain dependency inventory into the PostHog data warehouse, so you can analyze them alongside your product data.
Prerequisites
Credentials that can read the data you want to sync. PostHog only reads data, so read access is enough.
Adding a data source
- In PostHog, go to the Sources tab of the data pipeline section.
- Click + New source and click Link next to this source.
- Enter your credentials (see Configuration below) and click Next.
- Select the tables you want to sync, choose a sync method and frequency, then click Import.
Once the syncs are complete, you can start querying this data in PostHog.
Enter your Semgrep API token to sync your static analysis data - deployments, projects, code (SAST) and supply chain (SCA) findings, and secrets - .
Create a token in Semgrep AppSec Platform under Settings → Tokens and grant it the Web API scope. The API requires a Semgrep Team or Enterprise plan.
You'll be asked for:
- API token
Sync modes
Each table can be synced in one of several modes, depending on what the source supports:
- Webhook (when available) – the source pushes changes to PostHog in real time. Fastest freshness, lowest ongoing cost, and the only mode that reliably captures updates and deletes.
- Incremental – only new or updated rows are synced on each run, using a cursor field (such as an
updated_attimestamp). Cheaper than a full refresh, but deletes aren't captured. - Append only – new rows are appended using a cursor field; existing rows are never updated. Ideal for immutable, append-only tables like event logs.
- Full refresh – the whole table is reloaded on every sync. Use it when a table has no reliable cursor or when you need deletions reflected.
See sync methods for a full explanation of how each mode works and how to choose between them.
All Semgrep tables are full refresh. Each sync replaces the contents of the table.
Configuration
| Option | Type | Required |
|---|---|---|
API token | password | Yes |
Supported tables
| Table | Description | Sync method | Incremental field | Primary key |
|---|---|---|---|---|
deployments | The Semgrep deployment (organization) the API token can access, with its identifiers and links to related resources. | Full refresh | — | id |
projects | Projects (repositories) that have been scanned by or onboarded to Semgrep in the deployment. Archived repositories are not returned. | Full refresh | — | deployment_id, id |
sast_findings | Code (SAST) findings Semgrep has identified in the deployment, deduplicated across refs/branches to match the counts in the Semgrep UI. | Full refresh | — | deployment_id, id |
sca_findings | Supply chain (SCA) findings Semgrep has identified in the deployment's dependencies, deduplicated across refs/branches to match the counts in the Semgrep UI. | Full refresh | — | deployment_id, id |
secrets | Secrets findings Semgrep has detected in the deployment's repositories, with validation state for supported services. Note: this endpoint returns camelCase field names. | Full refresh | — | deployment_id, id |
scans | Semgrep scans run in the deployment, with their branch, commit, status, duration and finding counts. Semgrep returns the scans of the last 30 days. | Full refresh | — | deployment_id, id |
dependencies | Supply chain dependency inventory: each package version Semgrep found in a lockfile or manifest of the deployment's repositories. Dependencies of archived repositories are not returned. | Full refresh | — | deployment_id, dependency_key |
dependency_repositories | Repositories in the deployment that have supply chain dependencies, with their dependency counts. Archived repositories are not returned. | Full refresh | — | deployment_id, id |
dependency_lockfiles | Lockfiles in each repository with supply chain dependencies, with the number of dependencies each lockfile declares. | Full refresh | — | deployment_id, repository_id, lockfilePath |
Rows in every table except deployments carry extra deployment_id and deployment_slug columns added by PostHog so you can join them back to the deployments table. Rows in the dependency_lockfiles table also carry repository_id and repository_name, and rows in the dependencies table carry a dependency_key column that PostHog computes, because Semgrep gives dependencies no ID.
The scans table holds the last 30 days of scans, which is what Semgrep's API returns. The scans, dependencies, dependency_repositories, and dependency_lockfiles tables use API endpoints that Semgrep marks as experimental.
Troubleshooting
- If the connection fails with an authorization error, the API token is wrong, expired, or has been revoked. Create a new one, then reconnect the source.
- If a table syncs no rows, the credential may not have access to that data. Check its permissions, then reconnect the source.
- If sync fails with a 403 for dependency tables, your plan may not include API access to those resources. The
dependencies,dependency_repositories, anddependency_lockfilestables require the Semgrep Supply Chain product. Deselect the affected table or upgrade your Semgrep plan.
If your sync is failing or data looks wrong, see the Data warehouse troubleshooting guide. If that doesn't help, contact support – we're happy to help.