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 repository in GitHub, GitLab, Bitbucket, Azure Repos, or Generic Git that you can connect to ZeroPath (Gerrit and CVS are available on self-hosted ZeroPath only).

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 keys, 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.We recommend creating a dedicated SD Elements user named ZeroPath and generating this token as that user. SD Elements attributes every verification note to the token’s owner, so results then show “ZeroPath” as the updater instead of a person’s name (see the FAQ).

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 in the Add a Repository dialog. 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. Use a group or project access token, or a dedicated account PAT, with the api scope. Maintainer is recommended for automatic project webhooks. Connect under Add repository → GitLab. See the GitLab integration guide for lower-role workflows, repository restrictions, and MR pipeline requirements.
Bitbucket. Connect through Add repository → Bitbucket as described in the Quick Start.
Azure Repos. Connect from the Azure tab of the same dialog.

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, default task status mapping)
`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`	— (dashboard only)	List SD Elements projects accessible with the stored credentials
`securityCompass.listTaskStatuses`	`POST /api/v2/securityCompass/listTaskStatuses`	List the task statuses that exist on the connected SD Elements instance (id, slug, name, meaning)
`securityCompass.addProjectMapping`	`POST /api/v2/securityCompass/addProjectMapping`	Link an SD Elements project to a ZeroPath repository, start the initial rule sync, and, when the integration is enabled, push the repository’s latest finished full scan
`securityCompass.updateProjectMapping`	`POST /api/v2/securityCompass/updateProjectMapping`	Set the task status mapping of a mapping’s SD Elements project, shared by every repository mapped to that project, or clear it so the project inherits the integration default
`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.pushLatestScan`	`POST /api/v2/securityCompass/pushLatestScan`	Enqueue a results push of the repository’s latest finished full scan for a mapping
`securityCompass.getMappingAudit`	`POST /api/v2/securityCompass/getMappingAudit`	Retrieve the per-countermeasure coverage breakdown for a mapping
`securityCompass.getCountermeasureDetail`	— (dashboard only)	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/update/remove mappings, sync, push latest scan) requires the admin role. Read operations (get integration, get audit, get linked issues, get sync history) are available to all organization members. Listing SD Elements projects and task statuses (listProjects, listTaskStatuses) also requires the admin role, because both call SD Elements with the stored token on the caller’s behalf.

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.

addProjectMapping and updateProjectMapping accept an optional taskStatusMapping object with up to three keys, pass, partial, and fail. Each value is the slug of an SD Elements task status as returned by listTaskStatuses. A missing key means “leave the task status unchanged”, {} means verification note only, and null means “inherit the integration default”. Every slug must exist on the connected instance and have the meaning DONE or TODO; a slug whose meaning is NA is rejected. The mapping belongs to the SD Elements project and is shared by every repository mapped to it: updateProjectMapping with any of the project’s mapping IDs changes it for all of them, and addProjectMapping without taskStatusMapping keeps the project’s current mapping. Mapping responses carry both the project’s own taskStatusMapping and the effectiveTaskStatusMapping that pushes actually use; every mapping of one project returns the same values. See Task status mapping for what the mapping does.

Each mapping returned by getIntegration carries the result of its last push in lastPushStats, with the keys issuesMapped, countermeasuresUpdated, statusChangesRequested (notes that asked SD Elements for a status change), passCount, partialCount, failCount, notApplicableSkipped (countermeasures left Not Applicable), updateFailures, mappingFailures, unmapped, linksPersisted, repositoriesCombined (how many repositories mapped to the SD Elements project the push’s notes combined), and notInProject (covered countermeasures no longer in the project’s task list, which get no note). The counts describe those combined notes. getSyncHistory returns the audit events security_compass.mapping_update (a task status mapping was changed) and security_compass.push_requested (a push was requested on demand) alongside the sync, push, mapping, integration, and connection-test events.

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. If the new base URL points at a different SD Elements instance, ZeroPath also checks every task status your mappings name (the integration default and each project’s custom mapping) against that instance before saving. A status that does not exist there, or that means Not Applicable, blocks the save with an error naming the mapping; update the mapping or create the status on the new instance, then save again. If the new instance’s status list cannot be read (for example, the new API token is not allowed to list task statuses), mappings that name only the built-in DONE and TODO slugs are still saved, because those statuses exist on every instance; a mapping that names a custom status blocks the save with an error naming that status. 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. When several repositories share a project, ZeroPath combines their results; see Several repositories, one SD Elements project.

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 a full 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. The push usually completes within a few minutes of the scan finishing. The push matches the scan’s findings to the countermeasures they violate (see How findings are matched to countermeasures) and writes one verification note to every supported countermeasure in SD Elements. The note carries one of three outcomes:

Outcome	When ZeroPath reports it
Pass	No finding is mapped to the countermeasure. Reported with high confidence.
Partial	ZeroPath could not finish analyzing one or more findings that may belong to the countermeasure, or the only findings linked to it are secondary matches whose primary countermeasure is elsewhere. Reported with low confidence.
Fail	One or more findings have this countermeasure as their primary match. Reported with high confidence.

When several repositories are mapped to the project, the outcome combines all of them; see Several repositories, one SD Elements project. The note’s Findings list depends on the outcome. A Pass note has an empty list. A Fail note has one entry per violating finding, written as [<repository>] <title> [severity N], up to 50 entries; past that, one last entry carries the count of the remaining findings and points to Reference/Evidence. A repository with findings ZeroPath could not fully analyze, or with findings linked only as secondary matches, adds one entry that names the repository and the count. The note’s Reference/Evidence field holds the readable summary: the outcome, one line per mapped repository with the ID and finish date of the scan it last pushed and its own result, one link per finding in ZeroPath, and a link to all open findings of the mapped repositories. The text is kept under 8,000 characters; when the finding lines do not fit, the list ends with ”… and N more” (the repository lines are always kept). Each push replaces the previous verification result on the countermeasure with one that covers every repository mapped to the project, so SD Elements always shows the latest pushed scan of each. By default the push changes nothing else: the countermeasure’s task status in SD Elements stays as it is. An admin can make an outcome also set the task status; see Task status mapping below. 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.

Task status mapping

A task status mapping tells ZeroPath which SD Elements task status, if any, each verification outcome should set. It is optional. Without one, ZeroPath writes the verification note and leaves the task status alone. You configure it at two levels:

Integration default. In Manage Security Compass integration → Connection Settings, the Default task status mapping block has one dropdown per outcome: When verification is Pass, Partial, and Fail. Each offers Leave task status unchanged plus every task status on your SD Elements instance, shown as name (meaning), for example Complete (DONE). Statuses whose meaning is Not Applicable are listed but cannot be selected. Save it with Save Settings.
Per SD Elements project. On a project’s card, the Task status mapping icon opens an inline editor with two choices: Use integration default (with a summary of what the default currently does) or Custom for this project, which shows the same three dropdowns for this project only. The setting applies to every repository mapped to the project, because ZeroPath writes one combined note per countermeasure for all of them.

A project on the integration default follows it: change the default and every inheriting project changes with it. A project with a custom setting keeps it until you switch it back to the default, also when you add or remove some of its repositories. Removing the project’s last mapping clears it, so mapping the project again starts from the integration default. You can pick any status that already exists on your SD Elements instance with the meaning Complete (DONE) or Incomplete (TODO). That includes the built-in Complete and Incomplete and any custom status your SD Elements administrator has created, for example a ZeroPath-Verified status with the meaning Complete, so that a pass is visibly attributed to a scan rather than to a person. ZeroPath does not create statuses in SD Elements; create the custom status there first (see the SD Elements guide on custom task statuses). Not Applicable is never offered as a target. ZeroPath never changes a countermeasure a person marked Not Applicable. When someone has set a countermeasure to a status whose meaning is Not Applicable, ZeroPath still writes the verification note but sends no status change for that task, whatever the mapping says. The same happens when the countermeasure’s current status cannot be read, for example because it is no longer risk-relevant in the project: without a known status ZeroPath cannot tell whether a person marked it Not Applicable, so it writes the note and leaves the status alone. Whenever the mapping names at least one status, ZeroPath checks it against the live list of statuses before each push. If a configured status no longer exists on the instance (for example, a custom status was deleted or renamed), or its meaning was changed to Not Applicable, the push fails at once with an error on the mapping that names the status; a configuration error is not retried. Pick another status, or restore it in SD Elements, then push again. If the status list itself cannot be read (for example, the API token is not allowed to list task statuses), a mapping that names only the built-in DONE and TODO slugs still proceeds, because those statuses exist on every instance; a mapping that names a custom status fails with an error that names the status. A mapping with no status named never reads the list.

Ask your assistant
Use the dashboard

“Which SD Elements task statuses can ZeroPath set?” lists the statuses on your instance. Then: “Set the task status mapping for SD Elements project <project>: pass to ZeroPath-Verified, fail to Incomplete, leave partial unchanged.” The assistant applies the mapping and confirms it. “Use the integration default for that project” switches it back.

Creating a mapping on an enabled integration pushes the repository’s latest finished full scan to SD Elements as soon as the mapping’s first rule sync succeeds, so you do not need a new scan to see results on a project you just linked. After that, pushes happen automatically whenever a full scan finishes. To push again without a new scan, for example after changing the task status mapping, use Push latest scan:

Ask your assistant
Use the dashboard

“Push the latest scan of <repo> to SD Elements.” The assistant enqueues the push and reports which scan it used, or tells you the repository has no finished full scan yet.

A push is refused while a push of that same scan is still running (wait for it to finish, then try again) and while the integration is disabled (enable it first). A re-push of a scan that was pushed before runs again against the current mapping and the open findings as they are now.

Integrations created before task status mapping existed were given a default of Pass → Complete, Partial → Incomplete, Fail → Incomplete, so their SD Elements projects keep behaving as before on full scans. Two things changed for them: countermeasures a person marked Not Applicable are not overwritten any more, and PR scans do not push any more (only full scans and Push latest scan do). Edit the integration default if you want a different policy.

Several repositories, one SD Elements project

An application’s code often lives in more than one repository while SD Elements tracks it as one project. Map the same SD Elements project ID to each of those repositories (see Map a project to a repository). ZeroPath then reports one result per countermeasure for the whole project instead of one per repository. Each push writes one verification note per countermeasure that lists every mapped repository’s result, not only the result of the repository whose scan just finished. Each finding in the note is prefixed with its repository, for example [acme/api] SQL injection [severity 8.0], and the Reference/Evidence summary has one line per repository with the scan it last pushed and its result. The countermeasure’s outcome combines the repositories:

Outcome	When ZeroPath reports it
Fail	Any mapped repository has a finding whose primary countermeasure is this one.
Pass	Every mapped repository reports the countermeasure clean.
Partial	Anything else: a repository that hasn’t been scanned and pushed since it was mapped, whose first rule sync hasn’t succeeded, whose rule sync doesn’t cover the countermeasure, whose analysis didn’t finish, or whose findings link here only as secondary matches.

A countermeasure therefore passes only once every repository has reported it clean. A repository whose rule sync doesn’t cover a countermeasure keeps it Partial; its line in the note asks you to re-run Sync Rules for that repository. The task status mapping is set per SD Elements project, not per repository: the combined note has one outcome, so it sets one status. With Partial left unchanged (the default), a countermeasure that is already Complete stays Complete while a newly added repository is still pending, and changes when a repository reports Fail. When you add a repository to a project that already has other repositories, ZeroPath automatically re-pushes the combined results so the project’s SD Elements notes reflect all current repositories immediately — you do not need to manually push an existing repository after adding a new one. When you remove one repository’s mapping, ZeroPath pushes the latest scan of a repository still mapped to the project, so the project’s notes stop listing the removed one.

Ask your assistant
Use the dashboard

“Map SD Elements project <ID> to repository <second repo> in ZeroPath.” The project’s notes then combine both repositories automatically.

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 full scan completes, ZeroPath automatically pushes results to your SD Elements project. Each finding is matched to the countermeasure it violates, and every supported countermeasure receives a verification note (Pass, Partial, or Fail) whose Reference/Evidence text links back to the findings in ZeroPath. The task status in SD Elements changes only when an admin has configured a task status mapping for that outcome, and countermeasures a person marked Not Applicable are never changed. 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 verification result the finding counts toward), 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 verification result the finding counts toward, 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 verification result it counts toward) and may also be tagged to secondary countermeasures for traceability.

A countermeasure with no mapped findings receives a Pass verification note. A countermeasure with one or more primary findings receives a Fail note with one line per finding (title and severity) and, in Reference/Evidence, a link back to each finding in ZeroPath. A countermeasure whose candidate findings could not be fully analyzed, or that has only secondary matches, receives a Partial note. Whether a note also changes the SD Elements task status depends on the task status mapping.

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. PR scans never push to SD Elements: their findings cover only the changed files, so a push from one would misreport every other countermeasure. Only full scans push.

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

Work through these in order:

Is a task status mapping configured? By default ZeroPath writes only the verification note and leaves the task status unchanged. Check the integration default and the SD Elements project’s own setting (see Task status mapping). If the verification note is on the countermeasure in SD Elements, the push worked and no status change was requested.
Did the push run? Check the push status on the mapping card under Settings → Integrations → Security Compass. If the push failed, it retries automatically; a persistent failure is 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).
Was the mapping created after the last scan? Creating a mapping on an enabled integration pushes the latest finished full scan automatically. PR scans never push. To re-push, for example after changing the mapping, use Push latest scan on the mapping row.
Is the countermeasure Not Applicable? ZeroPath never changes a countermeasure a person marked Not Applicable. Change its status in SD Elements by hand if it should be verified again.

The push failed because a configured SD Elements status does not exist or means Not Applicable

A task status mapping refers to a status that is no longer on your SD Elements instance (usually a custom status that was deleted or renamed), or to one whose meaning was changed to Not Applicable after it was mapped. ZeroPath checks every configured status against the instance before each push and does not fall back to another status. Because the problem is in the configuration, the push is marked failed at once, without the automatic retries a transient error gets. Point the integration default or the mapping’s custom setting at an existing Complete or Incomplete status (or restore the status in SD Elements), then click Push latest scan.A related error reads “Cannot validate the configured SD Elements status(es) … because <host> did not return its task statuses”. The mapping names a custom status, and the API token could not list the instance’s task statuses, so ZeroPath could not confirm the status exists. Check the token’s permissions in SD Elements, or map the built-in Complete and Incomplete statuses instead, which need no lookup.

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. When several repositories share a project, ZeroPath posts one combined note per countermeasure and reports Pass only when every repository is clean. See Several repositories, one SD Elements project.

Which version control providers are supported?

GitHub, GitLab, Bitbucket, Azure Repos, and Generic Git. Gerrit and CVS are available on self-hosted ZeroPath only.

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, but by default only through verification notes. After each full scan completes, ZeroPath enqueues a results push for each project mapping linked to the repository. Each push runs independently in the background and writes a verification note (Pass, Partial, or Fail) with the finding list and links back to ZeroPath on every supported countermeasure. The countermeasure’s task status is left unchanged unless an admin has mapped the outcome to an SD Elements status: any existing status whose meaning is Complete or Incomplete, built-in or custom (for example “ZeroPath-Verified”), set at the integration level and overridable per project. See Task status mapping. Countermeasures a person marked Not Applicable are never changed, and ZeroPath never sets Not Applicable. If a repository is mapped to multiple SD Elements projects, each project receives its own push. You can check the push status on each mapping under Settings → Integrations → Security Compass.

Why does SD Elements show ZeroPath results as Manual Verification?

SD Elements labels a verification note with the connector that produced it. ZeroPath is not registered with SD Elements as a verification connector, so SD Elements files its notes under Manual Verification and shows the owner of the API token as the updater. The label is cosmetic: the outcome, the finding list, the Reference/Evidence text, and any task status change are all recorded. Only Security Compass can register ZeroPath as a verification connector in SD Elements; until then the label stays. To make the updater read “ZeroPath”, create a dedicated SD Elements user named ZeroPath and generate the API token you give ZeroPath as that user (see Credentials you need).

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, push the latest scan, list SD Elements projects and task statuses) 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.”
“Push the latest scan of <repo> to SD Elements.”

Task status mapping

“Which SD Elements task statuses can ZeroPath set?”
“Set the task status mapping for SD Elements project <project>: pass to ZeroPath-Verified, fail to Incomplete, leave partial unchanged.”
“Use the integration default task status mapping for SD Elements project <project>.”

​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

​Task status mapping

​Several repositories, one SD Elements project

​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

Task status mapping

Several repositories, one SD Elements project

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