How do I produce a Bandit HTML report?

`bandit -r . -f html -o bandit.html`. The html formatter writes a single self-contained file with each finding's severity, confidence, CWE reference and the offending source lines.

How do I share it without publishing our vulnerabilities?

Create the report `private` and add reviewers by name, or gate it to your email domain. A scanner report is an inventory of where the weak code is — it should never be created with public visibility and then narrowed afterwards.

Why not just read the CI log?

Because triage is the work, not detection. Most Bandit findings on a real codebase are `# nosec`-worthy in context, and deciding which ones aren't is a conversation between a developer and a reviewer — which a log can't hold.

How do I track the findings coming down?

PATCH the same report id every run. One stable URL, one revision per run, so the direction is visible and a new high-severity finding is a diff rather than a discovery.

Can reviewers respond to a specific finding?

Yes. Threads anchor to the rendered content, so 'this is a false positive, the input is validated upstream' sits on that finding and stays there on the next scan.

Share a Bandit report

Bandit finds the subprocess call with shell=True, the hardcoded password in a test fixture, the yaml.load that should be safe_load — and then writes its findings into a job that expires.

bandit -r . -f html -o bandit.html

One self-contained file: severity, confidence, CWE, and the source lines around each hit. No assets folder, nothing to serve.

Publish it privately

curl -X POST https://commareports.com/api/v1/reports \
  -H "Authorization: Bearer $COMMA_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d "$(jq -n --rawfile html bandit.html \
        '{title: "Bandit — api service", html: $html, visibility: "private"}')"

Note the private. Visibility is set at create time — private, registered or public — and a scanner report is the case where you choose it deliberately rather than fixing it later. It is a map of where the weak code is.

Then add the people who need it: named reviewers, your team, or a domain gate. See sharing & access control.

Triage is the actual work

On any real codebase most findings are contextually fine and a few are not, and telling them apart takes someone who knows the code. That's a conversation, and it needs to happen somewhere the finding is visible:

Anchored threads per finding — "validated upstream, marking # nosec with a reason" — see commenting on HTML.
Revisions, so the next scan shows what was fixed, what was accepted, and what's new.
A record, which is the thing an auditor asks for and a CI log can't produce.

From CI

bandit -r . -f html -o bandit.html || true   # bandit exits non-zero on findings

curl -fsS -X PATCH "https://commareports.com/api/v1/reports/$REPORT_ID" \
  -H "Authorization: Bearer $COMMA_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d "$(jq -n --rawfile html bandit.html \
        --arg title "Bandit — $GITHUB_SHA" '{title: $title, html: $html}')"

Bandit exits non-zero when it finds something, so guard the step or the publish never runs on exactly the builds worth publishing. More in publishing from CI.

Limits

Entry HTML: 5 MB. Assets: 25 MB per file, 250 MB and 500 files total.
60 requests/minute per token.

Try it

Comma is free — unlimited reports, unlimited commenters, unlimited revision history.

Publish a scan report →