InterGenOS takes security seriously. This document describes how to report vulnerabilities and how we respond.
Project status: R001.x is the first public release line; the project is in active development. The current release is always stated at https://intergenos.org/news.html. InterGenOS keeps a single supported line — the latest release is the supported release, and fixes reach users by advancing that line rather than through maintenance branches or backports, so every user runs the package set the project evaluates. The full policy is in docs/release-policy.md. This policy applies to all InterGenOS code and infrastructure from the date below onward. We are a small team; if we cannot meet a target, we will communicate openly and directly with the reporter. For each release, its Updates entry lists shipped packages named at their shipped versions in published advisories, with each advisory's severity, and the project patches the fixable part in the following cycle.
Primary: Email security@intergenstudios.com
Alternative: Open a private security advisory on GitHub.
Machine-readable contact info also published at https://intergenstudios.com/.well-known/security.txt per RFC 9116.
Anonymous reports accepted. We will never retaliate against good-faith reporters.
Encrypted submissions are fully supported and encouraged. The canonical PGP fingerprint for the project release and encryption keys is published at docs/signing-key.md, and you can import the armored public key from docs/signing-key.asc.
- Within 48 hours of receipt, we will confirm we have your report and begin triage.
| Severity | Target |
|---|---|
| Critical — remote code execution, authentication bypass, Secure Boot chain break | 14 days |
| High — local privilege escalation, cryptographic weakness | 30 days |
| Medium — denial of service, information disclosure | 60 days |
| Low — defense-in-depth gaps | 90 days or next release |
At fix release or 90 days from acknowledgment, whichever comes first. This is a deliberate safety net: we will not sit on unresolved vulnerabilities indefinitely.
If the vulnerability is in upstream code (kernel, systemd, glibc, etc.), we coordinate with their embargo. Our users receive the fix on the same timeline as upstream users — never later.
Published advisories include:
- CVE number (assigned via MITRE)
- CVSS score
- Affected versions
- Mitigation steps
- Patch commit reference
- Timeline (reported / triaged / fixed / disclosed)
- Reporter credit (see below)
A signing-key compromise is not a bug — it is a break in the foundation of trust. The standard framework above does not apply; this track is dedicated and aggressive. For details on how users should handle these trust failures, see the Repository Trust Model.
A confirmed compromise requires evidence, not claim:
- (a) Direct evidence — artifact of private-key material exposure, device-tampering indicator, or credential leak, OR
- (b) Anomalous signature — a valid signature observed in the wild that we did not authorize.
Mere claims route to the standard 48-hour triage and are likely closed without action.
| Timing | Action |
|---|---|
| Immediate | Acknowledgment |
| Within 12 hours | Revocation published + new keyring package available |
| Simultaneous with revocation | Public disclosure — no embargo, no delay |
Target: users running pkm update within 24 hours of the incident receive the new keyring and revoke trust in the compromised key.
- Fingerprint of compromised key
- First known compromised signature timestamp (if determinable)
- Downstream artifacts suspected tampered
- Replacement key fingerprint
- Verification instructions
- Incident timeline
- Convenience is never a reason to delay trust-anchor revocation.
- Our update infrastructure must be trustworthy. A compromised signing key means the update path itself is the attack.
- If there is any doubt about key integrity, we revoke. Re-issuing unnecessarily is preferable to leaving users exposed once.
For full details on the key custody architecture that defends against compromise, see the Signing Procedure and Signing Key Ceremony Procedure.
Accepted reports: we credit reporters in the advisory and on our Hall of Fame page, unless anonymity is requested.
Rejected reports: default to anonymity. If a reporter wishes to be publicly credited for a rejected or duplicate report, they may request it.
No bug bounty program at this time. We appreciate responsible disclosure and will credit researchers publicly, but we do not pay monetary rewards. This policy may change as the project grows.
InterGenOS is accepted into Anthropic's Cyber Verification Program (July 2026; Defense Access under the expanded program, October 2026) and OpenAI's Daybreak Blue, its Trusted Access for Cyber program (September 2026). Both lift the default safeguard refusals that frontier AI models apply to security work, for vetted organizations working on systems they are authorized to protect. The project's AI seats use this access to review and remediate InterGenOS's own security-relevant code; every finding lands in this repository with its evidence. Program pages: Anthropic · OpenAI.
This policy applies to:
- InterGenOS core packages and distribution artifacts
- The pkm package manager and repository infrastructure
- Signing keys and related trust infrastructure
- intergenstudios.com web properties
Out of scope:
- Upstream projects we package (report to them directly; we will coordinate)
- Third-party software installed by users post-install
Every release is published with the artifacts needed to verify it, and none of them requires trusting this document:
| Artifact | Where |
|---|---|
| Installation image | the current image, named on the Updates page; for example, https://repo.intergenos.org/iso/intergenos-r001.4.iso for R001.4 |
| Image checksum | the same name with .sha256 |
| Signature over that checksum | the same name with .sha256.asc |
| Release public key | https://repo.intergenos.org/keys/intergenos-release-key.asc |
| Signed package index | https://repo.intergenos.org/x86_64/current/InterGenOS.db and .sig |
| Signed source tag | the tag matching the current release named on the Updates page |
Verification is two steps and the order matters: check the signature on the checksum file first, then check the image against the checksum. The signature proves the checksum file is the project's and was not altered on the mirror or in transit; hashing the image against that checksum is what catches a truncated download or a substituted image. Neither step substitutes for the other.
The fingerprint to compare is the primary key's —
5597 A3E0 587B 2530 06D0 DD7B 8C50 8261 8208 3050. Your tools will report
the subkey that made a signature; subkeys rotate, the primary fingerprint is
the one to check, and it is also published in
docs/signing-key.md.
The commands, with the same filenames, are in
docs/getting-started.md.
The signed source tag is verified with git tag -v <release>, substituting the release name from the Updates page.
If any of these checks fails, do not install the image, and report it to security@intergenstudios.com — a verification failure on a published artifact is treated as a potential trust-anchor incident, not a download problem.
Known vulnerabilities and our response. InterGenOS ships with mitigations pre-applied.
| Advisory | CVE | Severity | Mitigated |
|---|---|---|---|
| Updates — canonical advisory list | See each release's entry | See each advisory | See each release's entry |
| Copy Fail | CVE-2026-31431 | HIGH (7.8) | 2026-04-29 |
| Dirty Frag + Fragnesia | CVE-2026-43284, CVE-2026-43500, CVE-2026-46300 | HIGH | 2026-05-18 |
Last updated: 2026-10-19