> ## Documentation Index
> Fetch the complete documentation index at: https://docs.flashduty.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Semgrep alert integration

> Send new Semgrep AppSec Platform findings and supply chain incidents to Flashduty On-call through a webhook.

Use the Semgrep AppSec Platform webhook integration to send newly detected code issues (SAST, SCA, secrets) and supply chain incidents to Flashduty On-call. Each finding becomes one Flashduty alert, and each supply chain incident that affects your projects becomes one Flashduty alert.

<div className="hide">
  ## In Flashduty On-call

  ***

  You can get the integration push URL in either of two ways.

  ### Use a dedicated integration

  1. In the Flashduty console, select **Channel** and open a channel
  2. Select **Configuration** → **Integrations** → **Private integration**, then click **Add an integration**
  3. Select **Semgrep** and click **Save**
  4. Open the integration card and copy the **push URL**

  ### Use a shared integration

  1. In the Flashduty console, go to **Integration Center → Alert Events**
  2. Select **Semgrep** and enter an integration name
  3. Configure the default route and choose a channel; you can add more rules under **Routes** after creation
  4. Click **Save** and copy the generated **push URL**
</div>

## In Semgrep

***

You need admin access to Semgrep AppSec Platform.

<Steps>
  <Step title="Create a webhook integration">
    1. In Semgrep AppSec Platform, click **Settings → Integrations → Add integration** and select **Webhook**
    2. Enter an integration name in **Name**
    3. Paste the full Flashduty push URL, including `integration_key`, into **Webhook URL**
    4. **Signature Secret** is optional (at least 15 characters). If you set one, Semgrep sends an `X-Semgrep-Signature-256` header with every delivery; Flashduty does not verify it and authenticates with the `integration_key` in the URL
    5. Click **Subscribe**
  </Step>

  <Step title="Turn notifications on in a policy">
    Create or edit a policy in [Unified Policies](https://docs.semgrep.dev/semgrep-appsec-platform/unified-policies/get-started#create-a-remediation-policy), click **Add action → Call a webhook**, and select the webhook integration. The policy's filters (severity, confidence, projects) decide which findings are sent to Flashduty. Semgrep requires at least one condition before it saves a policy, for example **Confidence** is any of High, Medium, Low.

    To receive supply chain incidents, turn on the **Early notification for Supply Chain incidents** policy and select the same webhook integration.
  </Step>

  <Step title="Save and verify">
    1. In **Settings → Integrations**, click **Test** on the webhook integration and confirm Flashduty returns success. The test posts `[{"text":"Test Notification","username":"Semgrep"}]`; Flashduty returns success and opens a separate Info alert titled "Semgrep test notification" that you close by hand
    2. Commit code that matches a rule and run a scan, then confirm Flashduty receives a new alert
  </Step>
</Steps>

## Payloads and recovery

***

Semgrep sends three kinds of objects, and one request can carry several:

| Semgrep object | When it is sent | Effect in Flashduty |
| :- | :- | :- |
| `semgrep_finding` | A policy matches a new finding | One alert per finding |
| `semgrep_supply_chain_incident` | Semgrep's security research team declares a supply chain incident | One alert when it affects your projects (`is_affected` is `true`); no alert otherwise |
| `semgrep_scan` | Every scan | No alert; Flashduty returns success |

Semgrep sends a finding only the first time it is detected and never sends update or fixed notifications, so Flashduty alerts do not recover automatically. Turn on the channel's [auto-resolve timeout](/en/on-call/channel/create-edit) (7 days suggested), or close alerts by hand after the issue is fixed.

## Alert Key

***

| Object | Field used |
| :- | :- |
| Finding | `numeric_id` (the finding's ID in Semgrep AppSec Platform) |
| Supply chain incident | `incident_id` |

The Alert Key is computed from the object type and the ID above, so a repeated delivery of the same finding merges, and a finding ID never merges with an incident ID that has the same number. Changes to the rule name or severity do not change the Alert Key. An object without its ID causes the whole request to be rejected.

## Severity

***

A finding's `severity` is a number derived from the rule severity:

| Semgrep `severity` | Rule severity | Flashduty severity |
| :- | :- | :- |
| `3` | Critical | Critical |
| `2` | Error / High | Critical |
| `1` | Warning / Medium | Warning |
| `0` | Info / Low | Info |
| `4` | Experiment | Info |
| Missing or other | - | Warning |

Supply chain incidents that affect your projects are always Critical.

## Labels

***

Findings:

| Label | Source |
| :- | :- |
| `check` / `rule_id` | Rule ID (`check_id`), also used as the alert title |
| `finding_id` | `numeric_id` |
| `repo` / `path` / `line` / `ref` | Repository, file path, line, branch |
| `commit_url` | Commit link |
| `semgrep_severity` | Raw Semgrep severity number |
| `confidence` / `category` | Confidence and category from rule metadata |
| `cwe` / `owasp` / `vulnerability_class` | Classifications from rule metadata, comma-separated |

Supply chain incidents:

| Label | Source |
| :- | :- |
| `check` | Incident title |
| `incident_id` | `incident_id` |
| `packages` | Affected package names, comma-separated (up to 50) |
| `affected_projects` | Affected projects, comma-separated (up to 50) |
| `advisories_url` / `blog_url` | Semgrep advisory and blog links |

Every alert carries `source=semgrep` and `event_type` (`finding` or `supply_chain_incident`). The alert description is the rule's `message`; code snippets are not sent.

## Troubleshooting

***

* **Flashduty returns an invalid-parameter error**: check that the webhook URL is complete and includes `integration_key`; the error is also returned when a finding lacks `numeric_id` or an incident lacks `incident_id`
* **No alerts arrive**: check that the policy has a **Call a webhook** action; Semgrep notifies only the first time a finding is detected, so existing findings are not re-sent
* **Alerts never close**: Semgrep sends no recovery notification, so turn on the channel's auto-resolve timeout
* **Too many alerts**: raise the severity or confidence filter in the Semgrep policy

For more details, see the [Semgrep webhooks documentation](https://docs.semgrep.dev/semgrep-appsec-platform/webhooks).