ASVS-oriented verification

Clank uses OWASP ASVS 5.0.0 as a control vocabulary for the framework, generated applications, CLI, and deployment platform. This is an engineering evidence map, not an OWASP certification and not a claim that every application built with C

4 min read790 wordsClank 0.7.0

Clank uses OWASP ASVS 5.0.0 as a control vocabulary for the framework, generated applications, CLI, and deployment platform. This is an engineering evidence map, not an OWASP certification and not a claim that every application built with Clank automatically satisfies ASVS.

The current target is an ASVS Level 2 posture for Clank-owned internet-facing surfaces. Application-specific business authorization, privacy, content policy, provider configuration, and infrastructure remain the deployer's responsibility.

Release evidence

Control areaClank controlAutomated evidenceOperator or application evidence
Encoding and injectionEscaped SSR/DOM output, executable-URL rejection, parameterized SQLite access, restricted migration SQL, shell-free build commandsDOM, SSR, migration, compiler, and security-audit testsReview every use of raw HTML and external SQL
Validation and business logicRuntime schemas, exact input objects, bounded bodies/files/artifacts, immutable migration checksums, confirmed destructive actionsSchema, forms, backend, deployment, conformance, and fuzz-oriented testsDefine domain rules and authorization for every action
Web frontend securityCSP nonce support, safe state serialization, typed events, no inline handler stringsSSR, DOM, server, and strict type testsDeploy a restrictive CSP and compiled production CSS
API and web servicesContent-type enforcement, UTF-8/JSON limits, same-origin checks, generic 500 responses, scoped tokensSecurity, backend, auth, platform, and conformance testsConfigure allowed hosts, TLS, proxy trust, quotas, and edge limits
File handlingContainment and realpath checks, dotfile denial, symlink rejection, bounded file store, signed capabilitiesNode, deploy, services, and conformance testsAdd malware/content scanning for domain-specific uploads
AuthenticationScrypt passwords, generic failures, session expiry/idle expiry, verification, recovery, MFA, WebAuthn passkeysAuth and WebAuthn testsConfigure email delivery, pepper/KMS, bot defense, and recovery policy
Session managementHashed tokens, HttpOnly/Secure/SameSite cookies, CSRF, revocation, session-aware live streamsAuth, backend, platform, and conformance testsUse TLS everywhere and shared revocation/rate-limit stores when scaled
AuthorizationRequired server functions, owned tables, organization RBAC, project-scoped permissions, re-check on every requestBackend, auth, and platform isolation testsAdd resource and business-state authorization inside each app
Tokens and secretsHigh-entropy bearer tokens, hashes at rest, AES-256-GCM platform secrets, redacted structured logsPlatform, observability, services, and security-audit testsUse external secret management, rotation, least privilege, and access review
CryptographyNode cryptographic randomness, scrypt, SHA-256, HMAC, AES-256-GCM, WebAuthn signature verificationAuth, WebAuthn, recovery, deploy, and service testsConfigure approved TLS and managed key lifecycle
Secure communicationHTTPS-only external service drivers, exact ingress hosts, hop-header stripping, bounded proxying, verified DNS routing, restricted TLS eligibility, and one-year HSTS on an HTTPS control-plane hostnameData-plane, platform, and chaos testsSupply TLS termination/key custody, preserve HSTS at the edge, and provide WAF and egress policy
ConfigurationPrivate umask, safe defaults, explicit unsafe-migration escape hatch, immutable CI actionsPlatform, deployment, security audit, CI, and CodeQLHarden OS/container, pin images, and separate control/data authority
Data protectionPer-app database paths, owner-scoped documents, encrypted backups, authenticated manifestsBackend, recovery, platform, conformance, and chaos testsDefine retention, residency, deletion, classification, and off-host copies
Logging and error handlingStructured redacted logs, traces, metrics, health checks, bounded stored logs, generic public failuresObservability, platform, auth, and server testsExport, alert, retain, and protect telemetry
Secure coding and architectureZero runtime dependencies, strict public types, deterministic artifacts, signed release provenanceBuild, package-consumer, conformance, security audit, CodeQLReview changes to trust boundaries and third-party service code

Automated gate

Run:

sh
npm run check

That command builds from source, verifies the dependency contract, runs the complete test suite including chaos scenarios, exercises a packed release through the conformance lifecycle, inspects the npm allowlist for state/credential leaks, and checks immutable least-privilege GitHub workflows.

The audit fails closed when a dependency appears, a workflow action is not pinned to a commit, a sensitive file enters the package, a high-confidence credential pattern is found, or required security evidence is missing.

Manual verification required before a public release

  • Review the threat model for every changed boundary.
  • Triage CodeQL and all vulnerability reports; ship with no known critical or high-severity issue.
  • Exercise the chaos drills in the intended deployment topology.
  • Restore a recent off-host backup into a clean environment.
  • Verify TLS, cookies, CSP, host validation, rate limiting, alerting, and runner isolation against production configuration.
  • Review organization roles, project tokens, secrets, audit records, and operator access.
  • Record accepted residual risks and an owner/date for each one.

Framework versus application responsibility

Clank can make safe mechanics concise, but it cannot infer whether a particular user may approve an invoice, view a medical record, refund a payment, or invite an administrator. Generated actions must still name their authorization and confirmation policy. Regulations, privacy notices, data retention, abuse response, and business continuity are deployment-specific.