Security Review & Advisory Process

This page describes how InterGenOS receives vulnerability reports, triages them, fixes them, and publishes advisories. It is written for contributors and for users who want to understand the discipline behind the trust chain.

Every decision below exists to give you a machine you understand, can modify, and can trust.

Project status. InterGenOS is at 1.0-dev (build id v1.0-dev1) and in active development toward its 1.0 release. The reporting and response process described here applies to all InterGenOS code and infrastructure. No public ISO has shipped yet, so the advisories published to date document vulnerabilities mitigated before any public installation existed.

Where the canonical policy lives

The authoritative, version-controlled policy is SECURITY.md at the repository root. This page summarizes that policy and the day-to-day process around it. When the two disagree, SECURITY.md wins. Users looking for the human-readable advisory list should also see the Security Advisories release-notes page; the broader hardening posture is covered in the Security Handbook.

Reporting a vulnerability

There are two intake channels:

Primary: email security@intergenstudios.com.
Alternative: open a private security advisory on the project’s GitHub repository.

Machine-readable contact information is published per RFC 9116 at https://intergenstudios.com/.well-known/security.txt.

Anonymous reports are accepted. Good-faith reporters are never retaliated against. Encrypted submissions are fully supported and encouraged; the canonical PGP fingerprint for the project’s release and encryption keys is published in the repository’s signing-key documentation, alongside the armored public key.

There is no bug bounty program at this time. Researchers are credited publicly (see Reporter credit below), but monetary rewards are not offered. This may change as the project grows.

Scope

What this policy covers:

InterGenOS core packages and distribution artifacts
The pkm package manager and repository infrastructure
Signing keys and related trust infrastructure
intergenstudios.com web properties

What it does not cover:

Upstream projects InterGenOS packages (report to them directly; the project coordinates — see Upstream coordination)
Third-party software a user installs after install

Two response tracks

Reports route into one of two tracks depending on what is at stake. The first is the ordinary software-vulnerability track. The second is reserved for the foundation of the trust chain: a signing-key compromise.

Track 1 — Software vulnerability response

Acknowledgment. Within 48 hours of receipt, the report is confirmed and triage begins.

Triage. Triage assigns a severity, which sets the fix target. Severities and their targets:

Severity	Examples	Target (from triage)
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 with the following release

Public disclosure. At fix release or 90 days from acknowledgment, whichever comes first. The 90-day cap is a deliberate safety net: unresolved vulnerabilities are not sat on indefinitely.

Track 2 — Trust-anchor compromise

A signing-key compromise is not a bug. It is a break in the foundation of trust, and the ordinary framework above does not apply. This track is dedicated and aggressive. The key-custody architecture that defends against compromise, and the user-side recovery procedure, are documented in the repository’s signing-procedure, signing-key-ceremony, and repository-trust documents.

What counts as confirmed. A confirmed compromise requires evidence, not a claim:

(a) Direct evidence — exposure of private-key material, a device-tampering indicator, or a credential leak, or
(b) Anomalous signature — a valid signature observed in the wild that the project did not authorize.

Mere claims route back to the standard 48-hour triage and are likely closed without action.

Response on confirmed compromise:

Timing	Action
Immediate	Acknowledgment
Within 12 hours	Revocation published, new keyring package available
Simultaneous with revocation	Public disclosure — no embargo, no delay

The target is that users who run pkm sync within 24 hours of the incident receive the new keyring and revoke trust in the compromised key.

Trust-anchor compromises are never embargoed. The update path is the attack when a signing key is compromised, so revocation cannot wait on convenience. If there is any doubt about key integrity, the key is revoked; re-issuing unnecessarily is preferable to leaving users exposed.

Upstream coordination

When a vulnerability lives in upstream code (kernel, systemd, glibc, and so on), the project coordinates with the upstream embargo. InterGenOS users receive the fix on the same timeline as upstream users, never later.

In practice this is the common case, because InterGenOS is built from source across six tiers (toolchain, core, base, desktop, ai, extra). The package set is large and drifts as the build evolves; derive the live count from the build manifest rather than treating any single number as permanent.

How a kernel fix actually lands

Both published advisories to date are upstream kernel issues, and they illustrate the standard pattern: a primary in-tree patch plus a defense-in-depth layer.

In-tree kernel patch. Patches live in packages/core/linux-kernel/patches/. The kernel package’s build.sh applies every *.patch in alphabetical order at configure time, so any future build picks up the fix automatically — no manual step beyond rebuilding the kernel (and the UKI, since the kernel image changed).
Defense-in-depth. Where a subsystem is rarely needed on a desktop, the affected modules are additionally blacklisted via a file under /etc/modprobe.d/. This holds even if a patch regresses or a fallback boots an unpatched kernel.
User control is preserved. Blacklist files are plainly visible and user-editable. A user who needs the affected functionality can remove the file or load the module manually. The trade-off — convenience for a few against security for everyone — is resolved in favor of security, consistent with the security-only posture.

Mitigations take effect on the next kernel rebuild and ISO rebuild; they are not retroactively active on already-built artifacts.

Advisory content

Published software advisories include:

CVE number (assigned via MITRE)
CVSS score
Affected versions
Mitigation steps
Patch commit reference
Timeline (reported / triaged / fixed / disclosed)
Reporter credit

Trust-anchor advisories instead include the fingerprint of the compromised key, the first known compromised-signature timestamp (if determinable), downstream artifacts suspected tampered, the replacement key fingerprint, verification instructions, and the incident timeline.

Where advisories are stored

Advisory source files live under docs/security/advisories/ in the repository, and the summary table in SECURITY.md indexes them. Two advisories are published as of this writing:

CVE-2026-31431 — “Copy Fail” (algif_aead local privilege escalation). CVSS 7.8 HIGH. Disclosed 2026-04-29; mitigated the same day. Layer 1 is the upstream kernel patch reverting the vulnerable in-place optimization in the crypto/af_alg.c family; layer 2 blacklists the algif_aead module. Verified to have zero impact on dm-crypt/LUKS, kTLS/IPsec/XFRM, OpenSSL/GnuTLS/NSS, SSH, or kernel-keyring crypto, since those use the in-kernel crypto API directly rather than AF_ALG.
IGOS-SA-2026-002 — “Dirty Frag + Fragnesia” (CVE-2026-43284, CVE-2026-43500, CVE-2026-46300). A cluster of local-privilege-escalation bugs in the kernel sk_buff shared-fragment path, disclosed between 2026-05-07 and 2026-05-13. Mitigated with three in-tree patches plus a modprobe.d blacklist of esp4, esp6, and rxrpc. The CVE-2026-43500 fix is an InterGenOS-authored backport, because the upstream mainline commit targets file locations that do not exist in the pinned kernel; the structurally equivalent site was located and patched in net/rxrpc/io_thread.c. The kernel version pin is binding for the 1.0 release line, so the chosen path is to backport fixes rather than bump the kernel.

The second advisory is the clearest argument for the defense-in-depth layer: Fragnesia was itself proof that the first Dirty Frag patches missed a related code path. The module blacklist blocks the affected modules regardless of patch state, which is exactly the failure mode the extra layer pays for.

Reporter credit

Accepted reports are credited in the advisory and on the project’s Hall of Fame page, unless anonymity is requested. Rejected reports default to anonymity; a reporter who wants public credit for a rejected or duplicate report may request it.

InterGenOS Wiki