It's the second of January, which is exactly when you start tidying up the year that's gone, and a year ago this week the whole industry got handed a problem that hasn't gone away. Spectre and Meltdown landed at the start of January 2018, and the twelve months since have been a slow, grinding lesson in what it means when the vulnerability is in the silicon and not the software.
I'm not going to pretend I called any of it. Like most people, I read the disclosures, looked at the affected-CPU lists, realised that "affected" meant "more or less everything we own", and started the patching.
What stuck with me through the year is how this class of bug rewires your instincts. Most security work is about a boundary you can point at: a missing input check, a permission set wrong, a service exposed it shouldn't be. You fix the boundary and the problem is gone. Speculative execution side channels aren't like that. The boundary you trusted, the one between processes, between guest and host, between userspace and kernel, turned out to leak through the very optimisation that makes the chips fast. You can't simply patch that away. You mitigate it, and you pay for the mitigation in performance.
That bill came due in real numbers. On the boxes I look after, the kernel page-table isolation work and the microcode updates were not free. Workloads heavy on system calls felt it most: anything doing a lot of small I/O, a lot of context switching. Nothing fell over, but the headroom I thought I had got quietly smaller, and capacity planning done before January 2018 was suddenly optimistic.
The follow-on disclosures through the year kept the treadmill turning. Each one arrived with its own variant name, its own microcode update, its own "are we affected" spreadsheet exercise across the fleet. By autumn I had a routine for it, which is its own kind of depressing: you shouldn't be good at a thing that's meant to be exceptional.
The lasting change for me isn't technical, it's a habit of mind. I no longer assume the layers below my code are solid ground. The CPU is a system with its own bugs, its own errata, its own update channel that I now actually track. Firmware and microcode went from "set once and forget" to "part of the patch cadence". And when someone proposes packing untrusted tenants tightly onto shared hardware to save a few quid, I think a lot harder about it than I would have done two years ago.
A year on, we're still shipping mitigations and still arguing about which ones to enable on which workloads. The flaw is in chips that will be in service for years yet. So this isn't a problem we closed. It's one we learned to live alongside, which, going into 2019, feels like the honest summary.