Skip to content

PR Comments

The pr-comment command decorates a pull request with two layers:

  • Inline comments anchored to the exact file and line of high-signal findings (blocking, plus CRITICAL/HIGH severity) that land on lines the PR changed.
  • A single summary comment that states whether the build is blocked, counts the findings, and links to the dashboard.

Comments are created by your CI runner using your CI platform token — SecureObs servers never write to your repositories. Only safe metadata (rule, severity, file, line, description) is posted; raw code snippets and secret values are never included in a comment.

PR comments are tier-gated. Free-tier runs skip the comment step with a warning.

GitHub Actions

No extra setup is required. The generated workflow grants the job pull-requests: write and passes the built-in GITHUB_TOKEN, which is all the review API needs. Open a pull request and the comments appear automatically.

GitHub PR comment
docker run --rm \
  -e SECUREOBS_API_KEY="$SECUREOBS_API_KEY" \
  -e GH_TOKEN="${{ secrets.GITHUB_TOKEN }}" \
  -e GITHUB_REPOSITORY="$GITHUB_REPOSITORY" \
  -e GITHUB_EVENT_NAME="$GITHUB_EVENT_NAME" \
  -e GITHUB_REF="$GITHUB_REF" \
  secureobs/scanner:v1 \
  pr-comment \
  --project-id "$SECUREOBS_PROJECT_ID" \
  --tenant-id "$SECUREOBS_TENANT_ID" \
  --pipeline-run-id "$GITHUB_RUN_ID" \
  --platform github

Azure DevOps

Azure DevOps requires "Allow scripts to access the OAuth token" and the build service identity needs permission to contribute to pull requests.

Azure DevOps PR comment
docker run --rm \
  -e SECUREOBS_API_KEY \
  -e SYSTEM_ACCESSTOKEN \
  -e SYSTEM_PULLREQUEST_PULLREQUESTID \
  -e BUILD_REPOSITORY_ID \
  -e SYSTEM_TEAMPROJECT \
  -e SYSTEM_TEAMFOUNDATIONCOLLECTIONURI \
  secureobs/scanner:v1 \
  pr-comment \
  --project-id "$SECUREOBS_PROJECT_ID" \
  --tenant-id "$SECUREOBS_TENANT_ID" \
  --pipeline-run-id "$BUILD_BUILDID" \
  --platform azuredevops

Behavior

  • Inline comments are posted only on lines the PR actually changed — both GitHub and Azure reject comments on untouched lines. Findings on unchanged code are tallied in the summary instead.
  • Only blocking findings and CRITICAL/HIGH severities get inline comments, so noisy scanners can't flood a PR. Up to 50 inline comments per run.
  • The summary comment is marker-identified and updated in place on later runs.
  • Re-runs remove the previous SecureObs inline comments first, so fixing a finding clears its comment and nothing stacks up.
  • The --pipeline-run-id passed to pr-comment must match the one used by the scan step so the comment reflects that run's findings. The generated pipelines handle this for you.
  • Inline annotation is best-effort: if the findings fetch or any comment call fails, the command falls back to the summary comment and never fails the pipeline. Missing PR context causes it to skip rather than create noise.