This is a non-exhaustive list of goals for hardening the Debian distribution, the Debian project and systems of Debian contributors and users. If you would like to help make Debian more secure, help on all of these topics is welcome. Don't be intimidated by the length of the list, pick the things you can do something about and put some time into them. If you aren't sure about how to start helping on a particular item, the debian-mentors list should be able to direct you.

Get more people to get involved in Debian so that we have enough people to continue it and keep it secure into the future.

Packaging process

Improve our use of crypto on personal and Debian systems, including upgrading OpenPGP keys and moving them off general purpose systems onto smartcards and similar.

Encourage more contributors to use Tor so that they are less easily targeted by active attackers.

Prevent installing packages with unpatched vulnerabilities, see 431804 for some debscan/apt integration ideas.

Build all binary packages, installer images, preinstalled images and live images on official Debian machines (buildds etc).

Implement reproducible builds (inc Linux), verifiable image builds and reproducible installs.

Fix the various issues with the security and privacy of apt and image mirrors.

Recruit more people to join the security issue tracking effort.

Revive the security audit project.

Revive static analysis services like DACA, firewoes, debile etc.

Periodically send notifications of open vulnerabilities to maintainers.

Encourage package maintainers to check their packages using various tools before upload:

Package more tools for testing the security of both code and installed systems.

Enhance the use of MAC frameworks like (SELinux, AppArmor, Tomoyo, SMACK etc).

Push the compiler flags hardening release goal. Push GCC/LLVM upstreams to enable these by default.

Enable various security features in the Linux kernel, for example hidepid fs.protected_symlinks etc.

Provide grsec versions of the Linux kernel, see #605090 and the blog post by Yves-Alexis Perez.

Debian policy should require that in every source package all security packages should be clearly marked as such in standard and easily parsable way with optional further references.

Build a secondary high-security (but slower) archive using SoftBoundCETS or Clang ASan or GCC ASan (see below) or similar for folks who prefer security to performance.

Refuse to use proprietary software on our personal Debian development machines and on Debian project machines and switch to hardware with free and auditable firmware. Develop security guidelines for personal Debian development machines.

Constructively attack the use of markets/repositories that distribute non-free software, helping make developer machines safer and make developers more aware of the risks:

All of the above for code that we run but don't package.

Work on improving FreedomBox security and port the improvements into Debian.


Educate upstreams about upstream best practices.

Work with programming language upstreams to eliminate entire classes of bugs. For example eliminate (use of) serialisation library misfeatures or the possibility of shell metacharacter injection.

Send upstreams patches for their systemd service files to enable various security features (video, slides).


Encourage users to run tools like tiger checksecurity debsecan.

Develop/package a tiger-like tool like this that provides suggestions and tips to less technical (desktop) users.

Improve debsecan by fixing its bugs

Also see DebianSanctuary

Non-Debian attack vectors:


Advertise the Securing Debian Manual and keep it up-to-date (maybe turn it into a wiki?)

Ideas from Russell Coker