Hey,
Chiderah here. Welcome back, and if this is your first issue, welcome in. You found me last week or sometime since. Either way, here's number two.
A quick note before we start: thank you to everyone who replied to issue one. I read every message. A few of you are also grinding through RHCSA right now, so this issue's learning section is for you in particular.
Let's get into it.
This week in cyber
A poisoned developer extension breached GitHub's own internal repositories. Think about that for a second.
This week GitHub confirmed that attackers reached roughly 3,800 of its internal repositories. The entry point wasn't a firewall hole or a stolen password. It was a compromised version of the Nx Console extension for VS Code, installed on an employee's machine. The Nx compromise itself traced back to the earlier TanStack npm supply-chain attack, and the same poisoned pipeline reportedly touched OpenAI, Mistral AI, and Grafana Labs along the way.
So the chain reads: one developer's system gets hacked, a popular extension gets a malicious update pushed through it, and that update quietly walks into the build environments of some of the most security-conscious companies on earth. Including the company that hosts most of the world's source code.
One thought.
We have spent twenty years teaching people to be suspicious of email attachments and sketchy downloads. Almost no one extends that suspicion to the tools they install to do the work. The VS Code extension. The npm package. The GitHub Action. The Docker base image. Every one of those is code running with your permissions, pulled from a registry you don't control, updated automatically while you sleep. The attack surface moved into the toolchain, and most of us are still guarding the front door.
If you write code or run build systems, two cheap habits pay off here: pin your dependencies to exact versions instead of letting them float, and turn off auto-update for editor extensions so a silent push can't become a silent breach. Neither is glamorous. Both would have helped.
I'll be watching whether this pushes the industry toward signed, verifiable extension and package supply chains. It should. It probably won't, until it costs someone enough.
On the continent
The African threat map is shifting, and the headline number surprised me.
Fresh intelligence from Check Point this quarter puts Nigeria at roughly 4,200 cyber attacks per week per organisation, the highest on the continent. But the trend underneath that number is the interesting part: Nigerian organisations actually saw attacks drop about 12% recently, Kenya and Morocco each fell by more than half, while Ethiopia climbed nearly 30%.
That movement tells a story. As regulation tightens and breach reporting becomes mandatory in markets like Kenya, South Africa, and Algeria, attackers appear to be rotating toward softer targets where disclosure laws and defensive maturity lag. The threat doesn't disappear. It relocates to wherever the friction is lowest.
This is the part of the African cyber story the global press almost never tells: the continent isn't one market, it's fifty-plus very different ones, and the attackers read the regulatory map better than most defenders do. I'll keep tracking where the pressure moves next.
What I'm learning: RHCSA networking, and a full-circle moment
This week was the networking chapter, and it hit me with something I didn't expect: a sense of having come full circle.
When I started in tech, my first real "aha" was networking in Cisco Packet Tracer. Dragging routers and switches onto a canvas, assigning IP addresses, watching a ping finally go through. That simulated world is where IP addressing, subnets, and gateways first clicked for me. This week I learned to do the same things for real, on a live Linux system, from the command line. Packet Tracer to nmcli. Same fundamentals, no training wheels.
Three things that landed this week:
1. Device vs connection is the mental model that unlocks everything. In NetworkManager (which is the only game in town on modern RHEL, the old network service is gone), a device is the physical interface and a connection is a configuration profile you apply to it. One device can hold multiple connections. Once that distinction clicked, every nmcli command suddenly made sense instead of feeling like incantation.
2. ip is for looking, nmcli is for keeping. Anything you do with ip addr add is gone on reboot. It's great for a quick test, useless for a real configuration. If you want it to survive a restart, it has to go through nmcli (or nmtui), which writes a real connection file to /etc/NetworkManager/system-connections/. I burned time early in the week "fixing" an address with ip and watching it vanish on reboot before this sank in.
3. Never touch /etc/resolv.conf directly. This one's a trap. You can edit it, your DNS will work, and then NetworkManager overwrites the whole file on the next restart and your change is gone. The right move is to set DNS on the connection itself: nmcli con mod <name> ipv4.dns 8.8.8.8, and let NetworkManager push it down to resolv.conf. The file is an output, not an input.
The exam tip I keep seeing, and now believe: nmcli is powerful but fiddly under time pressure. For speed on exam day, nmtui (the text menu) does the same job in under a minute. Learn nmcli to understand what's happening; reach for nmtui when the clock is running. More notes as I get closer.
Tool of the week: nmcli
I'm breaking my own pattern this week. Last week was ss, and I'd planned to stay in systemd territory. But the networking chapter put nmcli in front of me and I can't not write about it, because of where it sits in my own story.
Networking is where my tech journey actually started. Cisco Packet Tracer, dragging routers onto a canvas, assigning addresses, willing a ping to succeed. That was the first time any of this clicked. So learning to configure real networks on real Linux systems this week felt like closing a loop I opened years ago. Same concepts, no simulator.
nmcli is the command-line front end to NetworkManager, and it's how you make network changes that actually persist on RHEL. The commands I drilled this week:
nmcli con show # All connections, active and inactive
nmcli dev status # Every device and its state
nmcli con show <name> # Every property of one connection
Creating a static connection from scratch (the command worth memorizing):
nmcli con add con-name static type ethernet ifname ens33 \
ip4 10.0.0.10/24 gw4 10.0.0.1 ipv4.method manual
Modifying one that already exists:
nmcli con mod static ipv4.dns 8.8.8.8 # Set a DNS server
nmcli con mod static +ipv4.dns 1.1.1.1 # Add a second (the + matters)
nmcli con up static # Activate the changes
Two gotchas that cost me time so they don't cost you:
You use ip4 and gw4 when adding a connection, but ipv4.dns and ipv4.addresses when modifying one. It looks like a typo. It isn't. That's genuinely just how the syntax works, and it trips up almost everyone.
And the single best thing I learned all week: nmcli has full Tab completion if the bash-completion package is installed. Type nmcli, hit Tab twice, and it shows you every valid next word. You can build a long, correct command without memorizing the syntax at all. There's also a man nmcli-examples page that is pure copy-paste gold.
From Packet Tracer to nmcli. The fundamentals never changed. I just took the training wheels off.
That's issue two.
If something here was useful, forward it to one person who'd benefit. Every forward is the only growth lever I actually have.
And hit reply: what are you working on or stuck on in cyber this week? I read every single one, and a few of last week's replies are shaping what I write next.
See you next Saturday.
— 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.