How to add security scanning to your CI/CD pipeline

To add security scanning to a CI/CD pipeline with Cyberlop, open Integrations, pick a scan profile, click Copy, save the YAML in your repository, and add two secrets: CYBERLOP_URL and CYBERLOP_API_TOKEN. After that, every merge to your main branch starts a scan, waits for it, and prints the findings in the build log without ever failing the build.

A CI/CD integration is a pipeline job that starts a Cyberlop scan through its API whenever your code changes, then reads the result back. The snippet is generated for you, so you copy rather than write it.

What does the Cyberlop CI/CD integration do?

It runs one scan profile from your pipeline and reports the outcome in the build log. The Integrations page sums it up in one line: it triggers a scan for a profile on merge, reports findings to the build log, and never fails the build.

Running on every merge matters because vulnerabilities are now a leading way in. The Verizon 2026 Data Breach Investigations Report puts software vulnerabilities at the start of 31% of breaches, now ahead of stolen passwords as the most common way in. Testing the code you just merged is a small, repeatable answer to that. It is the same idea the NIST Secure Software Development Framework (SP 800-218) argues: secure practices have to be built into whichever development lifecycle model you already run, not bolted on at the end. See CI/CD, shift left and DevSecOps for the plain-English terms.

What happens in the three steps?

The generated job has three steps, shown below. Both code-host tabs follow the same pattern.

Polling 120 times at 30 seconds gives the job a window of about an hour. A typical scan of a small app takes roughly an hour, so a larger app may take longer than the window. The scan itself is tracked in Recent Scans, so you can always read the result there. Learn more in run a scan.

What do you need before you start?

You need a scan profile, a personal API token and your Cyberlop base URL. Gather these four things first.

Which profile should the pipeline run?

Choose a profile aimed at a staging or test copy of your application, never at a system you do not own or are not authorised to test. A profile belongs to a target, and a target is either white-box (it has a repository) or black-box (URL only, ownership verified). Read white-box vs black-box scans and create a scan profile first if you have none.

White-box profile

It reads your repository over HTTPS and tests the running app, so a finding can point to the file and line. Private repositories need a Git token; see connect a repository and Git access.

Black-box profile

It tests the live URL only and needs the target's ownership to be verified first. See verify target ownership.

How do you add the scan to your pipeline?

Choose the tab for your code host, select a profile, copy the YAML, commit it, then add the two secrets.

1. Click Integrations in the sidebar. The page reads "Wire Cyberlop into CI/CD and secret stores."
2. Open the tab that matches your code host. The first tab is a workflow for one code host; the second is a pipeline file for another. The third tab is a cloud key vault, which is a different task: see cloud key vault integration.
3. In Scan profile, search for and select the profile to run. Its id is written into the snippet.
4. Click Copy.
5. Save the YAML in your repository. The workflow tab names the file cyberlop-scan.yml in your code host's workflows folder; the pipeline tab names a CI file in the repository root.
6. In your repository settings, add the secrets CYBERLOP_URL and CYBERLOP_API_TOKEN (details below).
7. Push to your main branch, or start the workflow by hand, and watch the build log.

How do the two code-host tabs differ?

They do the same job in two pipeline formats. The differences are where the job runs and how it is started.

What goes in the two secrets?

The footer of the page says: add two secrets to your repository. Never paste either value into the YAML itself. Store both as masked secrets, a practice that sits in secrets management.

CYBERLOP_URL

This is the base URL of the Cyberlop app, the address you open in your browser. The job adds /api/ci/scan and /api/ci/result/... to it.

CYBERLOP_API_TOKEN

This is your personal API token. An admin issues it from Administration → Users; the raw secret is shown once, so copy it straight into the secret store. The job sends it as a bearer token in the authorization header.

Which API calls does the pipeline make?

The pipeline makes two calls: one to start a scan and one to read its result. Both use the bearer token, and each endpoint checks a permission.

The trigger accepts a profile id, and the API Reference also lists a profile name as an option, plus an optional commit SHA. The generated snippet sends the id and the SHA. The result is described as CI-friendly: status, whether it is done, totals, severity counts and findings, each with severity, title and location.

What does the request look like?

The sketch below only illustrates the two calls with neutral names. Use the snippet from Integrations in real pipelines, because it includes the polling loop and the report step.

# Illustrative only
SCAN_ID=$(curl -s -X POST "$CYBERLOP_URL/api/ci/scan" \
  -H "authorization: Bearer $CYBERLOP_API_TOKEN" \
  -H "content-type: application/json" \
  -d '{"profileId":"<profile-id>","commitSha":"<commit-sha>"}' | jq -r .scanId)

curl -s "$CYBERLOP_URL/api/ci/result/$SCAN_ID" \
  -H "authorization: Bearer $CYBERLOP_API_TOKEN" | jq '{done, totalIssues}'

Keep the base URL on https. RFC 6750 treats whoever holds a bearer token as able to use it, and says requests that carry one must travel over TLS.

Why does the scan never fail the build?

The generated job is non-blocking by design. The YAML comment says "Non-blocking: reports findings, never fails the build", and the job is marked to continue on error, so a failed or slow scan cannot stop a release.

That suits a first rollout. Your team sees findings in the build log next to the commit, and nobody is blocked while you learn what the results look like. Each finding appears as a line such as [severity] title — location, and the job ends with a notice that Cyberlop found a number of issues.

Can you make a scan block a release?

The generated snippet does not do it. If you later want a security gate, that is a change you make in your own pipeline, for example by reading the totals the result endpoint returns. Decide the rule with your team first, since a gate on every severity will stop builds for findings that are not urgent. See gating a build and severity and confidence.

Which token and permissions should the pipeline use?

Use a token whose owner can do only what the pipeline needs. The scan runs with the token owner's permissions and group scope, so a powerful owner means a powerful pipeline.

The trigger needs ci:trigger and the result needs scan:read. Create a role with just those permissions, give it to a dedicated user, and ask an admin to issue that user's token. This follows least privilege; the details are in API tokens and permissions.

The OWASP Top 10 CI/CD Security Risks lists insufficient credential hygiene as CICD-SEC-6 and recommends a separate credential set for each context, and secrets scoped so each pipeline and step reaches only the ones it requires.

Rotate the token when people or repositories change

An admin can regenerate or revoke a user's token. Update the pipeline secret straight after, or the next run will not authenticate. See API key rotation.

Limit which profiles it can reach

Group scope applies to the token, so a pipeline for one team can be kept to that team's profiles. Read groups and tags.

Where do you read the results?

You can read them in the build log first, then in the app. The build log shows a short summary. The app holds the evidence.

• Recent Scans lists the run with its result badge (Completed, Failed or Cancelled) and a link to the scan detail. See the scan detail page.
• Issues holds the findings for triage. See the Issues list and triage findings.
• For a white-box scan, the scan overview shows the commit, so you can match findings to a build.
• After a fix merges, the next run shows whether the issue is fixed or has returned. See fixed and regressed issues.

Email alerts when a scan finishes or finds critical or high issues are set in My Account; a chat message is possible too, see chat notifications.

How often should it run?

The generated workflow runs on a push to the main branch and on demand, which fits a "scan what we merge" habit. For a regular sweep that does not depend on commits, add a scheduled scan as well. Plan limits, such as scans at once, are shown in Settings → Plan & usage, so check them before wiring many busy repositories to one organization.

If the app is only reachable inside your network, set the profile's scan location to a self-hosted agent: self-hosted scan agents. See also continuous pentesting and the integrations overview.

Troubleshooting: why does the CI scan not work?

Most failures come from the token, the secrets or the profile. The causes below are the likely ones; the exact error text is not part of what we documented, so read your build log.

What mistakes repeat?

Pasting the token into the YAML

Anything in the file is visible to everyone with repository access. Keep it in the secret store.

Pointing the profile at production

Start with staging. Exploitation proves findings with a real browser, so decide deliberately before aiming it at a live system; see the exploitation phase.

Next step

Once the pipeline runs, read the API reference to see every endpoint a script can call, and API tokens and permissions to tighten the token.