V8.13.536.2025.12.04

Signed-off-by: Marc S. Weidner <msw@coresecret.dev>

README.md

@@ -32,6 +32,9 @@ include_toc: true
 **CISS.debian.live.builder — First of its own.**<br>
 **World-class CIA designed, handcrafted and powered by Centurion Intelligence Consulting Agency.**
 
+Developed and maintained as a one-man, security-driven engineering effort since 2024, **CISS.debian.live.builder** is designed 
+to serve as a reference implementation for hardened, image-based Debian deployments.
+
 This shell wrapper automates the creation of a Debian Trixie live ISO hardened according to the latest best practices in server
 and service security. It integrates into your build pipeline to deliver an isolated, robust environment suitable for cloud
 deployment or unattended installations via the forthcoming `CISS.debian.installer`. Additionally, automated CI workflows based
@@ -45,7 +48,7 @@ with a hardened initramfs chain including a dedicated Dropbear build pipeline fo
 with a hardened kernel configuration, strict sysctl and network tuning, pre-configured SSH hardening and fail2ban, and a 
 customised `verify-checksums` path providing both ISO-edge verification and runtime attestation of the live root. All components
 are aligned with the `CISS.debian.installer` baseline, ensuring a unified cryptographic and security posture from first boot to 
-an installed system. For an overview over the entire build process, see:
+an installed system. For an overview of the entire build process, see:
 **[MAN_CISS_ISO_BOOT_CHAIN.md](docs/MAN_CISS_ISO_BOOT_CHAIN.md)**
 
 Check out more leading world-class services powered by Centurion Intelligence Consulting Agency:
@@ -59,13 +62,14 @@ Check out more leading world-class services powered by Centurion Intelligence Co
 * [Contact the author](https://coresecret.eu/contact/)
 
 **Legal Disclaimer:**
-* This project is not affiliated with, authorized, maintained, sponsored, or endorsed by [Debian Project](https://www.debian.org/) 
+* This project is not affiliated with, authorized, maintained, sponsored, or endorsed by the [Debian Project](https://www.debian.org/) 
-* [Centurion Imprint](https://coresecret.eu/imprint/)
+* [Centurion Imprint & Legal Notice](https://coresecret.eu/imprint/)
-* [Centurion Privacy](https://coresecret.eu/privacy/)
+* [Centurion Privacy Policy](https://coresecret.eu/privacy/)
 
 ## 1.1. Preliminary Remarks
 
 ### 1.1.1. HSM
+
 Please note that all my signing keys are stored in an HSM and that the signing environment is air-gapped. The next step is to 
 move to a room-gapped environment. ^^
 
@@ -77,57 +81,48 @@ add_header Expect-CT                 "max-age=86400, enforce"
 add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
 ````
 
-* Additionally, the entire zone is dual-signed with **DNSSEC**. See the current **DNSSEC** status at: **[DNSSEC Audit Report](/docs/AUDIT_DNSSEC.md)**
+* The zones behind this project are dual-signed with **DNSSEC**. The current validation state is documented in the **[DNSSEC Audit Report](/docs/AUDIT_DNSSEC.md)**
-* A comprehensive TLS audit of the **`git.coresecret.dev`** Gitea server is also available. See: **[TLS Audit Report](/docs/AUDIT_TLS.md)**
+* The TLS surface of **``git.coresecret.dev``** is independently audited, and the findings are held in the **[TLS Audit Report](/docs/AUDIT_TLS.md)**
-* The infrastructure of the **`CISS.debian.live.builder`** building system is visualized here. See: **[Centurion Net](/docs/CNET.md)**
+* The topology of the underlying **`CISS.debian.live.builder`** building infrastructure is described in **[Centurion Net](/docs/CNET.md)**
 
 ### 1.1.3. Gitea Action Runner Hardening
 
-The CI runners operate on a dedicated host system located in a completely separate Autonomous System (AS). This host is solely 
+The CI runners live on a host in a separate autonomous system, and that host has exactly one purpose: run Gitea Actions runners. 
-dedicated to providing CI runners and does not perform any other tasks. Each runner is hermetically isolated from others using 
+Each runner receives its own service account without a login shell, is bound to a separate directory tree, and inherits a 
-non-privileged, shell-less user accounts with no direct login capability. Additionally, each runner executes within its own 
+hardened systemd unit with ``DynamicUser``, reduced capabilities, and restrictive sandboxing. A ``systemd-analyze security`` score 
-separate directory tree, employs `DynamicUser` features, and adheres to strict systemd hardening policies (achieving a ``systemd-analyze security`` 
+of around **``2.6``** is the baseline, not an aspiration. Traffic from those runners traverses both a software firewall (UFW) 
-rating of **``2.6``**). Docker containers used by runners do not run in privileged mode. Security is further enhanced through the use 
+and dedicated hardware firewall appliances. Docker, where used, runs unprivileged.
-of both UFW software firewalls and dedicated hardware firewall appliances.
 
 ## 1.2. Match Host and Target Versions
 
-Build, for example, a Debian Trixie live image only on a Debian Trixie host. The build toolchain and boot artifacts are 
+I always build a Debian Trixie live image on a Debian Trixie host. The toolchain and all boot components that matter to 
-release-specific: ``live-build``, ``live-boot``, ``live-config``, ``debootstrap``, ``kernel/initramfs`` tools, ``mksquashfs``, 
+reproducibility are release-specific: ``live-build``, ``live-boot``, ``live-config``, ``debootstrap``, ``mksquashfs``, ``grub``, 
-``GRUB/ISOLINUX``, and even ``dpkg/apt`` often change defaults and formats between releases (e.g., compression modes, SquashFS 
+the ``kernel``, ``initramfs`` tooling, and even ``dpkg`` and ``apt`` defaults evolve from one release to the next. Mixing 
-options, hook ordering, systemd/udev behavior). Building on a different host release commonly yields non-reproducible or even 
+generations produces fragile or outright broken ISOs, sometimes subtly, sometimes catastrophically. Keeping host and target in 
-unbootable ISOs (missing modules/firmware, ABI mismatches, divergent paths). Keeping host and target on the same version ensures
+lockstep avoids those mismatches and gives me predictable artifacts across builds.
-reproducible builds, matching dependencies, and compatible boot artifacts.
 
-## 1.3. Immutable Source-of-Truth System
+## 1.3. Immutable Source-of-Truth System and Encrypted Live Root
 
-This live ISO establishes a secure, fully deterministic, integrity self-verifying boot environment based entirely on static
+The live ISO acts as a sealed, immutable execution environment. All relevant configuration, all installation logic, and all 
-source-code definitions. All configurations, system components, and installation routines are embedded during build time and 
+security decisions are rendered into the image at build time and treated as read-only at runtime. On top of that logical 
-locked for runtime immutability. This ensures that the live environment functions as a trusted **Source of Truth** — not only 
+ immutability, I now layer cryptographic protection of the live root file system itself. The live image contains a LUKS2 container
-for boot-time operations, but for deploying entire systems in a secure and reproducible way.<br>
+file with dm-integrity that wraps the SquashFS payload. The initramfs knows how to locate this container, unlock it, verify its 
+integrity, and then present the decrypted SquashFS as the root component of an OverlayFS stack. The detailed boot and 
+verification chain is documented separately in **[CISS ISO Boot Chain](docs/MAN_CISS_ISO_BOOT_CHAIN.md)**<br>
 
-Once booted, the environment optionally launches a fully scripted installer, via the forthcoming `CISS.debian.installer`,
+In compact form, my expectations for the system are:<br>
-yet to deploy, that provisions the target system (the hardware the DVD is running on). The installer pulls no external 
-dependencies besides of the necessary Debian debootstrap and Debian Packages and never exposes the target system in a not 
-secure manner to the internet during installation. It operates strictly from within the verified image content, providing fully 
-secured provisioning. Combined with checksum verification, **activated by default**, at boot and strict firewall defaults, this 
-architecture guarantees that what is executed has not been tampered with and corresponds exactly to the intended source definition.<br>
 
-An even more secure deployment variant — an unattended and headless version — can be built without any active network interface
+* Every bit that matters for boot and provisioning is covered by checksums that I control and that are signed with keys under my solely authoritative HSM.
-or shell-access, also via the forthcoming `CISS.debian.installer`. Such a version performs all verification steps autonomously, 
+* The live root runs out of a LUKS2 dm-integrity container so that a tampered or bit-rotted SquashFS never becomes a trusted root.
-provisions the target device from embedded source artifacts, and reboots into a fully encrypted system image. The system then 
+* Verification steps are not advisory. Any anomaly causes a hard abort during boot.
-awaits the decryption passphrase input via an embedded Dropbear SSH server (SSH PubKey only) in the initramfs, exposing no ports
+* After the live environment has reached a stable, verified state, it can hand off to ``CISS.debian.installer``. The installer operates from the same image, does not pull random payloads from the internet, and keeps the target system behind a hardened firewall until the entire provisioning process has completed.
-without cryptographic hardened access, while also the `/boot` partition could be encrypted via the built-in support of 
+* For unattended, headless scenarios I also support builds where the target system is installed without ever exposing a shell over the console. After installation and reboot, the machine waits for a decryption passphrase via an embedded Dropbear SSH instance in the initramfs, limited to public key authentication and guarded by strict cryptographic policies. In such variants even ``/boot`` can be encrypted, with GRUB taking care of unlocking the boot partition.
-`grub2 (2.12-9)`.<br>
 
-This approach provides a fully reproducible, audit-friendly, and tamper-resistant provisioning workflow rooted entirely in 
+These combinations give me a provisioning chain that is auditable, reproducible, and robust against both casual and targeted tampering.<br>
-source-defined infrastructure logic.<br>
 
-After build and configuration, the following audit reports can be generated:
+Once the system is up, I can trigger a set of audits from within the live environment:
 
-* **Haveged Audit Report**: Validates entropy daemon health and confirms `/dev/random` seeding performance.
+* **Lynis Audit Report**: Outputs a detailed security score and recommendations, confirming a 93%+ hardening baseline.
-  Type `chkhvg` at the prompt. See example report: **[Haveged Audit Report](/docs/AUDIT_HAVEGED.md)**
-* **Lynis Audit Report**: Outputs a detailed security score and recommendations, confirming a 91%+ hardening baseline.
   Type `lsadt` at the prompt. See example report: **[Lynis Audit Report](/docs/AUDIT_LYNIS.md)**
 * **SSH Audit Report**: Verifies SSH daemon configuration against the latest best-practice cipher, KEX, and MAC recommendations.
   Type `ssh-audit <IP>:<PORT>`. See example report: **[SSH Audit Report](/docs/AUDIT_SSH.md)**
@@ -136,36 +131,27 @@ After build and configuration, the following audit reports can be generated:
 
 ![CISS.debian.live.builder](/docs/screenshots/CISS.debian.live.builder_preview.jpeg)
 
-## 1.5. Caution. Significant information for those considering using D-I.
+## 1.5. Caution. Debian Installer and Security Context
-
 **The Debian Installer (d-i) will ALWAYS boot a new system.**<br>
 
-Regardless of whether you start it:
+The classical Debian Installer (d-i) always boots its own kernel and its own initramfs. That effect is independent of the way it
-* via the boot menu of your Live ISO (grub, isolinux) like **CISS.debian.live.builder**,
+is launched: 
-* via kexec in the running system,
-* via the debian-installer-launcher package,
-* or even via a graphical installer shortcut.
 
-The following happens in all cases:
+* from a GRUB entry on the live medium, 
-* The installer kernel (/install/vmlinuz) + initrd.gz are started.
+* from within a running live session via a graphical shortcut, 
-* The existing live system is exited.
+* through kexec, 
-* The memory is overwritten.
+* or via helper packages such as debian-installer-launcher.
-* All running processes - e.g., firewall, hardened SSH access, etc. pp. - cease to exist.
 
-The Debian Installer loads:
+In all of these cases the running live system is discarded. The memory contents of the hardened live environment vanish, the 
-* its own kernel,
+firewall disappears, the hardened SSH daemon is terminated, and the hardened kernel is replaced by the installer kernel. The 
-* its own initramfs,
+installer brings its own minimal root file system, usually BusyBox plus a limited set of udeb packages, and it does not 
-* its own minimal root filesystem (BusyBox + udeb packages),
+implement my firewall, my AppArmor profiles, my logging configuration, or my remote access policies, unless I explicitly 
-* no SSH access (unless explicitly enabled via preseed)
+reintroduce those elements via preseed.
-* no firewall, AppArmor, logging, etc. pp.,
-* it disables all running network services, even if you were previously in the live system.
 
-This means function status of the **CISS.2025.debian.live.builder** ISO after d-i start:
+In that phase the security properties are therefore those of d-i, not those of CISS.debian.live.builder. This is not a defect in
-* ufw, iptables, nftables ✘ disabled, not loaded,
+Debian, it is a property of how any installer that boots its own kernel behaves. It is important to keep this distinction in 
-* sshd with hardening ✘ stopped (processes gone),
+mind when deciding whether a workflow must stay inside the hardened live context or may trade that environment for the standard 
-* the running kernel ✘ replaced,
+installer toolchain.
-* Logging (rsyslog, journald) ✘ not active,
-* preseed control over the network is possible (but without any protection).
 
 ## 1.6. Versioning Schema
 
@@ -187,59 +173,62 @@ and only when, they appear in all capitals, as shown here.
 
 # 2. Features & Rationale
 
-Below is a breakdown of each hardening component, with a summary of why each is critical to your security posture.
+Below I walk through the major hardening components, with a focus on why I implemented them the way I did and how they interact.
+I treat this builder as a reference implementation for my own infrastructure; **it is not a toy**.
 
 ## 2.1. Kernel Hardening
 
-### 2.1.1. Boot Parameters
+### 2.1.1. Unified Hardened Boot Parameters
 
-* **Description**: Customizes kernel command-line flags to disable unused features and enable mitigations.
+Both the ``CISS.debian.live.builder`` LIVE ISO and the ``CISS.debian.installer`` rely on the same kernel command line. I consider
-* **Key Parameters**:
+a diverging kernel baseline between installer and live system operationally dangerous, because it leads to two distinct sets of 
-  * `audit_backlog_limit=8192`: Ensures the audit subsystem can queue up to 8192 events to avoid dropped logs under heavy loads.
+expectations about mitigations and attack surface. The boot parameters I apply are:
-  * `audit=1`: Enables kernel auditing from boot to record system calls and security events.
+
-  * `cfi=kcfi`: Activates kernel control-flow integrity using kCFI to protect against control-flow hijacking.
+````bash
-  * `debugfs=off`: Disables debugfs to prevent non-privileged access to kernel internals.
+apparmor=1 security=apparmor audit_backlog_limit=262144 audit=1 debugfs=off \
-  * `efi=disable_early_pci_dma`: Stops early PCI DMA under EFI to mitigate DMA-based attacks during boot.
+efi=disable_early_pci_dma hardened_usercopy=1 ia32_emulation=0 \
-  * `efi_no_storage_paranoia`: Disables extra EFI storage checks to streamline boot without compromising expected storage integrity.
+init_on_alloc=1 init_on_free=1 \
-  * `hardened_usercopy=1`: Enables stringent checks on copy operations between user and kernel space to prevent buffer overflows.
+iommu.passthrough=0 iommu.strict=1 iommu=force \
-  * `ia32_emulation=0`: Turns off 32-bit compatibility modes to reduce attack surface on 64-bit hosts.
+kfence.sample_interval=100 kvm.nx_huge_pages=force \
-  * `init_on_alloc=1`: Zeroes memory on allocation to prevent leakage of previous data.
+l1d_flush=on lockdown=integrity loglevel=0 \
-  * `init_on_free=1`: Initializes memory on free to catch use-after-free bugs.
+mitigations=auto,nosmt mmio_stale_data=full,force nosmt=force \
-  * `iommu=force`: Enforces IOMMU for all devices to isolate DMA-capable hardware.
+oops=panic page_alloc.shuffle=1 page_poison=1 panic=0 pti=on \
-  * `kfence.sample_interval=100`: Configures the kernel fence memory safety tool to sample every 100 allocations.
+random.trust_bootloader=off random.trust_cpu=off randomize_kstack_offset=on \
-  * `kvm.nx_huge_pages=force`: Enforces non-executable huge pages in KVM to mitigate code injection.
+retbleed=auto,nosmt rodata=on slab_nomerge vdso32=0 vsyscall=none
-  * `l1d_flush=on`: Flushes L1 data cache on context switch to mitigate L1D vulnerabilities.
+````
-  * `lockdown=confidentiality`: Puts the kernel in confidentiality lockdown to restrict direct hardware access.
+
-  * `loglevel=0`: Suppresses non-critical kernel messages to reduce information leakage.
+The parameters fall into several categories.
-  * `mce=0`: Disables machine check exceptions to prevent side-channel data leaks from hardware error reporting.
+
-  * `mitigations=auto,nosmt`: Enables all automatic CPU mitigations and disables SMT to reduce side-channel risks.
+* The AppArmor-related flags ``apparmor=1``, ``security=apparmor`` guarantee that AppArmor is not an afterthought but an integral part of the security architecture from the first instruction. I do not accept a boot sequence that comes up without LSM enforcement and then attempts to enable it later.
-  * `mmio_stale_data=full,nosmt`: Ensures stale MMIO data is fully flushed and disables SMT for added protection.
+* The audit subsystem is configured to be always on ``audit=1`` and to tolerate heavy bursts without dropping events ``audit_backlog_limit=262144``. I treat the audit trail as an evidentiary artifact; truncation because of backlog limits is not acceptable in that model.
-  * `oops=panic`: Forces a kernel oops to trigger a panic, preventing the system from running in an inconsistent state.
+* The debug surface of the kernel is reduced aggressively. ``debugfs=off`` avoids a traditional footgun that exposes kernel internals in a way that is friendly to attackers and rarely necessary in production.
-  * `page_alloc.shuffle=1`: Randomizes physical page allocation to hinder memory layout prediction attacks.
+* Memory is hardened on several levels at allocation time and at free time. ``init_on_alloc=1`` and ``init_on_free=1`` provide deterministic zeroing, ``page_poison=1`` fills freed pages with a poison pattern, and ``page_alloc.shuffle=1`` shuffles the allocator so that a process can no longer rely on stable physical patterns. Together these measures raise the cost of use-after-free exploitation and other memory corruption attacks.
-  * `page_poison=1`: Fills freed pages with a poison pattern to detect use-after-free.
+* The IOMMU is not optional. I force it on ``iommu=force``, disable passthrough ``iommu.passthrough=0`` and require strict behavior ``iommu.strict=``1. Any environment that contains devices capable of DMA must have a correctly configured IOMMU, otherwise the trust model for the CPU and for the memory hierarchy collapses as soon as a hostile device is introduced.
-  * `panic=-1`: Disables automatic reboot on panic to preserve the system state for forensic analysis.
+* ``kfence.sample_interval=100`` activates KFENCE with a sampling interval that is still usable in production but sensitive enough to catch a meaningful subset of memory safety bugs under real workloads.
-  * `pti=on`: Enables page table isolation to mitigate Meltdown attacks.
+* Virtualization-specific knobs include ``kvm.nx_huge_pages=force``, to keep huge pages non-executable, and ``l1d_flush=on`` so that context switches flush the L1 data cache where needed.
-  * `random.trust_bootloader=off`: Prevents trusting entropy provided by the bootloader.
+* ``lockdown=integrity`` places the kernel into lockdown mode with an emphasis on integrity. In this project I consider the integrity of the system more critical than the ability to introspect a running kernel from userspace.
-  * `random.trust_cpu=off`: Disables trusting CPU-provided randomness, enforcing external entropy sources.
+* Speculative execution and microarchitectural issues are covered by ``mitigations=auto,nosmt``,`` mmio_stale_data=full,force``, and ``retbleed=auto,nosmt``. I combine the automatic mitigation set provided by the kernel with a forced Single Thread mode where it is required because simultaneous multithreading is simply not worth the residual risk profile in many server contexts.
-  * `randomize_kstack_offset=on`: Randomizes the kernel stack offset on each syscall entry to harden against stack probing.
+* ``nosmt=force`` acts as a guardrail here. It prevents a misconfiguration from quietly re-enabling SMT while the system operator assumes it is disabled.
-  * `randomize_va_space=2`: Enables full address space layout randomization (ASLR) for user space.
+* Fault handling is configured through ``oops=panic`` and ``panic=0``. An oops triggers a panic so that I do not continue to run a kernel in an undefined state. At the same time I instruct the system not to reboot automatically on panic, to preserve the state for post-mortem analysis rather than cutting the ground away under a debugging session.
-  * `retbleed=auto,nosmt`: Enables automatic RETBLEED mitigations and disables SMT for better side-channel resistance.
+* ``pti=on``, ``rodata=on``, and ``slab_nomerge`` are classical hardening parameters that I still consider essential. Page-table isolation, read-only data segments, and prohibiting slab merging collectively prevent a wide range of exploits, especially under pressure from speculative execution attacks.
-  * `rodata=on`: Marks kernel read-only data sections to prevent runtime modification.
+* To avoid brittle side assumptions, I remove legacy or obsolete interfaces: ``vdso32=0`` and ``vsyscall=none`` shut down the remaining vestiges of 32-bit vDSO and vsyscall support on 64-bit systems. ``ia32_emulation=0`` it again narrows the attack surface by disabling full 32-bit compatibility on 64-bit kernels.
-  * `tsx=off`: Disables Intel TSX extensions to eliminate related speculative execution vulnerabilities.
+* Finally, I do not trust entropy claims either from the bootloader or the CPU itself. I opt out of both with ``random.trust_bootloader=off`` and ``random.trust_cpu=off`` and rely on my own entropy strategy described later.
-  * `vdso32=0`: Disables 32-bit vDSO to prevent unintended cross-mode calls.
+
-  * `vsyscall=none`: Disables legacy vsyscall support to close a potential attack vector.
+All of these parameters are applied in exactly the same way for the live ISO and for the installer environment. That is a 
-* **Rationale**: Ensures early activation of protections, reducing exposure to CPU vulnerabilities before the system fully boots.
+deliberate design decision.
 
 ### 2.1.2. CPU Vulnerability Mitigations
 
-* **Description**: Enables all known kernel-level mitigations (Spectre, Meltdown, MDS, L1TF, etc.).
+I build the kernels with the relevant mitigations for Spectre, Meltdown, L1TF, MDS, TAA, Retbleed, and related families activated. 
-* **Rationale**: Prevents side-channel attacks that exploit speculative execution, which remain a high-risk vector in
+The ``mitigations=auto,nosmt`` flag ensures that new mitigations integrated into the mainline kernel become effective as they 
-  multi-tenant cloud environments.
+are added, instead of requiring that I micromanage every single toggle. The residual performance cost is acceptable in the 
+context I am targeting; stale mitigations can be revisited, but missing mitigations will not be.
 
 ### 2.1.3. Kernel Self-Protection
 
-* **Description**: Activates `CONFIG_DEBUG_RODATA`, `CONFIG_STRICT_MODULE_RWX`, and other self-protections.
+I enable the standard set of self-protection options, such as strict module page permissions, read-only data enforcement, and 
-* **Rationale**: Hardens kernel memory regions against unauthorized writings and enforces stricter module loading policies.
+restrictions around kprobes and BPF. The builder is not a kernel configuration tool, but it carries the expectation that the 
+kernels it runs with are compiled according to this hardening profile. I treat deviations from that profile as unsupported.
 
 ### 2.1.4. Local Kernel Hardening
 
@@ -443,9 +432,12 @@ predictable script behavior.
 
 # 4. Prerequisites
 
-* **Host**: Debian Trixie with `live-build` and ``debootstrap`` packages installed.
+To use **``CISS.debian.live.builder``** as intended, the following baseline is expected:<br>
-* **Privileges**: Root or sudo access to execute `ciss_live_builder.sh` and related scripts.
+
-* **Network**: Outbound access to Debian repositories and PTB NTPsec pool.
+* The build host runs Debian 13 Trixie, fully updated. Building a Trixie image on an older or newer release is technically possible but explicitly not supported.
+* The host has the standard live-build stack installed ``live-build``, ``live-boot``, ``live-config``, ``debootstrap`` and the cryptographic tooling required for ``LUKS2``, ``dm-integrity``, ``cryptsetup``, ``gpg``.
+* Disk space must be sufficient to hold the chroot, the temporary build artifacts, and the final ISO with encrypted root. For comfortable work I assume around 30–40 gigabytes of free space.
+* The user running the builder has root privileges and understands that the script is capable of creating, mounting, and manipulating block devices.
 
 # 5. Installation & Usage
 
@@ -608,13 +600,22 @@ preview it or run it.
 
 # 6. Licensing & Compliance
 
-This repository is fully SPDX-compliant. All source files include appropriate SPDX license identifiers and headers to ensure
+Unless stated otherwise in individual files via SPDX headers, this project is licensed under the European Union Public License (EUPL 1.2).
-clear and unambiguous licensing. You can verify compliance by reviewing the top of each file, which follows the SPDX
+That license is OSI-approved and compatible with internal use in both public sector and private environments. Several files carry
-standard for license expressions and metadata.
+dual or multi-license statements, for example **``LicenseRef-CNCL-1.1``** and / or **``LicenseRef-CCLA-1.1``**, where I offer a 
+non-commercial license for community use and a commercial license for professional integration. The SPDX headers in each file 
+are authoritative. If you plan to integrate **``CISS.debian.live.builder``** into a commercial product or a managed service 
+offering, you should treat these license markers as binding and reach out for a proper agreement where required.
 
 # 7. Disclaimer
 
-This README is provided "as-is" without any warranty. Review your organization's policies before deploying to production.
+This repository is designed for well-experienced administrators and security professionals who are comfortable with low-level 
+Linux tooling, cryptography, and automation. It can and will create, format, and encrypt devices. It is entirely possible to 
+destroy data if you use it carelessly. I publish this work in good faith and with a strong focus on correctness and robustness. 
+Nevertheless, there is no warranty of any kind. You are responsible for understanding what you are doing, for validating your 
+own threat model, and for ensuring that this tool fits your regulatory and operational environment. If you treat the builder, and 
+the resulting images with the same discipline with which they were created, you will obtain a hardened, reproducible, and 
+auditable base for serious systems. If you treat them casually, they will not save you from yourself.
 
 ---
 **[no tracking | no logging | no advertising | no profiling | no bullshit](https://coresecret.eu/)**