Bitbucket Pipelines

Reference the pipe in bitbucket-pipelines.yml, no plugin to install. It runs an offline compliance scan, writes SARIF, and can fail the build on severity. Your code never leaves the runner.

01 · Setup

3 steps.

01Add the pipe step

Reference the pipe in your bitbucket-pipelines.yml with your frameworks and gating severity.

pipelines:
  pull-requests:
    '**':
      - step:
          name: Compliance scan
          script:
            - pipe: docker://nirvahana/scrutora-scan-pipe:1.1.1
              variables:
                FRAMEWORKS: dpdpa,hipaa
                FAIL_ON: high      # none|low|medium|high|critical
02Run the pipeline

The pipe scans offline and writes SARIF. When FAIL_ON is set, a finding at or above that severity fails the step and blocks the pull request.

03Optional: keep the results in Scrutora

By default nothing leaves your runner, which is why the scan above needs no account and no key. Add --upload and the scan posts its RESULTS to your Scrutora account when it finishes: the findings, the data map, the RoPA entries and the dependency inventory travel, your source never does. Paid plans only; the scan itself stays free forever. Store the key as a secret (GitHub: Actions secret, GitLab: masked CI variable, Bitbucket: repository variable, CircleCI: context, Azure: pipeline secret, Cloud Build: Secret Manager) and expose it as SCRUTORA_API_KEY so it never reaches your build log. Repository, commit, branch and PR number are read from the CI environment, and the scan is filed under a project named after the repository unless you pass --project. Re-running the same commit returns the scan already stored rather than adding a second one, so a retried pipeline does not distort the trend line. If the upload fails, the build result is unchanged: the scan already gave its verdict, and the step logs a warning rather than failing the job. On GitHub Actions you can set upload: true on the action itself instead of running the container by hand, and read the resulting scan id from the scan-id output.

docker run --rm -v "$PWD:/src" -w /src \
  -e SCRUTORA_API_KEY \
  ghcr.io/nirvahana/dpdp-scan@sha256:71e306bdab91587e01ed6b83a1d2c3baecf4c55ecf880b440a5ab76fe85eb461 \
  scan . --no-ai \
    --frameworks dpdpa,hipaa \
    --json-output scrutora.json \
    --output scrutora-report.pdf \
    --upload

# SCRUTORA_API_KEY is read from the environment, never passed on the command
# line, so it stays out of your build log. Add --project "my-service" to file
# the scan somewhere other than a project named after the repository.

# ── GitHub Actions: use the action's own inputs instead ─────────────────────
#   - id: scan
#     uses: scrutora/scrutora-scan@v1
#     with:
#       upload: true
#       api-key: ${{ secrets.SCRUTORA_API_KEY }}
#   - run: echo "Synced as ${{ steps.scan.outputs.scan-id }}"
02 · What you get

After the first run.

No plugin install

It's a standard Bitbucket pipe. Just reference it in your YAML.

Build gating

FAIL_ON fails the step on high/critical findings, or run report-only.

SARIF output

Standard SARIF v2.1.0 for download and downstream tooling.

Obligation citations

Each finding maps to the exact DPDPA/HIPAA obligation.

03 · Questions

The ones people actually ask.

Do I need to install anything?

No. Reference the pipe in bitbucket-pipelines.yml, Bitbucket pulls the image and runs it.

Which frameworks can I scan for?

DPDPA, HIPAA, GDPR, PCI-DSS, RBI and more, set the FRAMEWORKS variable.

Is it free?

Yes, the CI scanning is free with no API key or account.

Bitbucket repository