Common Deployment Scenarios

Scenario 1 - Uploading a Fortify FPR with embedded source code

If you have a fortify FPR report with source code embedded, you can run an analysis through Bugsy without needing to connect to your repository. In this case, simply use the analyze mode and use -p (--src-path) and point it at the FPR file.

For example, let's say we have a file called fortify.fpr that contains both the SAST report + Source code:

sh

npx @mobb.ai/cli@latest analyze -f .\fortify.fpr -p .\fortify.fpr -r https://my_repo_url --api-key xxxxxxx

Explanation:

• -f .\fortify.fpr specifies the location of the SAST report

• -p .\fortify.fpr specifies the location of the source code (in this case embedded in the FPR file)

• -r https://my_repo_url specifies the location of the actual repository. We encourage that this field is specified correctly, as it tells Mobb where the fix commits should go to.

• --api-key xxxxxxx specify your API key here

Scenario 2 - Automatically create pull requests for trusted fixes

If you want Mobb to automatically generate pull requests for trusted fixes, you must first enable it under your Project Settings --> Fix Policy as shown here.

sh

npx @mobb.ai/cli@latest analyze -f sast_results.json -r https://github.com/mobb-dev/simple-vulnerable-java-project --ref dev --auto-pr --ci --api-key xxxxxxx

Explanation:

• --auto-pr will tell Mobb to respect the fix policy as defined in the project settings and generate a pull request for the issue types where automatic PR is enabled in the fix policy.

• --api-key is required whenever --ci is used.

Scenario 3 - Automatically commit fixes to a target branch

If you want to enable automatic commit for trusted fixes, you must first enable it under your Project Settings --> Fix Policy, as shown here.

This scenario is typically reserved for directly committing the fixes to a development branch.

sh

npx @mobb.ai/cli@latest analyze -f sast_results.json -r https://github.com/mobb-dev/simple-vulnerable-java-project --ref dev --auto-pr --commit-directly --ci --api-key xxxxxxx

Explanation:

• --auto-pr will tell Mobb to respect the fix policy as defined in the project settings

• --commit-directly will tell Mobb that instead of generating a Pull Request, generate a commit on the branch specified by --ref dev. Note that --commit-directly requires --auto-pr.

Scenario 4 - Handling Large FPR Files (50k+ Issues)

When dealing with very large Fortify FPR files (containing 50,000+ issues or exceeding 10GB in internal compressed XML size), you'll need to convert the FPR to SARIF format and compress it before uploading. This approach is necessary because:

• File size limitations: Direct FPR uploads are blocked when the internal compressed XML exceeds 10GB

• Network efficiency: ZIP compression reduces upload time for slower connections

Step-by-step process:

Step 1: Convert the FPR file to SARIF format

sh

npx @mobb.ai/cli@latest convert-to-sarif --input-file-path report.fpr --output-file-path report.sarif --input-file-format FortifyFPR

Step 2: Compress the SARIF file into a ZIP archive

sh

tar -a -c -f report.zip report.sarif

Step 3: Upload the compressed SARIF file for analysis

sh

npx @mobb.ai/cli@latest analyze -f report.zip -r https://<YOUR_REPO_URL> --ref <YOUR_BRANCH> --api-key xxxx --ci

Explanation:

• convert-to-sarif converts the large FPR file to SARIF format, which is more efficient for Mobb's backend processing

• tar -a -c -f creates a compressed ZIP archive containing the SARIF file

• The final npx @mobb.ai/cli@latest analyze command processes the compressed SARIF file like any other scan report

When to use this scenario:

• FPR files with 50,000+ issues

• FPR files where the internal compressed XML exceeds 10GB

• Slow network connections where compression significantly reduces upload time

Scenario 5 - Gating a pull request build on the Scan & Gate Policy

If you want a pipeline to fail when a pull request introduces a finding that your organization's Scan & Gate Policy blocks on, combine Mobb's native scan with --baseline-commit and --gate:

sh

npx @mobb.ai/cli@latest analyze -r https://github.com/org/repo --ref <pr-branch> --baseline-commit <base-sha> --gate --ci --api-key xxxxxxx

Explanation:

• --baseline-commit <base-sha> restricts the scan to findings introduced by the PR, so pre-existing issues on the base branch cannot fail the build

• --gate makes the CLI exit 2 when the policy blocks, 0 when it passes, and 1 on an operational error (including a scan that failed to finish)

• No -f / --scan-file is used — --gate enforces the policy on Mobb's own scan and is rejected when combined with a third-party report

See Scan and Fix Mode for the full exit-code table.

Scenario 6 - CI runners without a suitable Node.js version

@mobb.ai/cli ships a standalone binary with its runtime embedded, so the CLI itself does not need a Node.js install. This is the main practical reason to prefer it over npx mobbdev@latest in a pipeline.

sh

npx @mobb.ai/cli@latest analyze -r https://github.com/org/repo --ci --api-key xxxxxxx

Explanation:

• The CLI's own runtime requirement goes away entirely — the binary carries it

• npx is still npm tooling and needs Node.js >= 14 to run; that is the only remaining Node.js dependency

• After the first run the platform binary is cached, so later pipeline steps do not re-download it

• On a platform with no published binary (notably Windows on arm64), fall back to npx mobbdev@latest — see supported platforms

If your pipeline runs its steps in PowerShell, quote the package name: npx "@mobb.ai/cli@latest" analyze ...