SecurityTide #003

Hey,

Chiderah here. It's been a few weeks, and I owe you a straight explanation rather than pretending there wasn't a gap.

My domain expired. Not dramatically, not a hack, just the most ordinary infrastructure mistake there is: a renewal I didn't catch in time, and suddenly securitytide.com went dark and the newsletter went quiet with it. For someone building a publication about doing the fundamentals well, letting a domain lapse is a humbling little lesson in exactly the kind of operational discipline I write about. I've got it back, I've got calendar reminders and auto-renew set now, and we're moving again.

Here's the thing I can't ignore: the week I spent locked out of my own domain, scrambling to get back in, lines up almost too neatly with what I was studying in RHCSA. Because this week's chapter is about exactly that, getting back into a system you've been locked out of. So let's get into it.

A worm is crawling through the open-source supply chain, and it bypasses code review entirely.

The big ongoing story is a wave of supply-chain attacks hitting the npm and PyPI package ecosystems, with one campaign nicknamed Shai-Hulud spreading across 100-plus packages. The most technically significant single incident: the compromise of a Red Hat cloud-services npm namespace, where an attacker breached the CI/CD pipeline through GitHub Actions and injected a malicious payload into 32 packages across 96 versions, collectively pulled down well over 100,000 times a week.

Read that mechanism carefully, because it's the scary part. The attacker didn't steal a developer's password. They compromised the build pipeline, which meant the poisoned code sailed through every standard code-review gate untouched. The payload hunted for exactly what you'd fear: CI/CD secrets, cloud credentials across AWS, Azure, Google Cloud and Kubernetes, SSH keys, and access tokens.

One thought.

This is the same lesson from my very first issues, the toolchain is the attack surface now, escalating. We've spent decades teaching people to distrust email attachments. Almost nobody applies that same suspicion to a package their build system pulls automatically at 3am. When the compromise happens at the pipeline level, "did a human review this code?" stops being a meaningful defence, because the human reviewed clean code and the pipeline poisoned it afterward. The defences that actually help here are unglamorous and structural: pin dependencies to exact versions, scope your CI/CD secrets to the minimum, and rotate credentials on a schedule so a leaked token has a short shelf life. None of it is exciting. All of it would help.

African data-protection regulators have stopped warning and started fining, and the numbers are getting real.

The story I keep coming back to on this beat is regulation growing teeth, and the latest enforcement figures make it concrete. Kenya's Office of the Data Protection Commissioner has published more than 110 decisions in a single year, issuing real fines, including penalties against a digital lending company for unlawfully associating someone with a loan they never took. In Nigeria, the Data Protection Commission fined a major satellite-TV provider roughly ₦766 million (about half a million US dollars) over privacy breaches and illegal cross-border data transfers.

Those aren't symbolic slaps. They're the sound of a regulatory regime switching from "please comply" to "here is the invoice." And the trend is continental: data-localisation requirements landing in Kenya and Ghana, digital-sovereignty bills advancing in Algeria and Nigeria, and analysts projecting that Africa will pass 50 national data-protection laws this year.

Here's why it matters for security and not just compliance, the same point I made early on but now with receipts: enforcement changes attacker economics. When a breach becomes a half-million-dollar regulatory event on top of the incident itself, security budgets stop being a hard sell. The continent is building the financial incentive to defend itself, market by market, fine by fine. That's a more durable security improvement than any single tool, and it's happening largely out of view of the Western press that treats African cyber as a footnote.

There's no way I can write this section this week without acknowledging the obvious: I spent a week locked out of my domain, and the RHCSA chapter in front of me is about getting locked out of a system and breaking back in. Sometimes the lesson finds you.

The scenario every RHCSA candidate has to master: you don't know the root password (or it's been changed, or you've inherited a machine nobody has credentials for), and you need to get in and reset it. No reinstall. You break in through the boot process itself.

Three things that landed:

1. The boot process is an opportunity, not just a sequence. On a Red Hat system you interrupt GRUB at startup, edit the kernel line, and append rd.break to drop into an early root shell before the real system fully comes up. From there you remount the filesystem as writable, chroot into it, and you're effectively inside the machine with the power to reset the root password. The first time it works, it feels a little illicit, you've just bypassed authentication on a box you didn't have the password to. That's the point: it's a sanctioned, documented recovery path, and it's also a stark reminder of why physical access to a server is its own threat model.

2. The SELinux relabel step is the one everyone forgets. After you reset the password through rd.break, you have to create a file called /.autorelabel before rebooting, or SELinux contexts on the changed files go wrong and you can lock yourself out again. Miss this single step and you turn one lockout into two. The chapter that taught me to respect SELinux keeps collecting interest.

3. Recovery is a security topic, not just a sysadmin one. Everything that lets you recover a locked machine is also what an attacker with physical access could use against you. Boot-level password reset is exactly why server-room physical security, GRUB passwords, and full-disk encryption exist. Learning to break into my own machine taught me, viscerally, why you defend the boot process. Defender and attacker reading the same procedure, opposite intentions, the recurring theme of everything I'm learning.

I'll be honest: doing this the week I was locked out of my own domain landed harder than any practice lab would have. Sometimes the universe sets the curriculum.

If boot recovery is this week's skill, then the tool that pairs with it is the one that tells you what actually happened during a boot: journalctl, systemd's unified log reader. When a machine misbehaves at startup, or when you're investigating why you got locked out in the first place, this is where the story lives.

The commands that matter:

The two I lean on hardest: -b -1 to read the previous boot when a machine came back up wrong, and --since/--until to pin an incident to the exact minutes it happened. journalctl -u nginx --since "09:00" --until "09:15" has saved me more time than any dashboard ever has.

One gotcha that's bitten me: many systems don't keep journals across reboots by default, so journalctl -b -1 returns nothing right when you need it most. The fix is to enable persistent storage with mkdir -p /var/log/journal and restart systemd-journald. On any server you actually care about, you want that history waiting for you before the incident, not after.

Here's the security crossover, because there always is one: journalctl isn't just a debugging tool, it's a forensic timeline. The same command you use to ask "why did this service fail?" is what an analyst uses to reconstruct "what happened on this box, and when?" after an incident. Boot recovery gets you back into a locked machine. journalctl tells you the story of how it got locked in the first place. You want both skills, and this week taught me to want them badly.

That's issue three. We're back.

Thanks for sticking around through the quiet stretch, especially those of you who noticed and checked in. If something here was useful, forward it to one person who'd benefit. It's still the only growth lever I've got, and after a few weeks dark, I'm not taking a single subscriber for granted.

And hit reply, what are you working on or stuck on this week? Bonus points for your own "locked myself out and had to break back in" war story. I read every one.

See you next Saturday. For real this time.

— Chiderah

SecurityTide is a publication about practical cybersecurity, written from the field. Linux. Pentesting. Certifications. The African cyber landscape.

Founded and written by Chiderah Ikocha. Based in London. Currently chasing the RHCSA.

Read the manifesto · Visit SecurityTide