What is CI/CD pipeline scanning?
A job in your pipeline, after your deploy step, starts a scan of the one asset its token is tied to. The result passes or fails the CI job.
The portal generates that job for your CI system, and you add it to your pipeline file. PentestOps does not hook your repositories, Git events or deploys by itself.
| Question | Short answer |
|---|---|
| What you add | One job, generated by the portal for your CI system, added to your pipeline file. |
| What you store | A CI token and two portal URLs, in your CI's secret store. |
| When the scan starts | When your pipeline reaches the job, which you place after your deploy step. |
| When the gate fails the CI job | A scan finds issues at or above the severity you choose, counting every open finding or only the findings new since the previous scan. |
| Which CI systems | Six have a ready-made job. Other CI systems that have sh, curl and jq can use a plain shell version. |
| Which plan | Included in the Enterprise plan. |
Six CI systems, a ready-made job for each
The portal generates the job for the CI system you choose. Six systems have a ready-made job, and there is no seventh. There is also a plain shell version for other CI systems that have sh, curl and jq.
| CI system | Where the job runs |
|---|---|
| GitLab CI | The standard hosted runner. |
| GitHub Actions | The standard hosted runner. |
| Azure DevOps | The standard hosted runner. |
| Google Cloud Build | The standard hosted runner. |
| Jenkins | Your own Jenkins agent, which needs sh, curl and jq. |
| Bitbucket Pipelines | The standard hosted runner. |
How you set it up
Setup takes one job and three values: a CI token and two portal URLs. The portal generates the job for your CI system.
- Choose your CI system and your gate. The portal generates the job for that CI system. You choose the severity at which the CI job fails, and whether it counts every open finding or only the findings new since the previous scan.
- Store the token and two portal URLs. Put the CI token and the two portal URLs in your CI's secret store. The token is shown once.
- Add the job to your pipeline file. Place it after your deploy step.
- Run your pipeline as usual. Each time the job runs, it downloads the scan script from your own portal and starts a scan of the asset.
A token for one pipeline
Each pipeline has its own token, tied to one asset. The token can start scans of that asset and read their results, and nothing else. It is shown once, so keep it in your CI's secret store, and an admin can rotate or revoke it.
The target and your assets
The pipeline's target is added to your Asset Inventory and counts toward your plan's assets; a target already there is reused and nothing more is counted. Scans run once the target's ownership is verified.
The gate and what the job returns
The gate fails the CI job when a scan finds issues at or above the severity you choose: critical, high, medium or low. You also choose what counts, either every open finding or only the findings that are new since the previous scan.
A failed gate fails the CI job and nothing more. To hold a release, make that job a required check in your own CI or Git host.
The job ends with one of five exit codes.
| Exit code | What it means |
|---|---|
| 0 | The gate passed. |
| 1 | The gate failed, or the job could not set up or fetch the scan script. The log says which. |
| 2 | No verdict. |
| 3 | The gate passed, but coverage was incomplete and you asked the job to refuse that. |
| 4 | The wait ran out. |
Honest about coverage and about failures
If part of a scan did not run, the log says so, and you can set the job to fail instead of passing. That case ends with exit code 3.
When a scan ends without finishing, the pipeline log and the portal say why, when the scanner recorded a reason.
Results, fix steps and reports in the portal
- Every run is listed. Runs are listed newest first, and each run lists its findings most severe first.
- Fix steps with each finding. Each finding comes with suggested steps from the platform's built-in remediation playbooks.
- Reports and compliance reports. Each run links to the reports page with that scan selected, so a report or a compliance report can be generated from it.
- An email summary. When a pipeline scan completes, admins, managers and analysts are emailed a summary with counts by severity and the ten most severe findings by title.
Scanning a target inside your network
A target inside your network can be scanned from a pipeline through a PentestOps agent installed there, when the target is an IP address, a network range or a domain name and the agent is online.
A URL or an API cannot run as internal. If your target is one of those, a pipeline cannot scan it through an agent.
What CI/CD pipeline scanning does not do
- It does not block pull requests or merges on its own.
- It does not comment on pull requests or merge requests.
- It does not publish SARIF or send results to GitHub code scanning.
- It does not scan your source code, dependencies, containers or infrastructure as code.
- It is not an IDE plugin.
- It does not scan each commit or each diff.
- It is not zero configuration.
- It does not hook your repositories, Git events or deploys, so it does not scan automatically on every deploy.
- It does not run a URL or an API as an internal scan.
- It does not have a ready-made job for every CI system.