Post Corgea findings to Bitbucket Server pull requests from the pipeline script

[Ibrahimrahhal]

The upload_fpr_and_report.sh script we gave the customer (upload a Fortify .fpr, wait, print the findings) now has one more step: it posts those findings to the Bitbucket Server / Data Center pull request as review comments. The script lives in the repo for the first time, under scripts/pipeline/, so the version we hand out is the version we can review.

No CLI code changed. The Corgea side still shells out to corgea upload, corgea wait, corgea ls and corgea inspect exactly as before; everything Bitbucket is in the script, and the two existing modes behave identically when the BITBUCKET_* variables are not set.

What it posts

Comment shape follows the doghouse convention, adapted to a platform with no <details> element: Bitbucket Server collapses long comments behind "Show more", so the whole point goes on the first line and the explanation, fix and suggestion come after it.

• Valid finding: 🔴 SQL Injection (Critical · 🔒 Security) — <one-line summary> [View in Corgea ↗], then the issue explanation, the fix explanation, and the fix.
• Auto-triaged false positive: ✅ False positive — Fortify flagged X here, but Corgea's triage found it is not exploitable: <reason>, then the full reasoning and what the scanner reported.
• One summary comment with the severity breakdown and a link to the scan.

A Corgea fix becomes an applicable ```suggestion block, so the reviewer applies it from the PR. That only happens when the patch is a single contiguous change and every line it would replace is still in the diff holding the code the patch was computed against — the same guard reject_apply_mismatch gives us in doghouse. Otherwise the fix is shown as a ```diff block. Multi-line suggestions use multilineMarker + multilineSpan so Apply replaces the whole span rather than the first line (Bitbucket DC 9.3+).

Bitbucket API notes

Written against the v1004 (Data Center 10.4) REST API the customer runs: POST /rest/api/1.0/projects/{key}/repos/{slug}/pull-requests/{id}/comments with an EFFECTIVE-diff anchor, GET .../changes and GET .../diff/{path} to decide where a finding can be anchored, and GET .../activities to recognize comments an earlier run already posted (every comment carries a corgea-issue: <id> marker, so re-runs do not duplicate).

Findings whose file the PR does not touch are counted in the summary and otherwise skipped (POST_OUTSIDE_DIFF=1 posts them as plain PR comments). Fortify's build-machine paths are mapped onto repo paths by suffix, with STRIP_PATH_PREFIX as the explicit override. Credentials go into a 0600 curl config file rather than the command line, so they stay out of the build agent's process list. Any Bitbucket failure warns and leaves the console report and exit code untouched.

Testing

Ran the script end to end against a stub Bitbucket DC server and a stub corgea CLI, covering: a fix that becomes a multi-line suggestion (anchor line: 8, multilineMarker.startLine: 7, multilineSpan: 7-8), a false positive, a multi-hunk fix falling back to a diff block, a fix whose patch no longer matches the file being rejected as a suggestion, a finding outside the diff, PR auto-detection from the branch, a re-run posting nothing, absolute Fortify paths resolving to repo paths, every POST_* toggle, DRY_RUN, and the 404 / unreachable-server paths. shellcheck -S style is clean.

Both --report-only and the upload path were exercised; neither changed behavior.