Collect and review security evidence
Start with reviewed scope
Section titled “Start with reviewed scope”Keep .nklattice-apps.json for the exact app/profile set. The security profile additionally uses .nklattice-security.json with schemaVersion: 1 and one entry per reviewed app: appPath, origins (safe alias and URL), routes, endpoints, authzMatrix, trustedOrigins, explicit features and productionBuildRoots. This is not an auto-discovery approval.
Routes name a stable ID, origin alias, root-relative localPath, auth mode, renderMode and behavioral test IDs. Endpoints name the same identity/auth fields plus explicit POST/PUT/PATCH/DELETE mutation methods. GET mutation patterns are review candidates, never silently approved methods. Authorization cells bind persona alias, target ID, action and allowed/denied result. Feature flags cover webhook, ws, serviceworker, upload and embedded; explicitly review false values too. Build roots must remain within the app boundary. Never put credentials, real persona identities or private customer URLs in a public example.
This minimal declaration example is for a standalone static app; replace the origin and review every field against your app. It does not establish that a build, runtime request or behavioral test has run. SSR/ISR apps and authenticated endpoints need their own actual modes, targets, personas and test IDs.
{ "schemaVersion": 1, "apps": [{ "appPath": ".", "origins": [{ "alias": "public", "url": "https://example.test" }], "routes": [{ "id": "home", "originAlias": "public", "localPath": "/", "auth": "none", "renderMode": "static", "behavioralTestIds": [] }], "endpoints": [], "authzMatrix": [], "trustedOrigins": [], "features": { "webhook": false, "ws": false, "serviceworker": false, "upload": false, "embedded": false }, "productionBuildRoots": ["dist"] }]}These examples use the installed public 0.11.1 CLI. Review the exact package and inventory first:
pnpm exec lattice security inspect . --format jsonpnpm exec lattice governance run . --security-profile enterprise-web \ --security-manifest .nklattice-security.json --execution source \ --inventory .nklattice-apps.json --expect-apps 1 \ --evidence /tmp/lattice-security-evidence.jsonReview each suggestion from security inspect; it only reads candidates, executes no repository config and writes no assessment or manifest. Copy the packaged JSON Schema for the strict surface format rather than inventing fields. Use --policy for your own reviewed schema3 file instead of --security-profile. Schema2 defaults and dependency-only governance check remain available. The exact policy SHA, not its version label, binds evidence.
Evidence layers
Section titled “Evidence layers”| Layer | What it can establish | What remains outside it |
|---|---|---|
source |
Supported AST/data-flow facts, declarative config, lockfile and scanner output for the bound inputs. | Executed build/test behavior, CDN headers, complete cross-file/dynamic flows. |
build |
Exact reviewed production output roots and identity; supported bundle/script analysis. | That those bytes were deployed or served to every user. |
runtime |
Bounded observed response/header/body facts for declared routes and operator-established deployment expectations. | Nonce CSPRNG provenance, all cache variants, production TLS from loopback HTTP. |
behavioral |
Reviewed allowed/denied request, authorization and browser scenarios on the declared fixtures. | Untested routes/personas/devices or a general penetration test. |
operational |
Scoped provenance or manual operational receipt accepted under its authority/freshness contract. | Provider backup/SLA or whole-system certification without actual separate evidence. |
Source/build/runtime/behavioral freshness defaults to 24 hours; operational evidence defaults to 720 hours. Specific release readiness can require stricter limits. Commit, input, policy, ruleset, build, deployment, scope and timestamps must agree. A saved runtime artifact needs actual matching build bytes and explicit --deployment-id or per-app --deployment-map expectations established by the operator. The collector preserves fresh nine-domain failures; import cannot replace them with older passing values. Importing JSON never creates process-local runner, artifact or verified-CI authority.
--execution source never imports or executes repository modules/config/tests; approved static tool boundaries may run. trusted and isolated do not automatically approve executables or manufacture a sandbox. Operator Node integration owns pinned approved tools, credentials and a safe executor; absent execution proof remains incomplete. Run untrusted application code away from ingestion, deployment and npm credentials. Local-only operational context is not a shared wire contract or client-granted authority.
Candidate and confirmed findings
Section titled “Candidate and confirmed findings”Native sast:semgrep and secrets:gitleaks aggregate controls retain the scanner’s finding rule namespace. Source inference and low-confidence patterns are candidate findings requiring review. A confirmed blocker must satisfy its actual control severity/confidence and evidence contracts. Zero reported findings from an unavailable, partial or failed scanner does not mean zero risk. Raw diagnostics are kept local; only allowlisted normalized statuses/reason codes and redacted findings enter upload. Do not publish raw HTML, secret values, source excerpts or private identities by default.
Coverage counts are typed: files cannot fill route coverage, and one route cannot fill a missing endpoint. incomplete wins when required proof is missing even if a confirmed failure also exists. not-applicable needs a reviewed, evidence-supported exclusion; an unknown feature is not N/A. Complete measured zero is 0, unavailable is null; an empty control set never earns 100. Policy3 CLI still exits 7 for confirmed blockers despite an incomplete summary; otherwise missing proof exits 3.
Review and fix
Section titled “Review and fix”- Verify inventory, surface, policy and evidence identities; correct missing canonical routes without increasing traffic.
- Review confirmed secrets/advisories and high-confidence failures first; rotate compromised credentials before code cleanup.
- Apply the render/auth-specific remediation, rerun the relevant layer and full governance gate.
- Compare exact cohorts. A finding is fixed only when a complete matching scan proves absence; missing or contradictory current coverage keeps it open. Reappearance becomes reopened. Accepted risk remains visible and requires current matching authority.
security verify-report checks available structure and supplied-model semantics at the report timestamp with the original policy, inventory and manifest. It explicitly leaves source execution and production unverified. It is not a fresh scan. See commands and report trust.
Observation authentication scope
Section titled “Observation authentication scope”Runtime and behavioral observations record the measured scope as authScope: anonymous identifies requests sent without credentials, and personaAliases lists only reviewed fixture actors actually observed. Multiple actors remain a composite scope; an anonymous request is never assigned an invented user. The legacy single authPersonaAlias shorthand remains readable, but cannot accompany authScope. Aliases contain no credentials and grant no upload or workload authority. Build identity, freshness and trusted execution requirements still apply; local fixture observations remain local fixture evidence.