From 72ed21becfea3d8a0a086b69f9a61ee4f7abbc7b Mon Sep 17 00:00:00 2001 From: Cody Maffucci <46459665+Maffooch@users.noreply.github.com> Date: Thu, 6 Aug 2026 16:40:06 -0600 Subject: [PATCH 1/2] docs(sensei): describe the hub's views and the two fix-quota states MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The Sensei hub's toggle used to mix two questions: "DefectDojo-hosted" and "In-repo CI" listed onboarded repositories, while "Auto-fix Candidates" and "Scan Activity" were views across all of them. The hosted/CI choice is now a scope inside the Repositories view, so document the toggle as the three views it selects, and say plainly that candidates and activity always cover every repository. Also split the two reasons Approve can be disabled. "No fix quota on this license" and "quota exhausted" are opposite situations with different actions, and the hub previously reported both as exhaustion — which told a customer with no quota to wait for a reset that would never come. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_016VjaotfrkL2f2QHvhUcbsh --- docs/content/sensei/fixing_findings.md | 10 ++++++++++ docs/content/sensei/sensei_reference.md | 1 + 2 files changed, 11 insertions(+) diff --git a/docs/content/sensei/fixing_findings.md b/docs/content/sensei/fixing_findings.md index cec5eb58917..8102fdb1870 100644 --- a/docs/content/sensei/fixing_findings.md +++ b/docs/content/sensei/fixing_findings.md @@ -9,6 +9,16 @@ weight: 3 Once a repository is onboarded, Sensei surfaces directly on your findings and on the Sensei hub. This page covers scanning a repository, triaging auto-fix candidates, and remediating individual findings. You need at least **Writer** access to a finding's product to trigger a fix. +## Finding your way around the Sensei hub + +The hub's toggle selects which **view** you are looking at: + +- **Repositories** — the repositories onboarded to Sensei, with their status and row actions. +- **Auto-fix Candidates** — findings staged for approval. +- **Scan Activity** — the ledger of every scan and fix run. + +If an administrator enabled in-repo CI scanning, the Repositories view also offers a **Scanning** choice between **DefectDojo-hosted** and **In-repo CI**. This selects where scans run for the repositories listed; it is not a separate view, so auto-fix candidates and scan activity always cover every onboarded repository regardless of where its scans run. With CI mode off (the default) there is nothing to choose and the control is not shown. + ## Scan a repository Scans import findings into an engagement named after the branch. You can trigger a scan on demand from the Sensei hub: open a repository's row actions and choose **Scan now**. diff --git a/docs/content/sensei/sensei_reference.md b/docs/content/sensei/sensei_reference.md index 55af7a1df64..05542a67567 100644 --- a/docs/content/sensei/sensei_reference.md +++ b/docs/content/sensei/sensei_reference.md @@ -99,5 +99,6 @@ GitHub Enterprise Server uses the **same GitHub App** model as github.com; only - **A repository isn't listed when onboarding.** Only repositories the connection can access are shown. On **GitHub**, confirm the App is installed on the correct organization and its repository access includes the repository. On **GitLab**, confirm the access token's scope covers the project. On **Bitbucket Cloud**, confirm the **workspace** is set (tokens are workspace-scoped). On **Azure DevOps**, confirm the PAT's organization matches and its **Code** scope is granted. - **Scans or fixes never start after a webhook.** Confirm the repository's webhook points at the provider's receiver (`…/sensei/{gitlab,bitbucket,azure}/webhooks`, or `…/sensei/webhooks` for GitHub) with the correct secret/credentials, and subscribes to push + pull-request (+ comment) events. The provider's **recent deliveries** should show `HTTP 200`. Webhook-driven runs fire only for repositories onboarded in **hosted** mode; a push to a non-default branch is scanned via its pull request, not on its own. - **Nothing is happening after a scan.** Check that automated fixes are enabled (and your severity/risk thresholds match findings) on the repository's configuration, and that your **Fixes** quota isn't exhausted. +- **Approve is disabled on every candidate.** The hub says which of the two reasons applies, and they need different actions. *"Your fix quota is exhausted"* means the fixes on your license have all been used, so ask your DefectDojo administrator to raise the limit. *"No fixes are included in this license"* means no fix quota was ever provisioned: scanning and candidate staging still work so you can see what Sensei would fix, but approving needs a quota to be added. > **🔎 Still in BETA:** Sensei is evolving quickly. If behavior doesn't match this guide, check the [Pro changelog](/releases/pro/changelog/) for recent changes. From ecfedf7c2bc8ec4a4821fc589e5ce9d4f533638c Mon Sep 17 00:00:00 2001 From: Cody Maffucci <46459665+Maffooch@users.noreply.github.com> Date: Thu, 6 Aug 2026 17:57:00 -0600 Subject: [PATCH 2/2] docs(sensei): explain that a fix PR does not close the finding MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit A pull request changes the code, not what is running, so the finding stays open after Sensei fixes it — and for a finding that came from a cloud account, merging Terraform changes nothing the scanner reads until the infrastructure change is applied. The badge now distinguishes "PR open" from "PR merged", so document both states and what actually closes the finding. Also note that reappearances of an outstanding fix are recognised as the same issue and do not consume extra fixes, and add both to the troubleshooting list, where "why is this still open?" is the question people arrive with. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_016VjaotfrkL2f2QHvhUcbsh --- docs/content/sensei/fixing_findings.md | 13 ++++++++++++- docs/content/sensei/sensei_reference.md | 2 ++ 2 files changed, 14 insertions(+), 1 deletion(-) diff --git a/docs/content/sensei/fixing_findings.md b/docs/content/sensei/fixing_findings.md index 8102fdb1870..694da5b93b9 100644 --- a/docs/content/sensei/fixing_findings.md +++ b/docs/content/sensei/fixing_findings.md @@ -44,12 +44,23 @@ Clicking **Fix** (on the findings table or in a finding's detail header) opens t ![Fix with Sensei dialog](images/fix_with_sensei_dialog.png) -Sensei generates a remediation and opens a pull request. The finding's fix status is shown as a badge that moves through *in progress* → *PR open* (or *failed*). Once the pull request is open, the badge links straight to it. +Sensei generates a remediation and opens a pull request. The finding's fix status is shown as a badge that moves through *in progress* → *PR open* → *PR merged* (or *failed*). Once the pull request is open, the badge links straight to it. ![Finding detail with fix status badge](images/finding_detail_fix.png) > **💡 One fix, one PR:** each approved fix consumes one fix from your quota and opens one pull request. Review and merge the PR in GitHub as you would any other. +### A fix does not close the finding on its own + +The pull request changes your code; it does not change what is running. So the finding **stays open** after Sensei fixes it, and the badge says which step is still outstanding: + +- **PR open** — the change is waiting to be reviewed and merged. +- **PR merged** — merged, but not yet deployed. + +What closes the finding is the next scan that sees the fix in place. For code scanning that is the next scan of the branch you merged into. For findings that come from a cloud account, it is the next scan *after the infrastructure change is applied* — the scanner reads the account, not your repository, so merging Terraform does not change what it reports. + +While a fix is outstanding, the same finding may keep being reported by each new scan. Sensei recognises those as the same underlying issue and will not stage another candidate or open a second pull request for it, so a slow review or deploy does not consume extra fixes. + ## Auto-fix candidate triage When a repository has automated fixes enabled, each scan stages matching findings as **candidates** on the **Auto-fix Candidates** tab of the Sensei hub. This is Sensei's preview-first model: findings are staged, but **nothing runs (no LLM cost) until you approve**. Approving opens fix pull requests and consumes fixes. diff --git a/docs/content/sensei/sensei_reference.md b/docs/content/sensei/sensei_reference.md index 05542a67567..846762aae2e 100644 --- a/docs/content/sensei/sensei_reference.md +++ b/docs/content/sensei/sensei_reference.md @@ -100,5 +100,7 @@ GitHub Enterprise Server uses the **same GitHub App** model as github.com; only - **Scans or fixes never start after a webhook.** Confirm the repository's webhook points at the provider's receiver (`…/sensei/{gitlab,bitbucket,azure}/webhooks`, or `…/sensei/webhooks` for GitHub) with the correct secret/credentials, and subscribes to push + pull-request (+ comment) events. The provider's **recent deliveries** should show `HTTP 200`. Webhook-driven runs fire only for repositories onboarded in **hosted** mode; a push to a non-default branch is scanned via its pull request, not on its own. - **Nothing is happening after a scan.** Check that automated fixes are enabled (and your severity/risk thresholds match findings) on the repository's configuration, and that your **Fixes** quota isn't exhausted. - **Approve is disabled on every candidate.** The hub says which of the two reasons applies, and they need different actions. *"Your fix quota is exhausted"* means the fixes on your license have all been used, so ask your DefectDojo administrator to raise the limit. *"No fixes are included in this license"* means no fix quota was ever provisioned: scanning and candidate staging still work so you can see what Sensei would fix, but approving needs a quota to be added. +- **A finding is still open after Sensei fixed it.** Expected: the pull request changes your code, not what is running. The badge says whether the change is waiting to be merged or waiting to be deployed, and the finding closes on the next scan that sees the fix in place — for cloud findings, the next scan after the infrastructure change is applied. See [A fix does not close the finding on its own](/sensei/fixing_findings/#a-fix-does-not-close-the-finding-on-its-own). +- **A fixed finding keeps reappearing in new scans.** Also expected while the fix is outstanding, and it does not cost you extra fixes: Sensei links each reappearance back to the original and will not stage a second candidate or open a second pull request for it. > **🔎 Still in BETA:** Sensei is evolving quickly. If behavior doesn't match this guide, check the [Pro changelog](/releases/pro/changelog/) for recent changes.