Set up any other CI

Any CI that can run a container can scan with MopokeHQ. The scanner image holds the mopoke CLI and every scanner it runs, so one job is enough.

The scanner image

gitlab.boosoft.com.au:5050/mopokehq/scanner:1

• Public: any runner pulls it without a login. It is not on Docker Hub, so always use the full reference.
• :1 follows the current release of the CLI and scanners. Each release is also published under its own short commit tag; mirror one into your own registry if you need to pin it.
• Holds mopoke, syft, semgrep, gitleaks and trivy, each pinned to a release at least 14 days old and checked against a pinned SHA-256. Nothing is downloaded at scan time except trivy’s vulnerability database for image scans. See Scanners.
• The image has no entrypoint: run mopoke as the command.

The runner needs outbound HTTPS to gitlab.boosoft.com.au:5050 (to pull the image) and to app.mopokehq.com (to upload).

Bitbucket Pipelines

MopokeHQ serves a ready-made bitbucket-pipelines.yml:

curl -fsSL -o bitbucket-pipelines.yml https://app.mopokehq.com/ci/bitbucket.yml

If you already have a bitbucket-pipelines.yml, copy its mopoke step and its pipelines entries into yours instead.

1. Add MOPOKE_TOKEN as a secured repository variable (or a workspace variable, to cover every repository). Make it in MopokeHQ under CI tokens (Tokens and keys).
2. Bitbucket does not tell a pipeline which branch is the main one. The file assumes main. If yours is different, change the branch under pipelines and set the variable MOPOKE_DEFAULT_BRANCH.

It scans pushes to the main branch, tags and pull requests, and never fails the pipeline unless you set MOPOKE_GATE to enforce (see Merge gate).

Jenkins, Woodpecker and others

The CLI reads the repository, commit, branch and pull request from GitHub Actions, Gitea and Forgejo Actions, Bitbucket Pipelines, Jenkins and Woodpecker variables on its own. In those, a job needs only:

mopoke scan .

with MOPOKE_TOKEN set from your CI’s secret store, run in the scanner image. Set MOPOKE_DEFAULT_BRANCH on Jenkins (it does not say which branch is the default); Woodpecker says so itself.

Anywhere else, tell the CLI what it is scanning with flags or CI_* variables:

docker run --rm -v "$PWD:/src" -w /src \
  -e MOPOKE_TOKEN \
  -e CI_DEFAULT_BRANCH=main \
  gitlab.boosoft.com.au:5050/mopokehq/scanner:1 \
  sh -c 'git config --global --add safe.directory /src &&
         mopoke scan --project acme/shop --commit "$(git rev-parse HEAD)" --ref "$(git rev-parse --abbrev-ref HEAD)" .'

Flags go before the directory.

CI_DEFAULT_BRANCH matters: only scans of the default branch set the baseline, open new findings and mark old ones fixed. Without it, every scan is treated as a branch.

Commands

Command	What it does
mopoke scan [dir]	Runs the scanners on a directory (default .) and uploads everything.
mopoke deploy --env NAME	Reports that this commit is live in environment NAME.
mopoke sarif --kind KIND [--tool NAME] FILE	Uploads SARIF from another scanner.
mopoke upload --sbom FILE	Uploads a CycloneDX JSON SBOM you made yourself.
mopoke version	Prints the CLI version.

Flags for scan, upload and deploy

Flag	Default
--project PATH	CI_PROJECT_PATH	The repository’s path, such as acme/shop. It names the repository in MopokeHQ, so keep it stable.
--commit SHA	CI_COMMIT_SHA	The full commit SHA.
--ref NAME	CI_COMMIT_REF_NAME	The branch or tag.
--path DIR	none	A directory inside a monorepo that holds its own app. Each path is a repository of its own in MopokeHQ.
--runtime php=8.3.12	none	(scan, upload) The PHP version production runs, when nothing else says. A version read from a built image counts for more; see Scanners.
--image REF	MOPOKE_IMAGE	(deploy) The image this deploy shipped.

Environment

Variable
MOPOKE_TOKEN	Required. A CI token.
MOPOKE_URL	Default https://app.mopokehq.com.
CI_DEFAULT_BRANCH	The default branch’s name (see above).
MOPOKE_SCANNERS, MOPOKE_GATE, MOPOKE_IMAGE and the rest	See Scanners.

Exit codes

Code	Meaning	Suggested handling
0	Everything ran and was sent.
1	A scanner or an upload failed; the rest was sent.	Warn, don’t fail.
2	Usage: no token, no project, no commit.	Warn, don’t fail.
3	The merge gate failed, with MOPOKE_GATE=enforce.	Fail the job.

The ready-made templates do exactly this: only exit 3 fails a pipeline.

Report deployments

After a deploy succeeds, run:

mopoke deploy --env production

in the scanner image, or anywhere the CLI is installed, with the same MOPOKE_TOKEN and the same project and commit as the scan (flags or variables). Use your own environment names (production, staging); they are lower-cased. Add --image <ref> when the deploy ships an image your pipeline scanned.

Deploy reports are how MopokeHQ knows what is live. A problem in a deployed build is confirmed live, and a fix closes on its own only once MopokeHQ sees it deployed (see Priorities and deadlines). If the commit’s scan has not arrived yet, the deploy is recorded and links up when it does.

Upload SARIF from other tools

Results from CodeQL, another SAST tool or your own scanner go up as SARIF 2.1.0:

mopoke sarif --kind sast --tool codeql results.sarif

• --kind is sast, secret, iac, licence or container.
• --tool names the tool; it defaults to the name in the file. Findings are tracked per tool, so keep it the same between runs.
• Up to 10,000 results and 25 MB per upload.
• Run it with the same project, commit and branch as your scan. On the default branch, results set the baseline and open and close findings exactly like MopokeHQ’s own scanners. Results from other branches never change what the default branch has open.

The CLI trims the file before upload: no code snippets, code flows or surrounding source leave the runner.