Skip to main content
Static analysis is a built-in Code Security check that inspects your application source and built artifacts for security issues before publish. It is deterministic: the same code always produces the same findings. When issues are found, Clark fixes them automatically, and admins control which severity levels block deployment. No configuration beyond enablement is required. Superblocks manages the scanner and normalizes findings into actionable reports.

​
What it scans

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. For dependency and package vulnerabilities, see CVE detection. For issues that require reasoning about application logic rather than pattern matching, see the Security Agent.

​
When it runs

Static analysis runs 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: These thresholds are configurable per organization. You can adjust them based on your risk tolerance and the maturity of your security program.

​
Scope

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

​
What builders see

When a scan completes, builders see findings in their publish readiness checklist:
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 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.

​
Visibility and audit trail

Every scan is recorded as an audit log 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, so you can query security findings from agents, scripts, dashboards, or any other tooling.