{{Header}}
{{#seo:
|description=Reviews and feedback about the security of {{project_name_long}}.
|image=Reviews.png
}}
{{audit_mininav}}
[[File:Reviews.png|thumb|200px]]
{{intro|
Reviews and feedback about the security of {{project_name_short}}.
}}

= Definition of Audit =
The term "audit" in the context of computer security is frequently used without a clear definition. It is often referenced as a general concept, with little consideration for what an audit entails or how it is conducted. Many discussions assume that an audit is a simple, standardized process. An item to be checked off a list without a thorough understanding of its scope, methodology, or significance.

= Lack of Formal Audits =
{{project_name_short}} has not been subject to a full formal audit, but that has little significance. At the time of writing, other security/privacy-focused distributions like TAILS and Qubes have not been audited either. Even major operating systems such as Debian, Arch, and Fedora have not had public, published audits to date.

= Absence of Recognized Experts =
We are unaware of any serious research concerning the above distributions. Furthermore, no recognized experts, such as [https://en.wikipedia.org/wiki/Bruce_Schneier Bruce Schneier] in cryptography, exist for conducting a security-focused operating system review.

= Limitations of Published Audits =
Even the usefulness of any published audit must be considered. Audits of software and operating system platforms are necessarily carefully defined and limited in scope due to the vast complexity of such an undertaking. There are no all-encompassing audits that thoroughly examine or evaluate every possible aspect of security.

= Examples of Formal Security Audits of Other Software =
There have been formal audits of cryptocurrency wallets.

* [https://leastauthority.com/static/publications/LeastAuthority_Hiro_Stacks_Wallet_Extension_Final_Audit_Report.pdf Stacks Wallet Extension Security Audit Report]

= Examples of Partial Security Audits =
Independent researchers occasionally conduct partial security audits, a practice often referred to as security research.

* [[Ledger Hardware Wallet]]: [https://keylabs.io/ Keylabs] performed a partial audit as part of [https://wallet.fail wallet.fail], which was presented in {{VideoLink
|videoid=Y1OBIGslgGM
|text=35C3 - wallet.fail
}}.
* <code>Libbitcoin Explorer</code> (<code>bx</code>): [https://milksad.info/distrust.co Distrust] and independent researchers conducted a partial audit known as [https://milksad.info/ Milk Sad Disclosure].
* [[Kicksecure]]: {{Twitter_link|ProudmuslimDev|ProudmuslimDev}} performed an audit of a single script (whereas a Linux distribution consists of potentially hundreds of thousands of scripts and programs): {{Twitter_link|ProudmuslimDev/status/1878163686365544823|privilege escalation issue (Twitter)}} ([https://forums.kicksecure.com/t/upgrade-nonroot-privilege-escalation-issue/886 upgrade-nonroot privilege escalation issue (forums)]).
* [https://tails.net Tails]: [https://tails.net/news/version_6.11/index.en.html Critical security fixes].

Typically, researchers identify areas of interest either through their own investigations or by being directed to them by others. If a particular issue captures their attention, they may examine a few specific aspects in greater detail. White hat hackers who uncover security vulnerabilities may choose to publish a full public disclosure for the benefit of the community.

Security researchers often refer to themselves as such rather than as security experts or auditors. This distinction may be intentional, recognizing the additional weight and implications associated with the latter titles.

These independent researchers are usually not hired by the software projects they analyze, which can be beneficial as it helps maintain their impartiality. However, they do not claim to conduct full formal audits. Instead, they typically provide evidence of the security issues they discover while avoiding broad statements such as "we performed a full formal security audit" or "we found no security issues."

= Examples of Security Research =
* [https://www.freehaven.net/anonbib/ Free Haven's Selected Papers in Anonymity]

Nothing comparable exists for security-focused Linux distributions.

= Examples of Unaudited Software =
To explore this issue in further detail, consider the GNU <code>wget</code> computer program, which retrieves content from web servers. Has <code>wget</code> ever been fully, formally audited? Even if it has, what did the audit entail? A professional company providing software security audits as a service, or some kind of certification? At present, no such entities exist to provide this service within the Free Software and Open Source ecosystem, meaning there are no official quality seals for Linux distributions.

If the reader is aware of any such examples, please get in contact or edit this section. Also, consider whether it is reasonable to expect a reputable organization or individual to make statements like: "GNU <code>wget</code> has been audited, and no security vulnerabilities were found." In reality, it usually happens the other way around; when someone reviews the source code and finds nothing wrong, nothing is reported. On the other hand, if a vulnerability is found, it may bring recognition. Essentially, anyone who claims beforehand to have found no security issues does not receive a boost to their reputation but, in fact, risks looking bad if problems are discovered later on after their previous statements about no security issues.

= Why is Unaudited Software Being Used? =

The absence of a formal audit does not automatically indicate that software is insecure.

Software may be used despite lacking a formal audit for several reasons:

* '''Security-Hardened Design''': Some software follows strict security practices, such as kernel hardening, sandboxing, and least privilege principles, which reduce attack surfaces even without an audit.
* '''Transparency and Open-Source Development''': Open Source software allows continuous peer review, community contributions, and independent security research, often leading to the discovery and resolution of vulnerabilities.
* '''Active Security Research and Patching''': While not equivalent to a full audit, independent researchers often analyze software, report vulnerabilities, and contribute to security improvements over time.
* '''No Fully Audited Alternatives''': In many cases, no fully audited alternatives exist, and users must rely on the best available option while considering other security factors.
* '''Real-World Trust and Adoption''': Software may be widely used and trusted within security-conscious communities due to its track record, rapid vulnerability response, and adherence to security best practices.

The security of software is not determined solely by whether it has undergone a formal audit but by its design principles, how vulnerabilities are handled, and how well it integrates with other security-focused technologies.

= Call for Audits =
Anybody undertaking an audit of {{project_name_short}} is kindly asked to edit this section or get in contact so the outcome can be linked here.

{{reflist|close=1}}
{{Footer}}
[[Category:Design]]