Skip to main content

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 is currently in beta. Contact support to get on the waitlist.
Security scanning is a built-in Policy Agent 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

CategoryWhat it checksExample findings
Dependency vulnerabilitiesPackage manifests and lockfiles for known CVEsOutdated package with critical RCE vulnerability
Leaked secretsSource code and built artifacts for exposed credentialsAPI key hardcoded in a backend query
Code vulnerabilitiesApplication source for common vulnerability patternsSQL 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:
SeverityRecommended modeRationale
CriticalBlockingHigh-confidence issues that must be fixed before deploy
HighBlockingSignificant vulnerabilities that should not ship
MediumAdvisoryWorth reviewing but unlikely to be exploitable in context
LowAdvisoryInformational 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: 
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.