WEBVTT
00:00:00.239 --> 00:00:06.080
Let me tell you why security keeps failing in otherwise good software.
00:00:06.320 --> 00:00:08.560
It's not because developers don't care.
00:00:08.880 --> 00:00:11.279
It's not because they don't know enough.
00:00:11.839 --> 00:00:17.280
It's because no one ever clearly said what security actually means.
00:00:17.600 --> 00:00:21.760
And if security isn't explicit, that means it's optional.
00:00:22.399 --> 00:00:26.239
Hi, I'm Tanya Jenka, also known as SheHacksPurple.
00:00:26.480 --> 00:00:33.439
Welcome to DevSecStation, a podcast for software developers who want to build more secure software.
00:00:33.679 --> 00:00:43.679
In each episode, I'll share a short practical lesson about secure coding, software security, and how to build safer systems without slowing development down.
00:00:43.920 --> 00:00:47.600
You can jump in at any episode, at any time.
00:00:48.000 --> 00:00:49.840
No homework required.
00:00:50.560 --> 00:00:53.359
This episode is sponsored by MAISE.
00:00:53.600 --> 00:01:03.759
One of the biggest problems in security right now is that every vulnerability or cloud scanner says everything is critical, and honestly, no one has time for that.
00:01:04.000 --> 00:01:15.359
MAZES uses AI agents to investigate vulnerabilities in context, so you can focus on the issues that are actually exploitable in your environment and not just theoretically scary.
00:01:15.760 --> 00:01:27.200
Their AI agents also generate and prioritize fixes that knock out multiple vulnerabilities at once, which is honestly the kind of scaling that security teams really need right now.
00:01:27.439 --> 00:01:32.640
Learn more about maze at mazehq.com slash devsec.
00:01:33.040 --> 00:01:43.599
If you've ever shipped a feature and later been told this isn't secure, without anyone quite being able to explain why this episode was made for you.
00:01:44.239 --> 00:01:50.799
Security requirements are one of the most underrated tools in secure software development.
00:01:51.120 --> 00:01:53.760
And also one of the least understood.
00:01:54.000 --> 00:01:59.680
When most people hear requirements, they think bureaucracy.
00:02:00.000 --> 00:02:07.760
But security requirements aren't politics or policies, they aren't audits, they're not compliance checklists.
00:02:08.000 --> 00:02:18.159
What they should be is simple, clear, testable statements about how your software must behave to be considered safe and secure.
00:02:18.400 --> 00:02:21.599
If something matters, we write it down, right?
00:02:22.159 --> 00:02:26.400
And if we don't write it down, it's just wishful thinking.
00:02:27.280 --> 00:02:30.960
Here is a scenario that I see all the time.
00:02:31.520 --> 00:02:33.759
A feature ships and it works.
00:02:33.919 --> 00:02:34.479
Tests pass.
00:02:34.800 --> 00:02:38.960
Woo! Later, someone raises a security concern.
00:02:39.199 --> 00:02:42.719
Perhaps authentication wasn't enforced consistently.
00:02:42.960 --> 00:02:48.240
There's errors leaking sensitive information, and then the sensitive information is logged.
00:02:48.319 --> 00:02:49.120
Oh no.
00:02:49.520 --> 00:02:55.759
And the dev team says, honestly, well, we didn't know we weren't supposed to do that.
00:02:55.919 --> 00:02:57.120
They're not wrong, right?
00:02:57.280 --> 00:03:01.280
No one ever said this feature must enforce authentication at every entry point.
00:03:01.439 --> 00:03:03.840
There was nothing explicit anywhere.
00:03:04.080 --> 00:03:09.439
Or this data must never be logged, and then it explains what data it is.
00:03:10.000 --> 00:03:13.439
So developers did what developers always do, right?
00:03:13.520 --> 00:03:15.039
They filled in the gaps.
00:03:15.360 --> 00:03:18.639
And security, it got lost along the way.
00:03:18.800 --> 00:03:20.400
So how do we fix this?
00:03:21.039 --> 00:03:27.520
Well, a bad approach is assuming everyone has the same idea of what secure means.
00:03:27.840 --> 00:03:29.759
Because they definitely don't.
00:03:30.000 --> 00:03:33.120
And if you listen to this podcast regularly, you know that.
00:03:33.360 --> 00:03:38.639
And when expectations are implied, that means security is optional.
00:03:38.719 --> 00:03:40.000
And we can't have that.
00:03:40.240 --> 00:03:46.240
So a better approach would be hoping code review or security tools will just catch this issue later.
00:03:46.479 --> 00:03:54.960
And don't get me wrong, this helps, but it's reactive, it's expensive, and it's frustrating, and it misses stuff.
00:03:55.280 --> 00:04:02.879
The best approach we can do is writing security requirements and making them a part of the formal project requirements document.
00:04:03.039 --> 00:04:06.960
When expectations are crystal clear, developers don't have to guess.
00:04:07.120 --> 00:04:09.840
They can build the right thing the first time.
00:04:10.639 --> 00:04:14.719
So you might be thinking, what do security requirements actually look like, Tanya?
00:04:15.360 --> 00:04:20.800
Security requirements don't need to be long or complicated, but they do need to be specific and clear.
00:04:20.959 --> 00:04:24.639
So let me give you a whole bunch of examples because I love examples.
00:04:24.800 --> 00:04:27.279
Okay, example one, authentication.
00:04:27.519 --> 00:04:31.680
This endpoint must require authentication on every request.
00:04:31.920 --> 00:04:33.519
Example authorization.
00:04:33.839 --> 00:04:37.439
Only users with the admin role may perform this action.
00:04:38.000 --> 00:04:40.399
Input validation or input handling.
00:04:40.800 --> 00:04:45.199
All user supplied input must be validated before use.
00:04:45.759 --> 00:04:46.879
Data protection.
00:04:47.120 --> 00:04:50.800
This sensitive data must never be logged or returned in error messages.
00:04:50.959 --> 00:04:54.720
And then sensitive data is defined clearly elsewhere.
00:04:55.040 --> 00:04:56.800
Example, error handling.
00:04:57.040 --> 00:05:02.000
Errors must return a generic message to the client and log details internally.
00:05:02.560 --> 00:05:04.399
See how these aren't policies?
00:05:04.639 --> 00:05:07.839
They're clear and specific instructions.
00:05:08.079 --> 00:05:12.160
Plus, each one is testable and obviously we like that, right?
00:05:12.800 --> 00:05:17.279
If you do just one thing after this episode, please do this.
00:05:17.600 --> 00:05:23.120
Add security requirements to one feature or one ticket that you're working on.
00:05:23.360 --> 00:05:26.720
And here is how to do it without slowing things down too much.
00:05:27.040 --> 00:05:32.399
Step one, pick a feature, an endpoint, a change, something you're actively working on.
00:05:32.560 --> 00:05:36.959
Step two, write two or three security requirements for it.
00:05:37.279 --> 00:05:40.399
Think in terms of who can access this?
00:05:40.639 --> 00:05:42.800
What inputs should it be accepting?
00:05:43.040 --> 00:05:46.720
How it handles that data, what happens when it fails.
00:05:46.879 --> 00:05:48.240
That's a really important one.
00:05:48.480 --> 00:05:52.800
Okay, now step three, put those requirements somewhere visible.
00:05:53.040 --> 00:06:03.199
In a ticket, in the README, in the PR description, or better yet, add it to the project requirements if that's an option for you, if that's something that you have the power to do.
00:06:03.519 --> 00:06:10.480
So now the security on this feature is no longer guesswork, it's clear, it's precise, and it's testable.
00:06:10.959 --> 00:06:16.959
Security requirements aren't about control, they're about clarity, and clarity is kindness.
00:06:17.360 --> 00:06:21.279
When developers know what's expected, then they can meet those expectations.
00:06:21.680 --> 00:06:23.920
And when we don't know, then we improvise.
00:06:24.240 --> 00:06:28.639
And improvisation is where vulnerabilities are born, right?
00:06:29.199 --> 00:06:31.759
Thanks for listening to DevSecStation.
00:06:32.000 --> 00:06:37.360
If you enjoyed this episode, please subscribe, share it with a friend, or leave a review.
00:06:37.519 --> 00:06:39.920
It helps more people discover the show.
00:06:40.160 --> 00:06:45.199
If you'd like to learn more, I'm Tanya Janka, also known as SheHacksPurple.
00:06:45.360 --> 00:06:49.040
And I teach secure coding training for software developers.
00:06:49.279 --> 00:06:52.480
You can find me online at shehackspurple.ca.
00:06:53.199 --> 00:06:54.959
Thank you for being here.
00:00:00.239 --> 00:00:06.080
Let me tell you why security keeps failing in otherwise good software.
00:00:06.320 --> 00:00:08.560
It's not because developers don't care.
00:00:08.880 --> 00:00:11.279
It's not because they don't know enough.
00:00:11.839 --> 00:00:17.280
It's because no one ever clearly said what security actually means.
00:00:17.600 --> 00:00:21.760
And if security isn't explicit, that means it's optional.
00:00:22.399 --> 00:00:26.239
Hi, I'm Tanya Jenka, also known as SheHacksPurple.
00:00:26.480 --> 00:00:33.439
Welcome to DevSecStation, a podcast for software developers who want to build more secure software.
00:00:33.679 --> 00:00:43.679
In each episode, I'll share a short practical lesson about secure coding, software security, and how to build safer systems without slowing development down.
00:00:43.920 --> 00:00:47.600
You can jump in at any episode, at any time.
00:00:48.000 --> 00:00:49.840
No homework required.
00:00:50.560 --> 00:00:53.359
This episode is sponsored by MAISE.
00:00:53.600 --> 00:01:03.759
One of the biggest problems in security right now is that every vulnerability or cloud scanner says everything is critical, and honestly, no one has time for that.
00:01:04.000 --> 00:01:15.359
MAZES uses AI agents to investigate vulnerabilities in context, so you can focus on the issues that are actually exploitable in your environment and not just theoretically scary.
00:01:15.760 --> 00:01:27.200
Their AI agents also generate and prioritize fixes that knock out multiple vulnerabilities at once, which is honestly the kind of scaling that security teams really need right now.
00:01:27.439 --> 00:01:32.640
Learn more about maze at mazehq.com slash devsec.
00:01:33.040 --> 00:01:43.599
If you've ever shipped a feature and later been told this isn't secure, without anyone quite being able to explain why this episode was made for you.
00:01:44.239 --> 00:01:50.799
Security requirements are one of the most underrated tools in secure software development.
00:01:51.120 --> 00:01:53.760
And also one of the least understood.
00:01:54.000 --> 00:01:59.680
When most people hear requirements, they think bureaucracy.
00:02:00.000 --> 00:02:07.760
But security requirements aren't politics or policies, they aren't audits, they're not compliance checklists.
00:02:08.000 --> 00:02:18.159
What they should be is simple, clear, testable statements about how your software must behave to be considered safe and secure.
00:02:18.400 --> 00:02:21.599
If something matters, we write it down, right?
00:02:22.159 --> 00:02:26.400
And if we don't write it down, it's just wishful thinking.
00:02:27.280 --> 00:02:30.960
Here is a scenario that I see all the time.
00:02:31.520 --> 00:02:33.759
A feature ships and it works.
00:02:33.919 --> 00:02:34.479
Tests pass.
00:02:34.800 --> 00:02:38.960
Woo! Later, someone raises a security concern.
00:02:39.199 --> 00:02:42.719
Perhaps authentication wasn't enforced consistently.
00:02:42.960 --> 00:02:48.240
There's errors leaking sensitive information, and then the sensitive information is logged.
00:02:48.319 --> 00:02:49.120
Oh no.
00:02:49.520 --> 00:02:55.759
And the dev team says, honestly, well, we didn't know we weren't supposed to do that.
00:02:55.919 --> 00:02:57.120
They're not wrong, right?
00:02:57.280 --> 00:03:01.280
No one ever said this feature must enforce authentication at every entry point.
00:03:01.439 --> 00:03:03.840
There was nothing explicit anywhere.
00:03:04.080 --> 00:03:09.439
Or this data must never be logged, and then it explains what data it is.
00:03:10.000 --> 00:03:13.439
So developers did what developers always do, right?
00:03:13.520 --> 00:03:15.039
They filled in the gaps.
00:03:15.360 --> 00:03:18.639
And security, it got lost along the way.
00:03:18.800 --> 00:03:20.400
So how do we fix this?
00:03:21.039 --> 00:03:27.520
Well, a bad approach is assuming everyone has the same idea of what secure means.
00:03:27.840 --> 00:03:29.759
Because they definitely don't.
00:03:30.000 --> 00:03:33.120
And if you listen to this podcast regularly, you know that.
00:03:33.360 --> 00:03:38.639
And when expectations are implied, that means security is optional.
00:03:38.719 --> 00:03:40.000
And we can't have that.
00:03:40.240 --> 00:03:46.240
So a better approach would be hoping code review or security tools will just catch this issue later.
00:03:46.479 --> 00:03:54.960
And don't get me wrong, this helps, but it's reactive, it's expensive, and it's frustrating, and it misses stuff.
00:03:55.280 --> 00:04:02.879
The best approach we can do is writing security requirements and making them a part of the formal project requirements document.
00:04:03.039 --> 00:04:06.960
When expectations are crystal clear, developers don't have to guess.
00:04:07.120 --> 00:04:09.840
They can build the right thing the first time.
00:04:10.639 --> 00:04:14.719
So you might be thinking, what do security requirements actually look like, Tanya?
00:04:15.360 --> 00:04:20.800
Security requirements don't need to be long or complicated, but they do need to be specific and clear.
00:04:20.959 --> 00:04:24.639
So let me give you a whole bunch of examples because I love examples.
00:04:24.800 --> 00:04:27.279
Okay, example one, authentication.
00:04:27.519 --> 00:04:31.680
This endpoint must require authentication on every request.
00:04:31.920 --> 00:04:33.519
Example authorization.
00:04:33.839 --> 00:04:37.439
Only users with the admin role may perform this action.
00:04:38.000 --> 00:04:40.399
Input validation or input handling.
00:04:40.800 --> 00:04:45.199
All user supplied input must be validated before use.
00:04:45.759 --> 00:04:46.879
Data protection.
00:04:47.120 --> 00:04:50.800
This sensitive data must never be logged or returned in error messages.
00:04:50.959 --> 00:04:54.720
And then sensitive data is defined clearly elsewhere.
00:04:55.040 --> 00:04:56.800
Example, error handling.
00:04:57.040 --> 00:05:02.000
Errors must return a generic message to the client and log details internally.
00:05:02.560 --> 00:05:04.399
See how these aren't policies?
00:05:04.639 --> 00:05:07.839
They're clear and specific instructions.
00:05:08.079 --> 00:05:12.160
Plus, each one is testable and obviously we like that, right?
00:05:12.800 --> 00:05:17.279
If you do just one thing after this episode, please do this.
00:05:17.600 --> 00:05:23.120
Add security requirements to one feature or one ticket that you're working on.
00:05:23.360 --> 00:05:26.720
And here is how to do it without slowing things down too much.
00:05:27.040 --> 00:05:32.399
Step one, pick a feature, an endpoint, a change, something you're actively working on.
00:05:32.560 --> 00:05:36.959
Step two, write two or three security requirements for it.
00:05:37.279 --> 00:05:40.399
Think in terms of who can access this?
00:05:40.639 --> 00:05:42.800
What inputs should it be accepting?
00:05:43.040 --> 00:05:46.720
How it handles that data, what happens when it fails.
00:05:46.879 --> 00:05:48.240
That's a really important one.
00:05:48.480 --> 00:05:52.800
Okay, now step three, put those requirements somewhere visible.
00:05:53.040 --> 00:06:03.199
In a ticket, in the README, in the PR description, or better yet, add it to the project requirements if that's an option for you, if that's something that you have the power to do.
00:06:03.519 --> 00:06:10.480
So now the security on this feature is no longer guesswork, it's clear, it's precise, and it's testable.
00:06:10.959 --> 00:06:16.959
Security requirements aren't about control, they're about clarity, and clarity is kindness.
00:06:17.360 --> 00:06:21.279
When developers know what's expected, then they can meet those expectations.
00:06:21.680 --> 00:06:23.920
And when we don't know, then we improvise.
00:06:24.240 --> 00:06:28.639
And improvisation is where vulnerabilities are born, right?
00:06:29.199 --> 00:06:31.759
Thanks for listening to DevSecStation.
00:06:32.000 --> 00:06:37.360
If you enjoyed this episode, please subscribe, share it with a friend, or leave a review.
00:06:37.519 --> 00:06:39.920
It helps more people discover the show.
00:06:40.160 --> 00:06:45.199
If you'd like to learn more, I'm Tanya Janka, also known as SheHacksPurple.
00:06:45.360 --> 00:06:49.040
And I teach secure coding training for software developers.
00:06:49.279 --> 00:06:52.480
You can find me online at shehackspurple.ca.
00:06:53.199 --> 00:06:54.959
Thank you for being here.
