Dave's Blog

TL;DR: a terminal game first. One deterministic engine renders into a terminal, then mimics itself onto a browser, an APK, an iOS .ipa, a UEFI boot image and a from-scratch SSH arcade, with a replay-verified leaderboard that nobody can lie to. Every number below is measured in-tree; every bug in the final section was hit by a real player.

On 25 August 2026 I tagged v0.1.0 of SUPER CLI MARIO, a complete Super Mario Bros. style platformer that renders in a plain terminal. On 30 August I tagged v0.7.1. In the six days between them came 339 commits, 34,430 lines of Go (17,270 of those lines are tests), zero external dependencies, and a game you can play by typing ssh mario.baby, or just by opening https://mario.baby in a browser, with no client install, no account and no download.

That conversation is why I run an abliterated model. Not for edginess, not to own anyone in an argument, and not because I have exotic hobbies. Because I run an autonomous security agent that does offensive work all day, and a refusal from its brain is not a safety feature. For an unattended agent it's a wedged turn, a burned retry, and a half-finished task discovered hours later.

This post explains what "abliterated" actually means, what it costs you, what we do with ours, a live demo, and the operational reality of self-hosting one. The short version is that removing the model's refusals doesn't remove your safety problem. It relocates the problem out of the weights and into your infrastructure, where you have to solve it yourself.

An instruction-tuned model refuses things because it learned to. In 2024, Arditi and colleagues showed that in Llama-2-13B, refusal is mediated by a single direction in the model's residual stream. Not a sprawling safety subsystem, not rules scattered across billions of parameters. One vector.

On 22 June 2026, Executive Order 14412 turned post-quantum cryptography from a conference track into a compliance date. US federal agencies must be on quantum-resistant key establishment by 31 December 2030 and quantum-resistant signatures by 31 December 2031. Through the Federal Acquisition Regulation Council the same dates land on every covered contractor, which in practice means most of the supply chain. Yesterday the IETF published RFC 10024, putting the hybrid X25519MLKEM768 key exchange on the standards track for TLS 1.3. The browsers already have it on by default. Cloudflare already serves it.

Your government and your browser vendor agree on the message. Stop planning, start shipping.

I run my own CA, a fleet of Linux boxes, and enough SSH to constitute a lifestyle. This post is the migration order I'm actually following: what the algorithms are, what you can turn on this week, where the real time sink hides, and why signatures will hurt more than key exchange.

Nobody sane claims a cryptographically useful quantum computer arrives next year. The deadline doesn't care, because the attack that motivates it works today: harvest now, decrypt later. An adversary records your TLS sessions in 2026, stores the bytes, and decrypts them the year a suitable machine exists. Anything confidential past that horizon, medical records, state archives, signing root material, signed contracts, is already exposed in transit. The OpenSSL Foundation's analysis of the order and the news coverage both land on the same reading: the 2030 date is not a prediction about hardware, it's a buffer about logistics.

Three signers at Bybit approved roughly that transaction on 21 February 2025, and about $1.5bn left the exchange within minutes. The screen told them the truth. The keys signed a lie. Nearly every large North Korean crypto theft since 2019 contains some version of that gap, and the gap is where the money goes.

This is a sourced tour of how the DPRK actually steals digital assets. The running totals, the people-attacks that open the door, the kill chains inside six named heists, the laundering pipeline behind them, and the defences that held up when tested. Every claim carries a source and a date, because a fair chunk of what everyone knows about this subject is wrong, and I will flag the wrong bits as we pass them.

The UN Panel of Experts, in the last report before Russia vetoed its mandate out of existence in March 2024, counted 58 attacks on crypto platforms between 2017 and 2023 worth roughly $3bn, and assessed that illicit cyber activity funds about 40 percent of the DPRK's weapons of mass destruction programmes and half its foreign currency income (S/2024/215, March 2024). Its successor, the 11-nation Multilateral Sanctions Monitoring Team, put theft at $2.8bn for January 2024 through September 2025 alone (MSMT report, October 2025). Chainalysis carries an all-time lower bound of $6.75bn (December 2025), and TRM Labs crossed $6bn cumulative in April 2026 (TRM Labs, 30 April 2026).

Earlier this week the NSA published a Cybersecurity Information Sheet on securing MCP server deployments. When the signals intelligence agency starts writing hardening guides for a JSON-RPC protocol that Anthropic open-sourced in November 2024, you can assume the adoption curve happened without the security curve. The CSI is good, as these things go. It is also a strong signal that enough people have now wired autonomous agents to production credentials that somebody with a classified budget noticed.

I run coding agents against real infrastructure. Repos, deploy pipelines, cloud accounts, mailboxes. Some of them have shell access, because that's what makes them useful: the same property that makes them dangerous. This post is the threat model I use, what the MCP ecosystem actually provides, and the controls that have survived contact with agents trying their hardest to do the wrong thing.

A chatbot produces text. An agent produces effects. The difference is a loop and a tool belt: model decides, tool executes, result goes back into context, repeat until the task is done or the token budget dies.

Modern SaaS platforms often need to integrate with customer data stored in Azure. The user logs into the SaaS UI, but the actual data lives in the customer's Azure subscription. How do you provide real-time access without storing customer data in the SaaS database?

The answer: a PaaS API gateway that acts as a controlled bridge.

Data never touches SaaS storage.

Threat analysis gets a bad reputation. Over-complicated frameworks. Endless meetings. Documents nobody reads. Fancy diagrams that look impressive but change nothing.

Done wrong, it's box-ticking security theater. Done right, it's the foundation of effective security.

The difference: focus on what actually matters to your business, not what some framework says you should care about.

This is what works in practice at companies ranging from startups to global enterprises. No academic theory required.

Threat analysis is identifying what could attack you, how they'd do it, and what the impact would be - then using that to prioritize what to protect.

Service accounts. API keys. Connection strings. Database passwords scattered across config files, environment variables, Kubernetes secrets, and that one spreadsheet someone maintains "just in case". This is how most organisations handle non-human identity. It's also how most organisations get compromised.

Workload identity is about giving your services proper identities without the secret sprawl. An identity that your infrastructure manages, rotates, and revokes automatically. No passwords to rotate, no API keys to revoke when they leak.

This post covers what workload identity actually means, how to implement it on major clouds and on-prem, and the practical patterns that make it survivable.

Users have identities. They log in with SSO, use MFA, get provisioned and deprovisioned through HR systems. Messy, but understood.

Azure Logic Apps are everywhere in modern cloud architectures. They're the glue between services - orchestrating workflows, connecting APIs, moving data between systems. But from a security perspective, they're also potential attack surfaces if configured poorly.

This guide is for cyber security consultants assessing environments that use Azure Logic Apps. It covers the architecture, key configuration areas that matter for security, threat modeling, and common pitfalls to look out for. It's about understanding what's configurable, what the threats are, and where things typically go wrong.

Logic Apps are interesting from a security perspective because they sit at the intersection of multiple services. They're serverless (no infrastructure to manage), highly configurable (1000+ connectors), and often have significant permissions (managed identities with broad access). When misconfigured, they become pivot points for lateral movement, data exfiltration, or supply chain attacks. They're also easy to overlook in security assessments because they're "just workflow automation" - until you realize they have Contributor access to your entire subscription.

Azure Logic Apps is a serverless workflow orchestration service. You design workflows visually (drag-and-drop) or write them in code. The workflows connect to services - Azure, third-party APIs, on-prem systems - and execute logic based on triggers and actions.

Just back from Brussels for FOSDEM 2026. Always brilliant. Solid technical content, interesting people, too much Belgian beer. Here's what I took away from the best bits.

This year's highlights included some genuinely useful Go tooling (OOMProf for debugging memory issues with eBPF), the NixOS crowd showing off proper zero-trust infrastructure for homelabs using TPM attestation, and Daniel Stenberg reminding everyone that we're wasting time on AI hype while basic security problems go unfixed. Also covered: containers, systemd integration, and why Belgian beer is dangerous when you're trying to explain TLS to strangers.

The technical content was strong, but the real value of FOSDEM is always the people. Walking around ULB campus surrounded by folks who wrote half the software you use daily, having random conversations that turn into collaborations - that's what makes it worth the trip.

The Go track had some good content this year.

The On-Behalf-Of (OBO) flow is one of the lesser-understood OAuth2 grant types, yet it's critical for secure microservice architectures.

It preserves user identity through a service chain and limits damage when a single service gets popped.

If you're building microservices that need to maintain user context across service boundaries, this covers when to use OBO versus client credentials, security considerations, and practical implementation patterns.

The OAuth2 On-Behalf-Of flow allows a service that's already received an access token from a user to obtain another access token for a different service on that user's behalf. The key insight: the user authenticates once, and that authentication flows through your entire system via token exchanges.

Part 7 was meant to be the end. "Good luck, you'll need it." Fin.

Then someone asked: "Alright, but what tools actually work? Not vendor pitches. Not 'AI observability platforms' that cost more than my salary. Actual tools that help run AI systems without making everything worse."

Fair question.

Bonus episode. Practical tools and techniques that actually help when you're running AI systems. Things I've used. Things that work.

What you need: Track accuracy, latency, input/output distributions, drift.

Six parts of this series explaining what goes wrong with AI systems. Testing that doesn't happen. Monitoring that doesn't exist. Models shipped before they're ready. Incidents that could have been prevented.

You'd think after reading all that, teams would learn. They don't.

The same mistakes happen over and over. Not because people are stupid. Because the organizational incentives guarantee failure.

Part 7. The last of the core series. Why organizations are structurally incapable of running AI systems properly, and what you can do about it (spoiler: not much).

What gets rewarded: Shipping fast. Meeting deadlines. Saying yes. Being a team player. Delivering features.

This is where I tell you about actual AI deployments that went wrong. Real incidents. Real failures. Real consequences.

Names changed. Details changed enough that you can't identify the companies. But the failures? Those are real.

Part 6 of the series. Case studies. Learn from other people's mistakes so you don't repeat them.

What they built: AI system to triage emergency department patients. Predict severity, recommend priority.

This conversation never goes well. Have it anyway.

Part 5 of the series. This one's about saying no. When to do it, how to do it, and how to not get fired for it.

1. The model hasn't been tested properly

And that's how you end up debugging at 3am.

Part 4 of the series. This one's about testing AI systems before deployment. Not the "it runs on my laptop" kind of testing. The "I've actively tried to break this and couldn't" kind of testing.

Most teams test AI like this:

3:47am. Phone rings. On-call engineer sounds panicked.

Welcome to AI incident response.

Part 3 of the series. This one's about what to do when your AI system breaks at 3am and you're expected to have answers you don't have.

Normal software incident: Something breaks. You get logs. Stack traces. Error messages. You follow the trail. "This function threw an exception because this input was null because this service was down." Root cause identified. Fix deployed. Done.

Part 2 of the series on running AI systems. This one's about monitoring. Not the useless kind vendors sell you. The kind that actually tells you when things are broken before management finds out from Twitter.

Traditional monitoring for traditional systems: Is it up? Is it responding? What's the latency? Memory usage? CPU? Disk I/O?

This is part one of a series about running AI systems when you're the poor sod responsible for keeping them alive. Not the hand-wavy ethics stuff. The practical bits: what breaks, how to know it's broken, and how to not get blamed when it inevitably goes sideways.

Traditional software fails loudly. Database goes down? Error. API times out? Error. Memory leak? Eventually, error. You get logs, stack traces, alerts. Something to work with.

Security as Code isn't about running more scanners automatically. It's about changing how security gets built into systems. Most organizations miss this. They automate detection, declare victory, then wonder why breaches still happen.

I've watched this pattern repeat across dozens of organizations:

Most penetration testing is security theater. A PDF appears once a year, lists findings you already knew about, gets filed away, nothing changes. The checkbox is ticked. Compliance is satisfied. Security hasn't improved.

This isn't about shitting on pentesters. Good pentesters are worth their weight in gold. This is about how to get actual value from penetration testing instead of buying an expensive PDF that nobody reads.

A pentest answers one specific question: at this moment, could a skilled attacker with this scope compromise this target?

I've had this conversation too many times. Someone builds a new internal application, needs authentication, gets confused between OAuth2 and SAML. They're both "login with company account" from user's perspective. Underneath? Completely different protocols for different problems.

OAuth2 is an authorization framework. It's about delegation - giving an application permission to act on your behalf.

We obsess over secure coding practices. Input validation, authentication, access controls. But then we pull in 2000 dependencies from npm, PyPI, Docker Hub. We download images, run unverified binaries, trust package maintainers we've never met.

That's where supply chain attacks live. Not in your code. In everyone else's.

Your application includes your code plus every dependency, library, container image, and tool in your build pipeline. Each one is a potential attack vector.

If you read my post on building your own CA and thought "fine, but how do I actually issue certs without becoming the Certificate Person", this is the next step.

step-ca (Smallstep Certificate Authority) is the bit that makes internal PKI usable: automated issuance, short-lived certs, predictable renewal, and enough policy to stop someone minting a wildcard for your entire estate.

It also gives you a new thing to break at 3am.

This post covers a practical step-ca setup on a Linux VM, what to lock down, how to issue and renew certs, and the failure modes I've seen in the wild.

You can run an internal CA with OpenSSL and a folder of files. People do. It works right up until you have:

Famous last words. Eighteen months later, you're dealing with wildcard certs everywhere, browsers rejecting perfectly valid certificates, and nobody understands why the monitoring system stopped working after a cert renewal.

Internal PKI isn't hard because the cryptography is complex. It's hard because most organizations skip the guardrails that make PKI safe to operate at scale.

This is about building internal PKI properly. Not the minimum viable certificate authority. The kind that doesn't explode when someone makes a mistake.

I've seen this pattern at dozens of organizations:

"Here's the security checklist for the new release."

"We're deploying next week. When can we do the review?"

"The review takes two weeks minimum. You scheduled it last month."

"...we didn't."

This is the problem with security checklists. They're designed for a world where you deploy quarterly. In continuous deployment environments, they're the wrong tool.

The evolution from checklists to code isn't about abandoning security knowledge. It's about making security verification scale with modern development practices.

Before we get into how to transform them, acknowledge what they did well.

Zero trust has become the most abused term in security marketing. Every vendor has a zero trust product. Every slide deck has a zero trust slide. Every CISO has a zero trust initiative.

Most of them are buying a product and calling it a strategy.

This post is about what zero trust actually looks like when you have to implement it. Not the conference version. The version where you're staring at a network diagram, a list of legacy systems, and a budget that won't cover half of what the vendors quoted you.

Strip away the marketing and you're left with one idea: don't trust anything by default.

Incident response plans look great in documents. Neat flowcharts. Escalation matrices. Communication templates. Everyone has a role. Everyone knows what to do.

Then something actually happens and none of it works the way the document said it would.

This post is about what incident response looks like in practice. Not the framework version. The version where you're half awake, the logs are incomplete, and someone is asking you to confirm it's not a breach before you've even found the right terminal.

They fail for the same reason most plans fail: they were written for a world that doesn't exist.

DNS is the most boring critical system you run. Nobody thinks about it until it fails, and when it fails everyone suddenly becomes very interested in TTLs.

You can patch servers. You can roll back deployments. You can add more replicas. None of that matters if clients can't resolve names.

DNS security goes beyond "do DNSSEC and you're done". It covers availability, integrity, and watching the bits that attackers like because you usually leave them alone.

This post covers how DNS breaks in the real world, how attackers use it, what you can monitor without buying a new platform, and what to do at 3am when name resolution goes sideways.

On paper, DNS maps names to IPs.

This conversation happens constantly. OAuth 2.0 is everywhere, but most implementations get it wrong. Not spectacularly wrong. Just wrong enough to be exploitable.

The OAuth 2.0 specification is a framework, not a protocol. It gives you options. Most of those options are wrong for your use case. The security comes from knowing which options to pick and which to avoid.

OAuth 2.0 is authorization, not authentication. It lets one service act on your behalf without giving away your password.

Traditional security is defensive. Firewalls, EDR, access controls. Prevent attacks, detect intruders, respond to incidents. But there's a problem: you only know your defenses work when someone attacks. And you only find weaknesses when they're exploited.

Chaos engineering is offensive. You break things on purpose. Systematically. Repeatedly. Not to cause problems, but to discover them. To find where your resilience fails before attackers exploit those failures.

Chaos engineering is controlled failure injection. You deliberately break things to see what happens.

This conversation happens constantly. Organizations pick password managers the same way they pick any security tool - based on vendor pitch decks and analyst reports, not actual requirements.

The password manager market in 2025 splits into three categories: personal password managers, team password managers, and infrastructure secrets management. They're not interchangeable.

For individual use. Your email passwords, banking logins, personal accounts.

SSH hardening advice on the internet falls into two categories: the stuff that doesn't matter (change the port, install fail2ban, add a banner) and the stuff that does matter but nobody explains properly (certificate auth, key management, agent forwarding risks, auditing).

This post is about the second category.

If you're running Linux servers - on-prem, cloud, doesn't matter - SSH is your management plane. If SSH is compromised, everything behind it is compromised. Treat it accordingly.

Get these out of the way so we can focus on what does.

Traditional encryption works by keeping data secret until you need it. Decrypt, process, encrypt again. It's worked for decades. But it has a limitation: at some point, the data must be exposed in plaintext.

Confidential computing flips this on its head. Instead of protecting data by controlling who can access it, we protect data by ensuring it's never accessible in plaintext at all. Even during processing.

This isn't theoretical. Companies are using it today. Financial analytics on encrypted transactions. Healthcare processing without seeing patient records. Collaborative fraud detection between competitors without sharing raw data.

Confidential computing is about processing encrypted data without decrypting it. Three main approaches:

Bash is on every Unix-like system you'll touch. The shell is already there, waiting to be used, with nothing to install and no suspicious binaries to explain.

For security operators - red team, blue team, doesn't matter - this makes Bash incredibly valuable. You can do reconnaissance, establish persistence, monitor systems, or respond to incidents without touching disk or installing tools. Living off the land, as they say.

This is a practical guide to using Bash for security operations. Techniques that work when you're on a system and need to get things done.

It's already there. Every Linux box. Most Unix systems. macOS. Even Windows has WSL now. You don't install Bash. It's just there.

Security vendor marketing has drifted so far from reality that products and datasheets might as well be different languages. Bought a product that promises "zero false positive threat hunting"? Got a glorified SIEM with slightly better alerting. Purchased "autonomous incident response"? Got some prewritten playbooks and a lot of configuration work.

This isn't about shitting on all vendors. Some make genuinely good products. But the gap between what security teams think they're buying and what they actually deploy is massive. And that's before the sales team starts explaining how the "AI" part works.

Let's compare common vendor claims to what you actually get.

This conversation happens more than you'd think. Not because organizations lack security tools. Because they lack detection that works when prevention fails.

Canary tokens are silent tripwires. Fake data that looks valuable. When accessed, you get a clear signal that someone's where they shouldn't be, with no false positives, no tuning, and no complex rules.

Most organizations discover breaches the same way: someone external tells them.

This is the problem with security monitoring. Teams spend thousands on SIEMs that nobody uses. Meanwhile, Prometheus sits there collecting metrics, and nobody thinks to point it at security problems.

Prometheus is already in your infrastructure. It's collecting metrics. It's generating alerts. You just need to point it at the right things.

Most people use Prometheus for service health. Application performance. Infrastructure capacity. It's time-series data. Simple metrics. Basic alerting.