diff --git a/20-product-tdd/security-boundary-model.md b/20-product-tdd/security-boundary-model.md new file mode 100644 index 0000000..57d7b5e --- /dev/null +++ b/20-product-tdd/security-boundary-model.md @@ -0,0 +1,169 @@ +# Security Boundary Model + +## Purpose + +This document defines the shared security reasoning model for InKCre。It helps Humans and +implementations distinguish a vulnerability from an ordinary bug，hardening opportunity， +operational risk or accepted risk without maximizing controls for their own sake。 + +A security requirement needs an identified actor，protected asset，intended boundary，credible +attack path and proportionate control。Exact protocol admission，database grants，rendering， +credential handling and deployment behavior remain owned by the Unit that implements them。 +External vulnerability reporting remains owned by the applicable repository `SECURITY.md` and +organization policy。 + +## Shared Deployment Model + +```mermaid +flowchart LR + owner["Deployment owner"] -->|"operates and configures"| deployment["InKCre deployment"] + peer["Admitted Peer"] -->|"admitted protocol"| deployment + caller["Untrusted caller"] -->|"public or protocol surface"| deployment + source["External source and untrusted content"] -->|"collection"| deployment + extension["Reviewed Extension artifact"] -->|"declared runtime capability"| deployment + deployment -->|"selected requests and data"| provider["External provider"] + deployment -->|"persists"| infobase["Info-base"] +``` + +The arrows are trust and authority boundaries，not a promise that every deployment exposes every +path。Host isolation，transport termination，backups and provider custody are supplied by the +selected deployment and must be assessed with its Unit-owned runtime documentation。 + +## Actors And Authority + +| Actor | Shared posture | +| --- | --- | +| Deployment owner | Trusted administrator of one deployment。Can configure its Peers，inspect deployment-owned persistence and replace deployed artifacts。 | +| Admitted Peer | Inside the deployment trust domain after satisfying one executable Peer protocol。Peer equality does not imply identical execution capability，but the current product does not promise per-user or per-tenant isolation between admitted Peers。 | +| Untrusted caller | Has no deployment authority until admitted by the relevant public，Peer or Extension protocol。A public observation grants only its documented result。 | +| Extension protocol caller | Untrusted until the Extension-owned admission mechanism succeeds。Successful Extension admission grants only that protocol's intended authority。 | +| External source and collected content | Untrusted data。Collection does not make malformed，adversarial，stale or misleading content executable or trustworthy。 | +| Reviewed Extension artifact | Trusted application code within the runtime that admits it。An Extension registry is an organization mechanism，not a sandbox or tenant boundary。 | +| External provider | Outside the deployment boundary。It receives requests and data deliberately sent by configured capability code，subject to its own policy and credentials。 | + +## Protected Assets + +- confidentiality and integrity of info-base Blocks，Relations，stored bytes and derived output； +- credentials and signing material used to admit Peers，Extension callers，Sources，Storages and + external providers； +- the deployment owner's control over collection，organization，retrieval，configuration and + deletion； +- artifact，migration and dependency integrity； +- availability where an otherwise untrusted actor can cause meaningful denial，resource exhaustion + or external cost。 + +## Shared Boundaries And Invariants + +### Admission + +Core，database，Peer and Extension protocols may expose different admission surfaces。Authority +granted by one surface does not silently grant another surface's authority。Public routes reveal +only their intentionally public observations。 + +CORS，obscurity，route naming and possession of a non-secret client identifier are not authorization +boundaries。Exact claims，roles，credentials and denial behavior belong to the implementing Unit's +executable contract。 + +### Persistence And Credentials + +Persistence operated by the deployment is inside the deployment trust boundary unless a more +specific topology says otherwise。Persisting a credential in access-controlled deployment +configuration is not by itself a boundary violation。The relevant questions are whether an +unauthorized actor can obtain or exercise it through responses，logs，public artifacts，backups or +unrelated protocols，and whether its replacement and lifetime match the product need。 + +Encryption at rest，an external secret manager or non-persistence may become justified when a +deployment introduces an untrusted persistence operator，independently exposed backups，multiple +users，delegated administration，regulatory duties or another concrete boundary。They are not +automatic requirements without that boundary。 + +### Data And Code + +Collected content，filenames，metadata，provider responses，resolver input and AI input are data +controlled partly or wholly by external parties。They must not become code，filesystem paths，SQL， +templates，privileged commands or authorization decisions without an explicit validating boundary。 + +Storing or interpreting adversarial content is not itself a vulnerability。Executing it，letting it +escape its intended data context or allowing it to drive privileged behavior may be one。Each +presentation Unit remains responsible for safe rendering and interaction at its own boundary。 + +### Extensions And Artifacts + +A reviewed Extension shares the authority of the runtime or Peer that loads it unless that runtime +explicitly supplies a stronger isolation boundary。Runtime installation of unreviewed code is not +part of the current shared product contract。Artifact construction，dependency admission and release +integrity remain owned and enforced by the delivering repository。 + +### Privileged Operators + +The deployment owner，host administrator，migration authority and anyone able to replace a running +artifact already hold high authority within their scope。Protecting a deployment from its own fully +privileged operator is not a default product goal；a deployment that separates these roles must +document the new boundary explicitly。 + +## Security Classification + +A vulnerability requires both security harm and a credible attack path。Examples include an actor +crossing an intended boundary to： + +- read，create，change or delete protected data without the authority granted by the relevant + protocol； +- forge or bypass admission and gain materially greater authority； +- cause attacker-controlled data to execute code or privileged commands； +- expose credentials or private content through responses，logs，artifacts，caches，backups or + providers； +- compromise artifact，migration or dependency integrity in a way that reaches users； +- cause material denial of service or external cost from an otherwise untrusted position。 + +A surprising behavior，best-practice deviation，missing defense-in-depth layer or hypothetical +consequence without a boundary crossing is insufficient by itself。It may still be an ordinary bug， +privacy issue，hardening opportunity，operational risk or accepted risk。 + +## Common Non-Boundaries + +Unless another topology introduces a different actor or authority boundary，the following are not +vulnerabilities by themselves： + +- a deployment owner reading or changing its own configuration，persistence，backups or process + memory； +- one admitted Peer exercising a capability intentionally shared with admitted Peers； +- reviewed Extension code reaching resources intentionally available to its runtime； +- a credential being persisted within access-controlled deployment configuration； +- absence of encryption at rest or an extra authentication layer without a demonstrated + unauthorized reader or caller； +- malformed or hostile collected content being stored as inert data； +- an architectural hardening proposal without an exploit path or user harm； +- behavior requiring prior host-administrator，migration-authority or artifact-replacement access。 + +Accurate classification does not prohibit improvement。It prevents reliability，privacy or +hardening work from borrowing false urgency from the word “vulnerability”。 + +## Proportionality Method + +Before requiring a control or classifying a report，establish： + +1. **Actor and capability**：who acts，and what authority do they already possess？ +2. **Asset and harm**：what protected interest changes，leaks，executes or becomes unavailable？ +3. **Boundary**：what intended separation is crossed？ +4. **Attack path**：what reproducible or technically credible steps connect actor to harm？ +5. **Existing controls**：which executable，deployment or operational mechanisms already reduce + the risk？ +6. **Control cost**：what dependency，obscurity，failure mode，user friction or operational burden + would the proposed control introduce？ +7. **Classification**：vulnerability，ordinary bug，hardening，operational risk or accepted risk？ + +Prefer the least complex control that materially changes the identified risk。Re-evaluate when an +actor，asset，deployment assumption or trust boundary changes；do not preserve a conditional answer +as a timeless rule。 + +## Ownership + +- Shared actors，assets，boundaries and classification method：this document。 +- Product authority and cross-Unit topology：[System State And Authority](system-state-and-authority.md) + and [Unit Topology](unit-topology.md)。 +- Exact admission，persistence，rendering，runtime and deployment mechanics：the implementing Unit's + executable contract and local durable documentation。 +- External vulnerability reporting：the applicable repository `SECURITY.md` and organization policy。 + +Update this model when a shared actor，asset，deployment assumption or trust boundary changes。Do +not duplicate Unit-local mechanics here merely because they are security-relevant。 diff --git a/20-product-tdd/unit-topology.md b/20-product-tdd/unit-topology.md index a123511..6ece843 100644 --- a/20-product-tdd/unit-topology.md +++ b/20-product-tdd/unit-topology.md @@ -22,6 +22,9 @@ Define cross-unit technical boundaries and ownership so changes do not leak resp - Peer equality does not imply identical execution ability. A business facade may execute locally on a capable Peer or delegate one exact synchronous capability to another live Peer without turning the deployment into a fixed frontend/backend hierarchy. +- Shared actors，assets，trust boundaries and proportional security classification use the + [Security Boundary Model](security-boundary-model.md)。Each Unit still owns its executable + admission，rendering，runtime and deployment mechanics。 ## Knowledge Capability Topology diff --git a/docs/index.md b/docs/index.md index 0c6fb9a..17fcd0c 100644 --- a/docs/index.md +++ b/docs/index.md @@ -4,6 +4,7 @@ - [Product requirements](../10-prd/index.md) - [Unit topology](../20-product-tdd/unit-topology.md) +- [Security boundary model](../20-product-tdd/security-boundary-model.md) - [System state and authority](../20-product-tdd/system-state-and-authority.md) - [Cross-unit contracts](../20-product-tdd/cross-unit-contracts.md) - [Knowledge capability contract](../20-product-tdd/knowledge-capability-contract.md) diff --git a/tasks/shared-security-model-ownership/packet.md b/tasks/shared-security-model-ownership/packet.md new file mode 100644 index 0000000..02d052f --- /dev/null +++ b/tasks/shared-security-model-ownership/packet.md @@ -0,0 +1,35 @@ +# Shared security model ownership + +- **Objective**: move InKCre-wide actors，assets，trust boundaries and proportional security-classification method from + `core-py` into the shared Hub，then leave core-py with only its runtime-specific application of that model。 +- **Guardrails**: this is an independent ownership correction，not a `knowledge-lifecycle-capabilities` Unit，security audit， + control expansion or behavior change。Hub truth must remain meaningful without FastAPI，PostgREST，Alembic，one concrete + Extension or one repository's CI。External reporting remains owned by each repository's `SECURITY.md` and organization + policy；Spokes retain executable admission，rendering，runtime and deployment mechanics。 +- **Verification**: every migrated claim has one durable owner；Hub navigation reaches the shared model；core-py no longer + presents the shared model as repository-local truth；Hub is committed and pushed before the Spoke shared ref moves；Hub and + Spoke diffs pass their declared static checks。 +- **Current Truth**: `core-py/docs/30-unit-tdd/security-model.md` mixes stable project-wide reasoning with core-py actors， + runtime vocabulary，deployment links and a Memos PAT worked example。Its project-wide content is already consumed as a + collaboration boundary across InKCre，so repository-local ownership is misleading。 +- **Next Step**: publish a Hub-owned `20-product-tdd/security-boundary-model.md` containing only shared truth。After Human + review and Hub push，bump core-py's `docs/_shared` ref and replace the local monolith with a thin core runtime boundary note。 + +## Ownership split + +### Hub-owned + +- deployment owner，admitted Peer，untrusted caller/content，Extension protocol caller，Extension artifact and external + provider as shared actor categories； +- protected info-base，credentials，owner authority，artifact integrity and attacker-reachable availability/cost； +- admission，persistence，data/code，Extension and privileged-operator trust boundaries； +- vulnerability versus bug，hardening，operational risk and accepted-risk classification； +- actor → asset/harm → boundary → attack-path → existing-controls → control-cost reasoning； +- the rule that deployment topology changes may change a security conclusion without changing the method。 + +### Spoke-owned + +- exact routes，claims，roles，database grants，processes，migrations，logs，probes and deployment sequencing； +- renderer，native-client and transport-specific data handling； +- concrete Extension credentials and protocol admission； +- repository CI/dependency admission and local worked examples。