Ask HN: How much can we trust open-source projects or our hardware?

3 solosquad 6 9/8/2025, 12:52:52 AM
For large open-source security-focused projects like Kali Linux, we’re told there are no backdoors but with millions of lines of code, how can we actually verify that? Full manual auditing isn’t feasible for most individuals.

Some thoughts/questions:

Are reproducible builds and supply-chain audits enough to trust the binaries?

What strategies exist for spotting subtle backdoors in such large codebases?

For hardware, how do you approach the risk of compromised firmware, microcode, or hidden subsystems (e.g. Intel ME, AMD PSP)?

Do projects like Coreboot, Heads, or formally verified kernels meaningfully reduce this risk in practice?

Beyond reading every line yourself, what’s the best way to build confidence?

How much trust (percentage-wise) do you personally put in OSS security projects or commodity hardware, and what technical mitigations do you use to minimize blind trust?

Comments (6)

benoau · 10h ago
You have to at a minimum trust the OS vendor, probably a slew of development tools, and blindly trust all the hardware you work upon and cloud platforms you deploy to to only-work as advertised.

You shouldn't particularly trust any software, monitor outbound traffic, silo your different projects to minimize what software is adjacent to your projects and the fallout if something got access, minimize programming dependencies and browser and IDE extensions and add-ons and stuff coming from unknown 3rd parties. Stay behind the latest builds/updates/releases so problems have time to be identified.

pabs3 · 9h ago
Reproducible builds aren't enough, you need projects that are reproducibly bootstrappable solely from source without any binaries. Usually the starting point is a small amount (an MBR) of manually entered documented machine code.

https://bootstrappable.org/ https://stagex.tools/

lordkrandel · 5h ago
Secure for what? Intrusion? Spying? Data collection? Dont use internet then. Disconnect. No data will be taken from your laptop this way, unless you are a secret agent, or a criminal.
pabs3 · 9h ago
Almost all firmware is proprietary, so you aren't going to be able to trust it at all. Try to use hardware that has at least open boot firmware like u-boot or coreboot.

https://wiki.debian.org/Firmware/Open

bigyabai · 10h ago
Kali Linux is a pentesting distro. It's not claimed to be secure and AFAIK it makes deliberately insecure design decisions to enable spoofing/SDR attacks.

  Are reproducible builds and supply-chain audits enough to trust the binaries?
No. But for most applications trust isn't really required.

  What strategies exist for spotting subtle backdoors in such large codebases?
It's not hard. For big projects, contributors are usually a tight-knit group that heavily scrutinize any outsider PRs. By creating a rigorous system of code review (and implementing reminders for bad dependencies) you can deter backdoors decently well.

  For hardware, how do you approach the risk of compromised firmware, microcode, or hidden subsystems
You cannot.

  Do projects like Coreboot, Heads, or formally verified kernels meaningfully reduce this risk in practice?
No, but if properly configured they can reduce attack surface as-advertised.

  Beyond reading every line yourself, what’s the best way to build confidence?
I know this is a dumb answer, but "be smart" will get you a really long ways. Stick to the main roads, don't use software developed by 2 or 3 people if your personal security is paramount. Keep your systems slim and minimally networked, route any home servers through a VPN or proxy to prevent it from being harassed on the open internet.
solosquad · 10h ago
that’s true kali it’s designed for pentesting and not necessarily as a secure daily driver, but I was using it more as a stand-in example for large OSS projects where security is critical. Maybe a better example would be Qubes OS or OpenBSD