Security & Trust

The security route is the public map for HELM security documentation. It points readers to the trust model, verifier model, credential handling, TCB policy, and threat model without duplicating the /trust source page.

Audience

This page is for security reviewers, platform teams, procurement reviewers, and engineers who need to decide which HELM security document answers a concrete question.

Outcome

After this page you should know where to inspect fail-closed execution behavior, signed receipt verification, credential boundaries, and trusted-computing-base assumptions. Use /trust for the main security model and the linked subpages for narrower review.

flowchart TD
    subgraph Ingestion["1. Ingestion & Context Plane"]
        Security["Security route"]
        Trust["/trust security model"]
        Credentials["Credential security"]
    end

    subgraph Evaluation["2. Evaluation & Policy Plane"]
        Threat["Threat model"]
        TCB["TCB policy"]
    end

    subgraph Ledger["4. Tamper-Evident Ledger Plane"]
        Verify["Verifier trust model"]
        Evidence["Receipts and evidence packs"]
    end

    %% Operational Flow Edges
    Security --> Trust
    Security --> Threat
    Security --> TCB
    Security --> Credentials
    Security --> Verify
    Trust --> Evidence
    Verify --> Evidence

    %% Premium Styling Rules
    style Threat fill:#2d3748,stroke:#4a5568,stroke-width:2px,color:#fff
    style TCB fill:#2d3748,stroke:#4a5568,stroke-width:2px,color:#fff
    style Verify fill:#2f855a,stroke:#276749,stroke-width:2px,color:#fff
    style Evidence fill:#2f855a,stroke:#276749,stroke-width:2px,color:#fff

flowchart TD
    subgraph Ingestion["1. Ingestion & Context Plane"]
        Security["Security route"]
        Trust["/trust security model"]
        Credentials["Credential security"]
    end

    subgraph Evaluation["2. Evaluation & Policy Plane"]
        Threat["Threat model"]
        TCB["TCB policy"]
    end

    subgraph Ledger["4. Tamper-Evident Ledger Plane"]
        Verify["Verifier trust model"]
        Evidence["Receipts and evidence packs"]
    end

    %% Operational Flow Edges
    Security --> Trust
    Security --> Threat
    Security --> TCB
    Security --> Credentials
    Security --> Verify
    Trust --> Evidence
    Verify --> Evidence

    %% Premium Styling Rules
    style Threat fill:#2d3748,stroke:#4a5568,stroke-width:2px,color:#fff
    style TCB fill:#2d3748,stroke:#4a5568,stroke-width:2px,color:#fff
    style Verify fill:#2f855a,stroke:#276749,stroke-width:2px,color:#fff
    style Evidence fill:#2f855a,stroke:#276749,stroke-width:2px,color:#fff

Source Truth

• docs/public/security-and-trust/security-model.md
• docs/public/security-and-trust/threat-model.md
• docs/public/security-and-trust/tcb-policy.md
• docs/public/security-and-trust/key-management.md
• docs/public/security-and-trust/verifier-trust-model.md
• docs/public/reference/verify.md
• core/pkg/guardian/
• core/pkg/proofgraph/
• core/pkg/conform/

Review Path

Boundary Notes

The /security route is intentionally a map, not a second security model. It exists because the public navigation needs a stable security entry point while the canonical model remains /trust. Keep the route narrow: link to the exact security page that owns a claim, name the implementation path that proves it, and avoid restating route tables, compliance mappings, or release promises that belong elsewhere.

Security documentation must distinguish three classes of evidence:

• Runtime controls: policy evaluation, fail-closed behavior, credential scoping, verifier logic, and receipt emission implemented in code.
• Operator procedures: deployment, key handling, incident response, and runbooks that depend on the operator environment.
• Release evidence: checksums, SBOMs, attestations, signatures, and evidence bundles attached to a specific release.

Do not collapse those classes into a generic assurance claim. A reviewer should be able to follow a security statement from this map to a source file, route, test, release artifact, or narrower public page without relying on private sales material.

What This Route Does Not Claim

This route does not claim that every deployment is certified, audit-ready, or fully compliant. HELM can provide verifiable execution evidence only for the paths that are wired through its boundary and retained in receipts, proof records, or release artifacts. Customer-specific controls such as cloud IAM, network policy, key custody, log retention, and incident response remain the operator's responsibility unless a narrower HELM document names the exact managed surface. Keep public security copy precise: describe the control, point to the implementation or verifier, then state the evidence a reviewer can collect.

Troubleshooting