# secureblue: a security-focused Linux assembled as bootable containers

> secureblue is a desktop and server Linux distribution that is built with BlueBuild and shipped as OCI bootable containers on top of Fedora Atomic Desktop base images, so the operating system is an image you pull and boot rather than a set of packages you install. The repository is mostly configuration and build recipes, and its recent release notes are a good guide to what the project thinks matters, from disabling thumbnailing to going SUID-less.

**secureblue/secureblue** — A security-focused desktop and server linux operating system.

- Repository: https://github.com/secureblue/secureblue
- Website: https://secureblue.dev
- Stars: 1,095 · Forks: 106
- Language: Python
- License: Apache-2.0
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/secureblue-secureblue

## An operating system you boot from a container image

secureblue describes itself as a security-focused desktop and server Linux operating system, and the way it is built is the part that distinguishes it from a distribution in the usual sense.

The README says it is built using BlueBuild and shipped as a set of OCI bootable containers, using bootc, with Fedora Atomic Desktop's base images as a starting point.

Each of those four choices matters. BlueBuild is the build system, so the OS is assembled by a pipeline rather than compiled from a package tree. OCI containers mean the artefact is an image you pull, and bootable containers mean that image is a filesystem you can boot, not just a thing you run. And starting from Fedora Atomic Desktop means the base is an immutable, image based system where the operating system itself is the unit of update.

That last point explains the vocabulary. In an image based system you do not apt upgrade your way through a year of security patches, you pull a new image and reboot into it. That is a different operational model, and it is the model secureblue is built for, with the security posture as the reason to accept it.

The licence is Apache-2.0 in the repository metadata, the project site is secureblue.dev, the default branch is live, and the last push was on 2026-10-15. The project is a single maintainer by the look of the manifest, which names RoyalOughtness.

## The release notes are the clearest statement of intent

Three recent releases, and each title says what the maintainers think is worth doing, which is more informative than a feature list would be.

v4.9.1 from 2026-05-26 is titled Secureblue goes SUID-less. That is a structural security change, because the setuid bit is the mechanism by which a program runs with the privileges of another user, and removing the need for it removes a category of privilege escalation bug from the system rather than patching individual instances of it.

v4.9.2 from 2026-06-10 is Improved Homebrew security with brew-proxy. The Homebrew formula is a common way to install Linux applications on a desktop, and the project is putting a proxy in front of it so that the install path does not hand out arbitrary binaries.

v4.9.3 from 2026-09-03 is Thumbnailing is now disabled by default. Thumbnailing is the feature that generates preview images of files for a file manager, and the service that does it has to open every file, which is a large attack surface for something that only produces thumbnails. Turning it off by default is the same philosophy as the SUID change, removing a capability rather than restricting it.

Taken together, the three titles describe a project that reduces what the system can do, on the grounds that a desktop you use for work does not need to be able to run arbitrary code with elevated privileges or to decode every file you have ever opened. That is a coherent position, and it is a position an organisation has to agree with, because the flip side of removing features is that some workflows stop working.

## The repository is a build system rather than a source tree

The repository layout is the clearest description of what the project is, and there is no src/ directory of application code anywhere in it.

What is there is files/, which is the filesystem of the operating system image, modules/ for the pieces that are added on top, recipes/ for the build recipes, tools/ for the development tooling, uki/ for the Unified Kernel Image support, and docs/ for the documentation. There is a Justfile as the task runner, a cosign.pub file, and a LICENSES/ directory.

The pyproject.toml is the build tooling rather than the operating system itself. It declares the project as secureblue version 4.9, requires Python 3.14 or newer, and lists two dependencies, inquirer for the interactive prompts and rpm for the package format. The linting configuration is extensive, with ruff configured to a line length of 100 and a long selection of rule families, and a per file ignore that exempts the audit checks script at files/system/usr/libexec/secureblue/audit_secureblue.py from the annotation rules, with the comment explaining that audit checks' function signatures do not need type hints.

So the interesting part of this repository is a tree of files that describes a filesystem, plus the recipes that turn it into an image, plus the tooling that verifies the result. A reader looking for a kernel patch will not find one, and a reader looking for a packaging recipe will find exactly what they need.

## The security tooling is in the pipeline, not in the documentation

The badge row at the top of the README is a better summary of the project's security posture than any paragraph could be.

There is a build workflow, build-all.yml, an integration test workflow, integration_tests.yml, and a Trivy workflow, trivy.yml, which is a vulnerability scanner for container images. The project also carries the OpenSSF Best Practices badge and the OpenSSF Scorecard badge, which is an assessment of the security practices of the repository itself rather than of the software it produces.

And the repository has the supporting configuration for those practices. There is a .gitleaks.toml, which is the configuration for a secret scanner, a .pre-commit-config.yaml, a .shellcheckrc for shell linting, a .codespellrc for spell checking, and a .textlintrc for prose linting. The .editorconfig handles whitespace, and .gitattributes handles line endings.

The cosign.pub file is the interesting one. It is a public key, and it exists so that the images the project publishes can be verified by whoever pulls them, which turns the supply chain of the distribution itself into something a consumer can check rather than something they have to take on trust.

Combined with the OpenSSF Scorecard badge, the picture is of a project that treats its own build infrastructure as part of the product's security surface, which is the right instinct for something whose job is to be trusted with a machine.

## The licence is per file, and the alternative is to do it yourself

Two things about the terms and the alternatives are worth separating.

On the licence, the licence field in the repository's own metadata records Apache-2.0, but the pyproject.toml does something more precise. Instead of a single licence field it declares license-files = ["LICENSES/*.txt"], which means each file in the image carries its own licence text and the LICENSES/ directory at the root holds them. That is the arrangement a distribution built from many upstream components needs, and it is a sign the project takes redistribution seriously rather than papering over a single grant.

The alternative is not another distribution, it is doing the same thing yourself. The tools are public. BlueBuild, bootc and the Fedora Atomic base images are all available, so a team that wants an immutable, image based Linux with a hardened configuration can build one, and secureblue is essentially a maintained configuration of that build plus a set of decisions about what to remove and what to keep. The difference is that secureblue carries the maintainer's judgement, the security fixes to the configuration, and the integrations, and a team doing it themselves carries the maintenance instead.

That also sets the boundary for who should not use it. If your organisation needs a package set that matches a well known distribution, or a long term support promise from a vendor with a support contract, this is the wrong shape. The project is a single maintainer building a hardened immutable image, and it is a good fit for a user who values that and accepts the trade, and a poor fit for a support contract.

## Conclusion

Adopt secureblue if you want a Linux where the hardening has already been decided for you and where the system is an immutable image you can roll forward and roll back. Do not adopt it if you need a conventional package based distribution, if you depend on third party software that expects the wider Fedora package set, or if your policy requires a distribution with a long term support lifecycle that a single maintainer cannot promise. Verify first that the features and packages you need are present in the image you pick, that the per file licence files in LICENSES/ match your organisation's policy, and that your hardware is on the supported list before you commit a fleet to it.

## FAQ

### What is secureblue and how is it built?

It is a security-focused desktop and server Linux operating system, built using BlueBuild and shipped as a set of OCI bootable containers using bootc, with Fedora Atomic Desktop's base images as the starting point. The project site is secureblue.dev.

### What has changed in recent secureblue releases?

v4.9.1 from 2026-05-26 made secureblue SUID-less, v4.9.2 from 2026-06-10 improved Homebrew security with brew-proxy, and v4.9.3 from 2026-09-03 disabled thumbnailing by default.

### How is the secureblue repository licensed?

The licence field in the repository's own metadata says Apache-2.0, and the pyproject.toml declares license-files = ["LICENSES/*.txt"], so individual files carry their own licence texts in the LICENSES/ directory rather than a single grant covering everything.

### What security checks run in the secureblue CI?

The README shows a build workflow, an integration test workflow and a Trivy workflow for image vulnerability scanning, alongside the OpenSSF Best Practices and OpenSSF Scorecard badges. The repository also carries a .gitleaks.toml secret scanner configuration, a pre-commit configuration, shellcheck, codespell and textlint configurations, and a cosign.pub public key for verifying published images.

## Sources

- [License: Apache-2.0](https://github.com/secureblue/secureblue/blob/live/LICENSE)
- [Project website](https://secureblue.dev)
- [README](https://github.com/secureblue/secureblue/blob/live/README.md)
- [Releases](https://github.com/secureblue/secureblue/releases)
- [secureblue/secureblue on GitHub](https://github.com/secureblue/secureblue)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/secureblue-secureblue