Security Compass / SD Elements - ZeroPath Documentation

This integration is in beta. Day-to-day operations can be driven through your AI assistant (using ZeroPath’s MCP servers), the ZeroPath API, or the dashboard under Settings → Integrations. The one exception is the initial connection: supply the SD Elements API key through the ZeroPath dashboard, not through an AI assistant.

Overview

This integration connects a ZeroPath scan to an existing SD Elements project. Your SD Elements countermeasures are translated into ZeroPath scanning rules, and ZeroPath scans your repository against them. Three things sit in this relationship:

Your SD Elements project is the source of truth for countermeasures — the security requirements your application is expected to meet.
Your Git repository is what ZeroPath scans.
ZeroPath sits in the middle. It maps the project to the repository, classifies each countermeasure (covered by built-in analysis, covered by an auto-generated rule, or not supported), and scans the code against the resulting rules.

By the end of this page you will have an SD Elements project linked to a repository in ZeroPath, with its countermeasures synced into ZeroPath as scanning rules and scans running against them.

Before you start

Accounts you need

A ZeroPath tenant with admin access. If you don’t have one, talk to your Security Compass contact or email ZeroPath at support@zeropath.com. Provisioning a tenant typically takes about 24 hours.
An SD Elements deployment with API access, and at least one project you want to link.
A Git repository in GitHub, GitLab, Bitbucket, or Azure Repos that you can connect to ZeroPath.

Software you need

An AI assistant that supports MCP. The configuration below covers Claude Code, Cursor, and GitHub Copilot.
For the ZeroPath MCP server you install locally, the uv toolchain — it runs through uvx. The SD Elements MCP server is hosted by your SD Elements instance, so there is nothing to install for it.

Credentials you need

You will collect six values. Keep them somewhere safe while you set things up.

ZeroPath base URL

The host you visit to log in. For ZeroPath’s SaaS this is https://zeropath.com. Enterprise or dedicated tenants may use a different host — use whatever appears in your browser when you are signed in, with no trailing path.

ZeroPath organization ID

The identifier for your ZeroPath organization (it looks like org_0123ABC…). Find it under Settings → General in the dashboard, or ask your AI assistant once the ZeroPath MCP is connected: “What is my ZeroPath organization ID?”

ZeroPath API token (ID + secret)

Go to Settings → API Tokens, click to create a key, name it, choose an expiry, and copy both the token ID and the token secret. The secret is shown only once. Creating a token requires the admin role. See API Tokens for the full reference.

SD Elements base URL

The host you visit to use SD Elements, for example https://<your-sde-instance>.sdelements.com. Host only, no trailing path.

SD Elements API key

Create an API token inside SD Elements (under your user profile / API tokens) and copy it. Follow the SD Elements user guide and API documentation for their token flow rather than the ZeroPath one. Note that you won’t find a ZeroPath entry on SD Elements’ integrations page, and you don’t need one — creating this API key and supplying it to ZeroPath is all the SD Elements side requires.

SD Elements project ID

The numeric ID shown in the project’s URL when you view it in SD Elements (for example, …/projects/8/). You’ll supply one project ID per mapping.

Network access

If your repository or your SD Elements instance sits behind a VPN or in a private network, allow ZeroPath’s outbound IP addresses through:

112.134.81
232.87.32
37.222.237

Self-hosted ZeroPath with an on-prem SD Elements instance. ZeroPath’s SaaS deployment blocks connections to private or internal IP addresses as a security measure. If you are running a self-hosted ZeroPath instance that needs to reach an SD Elements deployment on a private network, set the SDE_ALLOW_PRIVATE_HOSTS environment variable to true on your ZeroPath deployment. This lifts the private-address restriction for SD Elements requests only, matching how self-hosted deployments handle other on-prem integrations. Contact support@zeropath.com if you need help with this configuration.

Provision your ZeroPath tenant

If you don’t have a tenant yet, request one through your Security Compass contact or at support@zeropath.com. Use one organization per proof-of-concept; separate customers get separate tenants for isolation.

Ask ZeroPath to enable Security Compass

The Security Compass integration is switched on per environment by ZeroPath. Once your tenant exists, ask your ZeroPath contact — or email support@zeropath.com — to enable the Security Compass integration for your organization. Until it’s enabled, the Security Compass option won’t appear under Settings → Integrations.

Add teammates

Once you’re in, you can add teammates. Roles are Admin, Member, and Viewer — see Teams & Permissions for what each can do.

Ask your assistant
Use the dashboard

“Invite alice@example.com as an admin to my ZeroPath organization.” The assistant adds the member and confirms the role it assigned.

Connect a repository

ZeroPath scans a Git repository, so connect one before you map it. Pick the provider you use; the full walkthrough for each lives in the Quick Start.

Ask your assistant
Use the dashboard

“Show me the GitHub installations available to my organization,” then “Connect the repository at https://github.com/acme/web to ZeroPath.” The assistant lists what it can reach and adds the repository you name.

Provider-specific notes:

GitHub. Use the Install GitHub App button on the Add Repositories page. The GitHub App requests read access to code plus read/write on checks and pull requests so ZeroPath can post results and open fix PRs.
GitLab. Create a group or project access token with the api scope and the Maintainer role, then set it up under Add Repositories → GitLab. See the Quick Start.
Bitbucket. Connect through Add Repositories → Bitbucket as described in the Quick Start.
Azure Repos. Connect from the same Add Repositories page.

You can also connect a repository by direct URL with an access token, which is how repositories are wired up in many SD Elements pilots. Token connections scan fine but don’t get the full set of GitHub App features (automatic PR checks, fix PRs). Use the GitHub App when you want those.

If the repository is behind a VPN, apply the same network allowlisting noted in Before you start.

Set up your SD Elements project

You want to finish this section with an SD Elements project whose survey is complete and whose countermeasures are populated, ready to map. ZeroPath doesn’t change how you build a project in SD Elements — create the project, complete its survey, and review the resulting countermeasures using the SD Elements user guide. A typical project (for example, a Django or .NET web app profile) ends up with a few hundred countermeasures spread across phases like Requirements and Development.

Ask your assistant
Use the SD Elements UI

With the SD Elements MCP connected you can explore without leaving chat: “List my SD Elements business units,” “Find the project named ‘Payment Service’ in SD Elements,” or “Show the countermeasures for SD Elements project Payment Service.” The assistant returns the matching business units, the project (with its numeric ID), and the countermeasure list with titles, phases, and status.

Install the MCP servers

Two MCP servers drive the assistant side of this integration:

The ZeroPath MCP — github.com/ZeroPathAI/zeropath-mcp-server, installed locally. It covers the general ZeroPath tools (read repositories, run scans, inspect issues and rules) and the Security Compass tools (mapping projects to repositories, syncing rules, reading the audit) in one server. Its install steps are also mirrored in MCP Installation. It uses the four ZeroPath values you collected: base URL, organization ID, API token ID, and API token secret.
The SD Elements MCP — hosted at https://<your-sde-instance>.sdelements.com/mcp, authenticating with your SD Elements API key in the sde-api-key header. There’s nothing to install for it.

The three subsections below give a copy-paste configuration for both servers together, in each client’s own format.

Claude Code

Claude Code’s recommended path is the claude mcp add command (see the Claude Code MCP docs). Run these two commands, substituting your values:

# ZeroPath MCP (local)
claude mcp add --scope user zeropath \
  --env ZEROPATH_BASE_URL=https://zeropath.com \
  --env ZEROPATH_TOKEN_ID=<your-token-id> \
  --env ZEROPATH_TOKEN_SECRET=<your-token-secret> \
  --env ZEROPATH_ORG_ID=<your-org-id> \
  -- uvx --from git+https://github.com/ZeroPathAI/zeropath-mcp-server zeropath-mcp-server

# SD Elements MCP (remote HTTP)
claude mcp add --scope user --transport http sde-mcp-server \
  https://<your-sde-instance>.sdelements.com/mcp \
  --header "sde-api-key: <your-sde-api-key>"

All options come before the server name, and the -- separates the name from the command that launches the server. If you prefer a file, the same two servers go under the mcpServers key in .mcp.json.

Cursor

Cursor reads MCP servers from ~/.cursor/mcp.json (global) or .cursor/mcp.json (per project), under the mcpServers key (see the Cursor MCP docs):

{
  "mcpServers": {
    "zeropath": {
      "command": "uvx",
      "args": ["--from", "git+https://github.com/ZeroPathAI/zeropath-mcp-server", "zeropath-mcp-server"],
      "env": {
        "ZEROPATH_BASE_URL": "https://zeropath.com",
        "ZEROPATH_TOKEN_ID": "<your-token-id>",
        "ZEROPATH_TOKEN_SECRET": "<your-token-secret>",
        "ZEROPATH_ORG_ID": "<your-org-id>"
      }
    },
    "sde-mcp-server": {
      "url": "https://<your-sde-instance>.sdelements.com/mcp",
      "headers": {
        "sde-api-key": "<your-sde-api-key>"
      }
    }
  }
}

GitHub Copilot

GitHub Copilot in VS Code reads MCP servers from .vscode/mcp.json (per workspace) or your user settings.json, under the servers key (see GitHub’s MCP docs). The SD Elements block here matches the configuration your SD Elements instance hands you:

{
  "servers": {
    "zeropath": {
      "command": "uvx",
      "args": ["--from", "git+https://github.com/ZeroPathAI/zeropath-mcp-server", "zeropath-mcp-server"],
      "env": {
        "ZEROPATH_BASE_URL": "https://zeropath.com",
        "ZEROPATH_TOKEN_ID": "<your-token-id>",
        "ZEROPATH_TOKEN_SECRET": "<your-token-secret>",
        "ZEROPATH_ORG_ID": "<your-org-id>"
      }
    },
    "sde-mcp-server": {
      "url": "https://<your-sde-instance>.sdelements.com/mcp",
      "headers": {
        "sde-api-key": "<your-sde-api-key>"
      }
    }
  }
}

Sanity check. Once a client is configured, ask your assistant: “Show me the Security Compass integration currently configured for my ZeroPath organization.” You’ll either see the existing integration and its mappings, or a confirmation that none is set up yet.

API access

All Security Compass integration management operations are available through the ZeroPath API in addition to the dashboard and MCP server. Authenticate with your API token (see API Tokens) and use the following operations:

Operation	HTTP endpoint	What it does
`securityCompass.getIntegration`	`POST /api/v2/securityCompass/getIntegration`	Fetch the integration and all project mappings for an organization
`securityCompass.upsertIntegration`	— (dashboard only)	Create or update the SD Elements connection (base URL, API token, enabled state)
`securityCompass.deleteIntegration`	— (dashboard only)	Remove the entire integration and all its project mappings
`securityCompass.testConnection`	`POST /api/v2/securityCompass/testConnection`	Validate the stored credentials against a specific SD Elements project
`securityCompass.listProjects`	—	List SD Elements projects accessible with the stored credentials
`securityCompass.addProjectMapping`	`POST /api/v2/securityCompass/addProjectMapping`	Link an SD Elements project to a ZeroPath repository and start the initial rule sync
`securityCompass.removeProjectMapping`	`POST /api/v2/securityCompass/removeProjectMapping`	Unlink a project mapping (and clean up generated rules when no other mappings remain for the repository)
`securityCompass.syncRules`	`POST /api/v2/securityCompass/syncRules`	Manually trigger a countermeasure-to-rule sync for a mapping
`securityCompass.getMappingAudit`	`POST /api/v2/securityCompass/getMappingAudit`	Retrieve the per-countermeasure coverage breakdown for a mapping
`securityCompass.getCountermeasureDetail`	—	Fetch full detail for a single countermeasure (description, how-tos, CWEs, linked issues)
`securityCompass.getLinkedIssues`	`POST /api/v2/securityCompass/getLinkedIssues`	List open ZeroPath findings linked to a specific countermeasure
`securityCompass.getSyncHistory`	`POST /api/v2/securityCompass/getSyncHistory`	Retrieve the Security Compass audit log for an organization

The operations with an HTTP endpoint listed are available both through the MCP server and as direct HTTP POST requests to /api/v2/securityCompass/{procedure}. All requests must include your API token headers (see API Tokens). The upsertIntegration and deleteIntegration operations (SD Elements credentials) are only available through the dashboard — API token callers cannot supply or rotate SD Elements credentials. The testConnection endpoint uses the credentials already saved in the dashboard; it does not accept an SD Elements API token directly. Managing the integration (upsert, delete, add/remove mappings, sync) requires the admin role. Read operations (get integration, get audit, get linked issues, get sync history) are available to all organization members.

When updating the SD Elements base URL via the API, you must supply an sdeApiToken if the new URL points to a different SD Elements origin than the one currently stored. This prevents the stored token from being forwarded to a different host.

End-to-end workflow

This is the operating manual. Each step has an assistant prompt and, where one exists, the matching dashboard path. The dashboard side lives in Settings → Integrations: the Security Compass card shows the connection, its mappings, and each mapping’s sync status; its gear icon opens Manage Security Compass integration, where the mapping actions live.

1. Connect your SD Elements instance

One-time per organization, and done in the ZeroPath dashboard. Get your API key from the SD Elements dashboard (see Credentials you need), then go to Settings → Integrations → Add Integration → Security Compass. In the dialog, enter the SD Elements Base URL and API Token, leave Enable Integration on, and click Create Integration.

Two things to know about this step:

Supply the API key only through the ZeroPath dashboard. Don’t paste it into an AI assistant — keep credentials out of chat.
There is nothing to configure on the SD Elements side. You won’t find a ZeroPath integration on SD Elements’ integrations page, and you don’t need one; supplying the API key here is enough.

2. Test the connection

Confirm the credentials work and ZeroPath can see countermeasures on a project.

Ask your assistant
Use the dashboard

“Test my Security Compass connection against project <SDE project ID>.” The assistant reports success and how many countermeasures it sees on that project.

3. Update credentials

When you rotate the SD Elements API key (or point at a different instance), re-save the connection. This overwrites the stored credentials and base URL but leaves your existing project mappings intact. Like the initial connection, this is done in the dashboard — get the new key from the SD Elements dashboard rather than handing it to an AI assistant. In Manage Security Compass integration → Connection Settings, update the Base URL or API Token and click Save Settings. The API Token field is optional when editing: leaving it blank keeps your existing token, and the field placeholder confirms this. Enter a new value only when rotating the key.

4. Map a project to a repository

A mapping links one SD Elements project to one repository. You can map several projects to one repository, and one project to several repositories.

Ask your assistant
Use the dashboard

“Map SD Elements project <ID> to repository <repo name> in ZeroPath.” The assistant creates the mapping and confirms it.

5. Sync rules from countermeasures

Syncing fetches the project’s countermeasures, classifies each one, and creates ZeroPath rules where they’re needed. The work runs in the background — it can take a few minutes for a large project. The mapping shows a running status while it fetches countermeasures, classifies coverage, and creates rules, then flips to a success summary when it finishes. A countermeasure that can’t be classified is skipped rather than failing the whole run. Subsequent syncs are faster: ZeroPath’s global catalog of Built-in countermeasures is checked first, and classifications that haven’t changed are reused without re-running the AI pipeline. If a sync encounters a transient error it automatically retries once before surfacing a failure — during the retry the mapping row shows “first attempt failed — retrying…” so you can see the recovery in progress. If the retry also fails, the mapping shows the error; you can expand View last sync error on the row for the full error message.

Ask your assistant
Use the dashboard

“Sync rules for the <project> to <repo> mapping.” The assistant starts the sync (it runs in the background) and, once it finishes, reports a summary along the lines of: 356 countermeasures — 274 covered by built-in analysis, a set covered by newly created natural-language rules, and 51 not currently supported.

Only one sync runs per mapping at a time. If you ask for another while one is in progress, ZeroPath tells you a sync is already running rather than starting a second one.

6. Review the mapping audit

The audit is the per-countermeasure breakdown: for each task, whether ZeroPath covers it with built-in analysis, covers it with an auto-generated natural-language rule, or doesn’t yet support it. This is the artifact most security reviewers care about.

Ask your assistant
Use the dashboard

“Show me the mapping audit for project <ID>.” The assistant lists each countermeasure with its coverage category.

7. Trigger a scan

Ask your assistant
Use the dashboard

“Run a full scan on <repo>.” The assistant starts the scan and confirms it’s queued.

8. Check sync and scan history

Ask your assistant
Use the dashboard

“Show recent Security Compass sync events” and “Show recent scans on <repo>.” The assistant returns the sync log (started, fetched, completed entries with counts) and the scan history.

9. Review findings and SD Elements results

After the scan completes, ZeroPath automatically enqueues a results push to SD Elements for each project mapping linked to that repository. Each mapping’s push runs independently in the background — if a repository is mapped to multiple SD Elements projects, each project receives its own push, and a failure on one does not affect the others. Each supported countermeasure is updated with a DONE or TODO status and a verification note; findings are matched to their most relevant countermeasures using CWE overlap and AI-assisted mapping. The push usually completes within a few minutes of the scan finishing. You can review findings in ZeroPath and in SD Elements:

Ask your assistant
Use the dashboard

“Summarize findings from the latest scan of <repo>.” or “Show recent Security Compass sync events” to check the push status.

Run the whole pipeline at once

You don’t have to do the steps one at a time. With the ZeroPath MCP and the SD Elements MCP connected, a single prompt can carry the whole pipeline:

“Set up <repo> with SD Elements project <ID>: create the mapping, sync rules, run the audit, kick off a full scan, and summarize what came back.”

The assistant creates the mapping, runs the sync (and reports the SAST / natural-language-rule / unsupported breakdown), surfaces the audit, starts the scan, summarizes the findings once the scan finishes, and reports when ZeroPath has pushed the results back to SD Elements.

Security Compass tab on the repository page

Once a repository has a Security Compass mapping and at least one successful rule sync, a Security Compass tab appears on that repository’s page. The tab gives you a full interactive view of the mapping’s countermeasures without leaving the repository context.

Countermeasure table

The table lists every countermeasure from the mapping’s last sync with the following columns:

Column	Description
Task ID	The SD Elements task identifier
Task Title	The countermeasure name
Coverage	How ZeroPath covers the task — see coverage types below
Issues	The number of ZeroPath findings linked to this countermeasure
Phase	The SD Elements development phase (e.g., Requirements, Development)
Priority	The task priority from SD Elements
Risk	The risk rating from SD Elements
NL Rule Name	Name of the auto-generated natural-language rule, when one was created

The header shows when the mapping was last synced and how many countermeasures are supported (out of the total). Click Download CSV to export the complete audit — the same file the export icon on the integration settings card produces.

Coverage types

Each countermeasure displays a color-coded coverage badge:

Badge	Meaning
SAST (green)	Covered by ZeroPath’s built-in analysis
NL Rule (indigo)	Covered by an auto-generated natural-language rule
Unsupported (gray)	Cannot be enforced through static analysis. Hover the badge to see why.
Eval Error (amber)	Coverage could not be determined during the last sync

Filtering, sorting, and search

You can narrow the table using:

Search — matches task ID, title, coverage, phase, natural-language rule name, and reject reason.
Coverage filter — select one or more coverage types to show.
Phase, Priority, Risk filters — appear when the mapping has tasks with those values; options are derived from the data actually present.

Every column header is sortable. By default, rows are ordered by coverage (SAST first, then NL Rules, then Unsupported, then Eval Errors), with higher-priority tasks surfaced first within each coverage group.

Countermeasure detail panel

Clicking any row opens a slide-over panel with the full detail for that countermeasure:

Header — coverage badge, priority, risk, and phase at a glance, plus the full task title and task ID.
Linked issues — ZeroPath findings that have been matched to this countermeasure, each showing status and match method, with a link to the issue detail page.
Description — the full countermeasure text from SD Elements.
Natural-language rule — the rule name and text when a rule was generated.
Why unsupported — the reason the task was skipped, when applicable.
How-tos — reference links and guidance from the SD Elements catalog.
Compliance — any compliance amendments associated with the countermeasure.
Classification — CWE identifiers and categories.

Press Escape or click outside the panel to close it.

Repository list badge

In the repository list, any repository that has a Security Compass mapping displays a small Security Compass icon next to its name. This lets you identify mapped repositories at a glance without opening each one.

Repository header badge

When you open the detail page for a repository that is linked to a Security Compass project, a small SD Elements logo badge appears in the repository header alongside the repository name. The badge tooltip shows the integration name and the date of the last successful rule sync.

Issues list badge

On the Issues page, findings from a repository that has a Security Compass mapping display a Security Compass icon directly in the issue title cell. The icon appears inline next to the issue title so you can identify which findings are associated with Security Compass–linked repositories at a glance, without opening each issue.

Security Compass tab on the Rules page

When the Security Compass integration is enabled for your organization, a Security Compass tab appears on the Rules page. The tab lists all rules that were automatically generated from SD Elements countermeasures across your mapped repositories. Within the Custom Rules tab, auto-generated rules display a badge next to their name so you can distinguish them from rules you created manually. See Custom Rules for more detail.

How ZeroPath turns countermeasures into rules

Whole-repository analysis

ZeroPath analyzes the whole repository. It identifies the applications inside it, maps sources, sinks, and the relationships among them, and builds a threat model per application. Traditional flaws are evaluated source-to-sink; higher-level controls are evaluated agentically against that threat model. For the deeper picture, see the SAST Overview and Custom Rules. ZeroPath maintains a global catalog of Built-in countermeasure classifications that is refreshed automatically on a weekly basis. When you sync a mapping, ZeroPath first checks this catalog for a cached classification before running the AI classification pipeline — so syncs on projects with mostly Built-in countermeasures are significantly faster than the initial sync. When you sync a mapping, each countermeasure lands in one of three buckets:

Built-in coverage — ZeroPath’s standard analysis already detects this class of issue (for example, “Validate all forms of input” or “Set HttpOnly flag on session cookies”).
Natural-language rule — the countermeasure maps to a policy ZeroPath enforces through an auto-generated custom rule scoped to the mapped repository (for example, an audit-logging or password-policy requirement).
Not supported — the countermeasure isn’t related to code development, or it can’t be implemented or enforced through static analysis (for example, “Verify that penetration testing has been performed”). These are skipped during sync.

Where mapped findings show up

After a scan completes, ZeroPath automatically pushes results to your SD Elements project. Each finding is matched to the countermeasure it violates, and SD Elements is updated with the status and a verification note that includes a link back to the finding in ZeroPath. Countermeasures with no violations are marked DONE; those with one or more findings are marked TODO. You can also review findings in ZeroPath’s standard Issues view, filtered by the repository, and use the mapping audit (step 6) to see the per-countermeasure coverage breakdown. When you open an individual issue in ZeroPath, the issue detail includes a Security Compass section listing every SD Elements countermeasure the finding has been matched to. For each linked countermeasure you can see the task title, a direct link to the task in SD Elements, whether it is the primary countermeasure (the one whose status was updated in SD Elements), and — for AI-assisted matches — the model’s rationale for the match. You can also retrieve this data via the API: the securityCompassCountermeasures field on the issue detail response contains the same information. The issue detail view also shows an expandable Security Compass countermeasures preview panel. The panel header displays the primary countermeasure title (or task ID when no title is available) and a count of any additional linked countermeasures. Expanding the panel loads the full detail for each countermeasure — description, development phase, priority, risk rating, and CWE tags — lazily on first expand, so the issue opens immediately without waiting for the detail fetch. Each countermeasure entry shows:

Its task ID and title.
A Primary badge when it is the countermeasure whose SD Elements status was updated, and there is more than one linked countermeasure.
The match method (rule-based or AI-assisted).
The model’s rationale for the match, when one is available.
A direct View in SD Elements link to the task.

If a detail fails to load you can retry it individually without re-expanding the whole panel. A Security Compass icon badge also appears next to the score badges in the issue detail header whenever the issue’s repository is linked to Security Compass, giving you an at-a-glance signal before you expand the countermeasures panel.

What that means for coverage

Out of the box, ZeroPath covers a large share of a project’s countermeasures directly, with much of the remainder covered by auto-generated rules and a smaller tail that a code scan can’t verify. The audit (step 6) is the per-countermeasure record of which is which for your project.

How findings are matched to countermeasures

After a scan, ZeroPath maps each finding to the countermeasure it most directly violates. Two matching strategies run together:

Rule-based matching — findings produced by a ZeroPath rule that was generated from a countermeasure are matched deterministically to that countermeasure with no AI call.
AI-assisted matching — all other findings are matched using an AI model, with candidates pre-filtered by CWE overlap to improve precision. Each finding gets one primary countermeasure (the one whose SD Elements status is updated) and may also be tagged to secondary countermeasures for traceability.

A countermeasure with no mapped findings is marked DONE in SD Elements. A countermeasure with one or more mapped findings is marked TODO, with a note listing the finding titles, severities, and links back to ZeroPath.

PR vs. full-branch scanning

Full scans

The default mode. Full scans run on a schedule (commonly nightly) and build the repository cache that ZeroPath reuses across scan types. Configure the schedule in Scanner Settings.

PR scans

Enabled per repository, PR scans check each pull request using the cache built by full scans. Most teams start with full scans on main, get comfortable, then turn on PR scans. See PR Scanning.

Ask your assistant
Use the dashboard

“Turn on PR scanning for <repo>.”

Security and trust

ZeroPath stores integration credentials and vulnerability records in an encrypted, per-tenant database. Source code is cloned only at scan time, inside a container, and removed when the scan finishes. ZeroPath runs external penetration tests and maintains a vulnerability disclosure program. SOC 2 reporting is in progress; a letter of intent is available on request. For the current compliance status and to request reports, see the resources below.

ZeroPath Trust Center: zeropath.com/trust-center
ZeroPath Trust Portal: zeropath.trust.site

Troubleshooting

Rule sync fails fetching SD Elements tasks (404)

The SD Elements project ID in the mapping no longer exists in the connected SD Elements tenant. Confirm the project exists in SD Elements and re-add the mapping with the correct ID.

API key not visible in the dashboard

Creating a ZeroPath API token requires the admin role. If you have the Viewer or Member role, ask an org admin to create the token for you. See API Tokens.

A repository behind a VPN can't be scanned

ZeroPath’s outbound traffic needs to reach the repository. Allowlist ZeroPath’s outbound IPs (see Network access).

The integration is pointed at the wrong SD Elements instance

If you run more than one SD Elements deployment, update the connection’s base URL and API key (step 3) to point at the right one. Existing mappings are preserved.

"Save connection settings (Base URL) first"

In the dashboard, save the connection settings (base URL and token) before you test a project or add a mapping. Test Connection runs against the saved base URL.

Rule sync says it's already running

Only one sync runs per mapping at a time. Wait for the in-progress run to finish, then start it again.

Rule sync failed — how do I see the error detail?

In Manage Security Compass integration, find the mapping row whose sync shows a red failed status. Click View last sync error to expand the full error message. ZeroPath automatically retries once after a first failure before surfacing the error, so a displayed failure means both attempts were unsuccessful. Fix the underlying issue (for example, an expired API key or a deleted SD Elements project), then click the Sync icon to start a fresh run.

The mapping audit is empty

The audit is available only after a successful sync. Run sync for the mapping first, then view or export the audit.

SD Elements countermeasure statuses are not updating after a scan

Results are pushed to SD Elements in the background after the scan finishes. Check the push status on the mapping card under Settings → Integrations → Security Compass. If the push failed, it retries automatically; a persistent failure will be shown as an error on the mapping. Make sure the integration is still enabled and the SD Elements API key has not been rotated — if it has, update it under step 3.

Results were pushed to SD Elements before the first rule sync finished

ZeroPath waits for a successful rule sync before pushing results for a scan. If a scan finished before the first sync completed, the push is deferred automatically and retried once the sync succeeds — no action is needed.

FAQ

Can one SD Elements project map to multiple repositories?

Yes — and multiple projects can map to one repository.

Which version control providers are supported?

GitHub, GitLab, Bitbucket, and Azure Repos.

Can ZeroPath run on-prem alongside an on-prem SD Elements?

The recommended setup today is SaaS. For on-prem requirements, talk to ZeroPath support.

Is there a ZeroPath app to install inside SD Elements?

No. There is no ZeroPath entry on SD Elements’ integrations page, and none is needed. Create an SD Elements API key and supply it to ZeroPath (in the ZeroPath dashboard, under Settings → Integrations) — that completes the connection.

Do I set up the SD Elements connection once, or per repository?

Once per organization. You save one connection (base URL and API key), then add a mapping for each SD Elements project and repository pair.

Which countermeasures does ZeroPath sync?

The countermeasures SD Elements marks relevant for the project — the ones produced by completing the project survey. Finish the survey before you sync so the full set is available.

Where do the generated rules live, and can I edit them?

Each rule ZeroPath creates from a countermeasure is a standard custom rule scoped to the mapped repository. View, edit, or disable them on the Rules page or through your assistant, the same as any other custom rule.

Does ZeroPath change anything in SD Elements?

Yes. After each scan completes, ZeroPath automatically enqueues a results push for each project mapping linked to the repository. Each push runs independently in the background: each supported countermeasure is marked DONE (no violation found) or TODO (one or more findings mapped to it), and a verification note with details and links is added to the countermeasure. If a repository is mapped to multiple SD Elements projects, each project receives its own independent push. You can check the push status on each mapping under Settings → Integrations → Security Compass.

My countermeasures changed in SD Elements. How do I update ZeroPath?

Re-run the sync for the mapping. ZeroPath reads countermeasures at sync time, so a fresh sync picks up additions, edits, and removals.

Do the MCP servers need to stay running for scans?

No. Scans run on ZeroPath’s infrastructure, on a schedule or on demand. The MCP servers are only how you drive setup and queries from your assistant.

Who can configure the integration and create mappings?

Managing the connection and mappings (create, update, delete, add/remove project mappings, trigger syncs) requires the admin role, whether you act through the dashboard, the MCP server, or the API. Read operations such as viewing the audit or linked issues are available to all members. Creating a ZeroPath API token also requires the admin role. See Teams & Permissions.

Assistant prompts you’ll use most

Setup

“Show me the Security Compass integration configured for my ZeroPath organization.”
“Test my Security Compass connection against project <SDE project ID>.”

Mapping and sync

“Map SD Elements project <ID> to repository <repo> in ZeroPath.”
“Sync rules for the <project> to <repo> mapping.”
“Show me the mapping audit for project <ID>.”

Scanning and results

“Run a full scan on <repo>.”
“Show recent Security Compass sync events.”
“Summarize findings from the latest scan of <repo>.”
“Show the Security Compass push status for the <project> to <repo> mapping.”

​Overview

​Before you start

​Accounts you need

​Software you need

​Credentials you need

​Network access

​Provision your ZeroPath tenant

​Ask ZeroPath to enable Security Compass

​Add teammates

​Connect a repository

​Set up your SD Elements project

​Install the MCP servers

​Claude Code

​Cursor

​GitHub Copilot

​API access

​End-to-end workflow

​1. Connect your SD Elements instance

​2. Test the connection

​3. Update credentials

​4. Map a project to a repository

​5. Sync rules from countermeasures

​6. Review the mapping audit

​7. Trigger a scan

​8. Check sync and scan history

​9. Review findings and SD Elements results

​Run the whole pipeline at once

​Security Compass tab on the repository page

​Countermeasure table

​Coverage types

​Filtering, sorting, and search

​Countermeasure detail panel

​Repository list badge

​Repository header badge

​Issues list badge

​Security Compass tab on the Rules page

​How ZeroPath turns countermeasures into rules

​Whole-repository analysis

​Where mapped findings show up

​What that means for coverage

​How findings are matched to countermeasures

​PR vs. full-branch scanning

​Full scans

​PR scans

​Security and trust

​Troubleshooting

​FAQ

​Assistant prompts you’ll use most

Overview

Before you start

Accounts you need

Software you need

Credentials you need

Network access

Provision your ZeroPath tenant

Ask ZeroPath to enable Security Compass

Add teammates

Connect a repository

Set up your SD Elements project

Install the MCP servers

Claude Code

Cursor

GitHub Copilot

API access

End-to-end workflow

1. Connect your SD Elements instance

2. Test the connection

3. Update credentials

4. Map a project to a repository

5. Sync rules from countermeasures

6. Review the mapping audit

7. Trigger a scan

8. Check sync and scan history

9. Review findings and SD Elements results

Run the whole pipeline at once

Security Compass tab on the repository page

Countermeasure table

Coverage types

Filtering, sorting, and search

Countermeasure detail panel

Repository list badge

Repository header badge

Issues list badge

Security Compass tab on the Rules page

How ZeroPath turns countermeasures into rules

Whole-repository analysis

Where mapped findings show up

What that means for coverage

How findings are matched to countermeasures

PR vs. full-branch scanning

Full scans

PR scans

Security and trust

Troubleshooting

FAQ

Assistant prompts you’ll use most