CISA Publishes Open Source Security Guidance: Verifiability Is the Difference
On 30 July 2026, the United States Cybersecurity and Infrastructure Security Agency published Open Source Software: Security Principles and Practices, a 31-page guidance document for federal civilian agencies. It is available at no cost and marked TLP:CLEAR, meaning it may be shared without restriction.
The document is addressed to US federal agencies, and it fulfils obligations under two executive orders on federal cybersecurity. It covers four areas: using open source solutions, contributing to open source projects, producing open source software, and evaluating open source artificial intelligence models. The observations below concern the first three.
Its analytical content is not jurisdiction-specific, and public administrations elsewhere — including in Europe — will find that it articulates, in the vocabulary of risk management, several positions that the open source community has been arguing for two decades.
What the guidance actually says
The central claim is more precise than the headlines suggest. CISA does not assert that open source software is more secure than proprietary software. It states that OSS is “no more or less risky than other software,” and locates the difference elsewhere: with open source, an organisation can assess code quality and security directly, rather than relying solely on vendor assurances.
This is a claim about verifiability, not about defect rates. It is also the more defensible claim, and the more consequential one for procurement. An agency evaluating proprietary software is evaluating a vendor’s statement about its own product. An agency evaluating open source software is evaluating the product.
The guidance draws the corollary explicitly. Among the benefits it lists for federal agencies is reduced vendor lock-in: open standards and modifiable code, CISA writes, protect agencies from “proprietary dependency traps.” A national cybersecurity authority has placed lock-in inside a security document rather than a competition-policy one. That is a meaningful shift in where this argument is permitted to live.
The C4 Framework
The most practically useful part of the guidance is Appendix A, which sets out the C4 Framework for assessing whether an open source project is trustworthy. Its premise is that, because contributors may be pseudonymous and are bound by no delivery obligation, trustworthiness cannot be assessed from who produced the software. It must be assessed from how the software was produced — which open source development makes visible in a way that closed development does not.
C4 groups the evidence into four categories:
- Codebase — commit recency, known vulnerabilities, dependency currency.
- Community — number of maintainers, institutional structure, whether the project sits within a foundation.
- Conduct — whether there is a vulnerability disclosure policy, whether code review is required, whether maintainers merge their own commits, the licence, the code of conduct.
- Configuration — whether defaults are secure, and what hardening the software supports.
The framework is applied in five steps: identify measurable criteria, determine risk tolerance and weight the criteria, collect observations (with automated tooling where available), evaluate against each criterion, and compare the result to the tolerance.
We would encourage public administrations to apply this framework to LibreOffice. Every category can be answered from public evidence: a continuous commit history since 2010, a published security policy and disclosure process, mandatory peer review, an OSI-approved licence, a documented code of conduct, and a governance structure — The Document Foundation, a German Stiftung with an elected Board of Directors — that is a matter of public record rather than of assertion.
We would encourage administrations to apply the same framework to every candidate solution, including proprietary ones, and to note which questions can be answered and which cannot.
Contributing, and the support question
The guidance also addresses a question that public administrations regularly raise about open source adoption: who is responsible for fixes. CISA’s answer is that no single entity is obliged to provide them, and that agencies should therefore plan accordingly — assigning internal staff, contracting third parties, or both — while following two principles in dealing with upstream projects: collaborate rather than demand, and push fixes upstream.
This is a fair description of how the LibreOffice ecosystem works. Support, long-term maintenance, and custom development are provided by certified developers and certified migration professionals, whose contributions return to the shared codebase and benefit every other deployment. The guidance is right that this requires organisations to plan for it. It is also right that the resulting improvements are shared rather than captured.
CISA further notes that where a project becomes unmaintained, an organisation may as a last resort take over a fork. This option has no equivalent in proprietary software, where end of support arrives on the supplier’s schedule and offers no remedy at all.
A note on scope
The document does not name any product. CISA states explicitly that it does not endorse commercial entities, products, or services, and nothing in the guidance should be read as an assessment of any particular software. What it provides is a set of criteria. The observation that LibreOffice satisfies them is ours, and rests on evidence that anyone may check.
Open Source Software: Security Principles and Practices is available from CISA: https://www.cisa.gov/resources-tools/resources/open-source-software-security-principles-and-practices
CISA’s announcement: https://www.cisa.gov/news-events/news/cisa-guide-helps-federal-agencies-securely-and-effectively-use-open-source-software
