ddaae5d chore(release): publiseringsklar for open/ — README for standalone rot + MIT + policy-filer f98b287 docs(plan): V1 RATIFISERT — og :275 er en andre tabellrad, ikke prosa d6bced7 docs(plan): SS11 ankrer ikke SS8 — funnet var reelt, men ikke raden som ble bestilt 3174475 docs(plan): §7.2 — feilanker-failuremoden var ikke hypotetisk, den inntraff git-subtree-dir: shared git-subtree-split: ddaae5d637ba4ee8425291d99cfe5c8f7b632001
62 lines
2.5 KiB
Markdown
62 lines
2.5 KiB
Markdown
# Security Policy
|
|
|
|
## Reporting a Vulnerability
|
|
|
|
If you discover a security issue, please report it responsibly.
|
|
|
|
**Please do NOT report security issues through public issues.**
|
|
|
|
### How to Report
|
|
|
|
Email: hello@fromaitochitta.com
|
|
|
|
Include:
|
|
- Description of the issue
|
|
- Steps to reproduce
|
|
- Potential impact
|
|
- Any suggested fixes (optional)
|
|
|
|
### What to Expect
|
|
|
|
- Acknowledgment within 48 hours
|
|
- Regular updates on progress
|
|
- Credit in the fix announcement (if desired)
|
|
|
|
## What the attack surface here actually is
|
|
|
|
This repository ships **no executable code** — no package, no pipeline, no CLI. It contains
|
|
normative specifications, example knowledge bundles, and golden fixtures. There is no dependency
|
|
tree to keep patched and nothing here that runs on your machine.
|
|
|
|
That narrows the realistic reports to three kinds, and all three are worth sending:
|
|
|
|
1. **A specification that mandates unsafe behaviour.** The specs are binding on the
|
|
implementations that consume them, so a weak rule propagates. The ingest specification in
|
|
particular governs a boundary where untrusted external data enters the system: its
|
|
credential-reference rule (manifests carry *references* to credentials, never the credentials
|
|
themselves) and its verdict-layer reservation exist for this reason. A gap in that text is a
|
|
real vulnerability report even though no code changes.
|
|
2. **A secret or personal data in the repository or its history.** The example bundles are
|
|
synthetic. If you find something that is not, report it — including in the git history, which
|
|
is public in full.
|
|
3. **A fixture that would make a consuming gate pass when it should fail.** The golden suites are
|
|
the only ground truth the implementations check themselves against. A fixture that silently
|
|
sanctions unsafe behaviour weakens every consumer at once.
|
|
|
|
## Supported Versions
|
|
|
|
| Version | Supported |
|
|
| ------- | ------------------ |
|
|
| latest | :white_check_mark: |
|
|
| < latest| :x: |
|
|
|
|
Consumers vendor this repository as a `git subtree`, so a fix here reaches them only when they
|
|
pull. If a report leads to a change in normative text, both reference implementations are
|
|
notified — but their pull is their own action, on their own schedule.
|
|
|
|
## Scope Note
|
|
|
|
The portfolio-optimiser method is a **technical framework**. Deploying organizations own their
|
|
own data protection, risk, and compliance assessments (DPIA/ROS). The specifications describe
|
|
technical prerequisites (local-only operation, provenance, no silent egress) but make no
|
|
compliance guarantees.
|