> ## 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.

# Security scanning

> Detect vulnerabilities, leaked secrets, and insecure patterns in AI-generated code before they reach production

<Note>
  Security scanning is currently in **beta**. [Contact support](mailto:support@superblocks.com) to get on the waitlist.
</Note>

**Security scanning** is a built-in [Policy Agent](/admin/policy-agents/index) that automatically inspects your application code, dependencies, and built artifacts for security issues before publish. When issues are found, Clark fixes them automatically. Admins control which severity levels block deployment and which are advisory.

No configuration beyond enablement is required — Superblocks manages the scanner, keeps vulnerability databases current, and normalizes findings into actionable reports.

## What it scans

| Category                       | What it checks                                          | Example findings                                               |
| ------------------------------ | ------------------------------------------------------- | -------------------------------------------------------------- |
| **Dependency vulnerabilities** | Package manifests and lockfiles for known CVEs          | Outdated package with critical RCE vulnerability               |
| **Leaked secrets**             | Source code and built artifacts for exposed credentials | API key hardcoded in a backend query                           |
| **Code vulnerabilities**       | Application source for common vulnerability patterns    | SQL injection via unsanitized user input, cross-site scripting |

Built-asset scanning is the authoritative gate for secrets — it checks the final bundle that would ship to production, not just the source. If a secret makes it into the build output, the scan catches it regardless of how it got there.

## When it runs

Security scans run automatically at **publish time** — after the application is built and before it deploys. The scan evaluates the exact artifact that would ship to production, so there is no gap between what was checked and what was deployed.

Builders do not need to trigger scans manually. The scan runs in the background and results appear in the publish readiness checklist.

## Admin controls

### Blocking thresholds

Admins configure which severity levels block publish and which are advisory:

| Severity     | Recommended mode | Rationale                                                 |
| ------------ | ---------------- | --------------------------------------------------------- |
| **Critical** | Blocking         | High-confidence issues that must be fixed before deploy   |
| **High**     | Blocking         | Significant vulnerabilities that should not ship          |
| **Medium**   | Advisory         | Worth reviewing but unlikely to be exploitable in context |
| **Low**      | Advisory         | Informational findings for awareness                      |

These thresholds are configurable per organization. You can adjust them based on your risk tolerance and the maturity of your security program.

### Scope

Security scanning applies to all applications in your organization by default. Admins can adjust scope as needed.

## What builders see

When a security scan completes, builders see findings in their publish readiness checklist:

```text theme={null}
Built-in Security Scan    Blocked — 1 critical secret detected
```

Clicking into the report shows each finding with:

* **What was found** — clear description of the issue
* **Where** — file path and location in the application
* **Severity** — critical, high, medium, or low
* **Fix with Clark** — one-click remediation for eligible findings

### Remediation flow

1. Builder clicks **Fix with Clark** on a finding
2. Clark modifies the application to resolve the issue (e.g., removes a hardcoded secret and references an environment variable instead)
3. A fresh security scan runs against the updated application
4. If the finding is resolved, publish unblocks automatically

If Clark cannot remediate a finding, the builder can escalate to an admin. Authorized admins can override a blocking finding when appropriate — for example, if a finding is a false positive or an accepted risk.

## Package visibility

Admins can view all npm packages in use across their organization’s applications, including versions. This gives security teams a centralized software bill of materials without requiring manual inventory.

## Continuous vulnerability monitoring

Security scans run at publish time, but Superblocks also proactively monitors for new CVEs that affect packages already deployed in your applications. When a newly disclosed vulnerability impacts a published app, admins are alerted — even if nothing has changed in the application itself.

## Visibility and audit trail

Every security scan is recorded as an [audit log](/admin/audit-logs) entry. Admins can see:

* What was scanned and when
* What findings were produced
* What action was taken (remediated, escalated, overridden)
* Which apps have outstanding advisory findings

All of this data is available programmatically through the [Superblocks MCP server](/admin/mcp-server), so you can query security findings from agents, scripts, dashboards, or any other tooling.
Admins can view all npm packages in use across their organization's applications, including versions. This gives security teams a centralized software bill of materials without requiring manual inventory.