LordOS is made by a small team, and we try to work the way serious open-source projects do. This page explains, honestly, which international standards our processes are aligned with, what implements each one, and what is still missing.
LordOS and iPERFEX hold no ISO certification. "Aligned with" means that we follow the main practices of a standard and publish the evidence below; it does not mean that an auditor has assessed or certified us, or that we meet every requirement.
Vulnerability disclosure and handling: ISO/IEC 29147 and ISO/IEC 30111#
What we do: a public Security policy with a reporting channel, scope, safe harbour and target response times (acknowledgement within 3 business days, assessment within 10, fixes for serious problems usually within 30, coordinated disclosure at 90 days); a machine-readable security.txt; credits and advisories for fixed vulnerabilities; signed releases so fixes can be trusted.
Still missing: a documented internal handling process (triage, severity scoring, fix and release steps); a public advisories page; CVE identifiers, through a CVE Numbering Authority or GitHub; GitHub private vulnerability reporting, which we will turn on when the repository is public.
Open-source license compliance: ISO/IEC 5230 (OpenChain)#
What we do: an inventory of every bundled third-party component and its license in THIRD_PARTY.md; license notices on the Licenses page, in the repository and in each Debian package's copyright file; an SPDX 2.3 software bill of materials (SBOM), generated by tools/release/make-sbom.sh and attached to every release starting with 0.8.0 beta; the process is documented in docs/COMPLIANCE.md. Contributions come in under the same MIT license with a sign-off (see Contributing).
Still missing: a written open-source policy; a named person responsible for compliance; training for contributors; an OpenChain self-certification.
Open-source security assurance: ISO/IEC 18974 (OpenChain)#
What we do: the Debian base receives Debian's security updates, installed from the Store or apt; the SBOM lists the components and versions in each release; release files and .lpk packages are signed; the security policy defines how we receive and handle reports.
Still missing: systematic monitoring of known vulnerabilities (CVEs) against the SBOM for each release; a documented process for it; an OpenChain conformance self-certification.
Information security practices (ISO/IEC 27001-style)#
We apply some practices that ISO/IEC 27001 describes, only where they are real:
- Least privilege: apps run in their own sandbox (Landlock, seccomp, cgroups, no capabilities), and the helpers that handle untrusted data (mail, documents, media, the password vault) drop their privileges and network access, as documented in docs/PRIVACY.md. The website deploy credentials can only write to one storage bucket and refresh one CDN distribution.
- Signed releases: every release file is listed in a signed
SHA256SUMS(see Code signing). - Key custody: the release signing key is kept only on the maintainer's machine, never in the repository or on a build machine, with an offline backup.
Still missing: an information security management system (ISMS), a formal risk assessment, documented controls and internal or external audits. We are not ISO/IEC 27001 certified.
Website accessibility: WCAG 2.2 AA#
What we do: the website targets WCAG 2.2 level AA: keyboard access with a visible focus outline, a skip link, reduced motion, light and dark themes, landmarks and text alternatives, as described in the Accessibility statement.
Still missing: a full audit against WCAG 2.2 AA, including testing with screen readers; on the distribution side, a screen reader, screen zoom and a high-contrast theme.
security.txt: RFC 9116#
What we do: /.well-known/security.txt with the Contact, Expires, Preferred-Languages, Canonical and Policy fields.
Still missing: an OpenPGP signature on the file.
Questions#
If you see a gap we haven't listed, or want to help close one, write to us through our contact form.