Private Policy Packs

Why private

The public policy examples describe mechanics. A real company pack contains sensitive role names, asset names, deployment restrictions, known exceptions, regulated-data classifications, and risk approvals. That material belongs outside the public repository.

Keeping it private is not only a confidentiality decision. A policy pack is a map of what an organization considers valuable and where it has already accepted risk, which is exactly the document an attacker would most like to read.

Recommended layout

company-sechelix-policy/        # private repository
  policy.json
  trust-boundaries/
  role-object-action/
  severity-overrides/
  safe-test-rules/
  accepted-risk/                # approvals, expiry, ticket references
  retention/
  CODEOWNERS

Start from policies/example-organization.json. Pin the SecHelix version or commit the pack supports, and record the pack own semantic version and digest so a gate decision can be traced to the exact policy that produced it.

Review rules

• Require security ownership for policy semantics and application ownership for business invariants.
• Require human approval for accepted risk. Models may summarize; they may not approve.
• Give every accepted risk an owner, reason, compensating control, ticket, approval time, and future expiration.
• Review severity overrides in both directions. Lowering a severity needs stronger justification than raising it.
• Reject wildcard trust boundaries and broad production-safe permissions.
• Test the pack against synthetic reports before enforcing it on releases.
• Keep policy history and audit every change.

The runner boundary

• Load private packs at runtime from protected storage or a private checkout.
• Do not copy them into public build artifacts, SARIF uploads, Pages content, cache keys, or logs.
• CI exposes only the gate outcome and a redacted reason summary to untrusted pull requests.
• Forked pull requests must never receive private policy or signing credentials.
• Run privileged evaluation only after the untrusted build is isolated and its artifacts are treated as untrusted input.

Supported controls

A pack customizes release decisions without changing the methodology. The controls the gate understands are:

• Blocking severities.
• Severities requiring independent verification.
• Severities requiring regression proof.
• Whether accepted risk is allowed, and its required approval fields.
• The outcome for integrity-critical unknowns.
• Required evidence tools.
• Forbidden deployment states.
• Severity overrides.

policies/default.json blocks unresolved verified Critical and High findings and returns INCOMPLETE for integrity-critical unknowns. policies/strict.json additionally blocks Medium findings and turns those unknowns into BLOCKED.