> ## Documentation Index > Fetch the complete documentation index at: https://docs.semgrep.dev/llms.txt > Use this file to discover all available pages before exploring further. # Add Semgrep to CI **YOUR DEPLOYMENT JOURNEY** * You have gained the necessary [resource access and permissions](/deployment/checklist) required for deployment. * You have [created a Semgrep account and organization](/deployment/create-account-and-orgs). * For GitHub and GitLab users: You have [connected your source code manager](/deployment/connect-scm). * Optionally, you have [set up SSO](/deployment/sso). Semgrep is integrated into CI environments by creating a **job** that is run by the CI provider. After a scan, findings are sent to Semgrep AppSec Platform for triage and remediation. By integrating Semgrep into your CI environment, your development cycle benefits from the automated scanning of repositories at various events, such as: * Push events * Pull requests or merge requests (PRs or MRs) * User-initiated events (such as GitHub Action's `workflow_dispatch`) **SEMGREP MANAGED SCANS** As an alternative to integrating Semgrep into your CI/CD system, consider [Semgrep Managed Scans](/deployment/managed-scanning/overview), which enables you to bulk onboard and scan your repositories without requiring changes to your CI. ## Guided setup for CI providers in Semgrep AppSec Platform This guide walks you through creating a Semgrep job in the following CI providers, which are explicitly supported in Semgrep AppSec Platform: * GitHub Actions * GitLab CI/CD * Jenkins * Bitbucket * CircleCI * Buildkite * Azure Pipelines * Semaphore If your provider is **not** on this list, you can still integrate Semgrep into your CI workflows by following the steps in [ Add Semgrep to other CI providers](/deployment/add-semgrep-to-other-ci-providers). ## Projects Adding a Semgrep job to your CI provider also adds the repository's records, including findings, as a **project** in Semgrep AppSec Platform. Each project can be individually configured to send notifications or tickets. ## Add Semgrep to CI To add a Semgrep job to your CI provider: Ensure you are signed in to Semgrep AppSec Platform. Click **[Projects](https://semgrep.dev/orgs/-/projects)** on the left sidebar. Click **Scan new project > CI/CD**. Click the name of the CI provider you use. You are taken to the **Add job** page. Follow the steps provided on the page. The process varies depending on your CI provider, but generally includes the following steps:

i. Click **Create new token** to create a `SEMGREP_APP_TOKEN`, which is used to when sending results to Semgrep AppSec Platform.

ii. Copy and paste the `SEMGREP_APP_TOKEN` and its value. Store it as an environment variable or secret in your CI provider.

iii. Optional: Click **Review CI config** to see Semgrep's default YAML configuration file for your CI provider.

iv. Click **Copy snippet** and paste it into your CI provider's configuration file (the filename is typically indicated in the page). Depending on your CI provider, you may have to create a custom configuration file or use an existing one.

v. Commit the configuration file to your repository.

vi. Return to Semgrep AppSec Platform and click **Check connection**. You have now added a Semgrep job to your CI provider; this starts your first **full scan**. Its findings are sent to Semgrep AppSec Platform for triage and remediation. To add a CI job to GitHub Actions: Ensure you are signed in to Semgrep AppSec Platform. Click **[Projects](https://semgrep.dev/orgs/-/projects)** on the left sidebar. Click **Scan new project > CI/CD**. Click **GitHub Actions**. A list of repositories appears. Select all the repositories you want to add a Semgrep job to. If you do not see the repository you want to add, adjust [ GitHub Application's Repository Access](https://github.com/settings/installations) configuration. See [Detecting GitHub repositories](#detecting-github-repositories) for more information. Click **Add CI job**. You are taken to the Add CI job page. Optional: Click **Review CI config** to see Semgrep's default YAML configuration file. Click **Commit file**. You have now added a Semgrep job to GitHub Actions. A **full scan** begins automatically after adding a new repository. Its findings are sent to Semgrep AppSec Platform for triage and remediation. ### Detecting GitHub repositories If you aren't seeing your GitHub repos in the Cloud Platform, complete the following steps to ensure that your GitHub repository is **detected** by Semgrep AppSec Platform: Log in to GitHub. Perform one of the following steps:

i. For repositories in personal accounts: Click your **profile photo > Settings > Applications**.

ii. For repositories in org accounts: Click your **profile photo > Your organizations > NAME\_OF\_ORG > Settings > GitHub Apps**. On the `semgrep-app` entry, click **Configure**. Under **Repository access** select an option to provide access:

i. All repositories will display all current and future public and private repositories.

ii. Only select repositories will display explicitly selected repositories. **TIP** You can edit your configuration files to send findings to **GitHub Advanced Security Dashboard (GHAS)** and **GitLab SAST Dashboard**. Refer to the following samples: * [GitHub Advanced Security Dashboard](/semgrep-ci/sample-ci-configs/#upload-findings-to-github-advanced-security-dashboard) * [GitLab SAST Dashboard](/semgrep-ci/sample-ci-configs/#upload-findings-to-gitlab-security-dashboard) ### Sample CI configuration snippets Refer to the following table for links to sample CI configuration snippets: | In-app CI provider | Sample CI configuration snippet | | :------------------ | :------------------------------------------------------------------------------ | | Azure Pipelines | [`azure-pipelines.yml`](/semgrep-ci/sample-ci-configs/#azure-pipelines) | | Bitbucket Pipelines | [`bitbucket-pipelines.yml`](/semgrep-ci/sample-ci-configs/#bitbucket-pipelines) | | Buildkite | [`pipelines.yml`](/semgrep-ci/sample-ci-configs/#buildkite) | | CircleCI | [`config.yml`](/semgrep-ci/sample-ci-configs/#circleci) | | GitHub Actions | [`semgrep.yml`](/semgrep-ci/sample-ci-configs/#github-actions) | | GitLab CI/CD | [`.gitlab-ci.yml`](/semgrep-ci/sample-ci-configs/#gitlab-cicd) | | Jenkins | [`Jenkinsfile`](/semgrep-ci/sample-ci-configs/#jenkins) | | Semaphore | [`semaphore.yml`](/semgrep-ci/sample-ci-configs/#semaphore) | ### Data collected by Semgrep When running in CI, Semgrep runs fully in the CI build environment. Unless you have explicitly granted code access to Semgrep, your code is not sent anywhere. * Semgrep collects [findings data](/semgrep-ci/findings-ci), which includes the line number of the code match, but not the code. It is hashed using a one-way hashing function. * Findings data is used to generate line-specific hyperlinks to your source code management system and support other Semgrep functions. ### Delete a project Deleting a project removes all of its findings, metadata, and other records from Semgrep AppSec Platform. In Semgrep AppSec Platform, click **Projects**. Search for your repository's name. Click the **windows icon** to access the settings page for that project. Click the **three-dot (...) button** at the header and click **Delete project**. To delete an archived project: In Semgrep AppSec Platform, click **Projects**. Switch to the **Not Scanning** tab of the **Projects** page. Select the checkbox to **Show archived** projects. Search for the archived repository's name. Click the **window icon** under **Details** to access the settings page for that repository. Click the dropdown at the header and click **Delete project**. **INFO** It can take up to a day **(24 hours)** for the [Dashboard](/semgrep-appsec-platform/dashboard) to correctly update and remove findings associated with a recently deleted project. ## Scan scope Semgrep scans can be classified by **scope**. The scope of a scan refers to what lines of code are scanned in a codebase. When classifying scans by scope, there are two types of scans: ### Full scan A full scan runs on your entire codebase and reports every finding in the codebase. It is recommended to perform a full scan of your default branch, such as main or master at a regular cadence, such as every night or every week. This ensures that Semgrep AppSec Platform has a full list of all findings in your code base, regardless of when they were introduced. To run a full scan, run `semgrep ci` without setting the `SEMGREP_BASELINE_REF` environment variable. Full scans are triggered at a scheduled time, when the `semgrep.yml` file is edited, or manually by a user. ### Diff-aware scan A diff-aware scan runs on your code before and after some "baseline" and only reports findings that are newly introduced in the commits after that baseline. Typically, Semgrep runs diff-aware scans upon the creation of a new pull request or merge request. For example, imagine a hypothetical repository with 10 commits. You set commit number 8 as the baseline. Consequently, Semgrep only returns scan results introduced by changes in commits 9 and 10. This is how `semgrep ci` can run in pull requests and merge requests, since it reports only the findings that are created by those code changes. To run a diff-aware scan, use `SEMGREP_BASELINE_REF=REF semgrep ci` where `REF` can be a commit hash, branch name, or other Git reference. Note that the `SEMGREP_BASELINE_REF` does not apply to GitHub Actions and GitLab CI/CD environments. This variable cannot be set to turn a diff-aware scan in GitHub Actions or GitLab CI/CD into a full scan. ### Default branch names When you add a Semgrep CI job to your repository for the first time, Semgrep performs a full scan on the primary, or default, branches. In many cases, Semgrep automatically detects these branches as primary branches. However, you can also [set the primary branch name](/deployment/primary-branch). This is useful for repositories with unique names. This lets Semgrep know what branch to prioritize and perform full scans on. ## Next steps You've set up Semgrep to scan in your repository and send findings after each scan. Your core deployment is almost complete. Remaining steps include: * Optional: [ Customize your CI job](/deployment/customize-ci-jobs). * For software composition analysis (SCA) scans using **Jenkins or Maven**: [ Set up SCA scans for your infrastructure.](/semgrep-supply-chain/setup-infrastructure) * For Jenkins users: Set up a separate CI job for diff-aware scans for feature branches (non-trunk branches) when a pull request or merge request is open. This is a prerequisite to receiving PR or MR comments. See Set up diff-aware scans. * Set up **PR or MR comments**, which post findings to developers in your SCM. This involves developers in the security process as active participants. See [ PR or MR comments](/category/pr-or-mr-comments) for next steps.