Access the full text logs of this transmission for compliance and review purposes.
Actual (00:00)
Welcome to Status Secure. In episode three, we discussed the inherent friction of the tech sector, the collision between software development velocity and infrastructure security. Devs are paid to ship code, security is paid to mitigate risk. Today we’re getting tactical. How does a security team actually secure the software factory without shutting down the assembly line? CISO if the CI CD pipeline is the new perimeter, how is InfoSec supposed to defend it?
when the code changes 50 times a day.
The CISO (00:29)
I’m an old school developer and so I understand developers. They just want to they just want to hurry make their code changes and get it out right and then work on the next bug or the next functionality with the next release. And and you know. CDC I is very good for that developers. You know love that the problem is old school.
What happens is the developer makes their changes, they compile, and now they’re in QA. And then after QA approves, then they do a security scan check at the end, which is too late. Which is too late. So security needs to change where they’re interacting with development. Instead of being at the end,
they have to move to the beginning, right? So they need to move to the left. So the, you know, I remember it was like, okay, security is just one of those things on my checklist as a developer to get past. So it was just a gate, right? So that way I get my code into production, right? But you can’t do that anymore. know, security needs to work really closely with development.
And that shift has to happen at the very beginning.
Actual (01:43)
got it. You know what this reminds me of when you say, we need to shift left is, when I was in the military, we had, and on the team, we had this training that was left with bang training. And the whole idea of it was to be aware, to learn awareness, learn some science, learn a little bit of, you know, body language and some psychology on behavior and mannerisms. And to be able to see sort of the battlefield environment.
and to have the, maybe a good educated guess on when things are about to happen. What has to take place kind of left of the bang so we can predict it, so we can stop it before it happens. And so for, would imagine if I’m listening to this, yeah, let’s move left and like, let’s stop, you know, a security threat from happening before it ever happens. And that can sound vague, like, okay.
that’s maybe a little bit ethereal or like assumptive. And so for example, something that we did down range was yes, we want to practice all of those things where we’re being aware and we’re keeping our eyes open and whatnot. However, we added tools. So our little firebases would have these, they would install these towers with cameras on them so that we can actually see.
when things are going to happen before they happen, or you would have the bigger basis would have big balloons in the sky. So you can see even further. And those were just maybe a, an actionable item that’s added to the left of bank sort of a mindset. And so what we’re doing in this episode is we want to give a set of actionable tools to help our security teams be able to see left of bank.
And so like best practice, let’s implement these towers, let’s implement these balloons and get these cameras up. So now you have better visibility so you can better protect your assets on the ground. And so on that note, let’s break this down into actionable intelligence. What are the first major blind spots a security team faces when looking at a development team’s code base? And what would be, what would be the exact tool that could fix it?
The CISO (03:43)
Hey, I would say, you know, the security needs to get really close with the development team because now you’re looking to put things in to, you know, in into their, um, into their process, right into their, if you’re familiar, you know, their SDLC, their software development life cycle. So, you know, there’s a lot of things that they do during their process. Like one is, you know,
I would say, at the same time, educate your developers. One thing is there’s OWASP, OWASP training, which is your open web software. That’s pretty common now. So all of your developers should take that. But one of the things they talk about there is hard coding, your secrets. I couldn’t tell you how many times I’ve seen a developer hard code credentials.
that’s one of the things that you can’t do developers like we’ll leave API keys, database passwords, AWS tokens directly in the source code. Okay. So now if that code’s in the repository, it’s available to everyone who has access to that repository or, or a malicious actor who gets into the repository and it’s open and I’ve seen open text, you know, credentials. So that’s one of the things that security should right away.
work with the developers, no hard-coded credentials anywhere. Next is automated secret scanning. So you’ve got, I can give you some examples of tools, but there’s plenty. You can just Google or ask AI these days. But you have to deploy them. And then what it does, these tools will actually look to see what the developers
you know, what the code is before it gets pushed into the repository. So it’ll scan for, you know, for vulnerabilities, for bad coding practices, those kinds of things. And that way, you know, it doesn’t even get into the build, into the software build. A lot of developers will use third party libraries. GitHub is a really popular one.
right, with developers. And unfortunately, because it’s open source, you don’t know what’s in there, right? You’d probably be surprised to know that there’s full of like CVEs, which are known vulnerabilities in those code repositories. So if you don’t know, especially companies that hire like contractor developers, and they have admin rights, right? They’ll pull down all kinds of libraries and you don’t know what’s now, you now don’t know what kind of…
vulnerabilities are in your code because it came with the contractor and they write their code and then they leave. And now there’s this vulnerability that’s hidden in your code that you weren’t aware of. Software composition analysis, again, you can take a look to see what tools are available. But these are like SCA tools. They scan dependencies during the build. So if there’s an outdated library with a CVE, it’ll
flag it, and really good tools will actually stop the developer from even being able to compile and push it to an environment, even to dev or stage or production. So those are the things that you should really start looking at for your development team as a security person.
Actual (07:01)
Got it. And so we’ll start with some of these, these categories here. Do you have examples, even just like some quick ones off the top of your head of tools that they can use. So, you know, start with the automated secrets and then the third party library software composition analysis. Could you just provide us some examples?
The CISO (07:20)
Yeah, I think, get Guardian, Chuffle Hog, Sing, Dependabot. I mean, there’s so many, there’s so many, like, if you go to security conferences, you’ll see a ton of new vendors popping up all the time. So, you know, if you want to see what’s the latest, what, you know, other people are using, you know, you need to talk to people who are in the, you know,
who are using them and get their opinion. I can give you all kinds of stuff, but every environment is different. Every culture is different. You got to find the one that actually works and that the developers will adopt. Because if you put it in and they don’t use it or they don’t like it and they make you take it out, it doesn’t matter.
Actual (08:01)
Got it, so we’re not telling them to stop coding. The tool’s just pointing them to safe versions of the code. But what about the environment that the code lives in? What happens when the code is safe but the server it’s running on is completely exposed?
The CISO (08:18)
Well, that’s kind of outside of the developer. That’s more infrastructure. Because developers don’t actually go into a data center and put servers into the rack. That’s more infrastructure. Unless you’re a small company, right? Because the smaller your company, the more hats a person will wear. So if your development team is also your infrastructure team,
You know, they just, they’re gonna have to learn. They’re gonna have to learn to do all the vulnerability scanings, all the things we’ve talked about before. Because if they put flawed code in to that, like everybody’s doing cloud. So if they put flawed code into the cloud environment, it’s now flawed, right? And so you can go and get,
you know, the tools for environment, for the infrastructure, for the cloud. Like there’s tools for development and then there’s tools for the environment that the code goes into. And those are different.
Actual (09:10)
Yeah, so let’s,
yeah, and on that note, let’s say the developer wrote a secure app, but they accidentally wrote a script that puts it in an Amazon S3 bucket with public rewrite access. How does InfoSet catch that before it goes live and becomes a front page data breach?
The CISO (09:27)
⁓ yeah, yeah. So this is cloud configuration. Now we’re talking about vulnerability management. So your infrastructure needs to be securely configured. before, let’s say they’re using AWS or Azure.
There’s tools out there that can scan the cloud environment. It catches open ports or public storage buckets, forces a fix before the infrastructure even exists. mean, cloud’s been around now for a while. So there’s a lot of tools. Definitely the scanning, which is part of vulnerability management scanning for infrastructure.
I think that container scanning and the… Those have been around. There’s what’s called like software bill of materials, which you deploy and then the container for the vulnerabilities and automatically generates, like kind of like what configuration you need. This gives security a…
exact immutable kind of receipt of every component inside the software before it leaves the building. But basically, these are like, if you’re going to put things on the cloud, you know, you really need to always know what the configuration is. I’ll give you an example. If you do, if you do like, I think if you do like Google Analytics, and you put it on,
you know, your portal that’s now sitting on AWS or Azure and your Google Analytics, there’s a configuration that comes as default where it sends the analytics to Google. If you don’t scan and aren’t familiar with that configuration and you don’t put it in as a rule to change the setting to no, don’t send your data to Google. It will just…
It will send whatever data the developer, they put their application there, but now their web app there, and now that data is being sent to Google. So it’s very important that you understand the configuration. And again, you have to have strong configuration management and vulnerability management working together.
Actual (11:33)
So for the marching orders for InfoSec leaders listening this week, you can’t just buy four tools, drop them on engineering director’s desk and expect them to be like, cool, thank you. So how do we deploy this without starting an internal civil war between security and developers?
The CISO (11:51)
Well, you you can’t do it all. That’s one of the things that security has to understand because some, I think some security practitioners, you know, they’re like, no, right? They’re, you know, they’ve been, they’ve been branded as the team of no, and that’s not how security needs to function now. So don’t do it all. You know, start with the most important, the high risk one, which is secret scanning.
That sounds like critical, leaked credentials, and is the easiest to implement, and is probably the most transparent to the developers. Integrate into their workflow. I talked about this before. It shouldn’t change the way your developers work. It should just work in parallel with them. So don’t make your developers log into a separate security dashboard.
They should still continue to use their tools. It’s just now those tools have additional integration to security tools that are transparent and hidden to the developer. If a vulnerability is found, the tool should automatically open a ticket in the developer’s backlog to take care of it. It should be seamless. So that way, it’s
You know, you’re, say this all the time. You’re enabling the developers, you’re enabling the business, right? Security should be very transparent and seamless. So that way it’s the path of least resistance. Because if, if every time I code something and all of a sudden security just blocks me and now I stop my work until I can get through that blockage, I’m not going to like security very much. I’m going to miss my timeline. I’m going to have all kinds of issues.
Actual (13:29)
That makes sense. Yep. So, you know, the perimeter is no longer just your network. It is the automated factory line that compiles your product. So InfoSec cannot be a roadblock at the end of the line. You must become the automated guardrails that keep the train on the tracks. Kind of like bowling. If you’re not very good at bowling, you put up the rails. Anyways, mission success is about asset integrity. So let’s execute to the standard and we’ll see you guys next week.
