Home on c-blog

Claude Code Source Leak: Claw Code Rebuilt It from Scratch

Mon, 06 Apr 2026 00:00:00 +0000

TL;DR

On March 31, 2026, a source map file was accidentally included in Claude Code v2.1.88 on npm, leaking ~512,000 lines of TypeScript. Original tweet by Chaofan Shou (@Fried_rice).
What was exposed: anti-distillation fake tools, undercover mode for stealth OSS contributions, frustration regex detection, native client attestation (DRM for API calls), 44 unreleased feature flags, and an autonomous agent mode codenamed KAIROS.
Claw Code (github.com/ultraworkers/claw-code) is a clean-room Rust reimplementation of the Claude Code agent harness, built by Sigrid Jin. It reached 50,000 stars in under 2 hours and became one of the fastest-growing repos in GitHub history.
Anthropic’s response: pulled the npm package within ~4 hours, issued DMCA takedowns on 8,000+ GitHub mirrors, and called it “human error, not a security breach.”

On March 31, 2026, Anthropic made a packaging mistake that gave the entire developer community an unfiltered look inside their most popular developer tool.

Linux Kernel Auditing: the happy family auditd, eBPF, and Falco (part 1/3)

Mon, 06 Apr 2026 00:00:00 +0000

TL;DR

auditd is the kernel-native audit framework — battle-tested, compliance-friendly, and available on every Linux distribution, but it produces verbose logs and has no native container awareness.
eBPF-based tools like Tetragon operate directly inside the kernel with minimal overhead, offering both observability and enforcement, but require modern kernels (5.x+) and a steeper learning curve.
Falco bridges the gap as a CNCF-graduated runtime security tool that uses eBPF to monitor syscalls and ships with curated detection rules out of the box.
auditd log types (SYSCALL, EXECVE, PATH, CWD, PROCTITLE, USER_AUTH) are the foundation of Linux forensics — understanding them is non-negotiable for anyone doing detection engineering.
No single tool covers everything — production environments benefit from layering auditd (compliance + forensics) with Falco or Tetragon (runtime detection + container visibility).

Every process on a Linux system talks to the kernel through system calls. File opens, network connections, privilege changes, process executions — all of it flows through a narrow interface that the kernel controls. If you can observe that interface, you can see everything that happens on the system.

Separating Authentication from Business Logic

Mon, 16 Mar 2026 00:00:00 +0000

TL;DR

Your backend should never handle authentication directly — login flows, session management, MFA, and token validation belong in a dedicated identity layer.
Authentik acts as a forward-auth gateway in front of your reverse proxy (Traefik, Nginx, Caddy), intercepting every request and injecting verified identity headers.
Two integration patterns: Forward Auth (proxy validates, backend receives headers) and OIDC Provider (backend validates JWTs issued by Authentik).
The backend becomes stateless with respect to auth — easier to test, scale, and audit.
Authorization policies (RBAC, group-based, attribute-based) live in Authentik, not scattered across your application code.

Most backend applications implement authentication as an afterthought — a middleware bolted onto the router, a session table in the same database as business data, password hashing logic mixed into the user service. This creates a tight coupling between identity management and business logic that makes both harder to maintain, test, and secure.

Read-Only FS in Docker Is Not Enough? Maybe not

Mon, 02 Mar 2026 00:00:00 +0000

TL;DR

--read-only doesn’t prevent code execution — attackers can run binaries entirely in memory using /proc/self/mem, /dev/shm, and the dynamic linker.
DDexec hijacks a running process’s memory to load and execute arbitrary ELF binaries without writing to disk.
The dynamic linker (ld-linux/ld-musl) can load binaries from writable paths like /dev/termination-log without the execute bit.
Runtime monitoring with Falco (eBPF-based syscall monitoring) is essential to detect these fileless techniques.
Defense-in-depth: combine --read-only with --cap-drop=ALL, seccomp profiles, no-new-privileges, and Falco for real container security.

Running your Docker containers with --read-only is commonly recommended as a security hardening measure. The reasoning is straightforward: if an attacker can’t write to the filesystem, they can’t drop and execute malicious binaries.