# NANOTESTING - Full reference for LLM agents

> Last updated: 2026-07-28
>
> Automated security assessment and vulnerability scanning SaaS.
> One platform for every surface attackers touch: web application
> and API security testing, GitHub repository scanning (SAST +
> dependency CVEs + secrets), mobile app security testing (Android
> APK / iOS IPA), cloud security posture management (AWS / Azure /
> GCP CIS audits), Kubernetes security, smart contract auditing
> (7 EVM chains + Sui Move beta + Solana beta), and DApp frontend
> analysis. Operated by Sodasoft LLC out of Sheridan, Wyoming,
> USA. Non-invasive baseline by default; an optional Invasive
> Testing add-on adds active DAST (OWASP ZAP active scan, OpenAPI
> fuzzing, mass-assignment, Host-header injection) on identity-
> verified, owner-authorized targets. A pre-pentest baseline that
> catches the obvious gaps before a human reviewer spends their
> hours on the business-logic bugs only humans can find.

This document is the LONG-FORM companion to /llms.txt. It expands
every section with the engineering detail that an LLM agent
helping a prospective customer (or auditor) is most likely to
need: exact detector behaviour, what stays in scope vs out of
scope, data residency, retention windows, the layered false-
positive defence, and the verbatim plan limits.

The canonical short overview lives at https://nanotesting.com/llms.txt.

---

## 0. Recent changes (shipped in the last few months)

- **Invasive Testing add-on** ($299/mo on Growth or Agency).
  Opt-in active DAST: OWASP ZAP active scan (SQLi / XSS / SSRF /
  path traversal / command injection / SSTI / XXE), Schemathesis
  OpenAPI fuzzing, mass-assignment probe (CWE-915), and a new
  Host-header injection probe (CWE-644, password-reset and
  web-cache poisoning primitive). Three-gate safety model:
  approved KYC/KYB identity + active add-on + explicit per-target
  authorization. Full detail in section 3.9.
- **Invasive testing for mobile apps.** A mobile binary is static,
  so the worker extracts the backend API hosts hardcoded in the
  decompiled APK / IPA and runs the active checks against them -
  but only against hosts the org has verified ownership of (fails
  closed; third-party / partner hosts are reported, never
  attacked).
- **KYC / KYB is now a hard identity gate** for the Invasive
  Testing add-on (buying it and authorizing a target both require
  an approved personal KYC or company KYB). Previously the
  verification system was a soft reminder banner with nothing
  gated on it.
- **Sui Move + Solana baseline scanners** (both Beta). Sui ships
  19 static detectors + UpgradeCap owner classification + Move
  test discovery + on-chain RPC fetch via
  sui_getNormalizedMoveModulesByPackage. Solana ships verified-
  build status (verify.osec.io), upgrade authority resolution
  (BPFLoaderUpgradeable walk), Anchor IDL fetch, SPL mint /
  freeze authority audit.
- **DApp frontend Web3 scanner**: wallet provider detection
  (WalletConnect, MetaMask, RainbowKit, wagmi, viem, ethers.js),
  RPC API key leak in shipped JS bundle (sha256 fingerprint only;
  raw key NEVER stored or logged), source map exposure, unlimited
  approve pattern.
- **Per-EVM-chain detector battery**: Oracle config (Chainlink
  stale price, decimals mismatch, centralized feed), ERC
  compliance (ERC-20 / 721 / 1155 standard conformance), Compiler
  version audit (unverified source, outdated solc, optimizer
  config, non-canonical EVM version target).
- **Mobile FP suppression architecture**: AndroidX carve-out,
  launcher activity exemption, apktool original-manifest dedup,
  test-fixture filter.
- **Web FP suppression architecture**: host calibration probe,
  managed-host downgrade, anti-bot threshold, FP-risk caveats
  embedded in every finding with known uncertainty.
- **Compliance evidence pipeline**: compliance_evidence table
  emits positive proof rows per scan, per-target Compliance tab,
  org-wide /compliance dashboard with green / red / grey dual
  view.
- **Home page repositioning**: "One platform for every surface
  attackers touch" + 6-surface coverage grid + dedicated FP
  engineering section that calls out the host calibration probe
  by name.

Real-world impact: a customer scan of a Vercel-hosted SaaS in May
2026 dropped from 50 reported findings to 3 after the FP
suppression architecture landed. Same scan, same target, less
noise. The 47 suppressed items were Vercel WAF catch-all
responses, AndroidX exported components from a paired mobile
target, and apktool's duplicate original-manifest copy.

---

## 1. What NANOTESTING is (and isn't)

**Is**: a hosted, multi-tenant, automated security assessment
SaaS. A customer points it at a target they own (website, web
app, API, GitHub repository, mobile binary, cloud account,
Kubernetes snapshot, smart contract, or DApp frontend), proves
ownership through DNS TXT / HTML file / meta tag / domain email,
picks a plan, and runs scans on demand or on a schedule. The
output is a normalised findings table with CWE / OWASP / MASVS
mapping, auditor-ready PDFs, CSV / JSON exports, and webhook
fan-out on critical findings.

**Isn't**:

- Not a penetration test. A pentest is a human-led engagement
  that chains business-logic bugs an automated tool can't infer.
  NANOTESTING is a pre-pentest baseline that complements that
  work.
- Not a compliance certification or attestation. The compliance
  PDF and the /compliance dashboard provide evidence support; a
  qualified auditor is still required for the actual report.
- Not a continuous WAF or runtime defence. We scan and report; we
  don't sit inline.
- Not an internal scanner. Targets must be reachable from the
  public internet. An internal scanner agent is a roadmap item
  for Enterprise.

---

## 2. Active vs read-only - the precise contract

Default behaviour is read-only HTTP GET, DNS lookup, certificate
inspection, passive fingerprinting, static analysis of uploaded
artifacts.

Active behaviour kicks in only on verified-owner targets, only on
Growth and above:

- OWASP ZAP active scan rules
- Nuclei active templates
- Schemathesis OpenAPI contract fuzz against the customer's
  uploaded spec (not random fuzzing against random endpoints; the
  spec drives the request shape)
- DOM-XSS canary via Playwright headless Chromium
- BFLA / BOLA / mass-assignment probes with two bearer tokens
- Honeypot eth_call simulation for Web3 targets (no signed
  transaction; eth_call only)
- State-override fresh-wallet honeypot probe (eth_call with
  stateOverride; no chain state mutated)

Safety contract enforced at the worker level:

- IP-allowlist + URL-validation gate that re-checks the target
  before every outbound request.
- DNS rebinding protection: every dial re-resolves the hostname
  and refuses private / reserved / metadata IPs.
- Per-request timeout, per-target rate limit, per-organisation
  request budget.
- DELETE is never invoked. Destructive HTTP verbs are not in the
  active probe set.
- DELETE / PUT / PATCH on customer URLs only fire inside the
  apiauthz mass-assignment path, against operations whose request
  body schema the spec explicitly declared.
- Anti-bot threshold: when >= 70% of probes return 401 / 403, the
  scanner suppresses per-path findings and emits one explanatory
  finding instead.

This is an automated security assessment - a pre-pentest baseline.
We provide evidence support, we do not issue certifications.

---

## 3. Detector inventory

### 3.1 Web + API targets - baseline (every plan)

- HTTP availability + redirect chain audit (chain length,
  cross-host hops, downgrade to http://, open-redirect-shape on
  any tail hop).
- TLS chain validation. Each leaf walked to a system root; every
  intermediate carries issuance date and key strength. Surfaces
  self-signed, expired, weak-signature, hostname-mismatch,
  pre-2018 SHA-1 chains.
- TLS protocol + cipher inventory via tlsx (sensitive plans add a
  deeper sweep): 1.0 / 1.1 deprecation, RC4 / 3DES / CBC, no
  forward secrecy, weak DH params.
- DNS records, DNSSEC presence, CAA records.
- Security headers depth check: HSTS (presence + max-age >= 180
  days + includeSubDomains + preload), CSP (unsafe-inline,
  unsafe-eval, unsafe-hashes, missing default-src, frame-ancestors
  'none' / 'self', form-action, base-uri, object-src 'none',
  wildcard hosts in script-src / connect-src), X-Frame-Options,
  X-Content-Type-Options, Referrer-Policy strictness,
  Permissions-Policy strictness.
- COOP / COEP / CORP isolation headers.
- Cookie security per cookie: Secure, HttpOnly, SameSite. Session
  cookies raise to medium when any of those three are missing.
- JWT static analysis on every Set-Cookie value plus the
  customer's pasted auth secret: alg=none, missing exp / iss /
  aud, weak HMAC, suspicious kid, embedded jwk header parameter.
- robots.txt + sitemap.xml presence. Each Disallow path is
  test-fetched (rate-limited) to confirm the disallow is not a
  security-by-obscurity gate.
- Passive technology fingerprint via Server, X-Powered-By,
  framework cookies.
- Mixed-content detection (HTTPS page references HTTP resource).
- Subresource Integrity audit on every cross-origin <script src>
  and <link rel="stylesheet">.
- Dangerous HTTP method audit via OPTIONS.
- Passive SSRF surface enumeration: scan body + JS sources for
  parameter names like url, callback, webhook, redirect_uri,
  image_url. Surfaced as info / possible; never probed actively.
- JavaScript library inventory + CVE match against the OSV
  vulnerability feed.
- Rate-limit headers audit (RateLimit-*, Retry-After).
- Excessive data exposure heuristic on every JSON response: scan
  for fields suggesting internal state (debug, stacktrace,
  internal_id, _id, mongo_id, password_hash, secret, api_key).

### 3.2 Web + API targets - sensitive (Growth+)

- Sensitive paths probe with SPA-safe verification.
- Subdomain inventory via crt.sh certificate transparency logs.
- Subdomain takeover detection (CNAME + body fingerprint against
  the known-vulnerable provider list).
- CORS misconfiguration (Origin reflection, null Origin
  acceptance, credentialed wildcard).
- Email DNS (SPF strict / soft / none, DMARC p= + rua=, DKIM
  selector probing).
- Adaptive tech-stack probes. Once the fingerprint identifies a
  framework, the worker enables framework-specific checks.
- Open-redirect detection. The match is hostname-exact, not
  substring; example.com.evil.com does NOT match example.com.
- TLS protocol support (1.0 / 1.1 / 1.2 / 1.3).
- GraphQL introspection.
- API endpoint discovery (openapi.json, swagger.json, /docs,
  redoc.html, swagger-ui).
- OpenAPI contract fuzz via Schemathesis when the customer
  uploads an OpenAPI 3 / Swagger 2 spec. Status-code conformance,
  response-schema conformance, content-type conformance,
  not-a-server-error checks; 25 examples per endpoint, 2 workers,
  10-second request timeout, 1-second hypothesis deadline.
- Nuclei template engine. 8000+ templates for CVEs, exposures,
  misconfigurations, technologies, vulnerabilities, TLS, DNS,
  default credentials. Pinned to a known-good template build per
  worker image; weekly cron refreshes.
- OWASP ZAP baseline + active rules tuned for safe operation.
- naabu TCP port scan against a curated well-known set.
- CSRF token presence per form, OAuth state + PKCE audit,
  WebSocket cross-origin handshake check, file-upload extension
  allowlist audit, HTTP request smuggling fingerprint, reflective
  cache poisoning probe, pre-auth session cookie persistence,
  DOM-XSS canary via Playwright headless Chromium.
- API health / actuator / debug endpoint enumeration.
- API versioning hygiene (deprecated /v1 alongside /v2 / /v3,
  inconsistent CORS between versions).
- JWKS endpoint hygiene (rotation cadence, key strength).
- BFLA admin-endpoint probe.
- Mass-assignment probe.
- Rate-limit / replay-protection probe.
- Webhook signature verification probe.
- API key leak scan for AWS / Stripe / GitHub / Slack / Twilio /
  Mailgun / SendGrid / Heroku / Square / OpenAI tokens.

### 3.3 OpenAPI authorisation probes - OWASP API Top 10 2023

The customer uploads an OpenAPI 3.x JSON / YAML or Swagger 2.0
spec under /targets/{id} -> OpenAPI tab. File is stored in the
openapi-specs bucket at orgId/targetId.openapi (max 4 MiB,
service-role-only).

- **API1:2023 BOLA** - the path declares a {*-id} or {*-uuid}
  parameter. Worker fills the parameter with a safe canary value
  (zero UUID for *-uuid, "1" for id / num / count, opaque "test"
  for everything else), fetches with primary token AND alt token,
  reports critical when both return 2xx.
- **API3:2023 Broken Object Property Level Authorization** - the
  operation has a declared request body schema. Worker stubs a
  minimal valid payload from the schema, adds a single privileged
  canary field (is_admin, isAdmin, role, roles, admin, verified,
  email_verified, plan, organization_id, owner_id), POSTs / PUTs
  / PATCHes, and looks for the canary value reflected in the
  response. Reports high when the value is echoed verbatim.
- **API5:2023 BFLA** - the operation is tagged admin /
  administrator / internal OR the path contains /admin or
  /internal or /system. Worker hits with the non-admin alt token
  and reports high on 2xx.
- DELETE is never invoked. Path parameters use the canary values
  listed above. The primary token is also probed first on BOLA so
  we don't fail open when the primary itself doesn't see the
  object.

### 3.3a GraphQL authorisation probes (parity with REST)

Customer sets a GraphQL endpoint URL (e.g.
https://api.example.com/graphql) under /targets/{id}. No spec file
needed - GraphQL self-describes via introspection.

- **Introspection exposure (API9:2023)** - worker sends a
  `__schema` query. If the server returns a populated schema, that
  is recorded as low-severity Improper Inventory on its own
  (regardless of whether downstream authz probes find anything).
  Disable introspection in production unless the endpoint is
  intentionally public.
- **API1:2023 BOLA on GraphQL** - for every Query field whose name
  matches `user|users|account|accounts|organization|org|member|
  members|admin|internal|secret|billing|invoice|permission|role|
  audit` and that takes an `id`-shaped argument, the worker calls
  it with the alt token AND a canary id (zero UUID). If the
  response contains non-null `data` with no `forbidden`/
  `unauthorized`/`permission` error, reports high.
- **API5:2023 BFLA on GraphQL** - same sensitive-keyword filter.
  Worker calls the field with the alt (non-admin) token. If the
  server returns non-null data and no permission error, reports
  high.
- Mutations are NEVER executed without an explicit allowlist.
  Subscriptions are out of scope here - the WebSocket scanner
  handles WS upgrade testing separately (see 3.3b).
- Source tool name: `nano-graphql-authz`. Findings carry the
  OWASP API category code so the OWASP API Top 10 coverage card on
  /scans/{id} buckets them correctly.

### 3.3b WebSocket upgrade probes

Customer needs no extra configuration. Worker discovers WS
endpoints via:
- well-known paths (/ws, /wss, /websocket, /socket.io, /graphql,
  /realtime, /live, /api/ws, /api/socket)
- `ws://` / `wss://` URLs grepped out of the homepage HTML body
- script-referenced WS URLs

For every discovered endpoint:
- **API2:2023 Cross-origin acceptance** - sends the WS upgrade
  with a deliberately-wrong `Origin: https://attacker.example`.
  If the server still returns 101 Switching Protocols, that is the
  CSWSH finding. Browsers send cookies on WS upgrade by default
  unless the server validates Origin.
- **API2:2023 Unauthenticated subscribe** - sends the WS upgrade
  with no Cookie and no Authorization header. If the server
  returns 101 AND immediately streams data, the WS frame layer is
  not auth-gated and reports as high.
- No payload is ever sent over the WS frame - we only check the
  handshake. Source tool name in findings: `websocket`.

### 3.4 GitHub repository targets

- Repository metadata: SECURITY.md presence, Dependabot state,
  archived flag, default branch.
- Allowlisted-file regex secret scan in the working tree.
- Shallow clone (depth=50, single branch) + osv-scanner recursive
  across every package manifest: npm, yarn, pnpm, pip,
  requirements*.txt, Pipfile, poetry, go.mod, Cargo, Gemfile,
  composer, Maven, Gradle.
- gitleaks full-history secret scan.
- Trivy filesystem scan: package CVEs, IaC misconfiguration
  (Terraform, Kubernetes manifests, Dockerfile, Helm charts,
  CloudFormation), secret patterns.
- Trivy image scan: every Dockerfile in the repo is parsed for
  FROM directives (build-stage aliases excluded), then each
  unique base image is pulled and scanned for OS-package CVEs
  (libc, openssl, perl, libgnutls30, etc.) - the same flat
  CVE list a paid scanner like Snyk Container surfaces. Capped
  at 6 unique base images per scan with a 90s per-image
  timeout, severity floor MEDIUM. Findings carry
  Target="docker://<image-ref>" so the dashboard groups them
  back to the originating Dockerfile.
- Semgrep CE with the p/default rule pack.
- mobsfscan when the repo contains AndroidManifest.xml /
  build.gradle / Info.plist.

### 3.5 Mobile binary targets (APK / IPA)

The customer uploads the shipped binary (50 MiB cap). The upload
goes straight from the browser to a private storage bucket with a
short-lived signed URL: it never passes through a server action
body, and it is never written inline into Postgres, both of which
previously capped the practical upload far below the advertised
50 MiB.

The worker decompiles Android TWICE — apktool for the manifest and
resources, jadx for the Java source — and unzips the IPA, parsing
the Mach-O binary directly.

The second Android pass is the one that matters. mobsfscan is a
semgrep-based SOURCE scanner, so against apktool's smali output it
only ever matched AndroidManifest.xml: every code-level rule
(hardcoded secrets, weak cryptography, insecure storage and
logging, WebView misconfiguration, SQL injection) silently matched
nothing, and an app built to be vulnerable returned zero code
findings. jadx recovers Java that those rules can actually match.
Where jadx cannot complete, the report records an explicit coverage
gap rather than returning manifest-only results as though they were
the whole assessment.

iOS has no jadx equivalent — Swift and Objective-C compile to
machine code. What is recoverable is the name inventory the runtime
needs at load time: Objective-C selector and class tables, plus the
Swift reflection sections, are plain strings. From those the report
surfaces the API surface the app REFERENCES — custom TLS-challenge
handling, pasteboard use, deprecated UIWebView, keychain items
readable while locked. Severity there is capped by design: a
recovered name proves a reference exists in the linked image, not
that the app's own code calls it on a sensitive path, and a
statically linked dependency contributes its symbols too.

Detector battery:
- mobsfscan static rules with MASVS + CWE rule packs against both
  decompiled trees.
- AndroidManifest analysis: cleartext traffic, debuggable=true,
  allowBackup=true, 26 dangerous runtime permissions enumerated,
  exported activities / receivers / services / providers without
  a permission attribute, custom-scheme deep links.
- Info.plist analysis (iOS): NSAllowsArbitraryLoads (ATS bypass)
  detection, 13 privacy permission claims, CFBundleURLSchemes.
- Third-party SDK fingerprint. 30+ Android SDKs (Firebase,
  Facebook, Amplitude, Mixpanel, OneSignal, Branch, Stripe,
  AdMob, AppsFlyer, Datadog, Sentry, Intercom, ...) and 25+ iOS
  framework names for the same vendors. One info finding per SDK
  so the customer can cross-check against their privacy
  disclosure.
- Trivy filesystem scan against the decompiled tree (CVEs in
  embedded native libraries, React Native lockfiles, Cordova /
  Capacitor lockfiles).

**Mobile FP suppression** (shipped this cycle):
- AndroidX carve-out drops findings against androidx.* /
  android.support.* / com.google.android.gms.* /
  com.google.firebase.* components that are by-design exported.
  Reduced AndroidManifest false-positive flood on every
  AndroidX-using app (which is effectively every modern Android
  app).
- Launcher activity exemption respects MAIN + LAUNCHER +
  LEANBACK_LAUNCHER + verified App Links. A launcher Activity
  being exported is the entire point of the launcher; we no
  longer flag it.
- apktool original-manifest dedup: apktool emits a decoded
  AndroidManifest.xml plus a raw original/AndroidManifest.xml
  copy. We suppress findings against the raw original/ copy so
  the same finding doesn't show up twice.
- Test-fixture filter drops hits in /test/, /tests/,
  /androidTest/, /__tests__/, /specs/, /mocks/, /fixtures/,
  /e2e/, /UITests/. Mobile test code routinely contains hard-
  coded credentials and intentionally insecure config; it isn't
  a production finding.

### 3.6 Cloud account targets

- AWS, Azure, GCP read-only IAM credentials are stored encrypted
  with AES-256-GCM (separate envelope from any other secret on
  the org). Worker runs Prowler with the CIS + best-practice
  rule packs, parses the JSON output, normalises into findings.
- Kubernetes snapshot upload (`kubectl get all -A -o yaml`) runs
  through Kubescape with the NSA framework. No outbound
  connection to the cluster.

### 3.7 Smart contract targets (Web3 add-on)

Web3 is a $299/month add-on that layers onto Growth or Agency
(Free + Starter not eligible; Stripe webhook flips
billing_profiles.web3_addon_enabled).

#### 3.7.1 EVM chain support matrix

| Chain      | Status     | Coverage                                      |
|------------|------------|-----------------------------------------------|
| Ethereum   | Supported  | Full V1                                       |
| Polygon    | Supported  | Full V1 (Polygon Amoy testnet on roadmap)     |
| BSC        | Supported  | Full V1                                       |
| Arbitrum   | Supported  | Full V1                                       |
| Optimism   | Supported  | Full V1                                       |
| Base       | Supported  | Full V1                                       |
| Avalanche  | Supported  | Full V1                                       |
| Sui (Move) | Beta       | 19 static detectors + UpgradeCap owner classification + Move test discovery |
| Solana     | Beta       | Verified-build + upgrade authority + Anchor IDL + SPL authority |
| Aptos / Cosmos / StarkNet | Not on roadmap | Reach out if needed              |

#### 3.7.2 Core EVM detector battery (all 7 chains)

- Slither static analysis on Solidity + Vyper source from the
  linked GitHub repo.
- On-chain Slither against the verified contract on each
  supported chain.
- Mythril symbolic execution via dedicated sidecar service.
- Echidna property-based exploration via dedicated AGPL-isolated
  sidecar (`trailofbits/echidna` unmodified upstream; sidecar
  surfaces failed invariants as high-severity findings). Echidna
  is the only AGPL dependency in the entire product and lives
  behind an HTTP boundary so its AGPL grant doesn't propagate
  into the main worker.
- NFT audit: ERC-721 / ERC-1155 detection, tokenURI scheme
  classification (HTTPS / IPFS / Arweave / data:), IPFS pinning
  probe, ERC-2981 royalty check.
- Owner classification: EOA (medium) vs Gnosis Safe (rendered
  N-of-M signers, low if threshold >= 2) vs OpenZeppelin
  TimelockController (info, positive signal).
- ERC-20 audit: mint() / blacklist() / paused() selector probes;
  rug-pull primitive flags.
- Token economy probes: owner-supply concentration (>=10% low,
  >=50% medium), Uniswap V2 (mainnet) / QuickSwap (polygon) /
  PancakeSwap (bsc) / BaseSwap (base) liquidity reserves.
- LP-lock detection: balance check against UniCrypt v2, UNCX,
  Team Finance, PinkLock + burn addresses. 0% locked =
  "rug-pull-ready".
- Fee-on-transfer detection (SafeMoon-style _taxFee +
  _liquidityFee).
- Honeypot simulation via eth_call simulating a sell to 0xdEaD;
  revert / false = honeypot.
- State-override fresh-wallet honeypot probe via eth_call
  stateOverride parameter.
- Proxy storage-slot collision detection (EIP-1967 admin /
  beacon / implementation slots + old-style TransparentProxy
  layouts).
- On-chain governance probe (OZ Governor / Compound
  GovernorBravo): voting delay + voting period + quorum
  numerator + Timelock min-delay; periods < 48h = governance
  risk.
- Bytecode opcode scan (SELFDESTRUCT high, CALLCODE low).
- Public audit registry cross-reference (Trail of Bits,
  OpenZeppelin, ConsenSys Diligence, PeckShield, CertiK,
  Runtime Verification).
- OFAC SDN compliance lookup against the contract + royalty
  receiver address.
- Web3 risk score (0-100) per target with a 12-point sparkline
  trend on the target overview tab.

#### 3.7.3 Per-EVM-chain modules (shipped this cycle)

- **Oracle config audit**: Chainlink price feed inspection.
  Detects stale price (last update timestamp older than the
  feed's declared heartbeat), decimals mismatch between feed and
  consumer, centralized-feed flag where only the deployer can
  update.
- **ERC compliance audit**: ERC-20 / ERC-721 / ERC-1155 standard
  conformance check. Verifies the required function set is
  actually present and the event signatures match the standard.
  Surfaces non-canonical implementations that may fail in
  integrator wallets.
- **Compiler version audit**: unverified source flag (Etherscan
  source not published), outdated solc (older than 6 months),
  optimizer config inspection (runs= setting, viaIR), non-
  canonical EVM version target.

#### 3.7.4 Sui Move (Beta)

- 19 static detectors covering capability leak, public transfer
  of privileged object, hot-potato discipline, witness misuse,
  unrestricted object access, friend-only function exposure, and
  more.
- UpgradeCap owner classification: EOA / multisig / locked
  (TransferRestrictions::None vs ::Compatible vs ::Additive vs
  ::Dep).
- Move test discovery in the package + reporting of which
  modules ship with tests (positive evidence).
- On-chain module fetch via
  sui_getNormalizedMoveModulesByPackage so the analysis runs
  against the actual bytecode the chain executes.

#### 3.7.5 Solana (Beta)

- Verified-build status check via verify.osec.io.
- Upgrade authority resolution by walking the
  BPFLoaderUpgradeable program data account; surfaces whether
  upgrade authority is set, who holds it, and whether it has
  been revoked.
- Anchor IDL fetch when the program publishes one.
- SPL token mint authority + freeze authority audit on associated
  mints.

### 3.8 DApp frontend Web3 scanner

For Web3 properties that aren't just a contract: the customer's
verified DApp URL gets scanned for:

- **Wallet provider detection**: WalletConnect, MetaMask,
  RainbowKit, wagmi, viem, ethers.js. One info finding per
  detected library so the customer can cross-check against their
  integration list.
- **RPC API key leak in shipped JS bundle**. We sha256-fingerprint
  the suspected key so the finding evidence is reproducible; the
  raw key is NEVER stored or logged. Customer rotates the key,
  the fingerprint stays stable enough to confirm the rotation
  worked.
- **Source map exposure**: production bundles referencing .js.map
  files that leak original source.
- **Unlimited approve pattern**: ERC-20 approve calls in dapp
  code paths that pass type(uint256).max as the allowance.

---

### 3.9 Invasive Testing add-on (active DAST)

SEO / topic keywords: dynamic application security testing (DAST),
active web vulnerability scanning, automated penetration testing,
OWASP ZAP active scan, API security fuzzing, mass assignment
(CWE-915), host header injection (CWE-644), web cache poisoning,
password reset poisoning, SSRF testing, authenticated scanning.

Everything in sections 3.1-3.8 is non-invasive: it reads,
fingerprints, and probes without sending exploit payloads or
mutating state. The Invasive Testing add-on ($299/mo on Growth or
Agency) unlocks the active checks that send real attack payloads
at a target the customer owns and is authorized to actively test.

#### The four active checks

1. **OWASP ZAP active scan** (web targets). Runs the ZAP automation
   framework: spider (1m) + passive-scan wait (1m) + active scan
   (3m). Active coverage: SQL injection, reflected / DOM / stored
   XSS, CSRF, SSRF, path traversal, OS command injection,
   server-side template injection (SSTI), XXE, HTTP parameter
   pollution, open redirect. Each ZAP alert (riskcode 0-3 ->
   info/low/medium/high, CWE-driven category) becomes a Finding with
   source_tool=zap. When the target has a stored auth secret, ZAP
   gets a replacer rule so the spider + active scan run authenticated.
2. **Schemathesis OpenAPI fuzzing** (API targets). Property-based
   testing of a discovered OpenAPI / Swagger spec. Generates POST /
   PUT / DELETE requests and checks status-code conformance, response
   schema conformance, content-type conformance, and not_a_server_error
   (catches unhandled 500s). Only runs when api_discovery surfaced a
   reachable machine-readable spec.
3. **Mass-assignment probe** (API targets). PATCHes a curated set of
   self-profile endpoints (/api/me, /api/users/me, /api/profile,
   /api/account, ...) with privileged extra fields (role, isAdmin,
   permissions, plan, organization_id) merged onto the pre-existing
   body. If the PATCH returns 2xx AND the response body reflects a
   privileged extra, it emits a confirmed CWE-915 critical (direct
   evidence the field was accepted). Requires a stored auth secret.
   source_tool=nano-mass-assign.
4. **Host-header injection probe** (web targets). Re-requests the
   homepage twice - once with a spoofed Host header, once with a
   spoofed X-Forwarded-Host - set to a unique canary, and flags the
   canary reflected into a redirect Location, a <base href>, or an
   absolute link / src. This is the primitive behind password-reset
   poisoning (a forged reset email pointing at the attacker host) and
   web-cache poisoning (CWE-644). GET-only; the pure detection core is
   unit-tested. A redirect-Location reflection is medium; a base-href
   / absolute-link reflection is low (exploitability depends on flow +
   caching). source_tool=nano-host-header.

#### Three-gate safety model

No active-attack payload is ever sent unless ALL THREE are true:

1. **Identity gate (KYC/KYB).** The workspace has an approved
   personal identity verification (KYC) OR company verification
   (KYB). Active testing is restricted to identity-verified
   customers. This gate is enforced server-side on BOTH buying the
   add-on and authorizing a target - it is the product's first hard
   gate on the verification system.
2. **Entitlement gate.** The org has the add-on active
   (billing_profiles.invasive_addon_enabled), set by the Stripe
   webhook on subscription, or comped by an admin time-bounded grant.
3. **Per-target consent gate.** The specific target is explicitly
   authorized (targets.invasive_testing_authorized), stamped with the
   authorizing user id and timestamp. This is the customer's written
   consent that they own the target and may actively attack it.

Additional controls: each invasive tool can be disabled per target
via the scan profile; web targets must already be ownership-verified
(DNS TXT / file / meta / domain email) to run any sensitive scan;
we recommend staging environments; and we NEVER run denial-of-
service, brute-force, or resource-exhaustion payloads.

#### Mobile apps: backend API testing with an ownership gate

A mobile binary (APK / IPA) is analysed statically - nothing is
"run." But a mobile app's real attack surface is the backend API it
calls, and those base URLs are almost always hardcoded in the
binary. When a mobile target is authorized for invasive testing,
the worker:

- extracts the first-party backend hosts from the decompiled tree,
  filtering out the long tail of SDK / analytics / CDN / schema
  noise and rejecting private-IP / loopback literals;
- runs the same active web checks above, but ONLY against backend
  hosts the org has VERIFIED OWNERSHIP of - i.e. a verified web/API
  target with the same host or a parent/child subdomain. Matching is
  conservative (exact + sub/parent only); it never infers ownership
  across different registrable domains, so a lookalike like
  example.com.evil.com is not treated as owned;
- fails closed: with no matching verified target (or any DB error on
  the ownership lookup), it scans nothing;
- emits one info finding that lists every discovered backend host,
  which were actively tested, and which were refused for lack of
  verified ownership. Third-party / partner API hosts the app calls
  are reported but NEVER attacked - the customer adds and verifies
  them as their own targets first.

No device emulator and no runtime instrumentation are used; the data
only reflects what was actually tested.

#### SSRF protection

Every active request (web or mobile-backend) is dialed through a
guard that resolves the host and blocks RFC1918 private space,
loopback, link-local, CGNAT, IPv6 unique-local, and the cloud
metadata endpoint range (169.254.169.254 - AWS / GCP IMDS). The
mobile backend extractor additionally rejects bare IP literals
before a host is ever considered.

Full customer-facing guide: https://nanotesting.com/docs/invasive-testing

---

## 4. False-positive + false-negative defence stack

NANOTESTING ships a layered FP/FN defence so an automated scanner
produces output procurement reviewers actually accept.

### 4.1 Confidence tier on every finding

Confirmed / Likely / Possible / Informational. Rendered next to
severity in the UI, in the PDF, and the CSV / JSON export. A
"Confirmed critical" carries a different weight to a "Possible
critical" when triaging.

### 4.2 Per-detector severity + confidence ceiling clamp

A per-detector severity clamp. 41 detectors carry an
explicit ceiling that the worker enforces at finding-emit time,
so a noisy rule can't silently surface a Critical Confirmed
finding it never had the data to support. JWKS hygiene is one of
a small allowlist where Critical Confirmed IS legitimate
(alg=none on a published key, symmetric oct key exposure).

### 4.3 Two-source corroboration for Critical

Findings carrying Severity=Critical must also carry a CWE /
OWASP / CVE reference; otherwise requireCriticalEvidence in
A corroboration pass knocks the severity
down to High.

### 4.4 Host calibration probe (Web FP suppression - shipped this cycle)

Before per-path scanners run, the worker sends 3 GET probes to
random non-existent paths and builds a (status, body-hash)
baseline. During the per-path scan, every real probe is compared
against the baseline. Matches are the host's catch-all (Vercel
WAF, Cloudflare bot challenge, SPA fallback that serves
index.html for everything) and are NOT recorded as findings.

This single mechanism eliminates the vast majority of the
"exposed paths" false-positive flood that hit Vercel-hosted
customers before May 2026.

### 4.5 Managed-host downgrade (Web FP suppression - shipped this cycle)

When the Server header matches vercel / cloudflare / netlify /
cloudfront / fly / render / fastly / github.com, every finding
from the per-path scanners gets:
- A severity downgrade (one level).
- An explicit FP-risk caveat appended to the description
  explaining that the managed host's catch-all behaviour may be
  responsible for the signal.

### 4.6 Anti-bot threshold (Web FP suppression - shipped this cycle)

When >= 70% of probes return 401 or 403, the scanner concludes
the host is running an anti-bot / WAF tier that will respond the
same way to everything. Per-path Missing-Header /
Missing-robots / Exposed-Path findings are suppressed and ONE
explanatory finding is emitted instead: "Host returned 401/403
for >= 70% of probes; per-path enumeration suppressed."

### 4.7 FP-risk caveats

Every finding with known uncertainty appends "False-positive
risk: <reason>" to its description. The reason field tells the
customer what to verify: "served by Cloudflare; may be a WAF
challenge", "AndroidX component; expected to be exported",
"apktool raw original/ duplicate; check decoded copy", etc.

### 4.8 Mobile FP suppression mechanisms

See section 3.5 - the four mobile FP mechanisms (AndroidX
carve-out, launcher activity exemption, apktool original-manifest
dedup, test-fixture filter) eliminate the dominant FP categories
on Android binaries.

### 4.9 Per-finding false-positive feedback

The dashboard has a "report as false positive" button; reports
write to finding_fp_reports with reason + signature + source
tool.

### 4.10 Admin per-detector FP-rate dashboard

At /admin/detector-accuracy. Surfaces FP rate per source_tool
over a rolling window so noisy rules get prioritised for rework.

### 4.11 Golden-fixture tests

Unit tests pin the contract of the
trickier detectors (clamp, corroboration, SRI, API key leak,
excessive data exposure, cross-origin policies, SSRF surface,
policy strictness, apiauthz parser, host calibration baseline).

### 4.12 Scan performance dashboard

At /admin/scan-performance tracks p50 / p95 / p99 + success rate
per scan_type over a rolling 7-day window so a detector
regression is visible before customers notice.

### 4.13 Customer evidence

A Vercel-hosted SaaS scanned in May 2026 dropped from 50
reported findings to 3 after the FP suppression architecture
landed. The 47 suppressed items broke down roughly as:
- ~30 Vercel WAF catch-all responses suppressed by the host
  calibration probe.
- ~12 AndroidX exported components from a paired mobile target
  suppressed by the AndroidX carve-out.
- ~5 apktool duplicate original-manifest findings suppressed by
  the original-manifest dedup.

---

## 5. Compliance evidence pipeline

NANOTESTING does NOT issue compliance certifications and does NOT
attest. We provide evidence support (NOT certification) that an
auditor or buyer can consume.

### 5.1 Data model

Each scan writes a compliance_evidence table row per control with
a positive or negative signal:
- framework (iso27001 / soc2 / owasp10 / nist_csf / cis8 /
  pci4 / hipaa / dora)
- control_id (e.g. A.8.24, CC6.1, A01:2021)
- target_id, scan_id, finding_id (nullable when positive)
- signal (positive / negative)
- detector that produced the signal
- evidence_blob (raw observation: header value, TLS version, etc.)

Positive signals are emitted alongside negative ones. A scan that
finds zero broken access control also emits the positive proof:
"ZAP active scan ran, found zero broken access control findings
=> CC6.1 positive evidence for this scan."

### 5.2 Controls covered today (25+ per scan)

**ISO 27001:2022 Annex A** -
- A.8.24 cryptography: TLS chain validity + HSTS + modern-TLS-only
  + CAA records
- A.8.26 web filtering: CSP + X-Frame-Options + COOP / COEP / CORP
- A.5.16 identity management: cookies with Secure + HttpOnly +
  SameSite
- A.8.20 networks: DNSSEC
- A.5.14 information transfer: SPF + DMARC + DKIM
- A.8.9 config: robots.txt + sitemap.xml
- A.8.8 vulnerability management: Nuclei clean run
- A.8.25 secure development: ZAP clean run
- A.5.10 acceptable use: no exposed paths

**SOC 2 Trust Services Criteria** -
- CC6.1 logical access (parallels A.5.16)
- CC6.6 network controls (parallels A.8.20)
- CC6.7 information transfer (parallels A.5.14)
- CC7.1 monitoring (parallels A.8.8 / A.8.25)

**OWASP Top 10 2025** -
- Mapped per finding category. A01 broken access control, A02
  cryptographic failures, A05 security misconfiguration, etc.

### 5.3 UI surfaces

- **Per-target Compliance tab** shows the matrix for that target
  (rows = controls, columns = last 12 scans). Green = positive,
  red = negative, grey = not yet measured by this scan.
- **Org-wide /compliance dashboard** rolls the matrix up across
  every target in the workspace.
- **Compliance PDF report** prints the matrix with the explicit
  disclaimer "This document provides evidence support and is not
  a certification or attestation. A qualified auditor is required
  for the actual report."

### 5.4 Framework coverage

Eight frameworks are mapped and exportable. Coverage is the share
of that framework's controls an external assessment can evidence;
the remainder render as "not assessed", never as passing.

- OWASP Top 10 (2025)   8 of 10 controls
- ISO/IEC 27001:2022    17 of 20
- SOC 2 (TSC)           6 of 9
- PCI DSS 4.0           5 of 12
- CIS Controls v8       7 of 18
- NIST CSF 2.0          5 of 12
- HIPAA Security Rule   4 of 13
- DORA (EU 2022/2554)   3 of 15

109 controls and 287 signal mappings in total.

DORA deserves its scope stated plainly. Of the 15 articles listed,
signals map to Art 7 (systems kept up to date), Art 8
(identification) and Art 9 (protection and prevention).
Governance (5-6), detection (10), response and continuity (11-14),
the testing programme (24-26) and third-party risk (28-29) are
organisational and cannot be observed by scanning a host.
Chapter V governs contractual arrangements with ICT service
providers - a CVE in a bundled library is software supply chain
risk, not a provider arrangement - so it carries no signals even
though dependency CVEs are detected and reported under Art 7
and Art 8. Art 25 is listed but unmapped on purpose: a
completed assessment contributes to it, but whether a testing
programme meets the required scope and cadence is a judgement this
product does not make. This pack is evidence for a DORA
assessment, never DORA readiness.

Control status has four values, and severity decides:
- at_risk            a critical / high / medium signal maps here
- observations_only  assessed, signals present, none a deficiency
- assessed_ok        assessed, nothing observed
- not_assessed       no automated signal can evidence this control

A control is never marked at risk on an informational observation
alone. PDF, CSV and JSON carry identical control status, tallies
and positive evidence for the same scan.

---

## 5.5 Scan attestations: evidence a third party can verify

Every scan writes an append-only scan_attestation row. A findings
list does not survive audit scrutiny on its own, because the
questions an auditor asks are about the assessment, not the defects:
what was in scope and was it authorised, when did it run, which
tools at which versions produced it, which checks actually executed,
and can the record be shown to be unaltered.

Scope and authorisation
- Target URL, target type, and the target's authorization_status at
  the time of the scan.
- The per-target scan profile: which individual tools the customer
  had switched off. Without it, two scans with identical
  attestations could have had different scope.

Time
- Start, end, duration.

Method
- Methodology version and score version.
- The worker image reference.
- Tool inventory with exact versions, split two ways: the tools that
  ACTUALLY RAN in this scan, derived from the steps that succeeded,
  and separately what merely existed in the worker image. A website
  assessment that lists an Android decompiler and a smart-contract
  analyser among its tools is not evidence; it is noise. A failed or
  skipped step means the tool contributed nothing and is not
  credited.
- Findings also carry the version of the tool that produced them, so
  provenance can be established from the row rather than by
  reconstructing the scan.

What did not run
- Every step that failed or was skipped, named, with its status and
  error. A count tells a reader how much was missed, never what.
- Coverage gaps are classified: a check attempted and failed against
  the target, versus an area this deployment cannot assess because
  the capability is not built or not enabled. Only the former
  withholds a grade. Conflating them meant an undeployed feature of
  ours permanently blocked a clean app from ever being graded.

Integrity
- Each row is signed with Ed25519 over a canonical serialisation.
  The private key lives only in the scanning worker's environment,
  never in the database, so possession of database credentials is
  not sufficient to forge a record.
- Each row chains to the organisation's previous attestation, so
  altering an old record breaks every later link rather than a
  single row.
- Rows are append-only. Re-running a scan adds a revision; it does
  not overwrite what was previously attested.
- The public key is published at
  https://www.nanotesting.com/.well-known/nanotesting-attestation-key
  so a third party can verify our evidence WITHOUT our cooperation.
  An integrity control that only the vendor can check is not one an
  auditor accepts.
- The serialisation is versioned, so records keep verifying under
  the format they were sealed with. Silently invalidating evidence
  already issued would be worse than the defect that prompted the
  format change.

Stated limits, because overclaiming here would defeat the purpose
- The worker holds the signing key. An attacker with the worker's
  secrets could still sign records. This raises the bar from "anyone
  with the database" to "someone with the worker's secrets"; it does
  not remove the vendor from the trust model. Doing that requires an
  external signer (KMS/HSM) and anchoring the chain outside this
  infrastructure.
- Timestamps are the worker's own clock and are not attested by an
  external time source. What was recorded is independently
  verifiable; when it happened is not. Closing that needs an
  RFC 3161 timestamp authority.

## 6. Prioritisation, retest, trend

- Every CVE finding is enriched daily with CISA Known Exploited
  Vulnerabilities (KEV) and FIRST.org EPSS exploitation
  probability. A daily cron at 03:17 UTC pulls upstream feeds and
  recomputes a 0-100 priority score (severity + KEV bump + EPSS
  bump + confidence) on every open finding.
- Findings list sorts by priority desc, not raw severity. KEV
  findings carry a red KEV badge; EPSS >= 0.9 carries an amber
  EPSS chip.
- Retest workflow: mark a finding fixed, click "Run retest", a
  new scan_job is queued through the plan-limit-respecting RPC.
  Finding status flips to verified_fixed if the signature no
  longer appears.
- Per-scan summary: severity counts, KEV count, top-EPSS,
  security score, mean priority, new / fixed / reopened delta
  vs previous scan.

---

## 7. Auditor-ready PDF reports

Four auditor-ready PDFs per scan, generated server-side via
react-pdf, with embedded PNG screenshots of every medium+ web-
facing finding (captured by the Playwright screenshot sidecar at
scan time and embedded as data: URIs so the report is offline-
self-sufficient):

1. **Executive** - top risks, score, severity counts, trend
   delta, KEV count, top EPSS.
2. **Developer remediation** - one ticket per finding: severity
   chip, KEV chip, priority score, CWE, OWASP category, CVE,
   Why / Evidence / How to fix / Acceptance criteria /
   Regression test hint.
3. **Compliance mapping** - OWASP Top 10 2025 + OWASP API Top 10
   2023 + ISO 27001 Annex A (25+ controls) + SOC 2 TSC
   evidence matrix. Explicit disclaimer printed on the cover:
   evidence support, not certification.
4. **Security trend** - score history (last 30 scans, SVG
   sparkline), MTTR, reopen rate, KPI cards.

When the Web3 add-on has produced findings, the Executive +
Developer + Compliance PDFs gain a dedicated Web3 / Smart
Contract section. When the DApp frontend scanner has produced
findings, the same PDFs include a DApp Web3 section.

---

## 8. Pricing - canonical numbers

Plan limits live in src/lib/billing/plans.ts. Same numbers as
the public pricing table and the Stripe products (which carry
metadata.app=nanotesting and the "Nano Testing -" name prefix).

| Plan       | Monthly | Annual   | Targets | Scans/mo | Reports/mo | Team | Workspaces |
|------------|---------|----------|---------|----------|------------|------|------------|
| Free       | $0      | -        | 1       | 1        | 0          | 1    | 0          |
| Starter    | $39     | $31/mo*  | 3       | 10       | 10         | 2    | 0          |
| Growth     | $79     | $63/mo*  | 15      | 100      | 100        | 10   | 0          |
| Agency     | $199    | $159/mo* | 50      | 300      | 300        | 15   | 25         |
| Enterprise | Custom  | Custom   | Custom  | Custom   | Custom     | -    | -          |
| Web3 addon | $299    | -        | layered on Growth or Agency only          |

\* Annual billing = monthly x 12 x 0.80, rounded. Billed yearly
in one charge. Save 20%.

**14-day free trial** is automatic on every Starter / Growth /
Agency Stripe Checkout (subscription_data.trial_period_days=14).
A payment method is collected so the conversion is silent at
trial end. Cancel any time before day 14 from the billing portal
for no charge. Verified one-time purchases are not eligible.

**Web3 add-on**: $299 / month on Growth or Agency only. Covers
all 7 supported EVM chains, Sui (Beta), Solana (Beta), and the
DApp frontend scanner.

**Invasive Testing add-on**: $299 / month on Growth or Agency
only. Unlocks the active / intrusive checks that send real
attack payloads: OWASP ZAP active scan (SQLi / XSS / SSRF /
path traversal / command injection / SSTI), Schemathesis
OpenAPI fuzz (generated POST / PUT / DELETE), the
mass-assignment probe (privileged-field PATCH; a reflected
privilege is a confirmed CWE-915 critical), and the Host-header
injection probe (spoofed Host / X-Forwarded-Host reflected into
a redirect, base href, or absolute link - the password-reset /
cache-poisoning primitive, CWE-644). Safety is a three-gate
model: (1) the workspace must be identity-verified - at least
one of personal KYC or company KYB must be approved by a
reviewer - (2) the add-on must be active on the workspace, AND
(3) each individual target must be explicitly authorized for
invasive testing (per-target consent stamped with who authorized
it and when) before any payload is sent. Customers can disable
any single tool per target, and we recommend pointing invasive
testing at a staging environment. We never run DoS, brute-force,
or resource-exhaustion payloads.

Mobile coverage: a mobile binary is static, but the app's real
attack surface is its backend API. When a mobile target is
authorized for invasive testing, the worker extracts the
first-party backend hosts hardcoded in the decompiled binary
(filtering SDK / analytics / CDN noise) and runs the same active
web checks - but ONLY against hosts the org has verified
ownership of (a verified target with the same host or
parent/child domain). Ownership gate by design: a binary
routinely embeds third-party / partner API hosts the customer
does not own, and we never attack those - they are reported so
the customer can add and verify them as targets first. The info
finding lists every discovered host, which were tested, and
which were refused for lack of verified ownership. No device
emulator, no runtime instrumentation. Full guide at
/docs/invasive-testing.

The **Verified Security Report** (human-reviewed) is currently
unavailable for new purchases; legacy subscribers retain access.
Automated evidence reports remain across Starter, Growth, and
Agency.

---

## 9. Team collaboration

- Per-finding discussion thread at /findings/{id}. Anyone in the
  workspace can post (up to 4000 chars per comment); only the
  author or an admin/owner can soft-delete (soft-deletes leave
  a "[removed]" tombstone for thread continuity).
- Bulk target import at /targets/import accepts a CSV (up to 100
  rows; name + url required, optional type / environment / risk
  / frequency). Each row passes the same URL + SSRF gate as the
  single-target form.
- Audit log at /audit-log records every member action against
  scans, targets, billing, members, findings, and the OpenAPI
  spec.
- Members tab in /settings supports invite-by-email with role
  (owner / admin / analyst / viewer); team-member limit is
  enforced per plan.

---

## 10. Privacy + GDPR + cookies

- **GDPR Article 15 + 20** at /settings/privacy -> Export my
  data. Downloads a JSON envelope: every row keyed to the
  caller's user id plus customer content scoped to organisations
  they own.
- **GDPR Article 17 + CCPA** at /settings/privacy -> Delete my
  account. Deletes sole-owner organisations (cascades to
  billing_profiles + targets + scan_jobs + findings + reports +
  audit_logs + compliance_evidence), removes memberships in
  shared orgs, drops user_preferences, deletes the auth.users
  row. Stripe customer is preserved so invoice copies survive;
  billing email is anonymised.
- **Cookie consent banner** on first visit. Strictly-necessary
  cookies (auth, theme, nt_active_org) are never blocked. The
  consent flag (nt-cookie-consent) gates future analytics
  scripts. We do not run advertising or cross-site trackers
  today.
- Per-entry cookie inventory at /legal/cookies.

---

## 11. Architecture

- **Web app**: Next.js 16 (App Router, RSC by default), hosted on
  Vercel. Supabase Postgres with RLS for tenancy isolation.
  Magic-link auth only - no passwords on the customer-facing app.
- **Encrypted object storage** (Supabase Storage) for raw scan
  output, PDF artifacts, screenshot evidence, customer OpenAPI
  specs, and mobile binaries (50 MiB cap, column-locked to
  service_role).
- **Worker**: Go binary on a containerised worker host (Fly.io).
  Long-polls scan_jobs, dispatches the right scan type, writes
  findings back. Bundles pinned binaries of Nuclei, osv-scanner,
  gitleaks, Trivy, naabu, tlsx, Schemathesis, Semgrep CE,
  Prowler, ZAP, Kubescape, mobsfscan, Slither, solc-select,
  apktool, plus the Trivy DB.
- **Sidecar services** (Fly.io apps reached over a private
  network): Mythril, Echidna (AGPL-isolated), Screenshot
  (Playwright headless Chromium), Sui RPC adapter, Solana RPC
  adapter.
- **Daily cron** (03:17 UTC) at /api/cron/refresh-threat-intel
  pulls CISA KEV + FIRST.org EPSS and recomputes priority on
  every open finding.
- **Hourly cron** at /api/cron/enqueue-scheduled fires verified
  targets that are due for their weekly / monthly evidence snapshot.
- **Stripe Checkout** for first-time payments. Plan change /
  cancel / resume happen inline in the dashboard via
  subscriptions.update. Webhook at /api/billing/webhook is the
  single source of truth for billing_profiles.plan +
  billing_status + scan_limit_monthly + web3_addon_enabled.
- **Theme system**: light / dark / system theme stored in
  localStorage for anonymous visitors and synced to
  user_preferences for authenticated users (cross-device).
- **Status page** at /status computes operational health from
  recent scan_jobs + email_events + audit_logs; revalidates
  every 30 seconds.

---

## 12. Subprocessors

| Vendor       | Purpose                       | Region       | Transfer      |
|--------------|-------------------------------|--------------|----------------|
| Vercel       | Web app hosting + CDN         | Global edge | EU SCCs (M2)  |
| Supabase     | Postgres + Auth + Storage     | EU (Ireland)| n/a (EU)      |
| Fly.io       | Worker + sidecar containers   | EU + US     | EU SCCs (M2)  |
| Stripe       | Payments + invoicing          | US          | EU SCCs (M2)  |
| Resend       | Transactional email           | US          | EU SCCs (M2)  |
| Cloudflare   | DNS + DDoS                    | Global      | EU SCCs (M2)  |
| Sentry       | Error monitoring              | EU (DE)     | n/a (EU-to-EU)|
| GitHub       | Code clone for repo scans     | US          | EU SCCs (M2)  |

Current vendor list, regions, and transfer mechanisms live at
/legal/subprocessors. 30-day advance notice on any new
subprocessor.

---

## 13. Authorisation model

Customers must prove ownership of a target before any full scan
runs. Four methods are accepted:

- DNS TXT record on the apex (preferred).
- HTML file at /.well-known/nanotesting-verification.txt.
- HTML meta tag on the landing page.
- Email confirmation to webmaster@ / security@ / admin@ on the
  verified domain.

Registered free users get one limited scan per day with all
results blurred until they verify ownership and upgrade.

---

## 14. Forbidden targets + safety contract

The Acceptable Use Policy at /legal/aup binds every customer:

- No targets the customer does not own or have written permission
  to test.
- No critical national infrastructure, financial settlement
  systems, healthcare-delivery systems, or life-safety systems.
- No bug-bounty programs the customer is not enrolled in.
- No customers of the customer.
- No payload injection beyond what the worker emits by default.
  Customers cannot upload custom Nuclei templates.
- No use of the platform for offensive security operations.

The worker enforces a complementary safety contract:

- IP-allowlist + URL-validation gate that re-checks the target
  before every outbound request.
- DNS rebinding protection: every dial re-resolves the hostname
  and refuses private / reserved / metadata IPs.
- Per-request timeout, per-target rate limit, per-organisation
  request budget enforced at the worker level.
- DELETE is never invoked. DELETE / PUT / PATCH on customer URLs
  only fire inside the apiauthz mass-assignment path, against
  operations whose request body schema the spec explicitly
  declared.
- Anti-bot threshold: when >= 70% of probes return 401/403, the
  scanner suppresses per-path findings and emits one explanatory
  finding instead.
- Invasive Testing add-on: active-attack payloads (section 3.9) fire
  only when the workspace is identity-verified (KYC/KYB), the add-on
  is active, and the specific target is explicitly authorized. For a
  mobile target, the extracted backend host is additionally required
  to match a verified web/API target the org owns; third-party hosts
  the app calls are reported but never attacked, and the path fails
  closed when ownership cannot be proven.

---

## 15. Data retention

| Data class                              | Retention                       |
|-----------------------------------------|----------------------------------|
| scan_jobs + findings (open + resolved)  | 12 months on Growth+, 3 mo Starter |
| Raw scan output blobs                   | 30 days on all paid plans        |
| PDF report artifacts                    | 12 months on Growth+             |
| compliance_evidence rows                | 12 months on Growth+             |
| Audit logs                              | 24 months                        |
| Stripe invoices (preserved by Stripe)   | 7 years                          |
| Backups (rolling)                       | 35 days                          |
| GDPR account-deletion scrub             | Immediate; backups age out at 35 |

---

## 16. Trust + legal documents

Eight-document legal stack under /legal, drafted for external
counsel review. Operating entity: Sodasoft LLC, 30 N Gould St,
Sheridan WY 82801, USA. Effective date 2026-05-14.

- /legal/privacy       - GDPR + UK GDPR + Swiss FADP + CCPA-aligned
- /legal/terms         - MSA, JAMS arbitration, class-action
                         waiver, Wyoming choice-of-law
- /legal/dpa           - DPA with Schedule 1 + Schedule 2 (TOMs)
- /legal/subprocessors - 8 subprocessors with regions + transfer
                         mechanisms
- /legal/aup           - Acceptable Use Policy
- /legal/cookies       - Per-entry cookie inventory
- /legal/refund        - 30-day full refund on annual,
                         service-level credits
- /legal/bug-bounty    - Responsible disclosure with safe harbour

/.well-known/security.txt points Policy + Acknowledgments at
/legal/bug-bounty. Contact: security@nanotesting.com.

---

## 17. Comparison pages

- /vs/burp-suite - vs Burp Suite. NANOTESTING = SaaS evidence on
  a schedule; Burp = human-driven proxy. Teams that ship
  continuously usually run both.
- /vs/nessus     - vs Tenable Nessus / Tenable.io. NANOTESTING
  owns the application + supply-chain + Web3 layers; Nessus owns
  the network + OS layer. Teams that ship to the cloud usually
  run both.
- /vs/detectify  - vs Detectify. Detectify dominates EASM
  (external attack surface management); NANOTESTING dominates CI
  + repo + mobile + cloud + Web3. Same money, different question.

---

## 18. Differentiators

- One platform for every surface attackers touch: web, API, repo,
  mobile, cloud, K8s, smart contract (7 EVM + Sui beta + Solana
  beta), DApp frontend.
- Repeatable on a schedule, not a one-off engagement.
- Normalised findings table with CWE / OWASP / MASVS / ISO /
  SOC 2 mapping.
- Confidence tier on every finding so triage is faster than
  raw-severity sorting.
- Auditor-ready PDFs that procurement reviewers accept as
  evidence support.
- Curated bundle of FOSS scanners (Apache / MIT / BSD / LGPL
  preferred; Echidna AGPL is the sole exception and runs as an
  isolated unmodified sidecar) maintained as a single SaaS so
  customers don't have to learn each tool.
- Read-only by default. Rate-limited active checks on verified
  targets. IP-allowlist + URL-validation gate re-checks the
  target before every outbound request.
- Layered FP engineering shipped in May 2026: host calibration
  probe + managed-host downgrade + anti-bot threshold + mobile
  AndroidX carve-out + launcher exemption + apktool dedup +
  test-fixture filter. The Vercel-hosted customer case study went
  from 50 findings to 3 after this landed.
- Compliance evidence pipeline that emits positive proof rows,
  not just failure rows. Per-target Compliance tab + org-wide
  /compliance dashboard.
- Per-detector FP-rate dashboard plus a per-detector severity +
  confidence ceiling clamp that ships in the worker, so noise
  cannot silently inflate.
- 14-day free trial on every paid plan; no surprise charge on
  day 14.

---

## 19. Key pages reference

| Path                | Purpose                                      |
|---------------------|----------------------------------------------|
| /                   | Landing page (one-stop shop positioning)     |
| /pricing            | Plan ladder with monthly/annual toggle       |
| /security           | Safe-scanning policy + authorisation model   |
| /sample-report      | Sample PDF output                            |
| /compliance         | Org-wide compliance evidence dashboard       |
| /docs               | Product documentation                        |
| /status             | Operational status (live)                    |
| /legal              | Index of the 8 legal documents               |
| /vs/burp-suite      | Comparison vs Burp Suite                     |
| /vs/nessus          | Comparison vs Tenable Nessus / Tenable.io    |
| /vs/detectify       | Comparison vs Detectify                      |
| /signup             | Magic-link only                              |
| /login              | Magic-link only                              |
| /dashboard          | Targets, scans, findings, billing overview   |
| /targets            | Target list                                  |
| /targets/new        | Single target add                            |
| /targets/import     | Bulk CSV target import                       |
| /targets/{id}       | Per-target detail + OpenAPI upload + Compliance tab |
| /scans              | Scan list                                    |
| /scans/{id}         | Per-scan detail, progress, findings, PDFs    |
| /findings           | Cross-target findings list                   |
| /findings/{id}      | Per-finding detail + discussion thread       |
| /reports            | PDF report archive                           |
| /audit-log          | Member action audit                          |
| /capabilities       | Per-target capability matrix                 |
| /settings           | Org settings (members, billing, integrations)|
| /settings/profile   | Display name + avatar URL                    |
| /settings/privacy   | GDPR export + account deletion               |
| /settings/notifications | Slack / Discord / generic webhook        |
| /settings/cloud-integrations | AWS / Azure / GCP + K8s + mobile    |

---

## 20. Contact + corporate

- Operating entity: **Sodasoft LLC**, 30 N Gould St, Sheridan WY
  82801, United States
- Founder: Ratomir Jovanovic
- Customer support: support@nanotesting.com
- Privacy / GDPR / DSAR: privacy@nanotesting.com
- DPO: dpo@nanotesting.com
- Legal: legal@nanotesting.com
- Billing: billing@nanotesting.com
- Security disclosure: security@nanotesting.com
- Domain: https://nanotesting.com
- LinkedIn: https://www.linkedin.com/company/nanotesting