Graphic
continued expressive artificial sketching | reinforcing visual media
Jo Zapf
Web & Application Development,
Networking and Cross-Media Solutions
"everything you can imagine is real"
0 years autodidactic journey*
Integrating diverse systems, services and platforms - whether cloud services, or custom infrastructure.
Architecture decisions driven by operational requirements: data protection, availability, scalability.
Automation and software solutions as a means of making processes possible, more robust, and/or more practical.
Focus areas
My work bridges development and operations (DevSecOps) – with a focus on automation, systems integration as well as networking & security.
- CI/CD & Automation – GitOps pipelines with Gitea Actions/act_runner, staged deployments and automated dependency updates (Renovate, digest pinning); supply-chain checks in the pipeline (SBOM & CVE scan per PR, signed images via cosign); infrastructure as code with Ansible.
- Systems Integration – bringing heterogeneous services together: central identities with SSO & 2FA (Keycloak), self-hosted stacks, hybrid cloud/on-premise architectures.
- Network & Security – segmented networks (deny-by-default), Zero-Trust with PKI & automatically rotating mTLS identities (step-ca), web application firewall, system hardening; proactive alerting & observability (Prometheus, Grafana, Loki).
- Interface & Support – reliable point of contact across business units, engineering and external partners; translating requirements and enabling users.
- AI-assisted Engineering – AI as a tool with clear guardrails: automated security & quality gates (CI/CD), reversible changes (version control), decisions stay with humans. Model choice follows data sensitivity – from cloud agents to local GPU inference with European open-weights models and an in-house knowledge base (RAG). Where automation needs credentials, the AI is kept out: the self-built Zero-Knowledge Secrets Broker hands them straight to the target system; they never leave my own infrastructure.
Current DevSecOps Projects
CV / Stages
Web
started with: html | css | dbms | javascript | php
Video
video- & post- production | motion graphics | 3D | cross-media
Photo
products | events | locations | people
Net Admin / IT
Functional IT Lead | network administration | automation | cross-media production
Application Dev.
in consequence of the past: vocational training started in 02.2025 *(expected graduation [IHK] early 2027)
Stages
2025
Application Development
in consequence of the past: vocational training started in 02.2025
*(expected graduation [IHK] early 2027)
#python
#java
#javascript
2016
Functional IT Lead / Net Admin / Project Management
head of it | network administration | automation | cross-media production
#project management
#IT lead
#customer service
#b2b
2013
Photo
products | locations | people
#b2b
#product
#events & locations
#portrait
#wedding
2011
Video
video- & post- production | motion graphics | 3D | cross-media
#b2b
#motion graphics
#animation
#3D
#dvd authoring
#green Screen
2007
Web
started with: html | css | dbms | javascript | php
#cms
#framework
#static
1999
Graphic
continued artificial sketching | reinforcing visual media
#intrinsic motivation
#cross media
Zero-Knowledge Secrets Broker
Update · July 2026
Security Architecture
Defense-in-Depth with 5 protection layers — audited against 9 standards from OWASP, ISO, GDPR, and NIS2.
A trust anchor for cryptographic key sovereignty
5 layers → Zero-Knowledge Core
Beta+ · signed integrity manifest in production (2026-07-15)
Chain of trust · click to enlarge
1 — Network Perimeter
Docker network isolation, bind to 127.0.0.1, Traefik as reverse proxy, Coraza WAF with OWASP CRS, CrowdSec at the host perimeter, dedicated Traefik route
secrets-anchor.local:8443 with RequireAndVerifyClientCert for identity-anchor paths.2 — Container Hardening
Rootless Docker daemon; in the container non-root user,
read_only FS, cap_drop ALL, no-new-privileges, seccomp profile (117 syscalls, Docker 29.x). Dependencies pinned and kept current — 34 known CVEs closed most recently.3 — Application & Audit
RBAC across every access path — including the MCP interface for AI agents (ADR-026); modes Zero-Knowledge / Trusted / both,
auth_mode split per policy (header / mTLS) since ADR-011. Admin rights in a dedicated scope, separated from the secret namespace (ADR-034); entry listing bound to identity, anonymous access denied (ADR-033). Pydantic validation, per-consumer rate limiting with bounded state (ADR-035), JWT RS256 with algorithm pinning. Gap-free JSON audit trail incl. source IP: who, when, what, granted or denied.4 — Cryptography
RSA-2048, AES-256-CBC, SHA-256, HKDF, PBKDF2 — Bitwarden-compatible crypto chain with MAC verification before every decrypt; a signed integrity manifest (RSA-3072-PSS, TOFU baseline with delta review) detects ciphertext swaps at access time — fail-closed. No algorithms below a 128-bit security level. Manifest version monotonic and operator-pinned — an old, still validly signed manifest cannot undo a rotation (ADR-032); the daily backup export hangs off the same signature (ADR-031). Prototype, not wired into production: envelope encryption with AES-256-GCM and ephemeral rewrap via X25519 — key sovereignty for payload data, rotation without re-encrypting the data (ADR-036).
5 — Memory Protection
SecureBuffer with
mlock, MADV_DONTDUMP, sodium_memzero — plaintext lives less than 1 ms in RAM.Core — Zero-Knowledge
Dual mode: Trusted-Get (plaintext via RBAC) + JWT RS256 with SHA-256 hash, TTL 5 minutes — both in production, both gated by the signed integrity manifest. Plaintext in both modes is only stored temporarily in SecureBuffer — cryptographically deleted via sodium_memzero after delivery — no plaintext in responses, logs or persistent storage.
Standards & Compliance
9 standards, weighted overall score 99 %
OWASP Top 10 (2021)
9 / 10
A01–A10 covered; A07 addressed for identity-anchor paths via mTLS (ADR-011); for service-secret paths network isolation remains — deliberately two-layered.
GDPR — Art. 5 / Art. 32
4 / 4
Data minimization, integrity, access control, deletion concept — technically fulfilled.
ISO/IEC 27001 — Annex A
14 / 14
Technically verifiable controls (A.8.x); mTLS implemented (Trusted-Get on
secrets-anchor.local:8443), SBOM & CVE scan in production as a CI job per PR (Trivy/CycloneDX).
NIS2 — Dir. 2022/2555 Art. 21
9 / 9
Risk analysis, crypto, access, incident response, BCP — supply-chain anchor secured (ADR-011), image signing in production via the
build-signer stack (cosign). Signed integrity manifest against ciphertext swaps in production (ADR-029/-030).
ISO/IEC 25010 — Product Quality
8 / 8
Functionality, performance, compatibility, security, maintainability, portability.
ISO/IEC 12207 — Lifecycle
6 / 6
Requirements, architecture, implementation, testing, documentation, config management.
SOLID
5 / 5
SRP, OCP, LSP, ISP, DIP — Vaultwarden primary, KDBX on separate external host as automatic failover + backup.
Clean Code
4 / 4
KISS, DRY, YAGNI, SRP — functions < 50 LOC, max. nesting depth 3.
Defensive Programming
5 / 5
Input validation, null safety, error handling, fail-fast, least privilege.
Overall Score (weighted)
99 %
Standards audited
9
Criticality levels
4
Key Metrics
Tests, performance, scope91 %
Test Coverage
709
Tests (671 pytest + 38 shell)
6,304
Lines of Code
420
req/s (p99 < 100 ms)
29
Consumer policies (RBAC)
< 1 ms
Plaintext in RAM
DevSecOps · Engineered Platform Architecture
Sovereign Workplace · opendesk EU
Self-hosted workplace on own infrastructure — defense-in-depth, Keycloak SSO with 2FA, and segmented Docker networks.
Defense in Depth
6 layers → data sovereignty
Production · self-hosted
0 — Host Firewall
UFW as packet filter on host level, CrowdSec for collaborative threat intelligence — with geoblocking and escalating bans, blocks known attacker IPs before they reach the Docker stack.
1 — Web Application Firewall
Coraza WAF with OWASP CRS as first ingress filter — request inspection, rule sets against OWASP Top 10, structured audit of rejections.
2 — Reverse Proxy
Traefik v3 with TLS termination,
PROXY protocol v2 for real client IPs, and declarative routing via Docker labels.3 — Identity & Access
Keycloak as central identity provider (OIDC). Second factor via TOTP and WebAuthn, central session and role management for all services.
4 — Network Segmentation
6 isolated Docker networks: databases and caches only reachable from authorized app networks, not from the proxy network.
5 — Container Hardening
Rootless Docker daemon; in the container non-root user,
read_only FS where possible, cap_drop ALL, no-new-privileges — minimized rights explicitly per service.Core — Data Sovereignty
All user data remains on own infrastructure: own databases, own object-storage paths, own secrets broker — no SaaS dependency.
Platform & Architecture
9 disciplines — implemented
Identity & SSO
Implemented
Keycloak as central IDP, OIDC for all services, second factor via TOTP and WebAuthn.
WAF & Reverse Proxy
Implemented
Coraza with OWASP CRS in front of Traefik v3, PROXY protocol v2, TLS termination at the edge.
Network Segmentation
Implemented
6 isolated Docker networks. Databases and caches only reachable from authorized app networks.
Container Hardening
Implemented
Rootless · non-root ·
read_only · cap_drop ALL · no-new-privileges — verified per service.
Secrets Management
Implemented
Integration Zero-Knowledge Broker: runtime tokens instead of
.env, audit trail per consumer.
Observability
Implemented
Prometheus + Grafana + Loki. Structured logs, service health dashboards, alerting to messaging.
Backup & BCP
Implemented
Borg with BLAKE2b encryption. Air-gap hardware control, fail-safe EXIT trap, systemd integration.
Supply Chain
Implemented
Digest pinning (Renovate), SBOM & CVE scan per PR (Trivy/CycloneDX) and image signing with cosign via a dedicated build-signer stack — in production.
Disaster Recovery
Implemented
Borg backup runs productively (encrypted, air-gap via Shelly, fail-safe trap). Reproducible rebuild via Ansible playbooks in active rollout.
Status overview
9 / 9 implemented
Services
~30
Networks
6
Containers
62
Key Metrics
Composition, persistence, identity62
Containers
~30
Services
5
Databases
3
Redis instances
6
Docker networks
2-FA
TOTP + WebAuthn
Backup System · Original Project
Segmented Borg Backup System
Atomic pipeline architecture with air-gap, guaranteed cleanup and multi-profile isolation — file-level daily, block-level for bare-metal recovery. Modular, defensive, running self-hosted in production since 2026-01.
Modular Pipeline Architecture · Profile-Driven
Data core with upstream isolation, pipeline, and verification logic
In Production · since 2026-01
Core — Data + Cleanup Trap
Persistent data, BLAKE2b-authenticated with content-defined chunking. Restore proven in practice — not just integrity checks. Recovery key separately encryptable for disaster recovery.
AIR-GAP — Mount-on-Demand
Backup volume is not mounted by default and partially powered down on the hardware side. Repository is offline — ransomware and tool access fails on the unmounted device.
PIPELINE — Wrapper-Segment Pattern
28 atomic segments, built once as wrappers around the production tools: logic stays with the service, backup segments stay lean. No drift between manual and automated runs.
PROFILE — 3 isolated backup profiles
Operating System, Application Workloads, Remote Edge Host — same pipeline, separate repositories. Local push for host and container data, pull architecture via SSH for remote.
CLEANUP — EXIT-Trap guaranteed
EXIT-Trap guarantees cleanup even on crash or abort: spindown, unmount, hardware deactivation. System reliably returns to the air-gap state.
VERIFY — Integrity + Down-Time Optimization
Integrity check mandatory on every run, runs in parallel with the already-live stack. Application start before verify/prune — down-time per run at ~20 min instead of several hours.
PULL-ARCH — Read-only mount for remote sources
Read-only mount of the remote source, minimal whitelist on the source host. No secrets or backup tools on remote — a compromise there does not jeopardize the repository.
Profile-driven backups · segmented pipeline
Multi-profile architecture
Operating System
Daily
Application Workloads
Daily
Remote Edge Host
Daily
Architecture Highlights
11 design patterns — all in regular operation
Source-read / target-write separation
In regular operation
Hardened systemd profile · sources read-only · write rights only on the target · consistency dumps in the target area, never in the source volume.
Air-gap through mount-on-demand
In regular operation
Mount only during the run · external devices powered down on the hardware side · default offline · no continuous write access for malware.
4-stage mount recovery
In regular operation
Escalation graceful → force → lazy → process analysis · protection list for critical workloads · defensively designed from real operational experience.
UUID validation before write
In regular operation
Cross-check of device identity before every write · protection against "wrong device mounted" · safe under hot-swap.
Guaranteed cleanup via EXIT-Trap
In regular operation
EXIT-Trap guarantees cleanup, even on crash or abort · spindown, unmount, hardware off · system reliably back in air-gap.
Wrapper-Segment Pattern
In regular operation
Tools live with the service · backup segments only as lean wrappers · logic written once, reused · no drift between manual and automated.
Multi-DB consistency snapshot
In regular operation
Maintenance mode at the application level · consistent DB dumps per engine · belt-and-suspenders: logical dumps + file-level after application stop.
Down-Time Optimization
In regular operation
Application start before verify/prune · stack back online after ~20 min (instead of several hours) · integrity check runs in parallel with live operation.
Verify discipline + Restore-validated
In regular operation
Integrity check mandatory on every run · restore proven in practice · recovery key separately encryptable.
Pull architecture for remote sources
In regular operation
Read-only mount of the remote source · minimal whitelist on the source host · no client, no secrets on remote · a compromise there does not jeopardize the repository.
Block-level disaster recovery
In regular operation
Monthly pull of a bit-exact storage image via fsfreeze + dd | xz · crash-consistent without service stop · NOPASSWD whitelist limited to 3 operations · complements the daily file-level Borg with a bare-metal restore path.
Live in production
11 / 11 patterns active
Segments
28
Phases
6
Profiles
3
Key metrics
All directly verifiable from code / config28
Segments
6
Phases
3
Profiles
~20 min
Stack down / run
24h
RPO (daily)
BLAKE2b
MAC + Hash
Block + File
Backup layers
recent
repositories
repositories
