Okay, so we're diving into the world of secure software development.
And you've given us a ton of info to unpack with these excerpts from 0-0 to
Chris Demain 8-section2.pdf.
Yeah, this stuffs everywhere these days, isn't it?
You know, even if you don't write a line of code yourself, everyone's using software,
and all that software, it needs to be secure.
That's what we're going to dig into today.
By the end of this deep dive, you'll be talking about classes and objects like a pro.
Okay, so no coding boot camp required for our listeners then.
Oh, like so this document jumps into the history of programming languages, which
all be honest, consumer about is exciting is watching paint dry, but it's important stuff.
It starts with machine language personally.
0-0's and 1's just aren't my love language.
Can imagine having to write out code like that.
Yeah, it's a bit of a headscratcher to imagine, right?
I mean, it's the earliest form of programming, but thankfully, it's a lot more well human
readable these days.
I think goodness for a simple language, right?
At least that gave us commands like ADD. It's too pretty bare bones, but hey, it's a start.
Right, baby steps.
But then we made a big leap forward with high level languages, am I right?
Yeah, you got it.
Language is like foretran and cobalt really changed the game.
Suddenly, you didn't have to be a computer whisperer to write code.
And this is where things get juicy from a security angle, because high level languages brought us
this huge shift.
Object-oriented programming.
We call it O-O-P-O-P.
I think that term thrown around a lot.
What makes it so revolutionary?
It sounds like the best thing since sliced bread for software development,
or is that an exaggeration?
You know, exaggeration. Imagine if I don't know, imagine if you had to build a house, right?
And I mean, build it from scratch.
Every single brick, every plank of wood, that's kind of how programming was before O-O-P.
Then O-P came along and it's like someone handed you pre-built walls, doors, windows.
Okay, that makes way more sense than trying to bake code bricks.
Mm-hmm.
So O-O-P is all about like reusable components.
Exactly.
We call this components objects, they're the building blocks.
And they're based on these things called classes, which are like blueprints.
So let's say you're building a social media app.
You might have a class for user that says, okay,
a user needs a username, a password, maybe a profile picture.
Then each new person who signs up, they become an object based on that class,
with their own unique data.
Makes sense. So instead of writing the same code over and over for each new user,
you just create this blueprint and tweak it, saves time, keeps things organized.
You're getting it, and that organization.
That's key for security.
This document we've got, it compares a well-designed program to a well-organized house.
If everything's labeled in its place,
way easier to find what you need, fix problems, keep things secure.
Love that analogy.
Okay.
Okay, so O-O-P, I brought some order to the Wild West of early programming.
What happened next?
That, my friend, is where things get even more interesting.
We're talking Python, C++, Java, languages that took those O-P principles
and really, really ran with them.
They made code cleaner, more efficient.
Suddenly, you could build much more complex software.
It's mind-blowing how these languages evolve to handle such complexity.
You know, it is, isn't it?
But of course, with great power comes great responsibility, right?
Always.
And speaking of responsibility, this document dies into some really crucial concepts
for building secure software.
There's this one part that talks about cohesion and coupling.
Honestly, those words always make me think of like a high school physics class,
which I barely passed.
Can you break those down from me and plain English?
Definitely.
It's actually a lot less intimidating than it sounds.
Think of it like building a car right.
You want all the parts to work together, obviously.
But you don't want one loose screw in the engine to make the whole thing fall apart on the highway.
Okay, terrifying analogy.
Yeah. But I get your point.
So how does that apply to building secure systems?
So cohesion, that's all about how well the different parts
within a module, like one specific part of the system, how well they all work together,
you want high cohesion, like a well organized toolbox, every tool has a purpose, right?
So it's about creating those focus modules, everything in its place.
What about coupling then?
Coupling is more about how much those different modules depend on each other.
Ideally, you want low coupling.
Meaning changes in one module, shouldn't cause a domino effect and mess up a bunch of others.
Going back to the car, you wouldn't want your brakes to stop working if the radio glitches out
would you?
I mean, I really wouldn't.
So high cohesion well defined modules, low coupling clear boundaries between them.
Got it.
But how does that actually make this software more secure?
Think of it this way.
When your code is well organized, high cohesion, low coupling,
it's just easier to understand, easier to test, vulnerabilities.
They're way less likely to slip through the cracks because you can actually see how everything
connects.
Makes sense.
It's like it's easier to find a rogue sock in a perfectly organized drawer than in a huge
messy pile of laundry.
Exactly.
And if a problem does pop up, it's way easier to fix it without breaking something else in the process.
Now there's another concept the stock mint touches on.
Polyonstantiation.
It's mouthful, I know.
Polyinstit what?
Yeah, that one sounds a little intimidating, not gonna lie.
Don't worry, it's not as scary as it sounds.
It's all about keeping sensitive information safe.
Imagine a database, right, with employee information.
Polyonstantiation lets you have multiple versions of that data,
but each version has different security levels.
This is kind of like some people see the basic info.
Others get the top secret stuff.
You got it.
Someone in HR might need access to salary details, but someone in marketing.
Not so much.
It's like having different levels of security clearance for accessing stuff within a system.
Clever. So it helps you control exactly who sees what?
Speaking of accessing control, this document goes deep on developer tools,
starting with integrated development environments.
I think I've heard those called IDEs, right?
What are some super exclusive developer club?
Not exactly.
Think of it as a developer's super power tool box and IDE.
It's a single platform where they can write their code, test it, find the bugs,
you name it, and there's seriously advanced these days that can even help with things like
security analysis.
So it's like the ultimate productivity hack for programmers.
Yeah.
But with all of those features, are there security concerns with IDEs themselves?
Could they be a vulnerability?
You're thinking like a security pro.
That's a great question.
Now IDEs themselves.
Generally, very secure.
This document, though, it points out a potential issue.
It's the plugins, the add-ons that developers sometimes use.
If those aren't from trusted sources, if they're not kept updated,
that's where things can get dicey.
So it's like adding fancy features to your car.
Gotta make sure those additions don't actually make it less safe, right?
It's not just having the tools as using them carefully.
Okay, so let's shift gears a bit.
Let's talk code repositories and version control.
I know there are these platforms get up being one, but I'll be honest,
there are a bit of a mystery to me.
I like to think of them as the collaborative heart of software development.
It's where developers come together to work on projects.
These platforms track every single change made to the code.
It's like imagine multiple people trying to edit the same document at the same time.
Recipes for disaster, right?
Version control.
That's our saving grace.
So it's like having a detailed history of every edit every tweak to a document.
Okay, that makes sense.
But how does this relate to secure software for the average person?
Ah, that is the million dollar question.
So these code repositories, especially the ones that host open source software, they're incredible.
It's all about sharing.
Developers can share code, build on each other's work,
is how innovation happens fast, but of course there's a flip side.
Let me guess open source code isn't always squeaky clean.
Exactly. It's not always intentional, but sometimes vulnerabilities can sneak into open source components.
And if those components end up in other software without anyone checking,
those vulnerabilities, they spread like wildfire.
Yikes, like a bad batch of ingredients ending up in a whole bunch of cakes.
So how do we avoid that recipe for disaster?
That's where the next piece of the puzzle comes in.
Application security testing.
We're talking about rigorously testing software throughout its entire existence.
From the moment it's just an idea, it's like having a dedicated team of taste testers,
making absolutely sure that software is safe to use, no nasty surprises.
Okay, so we got our taste testers. What are they actually doing?
The document mentions a bunch of different testing methods, but honestly it's an alphabet soup.
Ah.
Sask, date, dastery, it dastery, it what does it all mean?
Right, it's like a secret code, isn't it?
Don't worry, I'm here to decode.
Please do.
Okay, so sask that stands for static application security testing.
It's all about examining the source code itself, like looking for weaknesses in the blueprint before you even start building.
So no fancy software simulations just looking at the raw code.
Pretty much, it's a very meticulous process,
analyzing the code, line by line to find any security flaws,
and then you've got dast dynamic application security testing.
This one's more like taking the software for a spin, seeing how it behaves in the while.
So if sask is checking the recipe, dast is tasting the final dish.
Exactly, great analogy.
And then there's IASTS or interactive application security testing.
It's like having a security camera running inside your software 247,
watching every little thing that happens.
Okay, so it's the most, I don't know, vigilant of the three.
You could say that.
IASTS gives you real-time feedback tells you exactly where a vulnerability might be hiding in the code.
And there's one more acronym to add to the mix, even though it's not a testing method itself,
SCA or software composition analysis.
It's all about securing the software supply chain.
Okay, this is where I get lost.
Supply chain.
Remember, we were talking about those open source components and the risks they can bring?
That's where SCA comes in.
These tools scam through the code and identify every single third-party library,
every component, imagine it like a background check for your software.
Making sure none of the ingredients are expired or something.
Exactly. SCA helps make sure that everything's on the up and up.
That you're using those open source components safely and legally.
It's all connected secure code, secure component, secure systems.
It's a team effort.
Yeah, sounds like it's like building a house.
You know, you need strong walls, a sturdy roof, a good security system.
You can't just focus on one thing.
Exactly. Building secure software.
It's not a one-and-done thing.
It's something you gotta think about every step of the way from the initial design to the ongoing
maintenance.
And it's not just on the developers.
Everyone involved has a role to play and making sure things are secure.
This deep dive has definitely given me a whole new appreciation for how complex this all is.
And how important it is. We've gone from like the birth of programming languages to
testing and everything in between.
It's clearly not just for techies anymore.
You got it. We all rely on technology every single day.
So the more we know about how it works, the potential risks, the better choices we can make.
It's all about staying informed and advocating for systems that are, well,
systems we can actually trust.
Couldn't agree more.
Well, thank you so much for joining me for this deep dive.
This has been an incredible conversation.
My pleasure. I'll always happy to geek out about secure software.
And to everyone listening, thanks for sticking with us on this journey into the world of
secure software development.
Remember, a little knowledge goes a long way.
Until next time, stay curious out there.