> ## Documentation Index > Fetch the complete documentation index at: https://docs.superblocks.com/llms.txt > Use this file to discover all available pages before exploring further. # How findings work > Severity, scan modes, remediation, run errors, and the audit trail shared by every publish-time policy Every policy that runs at publish time behaves the same way once it produces a finding. This page covers that shared behavior: how severity is assigned, what a scan mode does, how remediation clears a gate, what happens when a run fails, and what lands in the audit log. It applies to [static analysis](/admin/code-security/static-analysis), the [Security Agent](/admin/code-security/security-agent), and publish-time [CVE detection](/admin/code-security/supply-chain/cve-detection). Two CVE detection moments work differently and are documented on that page. At install time, the check runs long before anyone publishes, so there is no scan mode to apply: Clark either installs the package, swaps it for a safe version, or blocks it. Continuous monitoring uses the same severities, but it reports to [Security Center](/admin/code-security/supply-chain/cve-detection#continuous-monitoring) rather than gating a publish. ## Severity Every finding carries a severity that reflects how serious the issue is and how likely it is to be exploited: | Severity | Rationale | | ------------ | ----------------------------------------------------------------------------------------------------- | | **Critical** | Directly exploitable with serious impact, such as a live credential in the shipped bundle | | **High** | A real vulnerability reachable from user input, such as an injection sink on an unsanitized parameter | | **Medium** | Worth reviewing, but exploitation depends on conditions that may not hold in your app | | **Low** | Hardening and hygiene, with no path to impact on its own | | **Info** | Context for the reviewer, not a defect | **Critical** and **High** findings are the only ones that can block a publish. Whether they do depends on the scan mode your admins set. Everything below High is always reported and never blocks. Severity reflects exploitability in context, not just pattern match. A mitigation such as input validation, output escaping, or platform-level access control lowers the severity of a finding rather than leaving it at its theoretical worst case. ## Scan modes The mode decides what happens when a policy produces a critical or high finding. It is set per policy, not per organization, so static analysis and the Security Agent each carry their own. | Mode | Critical and high findings | How a publish still goes out | | ---------------------------- | ------------------------------------------ | ----------------------------------------------------------- | | **Advisory** | Reported. Publish is not blocked. | The builder publishes as usual. | | **Blocking with exceptions** | The checklist guides the builder to a fix. | The builder can click **Publish anyway**. | | **Blocking** | Publish is blocked. | It does not. Every critical and high finding must be fixed. | New policies default to **Advisory**. ### Advisory The policy runs and reports what it found. Critical and high findings do not stop the publish. Use this mode to measure finding volume before you enforce a policy. ### Blocking with exceptions The publish checklist surfaces critical and high findings and points the builder at a fix, usually **Fix with Clark**. If the builder still wants to ship, they click **Publish anyway**. Anyone with deploy access on the application can do this, and it is the path for a false positive or an accepted risk. This is the right mode for most teams. It makes findings hard to miss and still leaves an escape hatch. ### Blocking Same guidance as Blocking with exceptions, with **Publish anyway** removed. Critical and high findings stop the publish until they are gone. There is no override. Use it where a critical or high finding must never reach production. ## Scope Some policies apply to every app. Others can be limited to a subset. | Scope | What it means | | ------------ | ---------------------------------------------------------------------------------- | | **All apps** | The policy's mode applies to every application in the organization | | **Limited** | The policy's mode applies only to the apps you select. Other apps skip this policy | Use a limited scope when one app needs a stricter mode than the rest of the fleet. For example, keep the Security Agent on Advisory for most apps, and set it to Blocking on the apps that handle sensitive data. ## Configure a mode and scope 1. Open **Policy Agents** in the dashboard 2. Select the policy and click **Edit** 3. Set **Mode** 4. Set **Scope** to **All apps**, or **Limited** and pick the apps 5. Save The new settings apply to the next run. They do not re-evaluate publishes that already completed. ## What builders see Every publish-time policy reports into **Pre-Publish Policies** on the publish detail, so builders get one view of what passed, what is running, and what is blocking the deploy. Pre-Publish Policies on a publish, showing an advisory run with one info finding Each policy is its own row with its own result. Above, the Security Agent reported one info finding and the security scan passed, so the publish completed. The banner at the top of the section states the mode in effect, which is why this run is marked **Advisory**: findings are reported and nothing blocks. Expand a finding to see: * **What was found**: a clear description of the issue * **Where**: the file path and location in the application * **Severity**: critical, high, medium, low, or info * **Evidence**: the code that triggered the finding, with secrets redacted * **Fix with Clark**: one-click remediation for eligible findings ## Remediation 1. The builder selects the finding they want to fix, and then clicks **Fix with Clark** 2. Clark edits the application to resolve it, for example by removing a hardcoded secret and referencing an environment variable instead 3. A fresh run evaluates the updated application 4. If the finding is resolved, the publish unblocks **Fix with Clark** never marks a policy as passed on its own. A remediation attempt does not clear a blocking gate, because only a fresh run against the new application state can confirm the fix. Policies evaluate and report; Clark makes the changes. Some findings cannot be fixed by Clark and are marked as such. Credential rotation, external account changes, infrastructure work, and human policy decisions all fall outside what Clark can edit. When Clark cannot fix a finding, the outcome depends on the mode: **Publish anyway** under Blocking with exceptions, or a required fix under Blocking. ## Run states and errors Every publish-time run is listed on the **Security runs** tab in Security Center. Filter by app, policy, status, who triggered it, and date. Security Center Security runs tab listing publish-time policy runs **Run status** is what the policy produced. **Decision** is what happened to the publish. In the example above, the security scan passed with no findings, and the Security Agent produced one finding that did not block, so both decisions are allowed. A run moves through these states: | State | Meaning | | ------------- | -------------------------------------------------------------------------- | | **Queued** | The run is scheduled and waiting to start | | **Running** | The policy is evaluating the application snapshot | | **Passed** | The run finished with no findings | | **Findings** | The run produced findings that do not block | | **Blocked** | The run produced critical or high findings under a blocking mode | | **Errored** | The run failed before it reached a verdict | | **Timed out** | The run exceeded its time limit | | **Canceled** | The run was stopped before it finished | | **Stale** | The application changed, so the result no longer describes what would ship | An **errored** or **timed out** run is not a pass. Because the policy never reached a verdict, a blocking policy holds the publish rather than letting an unreviewed app through. Retry the publish to start a fresh run. A **stale** result appears when the application changes after a run completes. The next publish re-runs the policy against the new snapshot. ## Audit trail Every run, finding, remediation attempt, escalation, and **Publish anyway** is recorded as an [audit log](/admin/audit-logs) event. Admins can see what was scanned and when, what findings were produced, what action was taken, and which apps have outstanding advisory findings. The same data is available programmatically through the [Superblocks MCP server](/admin/mcp-server), so you can query findings from agents, scripts, or dashboards. ## Permissions | Action | Permission | | ------------------------------- | -------------------------------- | | View policies, modes, and scope | `policies:view` | | Change a policy's mode or scope | `policies:manage` | | Fix with Clark | Deploy access on the application | | Publish anyway | Deploy access on the application | Admin and Owner get both `policies` actions by default. Developers and end users get neither. ## Related * [Code Security overview](/admin/code-security/index) * [Static analysis](/admin/code-security/static-analysis) * [Security Agent](/admin/code-security/security-agent) * [CVE detection](/admin/code-security/supply-chain/cve-detection)