Why Reading Code Makes You Dangerous (In a Good Way)

A vulnerability advisory drops on a Tuesday. Two people read the same report. One sees a severity score and waits for a patch. The other understands what a heap-based buffer overflow actually means and starts reducing risk before a fix even exists.

This episode breaks down why code literacy is a cybersecurity skill, not just a developer skill. It starts with the listener's question about learning C and C++ for security, then widens the lens to cover the full stack: why C still matters because of how it handles memory, how offensive operators use that knowledge to find and exploit weaknesses, and how defenders use it to read malware, assess real risk, and build their own tools. The episode maps four languages to four layers, C and C++ for how software touches hardware, Python for automation and speed, JavaScript for web attack surfaces, and Assembly for understanding what the machine is actually doing then closes with a four-step starter kit for building code literacy at any level.

Whether you're a security professional wondering where to start with code or a leader trying to understand what your team means by "exploit development," this episode makes the case clearly. Plaintext with Rich.

YouTube more your speed? → https://links.sith2.com/YouTube  
Apple Podcasts your usual stop? → https://links.sith2.com/Apple  
Neither of those? Spotify’s over here → https://links.sith2.com/Spotify  
Prefer reading quietly at your own pace? → https://links.sith2.com/Blog  
Join us in The Cyber Sanctuary (no robes required) → https://links.sith2.com/Discord  
Follow the human behind the microphone → https://links.sith2.com/linkedin  
Need another way to reach me? That’s here → https://linktr.ee/rich.greene

Transcript

Two Takes On A Vulnerability

SPEAKER_00 0:00

A vulnerability advisory drops on a Tuesday afternoon. Two people read the same report. One sees a severity score, critical, 9.8 out of 10. They flag it, they escalate it, they wait for a patch. The other reads the technical description, heat-based buffer overflow in the input parser. And because they understand what that means, they don't just see a number. They see which systems are actually exposed. They see which configurations make it worse. They see how to reduce the risk before a patch even exists. Same advisory, same Tuesday, very different responses. The difference isn't experience. It's that one of them learned enough about how software is written to understand how it breaks. Welcome to Plain Text with Rich. Today's episode comes from a listener who asked about the importance of learning C languages for cybersecurity. And great question. We're going to answer it, but we're also going to widen the lens. Because the real advantage isn't one language, it's understanding the layer you're working in. Let's start in plain text. Code literacy in cybersecurity doesn't mean becoming a software engineer. It means understanding enough about how software is built to see where it breaks, how it's abused, and what the evidence looks like after the fact. That's it. You don't need to build the house. You need to read the blueprint well enough to find the unlocked window. Now, let's talk about how the listeners question directly, right? C and C are foundational programming languages. C was created in the early 70s, C came about a decade later, adding more structure and features on top of C's foundation. Why do they matter for security? Because an enormous amount of the world's critical software is written in them. Operating system kernels, network stacks, embedded systems, firmware, databases. When you hear about a vulnerability in like Windows, Linux, a router, or a medical device, there's a decent chance the bug lives in C or C code. And here's why. C gives you direct access to memory. And that's powerful. Also dangerous. C lets the programmer decide exactly where data goes in the computer's memory and how long it stays there. Most modern languages handle that for you automatically. C says, yo, that's your problem. Think of it like driving. Most modern languages are cars with automatic transmission, any lock brakes, lane assist. C is a manual transmission with no guardrails. You have total control. You can also drive straight off a cliff if you're not paying attention. That freedom is why C is fast. It's also why entire categories of vulnerabilities exist. Buffer overflows, simply writing more data into a space than it was built to hold. Use after free, using a piece of memory after the program already gave it back. Format string bugs, right? Tricking a program into reading or writing memory it shouldn't touch. And these aren't exotic. They're some of the most common serious vulnerabilities in the world, and they've been around for decades. If you understand C well enough to see how memory works, you understand how a huge portion of real-world exploits function. Now, that's the listener's instinct, and it's a good one. Now, a reasonable question: if C is so dangerous, why is it still everywhere? Because replacing it isn't a weekend project, it's a decades-long migration. The code running inside your operating system, your network hardware, and most embedded devices were written in C because nothing else could do the job at the time. And rewriting billions of lines of code, right? Working, working code, right? It introduces its own risks. Now, newer languages like Rust are designed to prevent many of these memory problems. That's promising. But the existing C and C code bases, they aren't going anywhere soon. Which means the vulnerabilities aren't going anywhere soon either. And that's exactly why understanding these languages still matters for cybersecurity professionals. Now, let's split this into two lanes, because the listener also asks about offensive and defensive work. Now, offensive operators are the people trying to find and exploit weaknesses, penetration testers, red teamers, vulnerability researchers. For them, C and C literacy is close to essential. Why? Because exploit development often means understanding how a program mishandles memory, then crafting input that takes advantage of that mistake. You're reading someone else's code, sometimes disassembled, sometimes raw binary, and looking for the moment where trust breaks down. That moment is almost always at the level where C operates. Again, memory addresses, pointers, stack frames. Think of it like a locksmith. You don't just use the pick, you understand how the pins inside the lock are supposed to work so you can feel when one gives. Offensive work also involves writing custom tools, payloads, shell code, proof of concept exploits. These are often written in C or scripted in Python, sometimes both, right? In the same workflow. Understanding the target language and the tooling language is what makes an operator effective, not just dangerous. Now, defensive operators are on the other side, incident responders, detection engineers, analysts, blue teamers. For them, C and C knowledge shows up differently. When you're analyzing malware, you're often looking at compiled C or C. Reverse engineering means reading what the machine is actually doing and tracing it back to patterns that you recognize. When a vulnerability advisory comes out and says something like heap-based buffer overflow in the parsing module, defenders who understand C can assess the real risk. They know what that means for their environment, not just what the security score says. The gap between this is rated critical and I understand why this is critical is code literacy. Now, defenders also write code, detection rules, automation scripts, forensic parsers, the difference between a team that waits for vendor tools and a team that builds what it needs is often one or two people who can write working code under pressure. Now, as I said, I want to widen the lens because C and C are not the whole story. Security work happens at multiple layers and different layers speak different languages. Python is the Swiss Army knife for the defensive side. It's used for writing detection rules, automating investigations, parsing logs, building internal tools, prototyping ideas quickly. Most security teams that build their own tool and use Python. If you want to automate something boring so you can focus on something interesting, Python is usually the fastest path. On the offensive side, Python shows up in exploit scripts, custom scanners, and attack frameworks. Now, JavaScript matters because the web is a primary attack surface. Cross-site scripting, malicious browser extensions, supply chain attacks through package managers. If you understand how JavaScript runs in a browser, you can understand a big chunk of how web applications get compromised. Assembly. Assembly is the language closest to what the processor actually executes. You don't need to write it daily, but the ability to read it, right, even slowly is what separates someone who uses tools from someone who understands what the tools are showing them. Here's the pattern, right? C and C teach you how software touches hardware. Python teaches you how to move fast and build. JavaScript teaches you how the web works under the surface. Assembly teaches you what the machine is actually doing. You don't need all four on day one, but knowing which layer you're operating in and which language lives there makes everything else clearer. If we're looking for a plain text starter kit, right, for building code literacy, I would go with these four moves. First, learn Python well enough to automate a task you do manually today, right? Pick something real, parsing a log file, checking a list of URLs, renaming a batch of files. The goal isn't mastery, it's momentum. Once you've automated one thing, the second comes easier, third, fourth, so on and so forth. Second, read C well enough to understand a vulnerability report. You don't have to write production C, but again, when a CVE says stack-based buffer overflow, you should be able to picture what happened. Tons of free online resources and textbooks can get you there, right? Start with how variables, arrays, and pointers work in C. And that's the that's the foundation the rest of it builds on. Third, pick one side and go deeper. If offense interests you, study how exploits work. Read write-ups, follow researchers who publish proof of concept code and explain it step by step. If defense is your lane, practice reading code you didn't write. Open source tools, malware samples in a safe lab, scripts from your own team. The skill is pattern recognition, right? What does normal look like so you can spot abnormal? Fourth, don't try to learn everything at once. Pick the language that matches where you work. If you're in web security, start with JavaScript or another web-based language. If you're in malware analysis, start with C and assembly. If you're building detections and automation, start with Python. Fluency across layers is the long game. Play it in order, right? For our recap here, code literacy is a security skill, not just a developer tool. C and C matter because they're where critical software lives and where memory-level vulnerabilities are born. Offensive operators use that knowledge to find and exploit weaknesses. Defensive operators use it to understand threats, read malware, and assess real risk. But C isn't the only language that matters. Python, JavaScript, Assembly each cover a different layer of the stack. The goal isn't to master every language, it's to read the layer you're responsible for. Same field, different depths, choose yours and start. If there's a topic you want broken down in plain text, send it my way. Email me, DM me, drop it in the comments. Even a pull request works as long as it's not marked urgent at 2 a.m. I read everything and get back to you if it's possible. If this episode helped, share it with someone who'd actually benefit. This has been Plain Text with Rich. One topic, 10 minutes or less, no panic. See you next time.