docs(security): apply owner-approved root review policy

SECURITY.md

@@ -0,0 +1,41 @@
+# Jobjakt Security Policy
+
+## System and scope
+
+Jobjakt manages private career profiles, CVs, letters, applications, correspondence and related account data. Review the repository-owned React/Next static-export UI, ASP.NET Core API, EF data and background processing, Python AI/document sidecar, browser extension, deployment/CI configuration and their trust boundaries. Architecture documentation describes nginx, MariaDB, private files and internal services; actual deployed exposure and identity must be verified separately. Retained SQLite and legacy document paths remain in scope while supported.
+
+This policy supplies review context, not permission to run commands or test live targets. It does not certify existing controls. Root and component policies compose; nearest-path guidance takes precedence.
+
+## Threat model and trust boundaries
+
+Consider anonymous callers, two distinct authenticated owners, administrators, revoked or limited sessions, malicious document authors, incoming webhook senders and compromised external services. Treat route/body identifiers, uploaded files, HTML, job advertisements, external callbacks, logs and model output as untrusted.
+
+Assets include canonical Career Profile facts/history, CV overrides and frozen revisions, application records, attachments, authentication/recovery material, provider tokens, billing entitlements, audit records and recoverable backups. Trace browser-to-API, API-to-database/files/workers, API-to-sidecar and provider callback/outbound fetch boundaries. Do not assume a role, a client UI flag or an internal-network label proves authorization.
+
+## Security invariants
+
+- Establish authenticated identity and owner scope before disclosing or changing private data. Caller-supplied owner IDs cannot replace server identity. Apply ownership to nested resources, lists/search, downloads, exports and background work, not only direct item reads.
+- Enforce administrator and sensitive-operation permissions server-side, including self/last-admin restrictions. Session revocation, recovery, MFA and OAuth state/account-linking controls must preserve the intended identity boundary.
+- Preserve canonical Career Profile ownership, null-as-inherit CV settings and immutable submitted/frozen snapshots. All applicable application/CV/letter writes must enforce existing revision preconditions and atomic persistence; stale operations must not partially commit or overwrite newer data.
+- Bound untrusted document/upload/parser work. Validate type, size, owned paths and lifecycle state; reject traversal and unauthorized retrieval. Rendering/import must not execute active content, dereference unapproved URLs, expose local files or change another owner's data.
+- Treat AI output as a proposal. Keep consent, entitlement, manual fallback, source/revision checks and explicit review/apply boundaries. Private content must not reach an unapproved model/provider; model or document text cannot authorize tool execution.
+- Validate outbound destinations and redirects at network boundaries. Preserve job-provider rights/attribution and mailbox consent separately from sign-in identity. Validate webhook authenticity, identity binding and replay/idempotency where applicable.
+- Preserve browser output encoding, safe HTML/rendering boundaries, origin/cookie/CSRF protections and validated return/navigation targets. UI visibility never substitutes for API authorization.
+- Protect secrets, tokens and private document content in logs, diagnostics, browser bundles, exports and backups. Privacy deletion/retention must account for files, queued work and recovery copies; successful recovery claims require tested database/file/key consistency.
+- Treat CI/deployment inputs and dependencies as supply-chain boundaries. Review least privilege, secret handling, provenance, image/runtime exposure and reversible recovery; test fixtures or historical reports do not prove production configuration.
+
+## Reportable findings and severity context
+
+Report reachable violations with attacker preconditions, affected assets and evidence. Cross-owner private-data disclosure/mutation, account takeover, privilege escalation, unsafe parser/rendering execution, exposed credentials and unauthorized external data transfer warrant impact-based investigation. Separate confirmed reproduction, reasoned likelihood and unverified assumptions.
+
+Evaluate actual source/configuration and supported deployment modes. A package advisory, missing attribute or hypothetical path alone is not a reproduced exploit; equally, a passing mock test or limited deployment mitigation does not close a reachable issue. Record advisory/reachability and runtime evidence separately. Preserve failed, blocked, skipped and unexecuted checks explicitly.
+
+## Exclusions and accepted risk
+
+No vulnerability class, repository component or existing defect is implicitly suppressed. No new risk acceptance, severity downgrade or finding exclusion is granted by this policy. Historical deferred work and compatibility support remain reviewable.
+
+Production, adjacent networks, real personal data and third-party systems are excluded from active testing unless separately and explicitly authorized. This execution restriction does not exclude review of repository-owned integration or deployment code. Synthetic local fixtures are distinct from approved staging and live-service qualification.
+
+## Known limitations and qualification
+
+The independent audit is incomplete. Source analysis, package checks, local fixtures, hosted CI, native accessibility, provider/model behavior, isolated staging and production recovery are separate evidence lanes. Final integrated security review follows relevant application changes. Baseline/deep/final scan results, cost allowance, staging scope and human release acceptance must be recorded separately; none is established by creating this file.

docs/security-audit/CODEX_SECURITY_SCAN_REGISTER.md

@@ -1,5 +1,7 @@
 # Codex Security scan register
 
+3 November2026 update: owner approved exact root policy creation/publication. Define-security-policy workflow COMPLETED for root policy only; source base88bcd6d9, exact candidate and resolver results in ../security/ROOT_POLICY_APPROVAL.md. Managed standalone artifact ID/path is documented there; there is no scan ID. Root now resolves for API/UI, nested CV-doc policy remains closest. Baseline/deep/final scans below remain NOT RUN/BLOCKED; no charges, active targets or release acceptance approved. Earlier policy-pending entries are historical.
+
 2 November 2026. Source baseline `ba826de1e5c959352e4442ab2fec5d02445dd32d`, branch codex/security-offline-preflight. Owner confirms installation; actual tool metadata/skill files verified. Production/third parties excluded. Paid/deep compute allowance pending. ROE: ../security/00-rules-of-engagement.md.
 
 | Phase/workflow | Status | Actual evidence and limits |

docs/security/ASSESSMENT_INDEX.md

@@ -1,5 +1,7 @@
 # Independent security assessment continuation
 
+3 November2026 — root policy proposal explicitly approved and applied; ROOT_POLICY_APPROVAL.md records exact text identity and successful API/UI/nested policy resolution. This closes the root-policy decision only. Baseline/deep/final scans, current integration target/capability/cost preflight, full matrix and staging/human/release qualifications remain open. No new application/security fix or vulnerability closure is claimed.
+
 Continuation: ATTACHMENT_OWNERSHIP_REVIEW.md traces the parent ownership filter and corrects the reflection-only test assumption. Fourteen existing relational fixture tests freshly passed on identical Phase 10 backend/test sources; native evidence published at db818e5e. Matrix distinguishes direct controller denials from unexecuted HTTP/list/upload/missing-owner/MariaDB checks. No full security scan or final integrated acceptance is implied.
 
 Phase 00 offline preflight, 2 November 2026. Branch `codex/security-offline-preflight`, application baseline `ba826de1e5c959352e4442ab2fec5d02445dd32d`. No application/security implementation changed. No staging attacks or production access.

docs/security/ROOT_POLICY_APPROVAL.md

@@ -0,0 +1,13 @@
+# Root policy approval and resolver verification
+
+3 November2026. Owner explicitly answered **"Approve policy creation and publication"** to the exact41-line SECURITY.md proposal and target in this chat. Approval includes validating the chain and committing/publishing on the security review branch; it does not approve a scan, charge, active testing or production action.
+
+Target was reread and remained absent; HEAD was88bcd6d91c6823ffc6bbc6a6de176ab7769e729f and worktree was clean before creation. Applied text matches the approved candidate exactly after normal newline decoding. Policy LF SHA256: `4ec5365bdc1f84410b596b893463572b035f03d1260f51af722d1c32c8fa3eb3`.
+
+Installed define-security-policy workflow: policy inventory and root/nearest-path guidance reviewed; both existing docs-only policies resolved inside the repository, regular files below1MiB. API had no inherited policy before the change. After creation the actual resolver exited0 for JobTrackerApi and job-tracker-ui with the new root policy, and for docs/cv-import with root plus its existing nearer policy. No inherited policy overwritten. Diff whitespace check passed. No application tests run for this Markdown-only change.
+
+Exact proposal retained through Codex Security managed standalone artifact storage: `artifacts/root-policy-proposal.md`, artifact SHA256 `5d00af57cfa55de2792218916fd9cf646b470d821db6e8afee5c59c76dba116b`, at `C:\Users\Connor\.codex\state\plugins\codex-security\scans\Job-tracker\artifacts-ad2afb630ff68e10e32f349b87541ffb5778071babb98965362c085936a3f385\artifacts\root-policy-proposal.md`. Persistent readback succeeded. This is a standalone document collection, not a scan ID or result.
+
+No new finding exclusion, risk acceptance or severity downgrade. Canonical-profile, tenant, revision, parser/file, AI-consent, provider and recovery invariants remain review requirements, not assertions that all controls already pass. No secret values or private user content read/exported. Source-security and final integrated acceptance remain open.
+
+Next: reconcile the intended immutable integration revision before a baseline scan, finish capability/cost/scope preflight and record actual results. The older offline audit branch is not a final scan of A3 UI changes. Deep allowance and isolated staging remain distinct protected decisions; final integrated scanning follows relevant application changes.