Alice and Bob Learn Secure Coding

Okay, let's unpack this. We all rely on software for almost everything these days, don't.

We absolutely banking, smart homes, everything.

It's woven into the fabric of our lives. And frankly, the stakes for security have never felt higher.

Yeah, incidents aren't just annoying anymore. They can be genuinely dangerous exactly.

We're talking everything from massive data breaches to you know, critical system failures. It really makes you wonder as developers, what's our true obligation here to build software of the highest quality and standards.

That sense of responsibility really resonates, doesn't it.

It does, And.

What's fascinating here is how deeply that mission is reflected in the source material we're diving into today. Alice and Bob learn Secure Coding.

AH by Tanya Jacka.

Yeah, she makes it really clear the book wasn't just for herself, but for you the listener, and well for the personal desire for loved ones to use software safely.

That's powerful.

It's a strong call to action, really to instill a sense of responsibility in every developer to build more trustworthy products, especially when I mean, we've all heard endless stories of data breaches and security.

Incidents, too many stories.

It truly sets the stage for our mission today understanding how to elevate our approach to software security.

That's a powerful framing.

Yeah.

So if that's the why, what are the foundational principles the how? Today we're taking a deep dive into those core principles and practical steps for secure coding, drawing directly from this incredibly insightful book.

Yeah, lots to cover.

We'll explore general advice that applies across the board, specific best practices for say, popular technologies and common vulnerabilities to watch.

Out for usual suspects.

Our goal is really to equip you with the knowledge to create truly robust applications and hopefully contribute to a safer digital world. So where do we even begin when we're trying to build more secure software?

Well, the foundation For.

Many of us, I think trusting people is a natural instinct, but when it comes to systems, that mindset needs a fundamental shift, right.

Absolutely.

The book really hammers home the idea of adopting as zero trust model.

It does, and this raises an important question. Why why is never assumed trust so critical?

Yeah?

Way, Because if you implicitly assume trust you're opening yourself up to a whole world of risk. I mean everything from credential stuffing attacks.

Where they use stolen passwords from other breaches.

Exactly that, or malformed data. You simply cannot trust any data you receive, not really, even if it's from your own company's internal APIs.

Even internal stuff. Wow.

Remember Alice's experience in the book where executives were fish because they had admin privileges and no anti malware. Oh right, Yeah, that's the stark example of what happens when trust is just assumed in a system. It truly highlights how every piece of data, every interaction needs validation.

It's about being relentlessly proactive, isn't it.

Yes.

And part of that proactivity, which might sound a bit pessimistic but is actually incredibly realistic, is to assume breach and plan for failure precisely.

And this isn't just about having a disaster recovery plan tucked away somewhere, No, No, it's about fundamentally altering your development mindset. Imagine every line of code you write, you design it assuming it will be probed, tested, or even compromised.

Okay, so what does that actually mean in practice?

Well, It affects your testing, your logging, your error handling, not just at the end, but from day one, right from the start. It means designing your systems, your processes, and your reactions as if a breach will happen, like launching your incident response the moment of vulnerability.

Is reported, not waiting for proof of exploit.

Exactly, using multiple layers of defense, constantly monitoring your network for suspicious activity. It's about building in resilience from the ground up, not just cleaning up after the fact.

Okay, So, if we accept that breaches are kind of inevitable a matter of when, not if, how do we make secure choices the easy choices for developers because often the secure way feels harder.

That's a key challenge.

The book introduces this concept of secure defaults or a paved road right yep, where the most secure settings are the default Yes.

And this is a potential game changer because it applies both to the products you build for users and your own internal development environments.

How so well.

Examples from the source material include creating clear policies and importantly tools for things like secret management, even setting up pre commit hooks.

In the version control Yeah.

Hooks that actually reject code if it contains secrets. Imagine a system where the easiest path for a developer is also the most secure.

That's the dream.

It's also why things like security policy compliance, you know, actually prioritizing fixes for broken policies and using static application security testing or SASD.

Where tools scan the code.

Itself right, using SAS to automatically block bad code patterns before they even get checked in. That's crucial.

And speaking of making secured choices easier, a cornerstone of that has to be applying the principle of least privilege. Don't give more access than necessary for only as long as necessary. Sounds simple, but I know in practice teams can struggle with this, finding that balance between security and well convenience.

It's a common struggle absolutely. But the real insight here, I think, is understanding how reducing that blast radius isn't just a security win, it can actually simplify maintenance and compliance in the long run too.

How does that work?

Well, think about it. Whether it's giving a user access to a network or an application, every privilege granted carries risk.

Sure.

The book illustrates this really well with Bob's strategy at we hack Purple creating separate vaults like secure containers with specific access for different teams. Marketing gets one admin gets another.

Okay, segmented access exactly.

So if someone leaves, you only have to rotate a small subset of credentials. That saves immense time and reduces risk compared to having shared overly brought access. It's all about minimizing the damage if an account is ever compromised.

Right, containing the potential fallout makes sense. So we've covered designing securely, but once that data starts flowing in, that's often where the real vulnerabilities creep in, isn't it.

Oh? Absolutely, that's prime attack surface.

The book really emphasizes input validation and outputting coding.

And this is fundamental. So many attacks start here. Any data entering your application or API is a potential attack vector, period.

And the critical insight you mentioned earlier.

Yes, never assume data is safe, even if it comes from your own database, because it might have been maliciously stored there previously. Someone might have found a way to poison your data store.

Wow. Okay, paranoia is good here.

A healthy dose, And for web applications, outputting coding is essential to prevent cross site scripting excess.

As injecting malicious scripts into websites.

Precisely, and a huge takeaway from the book something really practical. Always use an allow list when validating input, not a block list.

Explain that difference again.

Okay, so a blocklist tries to list all the bad things like specific characters or script tags and reject them. But trying to block every possible bad input is a losing battle. Hackers are clever, they'll find ways around it exactly. The book points out examples using URL encoding to bypass simple blocks, and allow list, on the other hand, defines precisely what is acceptable, like only alphanumeric characters of a certain length, so.

You define the good not the bad.

Right. It's far more robust and usually easier to maintain because you're focused on what's permitted, not trying to guess every possible attack.

That makes a lot of sense. And then there's the big one, sequel injection. It feels like a classic, almost mythical vulnerability.

Sometimes, but it's still out there.

Still the infamous number one worst vulnerability for web apps. According to many sources, it's almost disturbingly easy to exploit isn't it.

It really is Bob's eye opening experience at that capture the flag contest, learning how something as simple looking as or one on one could completely bypass a log instagram just like that, Just like that. It illustrates just how powerfully simple yet devastating these attacks can be.

So what's the defense the silver bullet?

Well, there's no single silver bullet in security. But for SQL injection, the solution, as the book emphasizes, is using parameterized queries or stored procedures properly implement.

Okay, parameterized queries, what do they do?

They ensure your user input is always treated as data, just plaintext, never as executable code. It strips away those special powers an attacker might try to inject with things like or one or one makes their attempts harmless data instead of active commands.

Okay, crucial technique. Now shifting gears slightly. A constant headache for many developers I know from experience is secret manage.

Oh yes, big one.

It's just so tempting, isn't it to store connection strings or apikeys right there in your code, or maybe you can fig file checked into source control.

It is tempting easy, and the author shares a really telling personal antecdote about finding live banking passwords in source code in twenty twenty.

One, Wow in twenty twenty one, Yeah.

Long after she knew better, which just highlights that despite common knowledge, the message isn't getting through to everyone, or maybe the tooling isn't easy enough.

So what's the core principle here?

Secrets are fundamentally for machines to authenticate to other machines, not for humans to read or manage directly in code. The solution is dedicated secret management tools, things like Hashi Court Vault as your Key Vault AWS secrets manager tools built for the job exactly, and the book provides a clear actionable path. First, migrate any existing secrets out of your codebases.

That's step one the cleanup.

Then, crucially, implement those pre commit hooks we talked about earlier in your version control hooks that specifically block any future attempts to check in secret.

They get impossible to make the mistake again.

Essentially, yes, make it practically impossible to accidentally expose these crucial credentials.

Okay, so we've talked code data input, but our systems constantly interact with the outside world too. How do we secure those interactions data flying back and forth?

Communication security is absolutely paramount HTTPS everywhere. Yes, the book is very clear all data transmitted over the Internet must be encrypted using AHGTPS and the latest version of Transport Layer Security TLS. TLS the underlying protocol, right, the cryptographic protocol that actually ensures secure communication over a network. And a critical warning here something Bob learned the hard way in another CTF story, Oh never try to write your own encryption software.

Oh roll your own cryptot.

His homemade encryption which turned out to be just double base sixty four encoding, not real encryption at all. Oh dear was in less than a minute. It truly underlines why encryption is a job for experts trying to diy it is almost guaranteed to create a massive vulnerability. Use the standard, vetted libraries and protocols.

Good advice. So when we're talking about hardening the entire system, not just the web app part, what about securing things like databases themselves or mobile apps. They have unique challenges.

Absolutely each layer needs attention. The book outlines a multifaceted approach for databases. It's things like hardening the server itself, securing the network connections to it, firewalls and such right and using least privilege for access, for instance, making sure the application connects with a read only account if that's all it needs, not with full database owner or DBO access.

Minimize the app's power over.

The database exactly. Plus regular patching obviously and strict detailed logging are non negotiable, and for mobile apps, different set of concerns. There. You need to think about things like obfuscating and minifying your code to deter reverse engineering, making.

It harder to figure out how the app works.

Correct, And be extremely careful with storing sensitive data in memory, especially on Android where memory isn't always truly wiped after use, potentially leaving data accessible.

Oh interesting nuance.

And critically and sure sensitive data isn't included in unencrypted device backups. That's a common slip up. It's about being paranoid at every single layer.

Okay, paranoia is the theme. What about error messages? You'd think being helpful is good telling users exactly what went wrong, you would think so, but not always the case in security isn't.

No, that's another lesson Bobb learned the hard way during a penetration test.

What happened?

Those polite, detailed error messages that reveal too much about the internal system workings like specific database errors, file paths, server versions, information leakage precisely. They can be absolute gold mines for attackers, allowing them to map out your system and refine their attacks.

So what's the advice.

It's simple, really. For end users, error messages should be generic, something like bad input, please try again, or an error curd please contact support. Keep it vague, yes, save the details. The stack traces all the specifics for your internal logging and debugging systems where only authorized personnel can actually access them. Don't give attackers free information, right.

Log it securely, don't display publicly. Makes sense now, the book really emphasizes integrating security throughout the entire software development life cycle the SDLC.

Yes, that's a core theme.

It's not just an afterthought or a final check but woven into every single phase. That sounds great in theory, but you know, in practice, I've seen teams struggle to make it a continuous process rather than just a rushed checkbox exercise.

At the end, you've hit on a crucial point there. It's easy to say shift left, but harder to do consistently.

So how do we make it real?

It's not just about doing security at the end, it's making it fundamental, from defining explicit security requirements right at the start of a.

Project before coding even begins.

Exactly, performing threat modeling during the design phase. And this doesn't have to be super formal all the time. Even an informal team brainstorming session about what could go wrong can be hugely beneficial.

Just thinking like an attacker for a bit, right.

Then using those AST tools we mentioned, and also software composition analysis or SCA tools ah, the.

Ones that check third party libraries.

Yes, checking your dependencies for known vulnerabilities during coding, and of course rigorous security testing both automated and manual before release.

It sounds like a lot for developers to take on.

It can be, which is why the book encourages you to become a security champion within your team.

What's that involved?

Acting as a kind of liaison with the main security team. You get extra training, maybe increase visibility, and you help translate security needs into practical steps your team can take. You become the go to person for security questions on the team.

So bridging the gap between dev and sec.

Exactly, directly contributing to protecting your colleagues, customers, and the whole organization.

That's interesting that the book also touches on something very current, very rapidly evolving, using AI safely in development.

Oh yeah, the elephant in the room these days.

There's a lot of excitement obviously, but also a lot of potential pitfalls, isn't there?

Absolutely, and it highlights common pitfalls directly. The core advice never allow AI to have agency over your systems or data, meaning.

Don't let it deploy code or change settings automatically.

Precisely, you, the human, need to validate all code written by AI before it goes anywhere near production, runsst and sea tools on it, just like you would your own code.

Treat it like code from a junior dev, your.

Mentoring kind of Yeah, and critically, you need to understand what the AI generated code actually does yourself. Don't just blindly trust it because the AI said it works, just like.

You wouldn't blindly pull a random image from Docker Hub.

Exactly same principle. The human in the loop is still the ultimate gatekeeper for security and quality.

Okay, wow, this deep dive has really shown I think that secure coding isn't just another technical skill to learn.

No, it's more than that.

It's profound mindset shift, isn't it And a continuous.

Journey, definitely continuous.

From understanding these core principles like never assume trust and least privilege to implementing practical steps like parameterized queries and proper secret management, every choice you make as a developer truly has an.

Impact, every single one.

It's really about building quality and trustworthiness into every line of code from the ground up.

And if we connect this to the bigger picture, it raises an important question for you, the listener. In a world that's increasingly reliant on technology, what if every piece of software you interact with, your banking app, your smart home divides the systems at work. What if it was all built with the level of care and the security principles we discussed.

Today, that would be significantly different.

Think about the widespread impact, how much safer our digital lives could actually be. The responsibility really lies with all of us developers, testers, architects, everyone to raise the bar, to keep learning and to proactively engage with these security practices.

That's a powerful thought for you to mull Over. The book makes a great point too that technical debt is almost always security debt and disguise.

Oh that's so true, that outdated library, that unpatched server security risks.

So staying on top of updates and managing dependencies isn't just about efficiency or new features. It's fundamental to robust security, and our source encourages us all to be super rosers, not just in our technical skills, but in our awareness awareness that we as people who build and manage systems are targets.

We have privileged access exactly, and.

So we must protect our own work devices, our accounts are data with extreme vigilance. So maybe a final question for you listening, what new security practice will you try to implement this week in your own projects, even a small one.

And remember you don't have to figure this all out alone. Good point joining security communities like oas, finding mentors, or even just asking your organization's security team for help. These are invaluable steps. As the author says, they are experts hired specifically to help you make them earn their paychecks exactly. Your commitment to these principles, your questions, your efforts, they

That's it for this deep dive into secure coding. We hope this has given you plenty to think about and some actionable insights to apply. Hopefully, so join us next time for another deep dive into a topic that will leave you well informed and probably, as usual, a little surprised. Until then, keep digging,