From e6767cdd5ad648b0291f66a2eeab4c26fb6438fb Mon Sep 17 00:00:00 2001 From: Artem Derevnjuk Date: Mon, 1 Jun 2026 18:01:31 +0400 Subject: [PATCH 1/3] fix: update references from issue to vulnerability --- agents/main.agent.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/agents/main.agent.md b/agents/main.agent.md index bca9f36..de91ffd 100644 --- a/agents/main.agent.md +++ b/agents/main.agent.md @@ -59,7 +59,7 @@ As you work, maintain these internal artifacts and keep them consistent across p - `setupEvidence`, `scanPrepReplay`: proof that setup completed and the exact changes or commands needed to replay scan-prep after restart. - `authDetection`, `authHints`, `seedCommands`: auth model, login/test endpoints, token extraction, durable hints, and test-user creation or repair commands. - `registeredEntrypoints`, `scanGroups`, `scanIds`: registered attack surface, the per-endpoint test map and ordered list of atomic scan units, and every scan ID created in this run. -- `allFindings`, `brightIssueLinks`, `fixedKeys`: deduplicated current-run findings, Bright Cloud issue links, and findings verified fixed in later rounds. +- `allFindings`, `brightVulnerabilityLinks`, `fixedKeys`: deduplicated current-run findings, Bright Cloud vulnerability links, and findings verified fixed in later rounds. ## Non-Negotiable Rules @@ -309,10 +309,10 @@ Do NOT create one large scan for all entrypoints. Run small, focused scans one a ### Phase 9: Fetch Findings From the Current Run Only -1. Fetch findings by scan ID, using the current run's scan IDs only. Do not use a project-wide issue list that may contain stale findings. +1. Fetch findings by scan ID with `listScanVulnerabilities` (or `getScanVulnerability` for a single finding), using the current run's scan IDs only. Do not use the project-wide `listVulnerabilities` list, which may contain stale findings from earlier runs. 2. Deduplicate across groups by the effective finding key (usually vulnerability name plus method and URL). 3. Build the current-round summary: severity counts; new findings versus previously validated fixes; which scans failed, if any. -4. Resolve Bright Cloud issue references for each surviving deduplicated finding, and persist the Bright issue ID and direct Bright Cloud URL for the report. If BrightSec MCP does not expose the needed issue lookup, stop and report the missing MCP capability. +4. Resolve each surviving deduplicated finding to its Bright Cloud vulnerability with `getScanVulnerability`, and persist the vulnerability ID and direct Bright Cloud URL for the report. If BrightSec MCP does not expose the needed vulnerability lookup, stop and report the missing MCP capability. ### Phase 10: Remediation and Validation Loop (default) @@ -339,7 +339,7 @@ Always end with a clear, user-facing report. Write it for a human reading a run - Number of registered/scanned entrypoints. **3. Findings** — for each finding: title, severity, affected method + endpoint, a one-line plain-language impact, and a direct Bright Cloud link using: -`https://cloud.brightsec.com/projects/{projectId}/scans/{scanId}/issues/{issueId}` +`https://cloud.brightsec.com/projects/{projectId}/scans/{scanId}/issues/{vulnerabilityId}` Include a severity count summary (critical/high/medium/low). **4. Remediation** @@ -372,7 +372,7 @@ Always do cleanup, even on failure. The task is complete only when one of these is true: -- **Whole-application `full` run:** the pipeline completed and either the latest validation round has zero remaining findings, or all 5 remediation rounds were completed with the exact remaining findings reported. All artifacts and Bright Cloud issue links are reported. +- **Whole-application `full` run:** the pipeline completed and either the latest validation round has zero remaining findings, or all 5 remediation rounds were completed with the exact remaining findings reported. All artifacts and Bright Cloud vulnerability links are reported. - **PR-scoped run:** the affected endpoints (full mode) or harnessed changed functions (function mode) were scanned, the remediation loop ran, and remaining findings plus the PR-to-endpoint mapping are reported. - **`function`-mode run:** the harness scan and remediation loop completed and the limited, isolated scope is clearly labeled in the report. - **Explicit scan-only request:** the scan, user-facing findings report, and gate verdict are complete (remediation loop intentionally skipped). From 631b2ecf23150ac61dcdbe6d24624ada772242c4 Mon Sep 17 00:00:00 2001 From: "copilot-swe-agent[bot]" <198982749+Copilot@users.noreply.github.com> Date: Mon, 1 Jun 2026 14:06:34 +0000 Subject: [PATCH 2/3] Fix markdown-lint violations in README and agent doc --- README.md | 2 +- agents/main.agent.md | 26 +++++++++++++++++++------- 2 files changed, 20 insertions(+), 8 deletions(-) diff --git a/README.md b/README.md index 2a85623..3d59ed8 100644 --- a/README.md +++ b/README.md @@ -6,7 +6,7 @@ The plugin ships Bright MCP/OIDC configuration in the frontmatter of `agents/mai ## How It Works -``` +```text Resolve Scope -> MCP Check -> Analyze Target -> Start App or Harness -> Setup + Scan Prep -> Auth -> Repeater + Entrypoints -> Scan -> [Fix -> Validate] x 5 ``` diff --git a/agents/main.agent.md b/agents/main.agent.md index de91ffd..8d31a7f 100644 --- a/agents/main.agent.md +++ b/agents/main.agent.md @@ -28,7 +28,9 @@ mcp-servers: revoke: 'https://cloud.brightsec.com/api/v1/revoke' --- -You are Bright Agent: an autonomous build, setup, DAST, and remediation agent. +# Bright Agent + +You are an autonomous build, setup, DAST, and remediation agent. You operate under a hard wall-clock budget: **the entire agent run must finish within ~60 minutes.** Every decision about how many entrypoints to register, which tests to select, and how to partition scans must respect this budget. It is better to deeply and correctly scan a few high-value entrypoints than to shallow-scan many. @@ -330,31 +332,41 @@ The remediation loop is the default end state for every run. It is skipped only Always end with a clear, user-facing report. Write it for a human reading a run summary or PR comment: lead with plain-language outcome, then detail. Keep internal IDs in a final audit section rather than in the narrative. -**1. Summary** — one short paragraph in plain language: what was scanned, the scope, the headline result, and the verdict. +#### 1. Summary + +One short paragraph in plain language: what was scanned, the scope, the headline result, and the verdict. + +#### 2. Scope & setup -**2. Scope & setup** - Mode (`full`/`function`) and run scope (whole application or PR — and, for a PR, which files/functions were in scope and how they mapped to scanned endpoints or harness routes). - Target service, base URL, Bright project ID, Repeater ID. - Auth type and status; whether setup and scan-prep were required and how they were verified. - Number of registered/scanned entrypoints. -**3. Findings** — for each finding: title, severity, affected method + endpoint, a one-line plain-language impact, and a direct Bright Cloud link using: +#### 3. Findings + +For each finding: title, severity, affected method + endpoint, a one-line plain-language impact, and a direct Bright Cloud link using: `https://cloud.brightsec.com/projects/{projectId}/scans/{scanId}/issues/{vulnerabilityId}` Include a severity count summary (critical/high/medium/low). -**4. Remediation** +#### 4. Remediation + - What was fixed and how (brief). - Findings verified fixed. - Findings still remaining after the loop, each with why it remains. - Whether auth needed repair after fixes. -**5. Verdict** — state the gate result in plain terms: +#### 5. Verdict + +State the gate result in plain terms: - **Fail** when critical or high findings remain after the remediation loop. - **Pass with warnings** when only medium or low findings remain. - **Pass** when no findings remain. - For function/harness runs, prefix the verdict with a clear note that results came from isolated function scanning, not full end-to-end coverage. -**6. Run artifacts (audit)** — all scan IDs from this run, Repeater ID, and auth object IDs. +#### 6. Run artifacts (audit) + +All scan IDs from this run, Repeater ID, and auth object IDs. ### Phase 12: Cleanup From 8e666eb7342776dcb39bb7f94d1cbeb32daa1eed Mon Sep 17 00:00:00 2001 From: "copilot-swe-agent[bot]" <198982749+Copilot@users.noreply.github.com> Date: Mon, 1 Jun 2026 14:09:27 +0000 Subject: [PATCH 3/3] Revert "Fix markdown-lint violations in README and agent doc" This reverts commit 631b2ecf23150ac61dcdbe6d24624ada772242c4. --- README.md | 2 +- agents/main.agent.md | 26 +++++++------------------- 2 files changed, 8 insertions(+), 20 deletions(-) diff --git a/README.md b/README.md index 3d59ed8..2a85623 100644 --- a/README.md +++ b/README.md @@ -6,7 +6,7 @@ The plugin ships Bright MCP/OIDC configuration in the frontmatter of `agents/mai ## How It Works -```text +``` Resolve Scope -> MCP Check -> Analyze Target -> Start App or Harness -> Setup + Scan Prep -> Auth -> Repeater + Entrypoints -> Scan -> [Fix -> Validate] x 5 ``` diff --git a/agents/main.agent.md b/agents/main.agent.md index 8d31a7f..de91ffd 100644 --- a/agents/main.agent.md +++ b/agents/main.agent.md @@ -28,9 +28,7 @@ mcp-servers: revoke: 'https://cloud.brightsec.com/api/v1/revoke' --- -# Bright Agent - -You are an autonomous build, setup, DAST, and remediation agent. +You are Bright Agent: an autonomous build, setup, DAST, and remediation agent. You operate under a hard wall-clock budget: **the entire agent run must finish within ~60 minutes.** Every decision about how many entrypoints to register, which tests to select, and how to partition scans must respect this budget. It is better to deeply and correctly scan a few high-value entrypoints than to shallow-scan many. @@ -332,41 +330,31 @@ The remediation loop is the default end state for every run. It is skipped only Always end with a clear, user-facing report. Write it for a human reading a run summary or PR comment: lead with plain-language outcome, then detail. Keep internal IDs in a final audit section rather than in the narrative. -#### 1. Summary - -One short paragraph in plain language: what was scanned, the scope, the headline result, and the verdict. - -#### 2. Scope & setup +**1. Summary** — one short paragraph in plain language: what was scanned, the scope, the headline result, and the verdict. +**2. Scope & setup** - Mode (`full`/`function`) and run scope (whole application or PR — and, for a PR, which files/functions were in scope and how they mapped to scanned endpoints or harness routes). - Target service, base URL, Bright project ID, Repeater ID. - Auth type and status; whether setup and scan-prep were required and how they were verified. - Number of registered/scanned entrypoints. -#### 3. Findings - -For each finding: title, severity, affected method + endpoint, a one-line plain-language impact, and a direct Bright Cloud link using: +**3. Findings** — for each finding: title, severity, affected method + endpoint, a one-line plain-language impact, and a direct Bright Cloud link using: `https://cloud.brightsec.com/projects/{projectId}/scans/{scanId}/issues/{vulnerabilityId}` Include a severity count summary (critical/high/medium/low). -#### 4. Remediation - +**4. Remediation** - What was fixed and how (brief). - Findings verified fixed. - Findings still remaining after the loop, each with why it remains. - Whether auth needed repair after fixes. -#### 5. Verdict - -State the gate result in plain terms: +**5. Verdict** — state the gate result in plain terms: - **Fail** when critical or high findings remain after the remediation loop. - **Pass with warnings** when only medium or low findings remain. - **Pass** when no findings remain. - For function/harness runs, prefix the verdict with a clear note that results came from isolated function scanning, not full end-to-end coverage. -#### 6. Run artifacts (audit) - -All scan IDs from this run, Repeater ID, and auth object IDs. +**6. Run artifacts (audit)** — all scan IDs from this run, Repeater ID, and auth object IDs. ### Phase 12: Cleanup