Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
/software security: from protected to productive
53 Plays4 months ago
This week, James and Aaron explore modern security challenges and opportunities with Tyler Welton, a 15+ year InfoSec expert. They discuss open-source vulnerabilities, confusion attacks in third-party tools, and how security products can help developers stay productive while staying protected.
Recommended
Transcript
Challenges in Security Fixes
00:00:03
Speaker
Discovering is easy. Fixing is hard. Fixing is really hard. It's a hard in a way that I think most security people, I'm not knocking on my security folks, but we don't understand. I've been grateful to work around a lot of developers and understand really the complexity of a lot of that problem. A lot of the solution needs to be distilling that down, answering those questions way quicker, right? Am I vulnerable to this? Yes or no. Do I have the information in front of me that I can make that decision and develop?
00:00:32
Speaker
And so my hope is that that evolves.
Podcast Introduction
00:00:40
Speaker
Welcome to the forward slash where we lean into the future of IT. t I'm your host Aaron Chesney with my beautiful co-host James Carmen.
Expert Introduction: Tyler Welton
00:00:49
Speaker
Today we welcome into the fold Tyler Welton. Tyler Welton has been in information security for 15 plus years serving in roles as engineer, pen tester, chief security officer and architect.
00:01:02
Speaker
He has pioneered new attacks against application development systems, co-written the OWASP CICD standard, and has spoken at conferences such as DEFCON and Bsides about his work. Tyler is the founder and CEO of Untamed Theory and principal security architect at Build Technologies.
Importance of Supply Chain Security
00:01:25
Speaker
And he's going to be talking to us today about supply chain security. Welcome.
00:01:32
Speaker
however Thank you so much. It's great to be with you. <unk>t not to have it you know yeah Speaking of security, I recently discovered I was a victim of identity theft. I was walking down the street and saw someone that looked just like me.
00:01:47
Speaker
wow
00:01:53
Speaker
See it, the oof is, uh, my highest regard for that joke. That's right. Yeah. Yeah. Well, that's the, you know, that's the whole goal of the joke is, is for the groan, the goth, uh, or the eye, the best is the eye roll. Um, it's very nice intro though. Thank you. Well, to get back on time, you know, one of the things that I thought was interesting after we talked, um,
00:02:20
Speaker
Yes, what was it two days ago? um I saw in the s SC times, there was actually an article about open source security. And I thought that was that was kind of interesting that, you know, we're, we're on point with this. yes And that's it's the and forefront of of the press. So ah what can you tell us about what a supply chain attack actually is? Yeah, I mean,
00:02:49
Speaker
You know, my focus has been a lot around specifically software supply chain, right? And the software development lifecycle and what it means to attack the software development lifecycle. And then watching as real threats have sort of evolved and adapted their techniques against that. ah Supply chain more generally is really, you know, attacking any component of a supply chain, whether that's a physical supply chain or a software supply chain. In our case, right we're talking about all the components and the entire process from code sitting on a developer's machine to being built, having third-party libraries compiled, and and to build in some sort of artifact that then goes and runs in a production environment, potentially you know touching data, ah dealing with encryption keys, ah and all the things that a software does. so it's really
00:03:44
Speaker
the software supply chain is specifically what I'm talking about. And we can dive into any part of that. um But, you know, the software development lifecycle is the target. So basically anything in that development process that can get injected into your application on purpose like as as part of your build process and in getting it out the door. Yeah, absolutely. any Anything that could get injected into the software. And then there's there's layers to it. So the software itself could be the target where I want to affect the software in some way. ah But then a lot of the work that I did around the CICD systems, and you mentioned the OWASP top 10, which is
00:04:29
Speaker
It's an open web application security project. They kind of drive the standards around web security, web app security. And a lot of the work I did around that was actually attacking the software supply chain itself. So using the tools in the supply chain that we use to build systems and targeting those and leveraging those against companies that are using them.
Detection of Supply Chain Attacks
00:04:55
Speaker
Yeah. So what are, what are some of the, like, what would one of these attacks kind of, uh, look like? Like, how would you know that you're, you're being a victim of one of these types of attacks? Yeah, that's a great question. Uh, I think there are some standards, you know, hopefully the worst case scenario is you figure it out as it's happening or after it's happening. Right. That's that's your victim at that point.
00:05:26
Speaker
And that might be through signs of data exfiltration, large amounts of data leaving your environment. right and But what's difficult right is that the tooling really, it's exploiting flaws in the tooling that otherwise don't have security monitoring in place for them.
Supply Chain Attack Techniques
00:05:43
Speaker
I'll give you an example. and And they're getting better at this. But one of the areas of focus that I really dove into and and helped develop was what's called poison pipeline execution. That was the style I spent a lot of time on. And then that made it into the OWASP top 10 CICD list. But what that is, is using change requests as a means of entry right into software. So I would open malicious PRs. Now I was doing this as a is a white hat.
00:06:14
Speaker
tester right for research purposes, but ah opening a malicious PR and then knowing that that pull request would hold downstream instructions for maybe like a GitHub action or a Jenkins server to run some stuff on. And then I would leverage that. right And the it's one of those things, not a lot of Jenkins servers had monitoring solutions on them. right How many are really watching the traffic on their Jenkins server other than maybe you know making sure it doesn't get full or or something like that. But as far as a critical piece of infrastructure, you know detecting that to your question, it's difficult unless you're already watching the traffic on that ah box or on that server if you're self-hosting it. you know You're not really looking for for malicious requests. And what does a malicious request even look like? So I know that's not really an answer but um to to what do we do to prevent. But in that specific instance,
00:07:11
Speaker
it comes down to kind of basic monitoring of your systems and and and understanding what it's but what normal behavior is supposed to look like, right? So if you're if you're doing enterprise software at a company, most likely you would be internal to to do these kinds of attacks. So this would be kind of like ah something that's coming from the inside, but open source, that's not the case, right? Cause you've got, you've got pull requests coming in from anywhere. Exactly. I mean, that's exactly it. And imagine that you are trying to be a steward of the development world, right? And you are wanting to contribute part of what your company is building back to the open source
Open Source Project Vulnerabilities
00:07:55
Speaker
community. I mean, how many companies are doing that? Lots, right? Netflix. So how many people use Netflix utilities in there? So it's a common thing.
00:08:06
Speaker
but And of course, you want to do that first line of checks to linting checks or making sure there's basic tests run correctly before a human gets involved to even review this open source pull request. But a lot of times those tools are run on internal infrastructure. you know And that's where it gets really problematic. And the systems that are GitHub, right they've gotten a lot better in the in the last two to three years about some of their controls.
00:08:33
Speaker
But a lot of times those tests were being run on internal private servers, sometimes the same server like Jenkins servers or um you know GitHub actions or or some kind of runner right um that had access to all sorts of stuff. um And so if the attacker was able to compromise that, they now through an open source project had access to all sorts of internal infrastructure pieces.
00:09:02
Speaker
which is scary, you know? Not as scary as the one thing you had mentioned before when we talked about this, I associate it with like the long con yeah of taking over an open source project. Can you you explain how that one works a little bit?
Case Study: XE Utils Library Attack
00:09:23
Speaker
Yeah, the XE utils hack comes to mind, right? where ah This library, there was a core foundational library in most Linux distributions, ah was was Target. and What made this one unique and really pops out to me is not just the technical hack, right? I love technical hacks. I'm a hacker, i so I can dive deep on a lot of the tech pieces of this. But I think what's so interesting about this is the long con is the best way to say it. ah
00:09:56
Speaker
it took almost three years to pull off and it started with, so it was pure social engineering. The foothold in the door was pure social engineering. It was, contributed so the attacker set up a few things and we don't know if it was one, probably a team we would suspect, ah highly suspected it was a nation state actor, but opened a ah GitHub user, started making active, legitimate requests and ah contributions to this open source project over a series of three years. And as time went on, they were making and being very helpful, like legitimately contributing to this project as a means of gaining trust. right And in in addition to that, some smaller sub-accounts were also contributing or at least participating in the conversations.
00:10:51
Speaker
And they got ultimately that accumulated in this attacker getting ah co-management of this open source project. They sort of convinced the owner, you know, you've been doing this a long time, right? You probably, I know it's hard, you know, they'd have some of these sub-accounts complaining about the response time of the maintainer. And then through that, they were able to ah convince, hey, so-and-so over here, I think,
00:11:20
Speaker
GIT75 was the username. like They've been contributing a lot and and have a better response. And maybe it's time you maybe let them ah give them access to the repo and let them co-maintain with you. right And that's what happened. And that took about three years to do. And from there, right then they did all the technical side, all the technical work. They implemented a backdoor. They implemented a backdoor that was dormant 90% of the time. right And it allowed a backdoor with very specific encryption keys to, inner long story short, it intercepted the way that OpenSSH worked um and and fully compromised this very core Linux utility. Yeah, so that's to your point, much, much scarier, right? Yeah. and how do How do you detect that? How do you detect the freer social engineering attack, you know?
00:12:16
Speaker
Yeah. so It's almost a distrust of everybody. thing No, it's mine. Mine, mine, mine. Not to be cynical, but yeah, I mean, that's kind of what it is. and
00:12:28
Speaker
Uh, in, you know, and that's not, that's not the way we want to move forward. You know, you want, especially in the open source community, you want the help from other people. Um, and you know, this is, this is the kind of bad Apple that could, that could spoil the bunch. Right. Um, because, for sure you know, at some point that gets back to a legal personnel and a company and they're like, we we can't use this anymore. And now.
00:12:58
Speaker
Adoptions go way down. Adoptions go way down, but also, you know, there's a few elements here. I don't imagine a world that isn't running ah on open source somehow, right? Yeah, there's closed source software, but we're so we're so we're too far down the path to turn back, even if that was something we wanted to do, which I don't think it is.
00:13:22
Speaker
Yeah, I make the joke about going off the software grid and just, I'm building everything myself. That's every way I can trust anything. yeah Build my own OS, build my own my own and languages, my own compilers, do the whole thing. Reinvent every single wheel, right? Yeah, right. Exactly. Yeah. Wow. Well, so I, I, I've seen these things happen and I think we, we kind of shared a little funny meme that was like, you know, the bunch of building blocks and there's just,
00:13:52
Speaker
Like here's everything that all of this solution stands on. And then there's like this one little block of just some dude in Oklahoma maintaining something from the library. what they' Like this this is the little piece that's going to mess you up. Now, do we see, because um've ah I've contributed to the Apache Software Foundation. I've been been a member of the Apache Software Foundation for many years. Are we seeing any of that like kind of infiltrating any of the organizations yet? Or is it more of these kind of individual maintainers? Is that where we're primarily seeing these, these sort of attacks?
00:14:21
Speaker
You know, it's a great question. I don't really have a good answer to that um without kind of going one by one, right? A lot of those core utilities for the longest time were, but you see things like the Apache Foundation where they're sort of taking and it's not, it's centralizing control of those to some degree, or at least providing some sort of group management. Cause I think the worst case scenario is that there's a, and you always, when you're doing like contingency planning for a company, right? You always have your hit by a bus scenario.
00:14:52
Speaker
Yeah. I think when you just take that alone into account, let alone a malicious actor or anything like that, if you take that into account and say, wow, how many people are using basic compression on Linux? Like it's everywhere, right? And to have that functionality dependent on a guy or a gal somewhere. Um, that's, you know, that alone is a problem. So I think,
00:15:17
Speaker
just more eyes, right? ah but But I think when it comes to like NPM, ah like moving away from like Linux and more into the the code dependency world, you are seeing some adopt, maybe adoption is a better word, right? You're seeing groups come along and watch, watch and rank. And and that gets us a little bit closer to,
00:15:40
Speaker
you know, forcing it, and I downrank it if there's only one contributor and the code hasn't been updated in two years, right? That get can affect the way that, um you know, it's security score or it's trust level or whatever. And so you are starting to see some of that. I know NPM themselves are doing that and ah starting to integrate a lot of that into their platform. But yeah, I still think there's a ways to go there.
00:16:06
Speaker
Kind of need like a rotten tomatoes for software rating. Yeah. Absolutely. Rotten apples or something like that. That's a great idea. And there, and there is some of that to some degree, right? Where you kind of give it a generic ranking, how stale is it, but it's not, it's usually centralized to the platform like NPM as an example, but they're not covering everything else. You know, it'd be great to have something that, um,
00:16:31
Speaker
gave you a picture of the open source projects, went through the top 1000, and you could always guarantee that you had an accurate picture of you know how long has it been since someone's even touched this code, right?
Risks in Software Dependencies
00:16:42
Speaker
um And I have seen, I have seen marketplaces on different pieces of software that use plugins and have kind of an open API type of thing, uh, where they allow, you know, external third-party development for plugins have like rating systems in their, their marketplace for types of things and like, um, metrics on.
00:17:06
Speaker
last update and and things of that nature. So that when you are looking through like a long list of like plugins that you're going to pull into like your IDE or or your CMS or something like that, that you can you can see these things and go, it only got two stars and hasn't been touched for three down a year and a half. It's it's on a version 001. I don't think I want this in my system.
00:17:35
Speaker
Right, right. yeah The one thing that's hard, like I know at Apache, one of the one of the project health like metrics is that, you know, when's the last contribution? When was the last release? Yeah, that can be a little misleading, especially an open source, depending on the what the library is. But sometimes you're just done, you know, like, think about something like LPAD, you know, your your left pad of a string.
00:17:57
Speaker
There's only so many ways to skin a cat, so to speak, right? like That's, that's true. That's true from the downloads. Yeah. And that helps downloads. Yeah. Usage. Is it being heavily used? Um, yeah, update. Yeah. I can see how that can be misleading. It's like, especially the simpler the code, you can solve that problem elegantly. Then you don't really need to go beyond it, but, uh, at the same time, right. One thing I would be concerned to with as a security person is.
00:18:24
Speaker
What dependencies is that dependency using, right? What second order dependencies are is there and are they stale and do they introduce vulnerabilities where maybe they weren't vulnerable. The first time that code is developed hasn't been touched in two years, but, but some zero days have been discovered in those dependencies that it's built out of and do those need to be, you know, reevaluated. And when those are horrible to find in a dependency tree. If somebody picks up on a vulnerability, like you, your check marks report or whatever.
00:18:54
Speaker
says, Oh, you've got, you know, this, this thing. And like, I'm not bringing that in as a dependency. So that means one of my dependencies is bringing that in as a dependency or one of its dependencies is bringing it as dependency. So you have to start walking that tree all the way down to try and find which one is using the bad one and then work it back up to find a version that does. And it's.
00:19:20
Speaker
It's a logistical nightmare and could you could spend days just trying to find, okay, where actually is this vulnerability because this is not a library that I'm using directly.
Managing Dependency Vulnerabilities
00:19:30
Speaker
Yeah. So we've developed the untamed security platform over the last year and, and SCA or dependency vulnerability scanning as part of that. And one of the things we're doing right now is.
00:19:42
Speaker
working towards a solution. like Right now, I can find all those vulnerable dependencies in your tree. in your tree right But reachability analysis is another big, big part of that. Not only are you using that third order dependency, maybe you are, maybe you aren't. Maybe when it all gets said and done, that exists or doesn't. But if it does exist, are you using the vulnerable function? Because usually there's like some component of it. Oh, this function and this library of this version Okay, does that get called, is there any permutation of um your applications use of that library that might result in that function being called. And if the answer is no, then it's, it's a non issue, and you've sunk a lot of time into investigating if that was an issue or not, you know, and so it's absolutely.
00:20:31
Speaker
In order to really gain adoption from developers, I think with a lot of the security tooling, it's really important that we make that process a lot easier and a lot cleaner and hopefully automated, right? Yeah. And that's, and that's the key. I mean, the from the development side, the more information you have on something that gets flagged, the better, because then I can go right to it and go, yeah, it's not a thing.
00:20:57
Speaker
But I love that that usability metric, because that's what's missing out on some of these things. It's like, well, yeah, if you're using it this way, I could see that being a vulnerability, but we're not doing that. you know We're using it for this part over here, especially in large libraries. I mean, if if you're pulling in a large library, you're only probably using 10 to 20% of that library for what you need it for.
00:21:25
Speaker
And then the rest is extra utilities for edge cases and things like that. And that you may not be using in your application. It's kind of pointless to go chasing after the red herring. Yeah, spring boot, for instance, I mean, it's just and brings in the kitchen sink for a lot of that stuff or even makes them, you know, optional. Uh, but sometimes I can still show up now. And some of this, like tracking these things down, like nowadays, Tyler, it's, it's like, it's not even really optional anymore. I think there's in there like legislation and and regulatory requirements now around like making sure, you know, what the heck is your stuff.
Regulatory Requirements: SBOM
00:22:04
Speaker
Absolutely. And that's, it's really interesting. So, um, yeah, they it's being regulated. Now there've been, there's the framework regulation and now there's even executive orders, um, that are out that are, um, now it's very specific as to who. So in this case, they're very concerned about government, right? Any governments, but it doesn't just mean the government developing the code. It means,
00:22:28
Speaker
If you're going to be a vendor of a government ah a government entity or do some government project, right you're going to need to be able to attest to a few things. One is just they kind of generically define secure code. So making sure you're scanning and securing your code, that's one requirement. But the other is SBOM specifically, so the Software Bill of Materials. And it's just a list of libraries basically and components that can include like frameworks like like Docker or something like that as well. But just the stuff, a list of stuff is a good way of saying it. It's a list of stuff that your software is made of. But you need to be able to attest to the and provide it in a specific format. um And so we're doing that on our platform. You can export that if you've ingested the repositories. But um it's they're going to require that you be able to provide that as a service provider. And that's new.
00:23:21
Speaker
um Yeah, it's been it's been in talk for a while the mega executive order came out in 2021. It's 14 028 is the executive order What you know, it's a big software specific one, right? But they're really doing it for not only government but AI now they're gonna want you to show If you're building an AI system, what's in your AI system? Hmm Um, and that, I know that's a very generic thing to say because ah right. everything thinks a i these days Yeah, it's all AI statement. It's AI. Isn't it just a series of s statements? Correct me if I'm wrong. Everything boils down to the, uh, bit switches, right? It's yeah automated if statement writing, I guess. or
00:24:03
Speaker
Yeah. Well, the S-bomb, what I wanted to ask Aaron real quick, like it's kind of easy to do. i'm I'm a Java guy, right? So I think of like, you know, using Maven and you you can kind of get, we've been able to do the dependency tree as kind of Aaron was alluding to, but you know, in the modern world, everything's containerized. So I would imagine the, and I don't know a lot about the S-bomb world. I know this is an area that you're actively working and does the S-bomb have to include like everything down into the container, like the version of XZ that's in the image that you're based your stuff on and every layer that's in there, like you you have to have all of those things, everything baked into the S-bomb. Um, per legislation, it's not super clear on exactly what components, but typically there's, you'll have, you'll find two types of S-bombs that get generated. One will get generated from a container or it can be generated from a server image.
00:24:57
Speaker
And so you can point those at containers specifically. The most common kind is to look at a repository and generate an S-bomb from the repository. And that will include mainly third party libraries. um but But yes, you can do it at a container level and probably should, right? Because for example, that utils hack, that was ah that was a, I won't call it OS, it was a container level or OS level dependency.
00:25:23
Speaker
And so it wouldn't have been caught right in a standard S-bomb ah with a manifest. It's just like a, you know, a pip file and a Docker file or something like that. Um, unless it was spelled out in the Docker file, but a lot of these are in the base images, right? And so, I seem to remember back, this was a while ago.
00:25:45
Speaker
When legal kind of was snooping around our software that they wanted like a list of everything we were installing on the servers as well as, you know, what we were.
Understanding Software Licensing
00:25:57
Speaker
You know, and we had to go manually do license checks on all the third party stuff. That's another thing. and Yeah. like that So, you know, and to make sure that we are compliant with the licensing. So there was like certain licenses we couldn't use. And I remember which one I i remember that MIT one was okay.
00:26:16
Speaker
I think the Apache one was okay, but there was another one out there that we can't use it. Yeah. The GPL stuff forces you to, if you're using open source, you have to open source your stuff and provide the source to other people. those yeah that really It was the GPL ones. The copy left. Yeah. The copy left. And that can be, oh, massively problematic. And I'm going to talk, ah I'll say this anecdote and I'll probably have some of the details wrong because it's sort of secondhand, but, um,
00:26:45
Speaker
Cisco had a problem with that, where they had copy left software running as in their firmware in there some of their switches or some of their hardware. I'll say hardware. I don't know if it was switches or not. And they had to physically recall millions of dollars of switches because an owner of one of those copy left licenses claimed ownership, found out they're downstream in this software and decided to take their share. right Wasn't there an era of, I i forget the the group of folks that was doing it, but there was one that was like,
00:27:21
Speaker
they were buying things that had these patents and they were and then they would just use almost like patent warfare, so to speak, right? Oh, yeah. Yeah, very much like you're saying. i yeah Yeah, if that's in your software, I'm coming after you. And I'm just, you know, it's almost like extortion. kind of it It is. i mean It was general patent was general. yeah yeah Yeah. I got another groan. That was good.
00:27:47
Speaker
Yeah, yeah, it it was it was like this this like technology extortion thing going on you know and Real nice software package you got there me sure would be a shame for something to happen to be shame If you're using this for a linting library wouldn't never license for that hope you had to Open source all your stuff that's Give away all your crown jewels i you'd hate to do that yeah
00:28:18
Speaker
No, man, that's exactly, that's exactly, I mean, it's ambulance chasing for software licensing, right? yeah and said yeah I love it it. It did feel that way. It's like, oh my gosh. and so As you could tell, like I love our our legal departments.
00:28:34
Speaker
Well, it's one of those things like you don't, You want it when you need it. yeah You don't appreciate them until you need them. Yeah, exactly. And I find them coming up most often, right? That kind of check, having that check baked into your software development, man, it's a, it's a, especially around acquisitions, right? that's My experience, I'm sure it happens other times, but it always seems in mergers and acquisitions or adoption of new tech, right? Uh, that's when it comes up is what's in here or what are we buying? And, um, you don't want any surprises. So it is important. Yeah. Especially if you're involved with the DOJ, you know, it's, it's, uh, they, they take a hard look at what you're doing. And we'll say you've got to make.
00:29:24
Speaker
party, this has to, you're getting too much competitive advantage in this one area. So you gotta, to you know, make something available there. Yeah. And that can be, that can, I've seen it kill a major merger because there was like, we have, we, the way we have it ingrained in our systems, we cannot figure out how to make this available to the, for public consumption that won't give away our trade secrets. Yeah.
00:29:54
Speaker
Absolutely. And that's a and's a thing to keep in mind, right? know Especially if you're super dependent on your intellectual property as a business, right? Some some IP exists, some doesn't. Not all the software developed is intellectual property per se, but um yeah, super creep super crucial.
00:30:15
Speaker
yeah That's an interesting. Like you think about, and and I'm somewhat new to this world myself, but like when, if you're you know looking to sell a company or whatever, all of the different things as Aaron saying that they they investigate, like the all the aspects that they think about whether or not you would be a desirable acquisition or not.
00:30:31
Speaker
with everyone kind of waking up and realizing, oh, I'm a tech company. That, and my dog is emphasizing this for me. And everybody's saying, you know, I'm a tech company now, that's gotta be a big part of this this picture going forward in the future is like, can you, the provenance, so to speak, of your of your code and your intellectual property, did did you actually come by this legally and is everything legit now? That's a fascinating topic. Well, we could even dive into the provenance discussion.
00:31:00
Speaker
Right. Which is there's and i we can go down here as far as we want to. But the idea of provenance of your supply chain and is a thing. And there are standards now um by that you can use to sign every commit. And that culminates almost blockchain style right up into the signatures that sign signatures that sign your containers.
Provenance in Supply Chains
00:31:24
Speaker
and And ideally, right with full provenance, ah you can tell the story, complete story,
00:31:30
Speaker
If you have an artifact running, let's say it's a zip file that you send off to run in a lambda, ah you can tell the full story of how that was built down to the third parties. You can un unravel it all, essentially, and have it validated so that you know that the artifact that's running is, in fact, the art what you think it is. And if it was interrupted at any point in that process to inject something malicious or something was taken over, you know it'll break that provenance cryptographically in a test of the thing that's running. So that's that's a hard problem. I don't know anyone who can say they have have it fully implemented, right? But Salsa is the framework I'm thinking of that came from Google, SLSA. And they're they're attempting now and have been for a couple of years to provide a framework that you can start making those attestations. But it's a hard, hard thing to do.
00:32:25
Speaker
It's basically a digital paper trail of your of your artifacts, right? Yeah, exactly. and The massive spider web will allow you to follow the money back to. but Yeah, I mean, and you'd have to like be able to prove that this thing I don't have a better phrase for it like almost like it's like forensically complete. The entire story is in there every bit. There's no pieces missing. Nothing's nothing. No gaps in this story whatsoever. The whole everything is complete. That's that is that's probably is a really hard Yeah, I mean, they're a lot of fun even just getting code commit signatures from an entire development team, that's hard, right? Like, like just ah the, you know, because you got to do all the signing and all that is, you know, hopefully it's not super hard, but it's hard enough to just ensure that that's always running, right? um Let alone every other component of that, having your build system every time it builds something, sign it, every package it downloads, sign that package.
00:33:22
Speaker
validate how far down the dependency tree do you validate? it's just big It's a big problem. Well, and yeah like the GPG with us being so distributed, like all those keys that you use to sign, they have to kind of be attested to by others. And you have to do that virtually. And how do you do that securely? Like, do I hold my license up in the camera? They have sometimes they have co-signing parties where if a conference is ever there together, they'll sign each other's keys. Yeah. Make sure that they're they're signing parties. Yeah. Yeah. Securing each other's keys. And it's all fascinating for sure.
00:33:55
Speaker
and And you can't ever fully do it. like you like if you just You can just keep following that forever. So what at what point do you go, good enough? Right. right yeah you know and And that's going to differ based on what you're protecting. I think once you put your passport numbers into the system, I think that's probably about as fine green as you can get. right We validated that this is the actual person that wrote this code.
00:34:23
Speaker
You know, I'll validate your key, Mr. McLovin. It seems legit. That's gotta be right. Gotta be right. Okay, Mr. Mickey Mouse. ah Here's your commit. yeah You're now free to go commit anything you want. Yeah. Oh, yeah.
00:34:44
Speaker
So one of the one of the things that we we discussed earlier, too, that is is another one of these kind of like attack things that we need to be concerned about is it this idea of a confusion attack.
Dependency Confusion Attacks
00:34:58
Speaker
Oh, sure. Yeah. Depends to confusion. There's there's ah we can certainly dive into that. um Confusion attacks aren't really It's kind of like the same tactic applied to with a different medium, if that makes sense. um there's And there's a number of different ways to do it. One of the most common ways it was happening earlier on in third-party library dependencies was it wasn't so much the dependency itself. It was it was an issue of trust. And you know imagine a scenario where you have
00:35:32
Speaker
private and public dependencies. Maybe you you're leveraging a bunch of public third parties and you also have some cache, right? Like a Nexus cache or something like that. Or maybe you're using the GitHub artifact, ah the GitHub cache or whatever it is.
00:35:48
Speaker
um And it would play, the attack would play on the confusion between the two. And what you had was really the systems preferring and and defaulting to public facing repository. So imagine a scenario where your team had an internal package called ABC package. and But the system that when you said NPM install ABC package,
00:36:14
Speaker
By default, it went out to check if there was a public repository first. The caching systems were vulnerable to this because they would default by going out and grabbing the public package with that name first. But let's say you never had a public package with that name. Well, that allowed an attacker to set up a set up one in a public if that If that public open source name wasn't taken yet, they like an NPM package, they could go and take that name and then systems would default to using that and not cache the private one. It wouldn't reach out to the private one first. And and through this, like there were some big, you know if you were able as an attacker to find out the name of ah some internal package, which there's a million ways to do that,
00:36:58
Speaker
through error handling and all sorts of ways, social engineering, right? and Any number of ways to find out the name of, or even brute force, you could just go sign up and create a bunch of malicious, you know, and the more sophisticated ones, right? Would function somewhat like the one they were supposed to be emulating. um And through that, that was a dependency confusion attack. Wow.
00:37:23
Speaker
You're also seeing just even simpler stuff. Like you know about domain squatting, right? Where you get a slight typo in the name of a DNS record. Well, same thing's happening in GitHub, right? um Where you're just taking a package name. I'll take the Go the go language as an example where you can put a exact GitHub repository URL as your dependency in your manifest. And they would just type of squat and will type of squat on GitHub.
00:37:52
Speaker
and just you know off by one name squat for a repository. Now you have to mess with the org name there, but that's not too hard to do. Yeah, so those are some examples for sure.
Preventing Supply Chain Attacks
00:38:07
Speaker
um that's ah That's still a continuing threat. What we did see from that initial ah you know slew of attackers using this is that The vendor started buttoning up because a lot of those were vulnerabilities in the, in the nexus repository or the GitHub actions, not understanding. So they, once the vendor got their stuff in order, some of those golden classifications kind of went away, but they're not gone. You know, they're not gone at all. So this is, this is all.
00:38:41
Speaker
pretty scary kind of stuff if you're a developer and you're like, dang, how can I trust anything out there? What are some of the things that we can do as like countermeasures that try and make sure that we're not getting victimized by these different attacks? Yeah, that's a, I mean, that's a great question. So this typo, like the dependency confusion attack,
00:39:06
Speaker
Really, it's it's funny how so much we want to do that is technical. And I think there's an element of technical, what I'll call a code foundation that you can have in place. There's scanners that are checking for dependency vulnerabilities. um Scanners are looking for code vulnerabilities, ah vulnerabilities in the infrastructure you're deploying. Those are all paramount. But in addition to that, it goes back to just There's something to be said for someone reviewing your code, right? Peer review of your code is the human element being introduced ah in like a typo squatting scenario. That's where those will get caught, right? Is, oh, you misspelled this. Ah, thanks, man. you know You missed a period here. yeah Yes, exactly. And as kind of hard as that is to,
00:39:58
Speaker
you know fully rely on, um in a lot of cases that's going to catch catch some of this stuff. um so So peer review and process, just what's your process for validating third parties? When your company or oregon team introduces a new vote library, what is your what what's your three check boxes that you want to look for first in validating that that's a library you want to use?
00:40:21
Speaker
um It's easy to go after a new shiny, right? It's easy to NPM install something that looks looks good, but I think... Well, we used to call it the bleeding edge, right? so There's a reason for it. It doesn't bleed for no reason. Right. So what do you see is kind of the future of um supply chain security?
Future of Platform Responsibility
00:40:47
Speaker
Yeah, I see a few things. I see Platform starting to take more accountability for for ah Being a manager of the process. So what I mean by that is like a github or a You know gitlab not just source code management even but even package managers right docker hub starting to bake a lot of that in not just the checks, but um
00:41:17
Speaker
you know starting to take some accountability to the fact that they are hosting things that could potentially be malicious. I think it's in their interest to do that. But like financially, it's in their interest to do that reputation-wise. And if they want to be a player and a steward in the open source space, they certainly are going to need to continue to improve there. So I see that. I see a lot of that happening. And with a dependency confusion, as an example, we saw the vendors changing their tune. And that kind of helped things.
00:41:46
Speaker
um So I see that evolving and in that way. I also see things happening much, much faster, right um meaning the checks and the fixes. um We're just seeing code develop at a much more rapid pace. And I think some of the processes are shifting to adapt to that fast pace of development. And with that, at least my hope is,
00:42:13
Speaker
you know, and and it untamed, we're really trying to get ahead of this curve and develop scan types that are going to detect things a lot sooner in the pipeline. ah I think we're going to see things get detected and fixed a lot faster. At least that's maybe my glass half full ah look at things. Hey, I hope you're right. Yeah. Some of these security things can take forever to not only discover, but to you know find where it's at. Yeah, I think it has we're leaning into the discovering. We can do that easy, right? Discovering is easy. Fixing is hard. Fixing is really hard. It's a hard in a way that I think most security people and not knocking my security folks, but we don't understand. And so really, I've been grateful to work around a lot of developers and understand really the complexity of a lot of that.
00:43:10
Speaker
problem. But a lot of the solution needs to be distilling that down, answering those questions way quicker. right is Am I vulnerable to this? Yes or no. Do I have the information in front of me that I can make that decision as a developer? I think that's a huge piece of it. And so my hope is that that that evolves. That's the part that needs to be evolving. Scanning and detecting is fantastic. It's step one. right But it's not the full picture.
00:43:38
Speaker
Yeah. Like one of the the modern software practices and is, you know, staying current with dependencies.
Keeping Dependencies Up-to-date
00:43:45
Speaker
Like you could say, Oh, our features done. Okay. But yeah that you're not done done. You still have to keep like, okay, that, that new a bug fix brand or, you know, patch version came out. You need to upgrade to that. Cause the closer you stay to the front, the more likely it is you're going to be able to quickly.
00:44:02
Speaker
Bring in the patches that fix security vulnerabilities if you're 20 versions behind chances are you're gonna have to go rip through your code and that's exactly Signatures on stuff like you gotta to try to stay current and that makes it really hard especially though you said this stuff It's only accelerating. It's getting faster and faster. So just staying fresh with your dependencies is is the way to go You got to stay really close to the the bleeding edge so to speak as Aaron would put it Yeah, or you'll get left behind Yeah, yeah, that's exactly it. I mean, it's patch management at its core, which really is not even a security function, right? I mean, it kind of is, it has security implications, but patch management of your libraries and patch management of your base OSs, how often are you updating your base images? And I think, you know, I'd be curious to hear your all's perspective on this from the dev side, but ah it seems like
00:44:53
Speaker
you know, automating that is is difficult because automating it requires really proper testing that you need to be able to move. If you're going to move that fast, you need to be able to trust the thing that comes out of that automation. In order to do that, you need testing that you trust. And it that's a hard problem problem too, right? Absolutely. And so, yeah. So some of the some of the things that I've, I've gleaned from today, one, have somebody look at your dependency structures as part of a peer review. Just make sure that you're not using old outdated things or made a mistake um in your entries, possibly looking for settings that are taking public over private rep republic repositories for appropriate.
00:45:48
Speaker
um some of the other One of the other suggestions that I liked was stay current with the libraries that you're using so that you're getting all of those security patches from your downstream.
00:46:04
Speaker
Yes. Or I'm sorry, that would be your is that upstream downstream. ah like you always get for views upstream Yeah, I guess you be upstream. Yeah. From your upstream doing it all downstream. Yeah. Yeah. You're sending stuff downstream. So yeah yeah, it'd be all upstream. So from your upstream dependencies, you know, you're getting all of their security patches and stuff into your application to make it a little bit more sound.
00:46:33
Speaker
and leverage your platforms for scanning and detection of any kinds of known vulnerabilities. 100%. That covers the basics, right? um Oh, and the other one I thought was interesting too is also check for security gaps in your platform as well, not just your in your pipelines.
00:46:59
Speaker
Yeah, yes. Make sure that the things you're using, not just the code you're writing. We talked all about, we think about SIP, SAP, and SOP, right? There's security in the pipeline, and so security around the pipeline, and security on the pipeline.
00:47:19
Speaker
and Really we've been talking about security in the pipeline. So what are the, what is the end goal and what are we developing and what does that thing look like? ah You know, if we're manufacturing a car, what we've been talking about are all the parts and the end product and testing it, but we haven't talked really much. and We actually did it with the dependency stuff around the factory is building the car and all the equipment that the fact, what is the fact, can I hack the factory equipment?
00:47:47
Speaker
right And, uh, yeah, there's a lot of room there. Um, you need, you need the OSHA for software. Yeah. Oh man. I don't know if I like that analogy, but yeah. Oh, it's a good analogy. It's just, uh, I don't, you know, I don't want to be closer. Has everyone had their hard hats? Yeah. $10,000 for every unlabeled spray bottle on your shelf. Yeah. Where's your lockout tags? Yeah. Um,
00:48:16
Speaker
So this has been great. I want to thank you for that. So we're going to move on to our next section, yeah which is ship it or skip it. Okay. Shipper, skip, shipper, we'll skip everybody. We got to tell them that shipper was good. And what we're going to do with ship it or skip it is we're going to throw out a topic that you're either going to say, yeah, this is great. Ship it, use it, um, or skip it.
00:48:44
Speaker
And yeah maybe not so much and that we want to be doing this kind of stuff. um and And then there's the gray areas in between, you know, because, you know, there's nothing every, everything isn't always cut and dry. So ah James, you want to give us our first ship it or skip it. All right. Yeah. I mean, I, I'm, I.
00:49:06
Speaker
I looked for topics today and I was kind of like, let's, let's get some like really controversial stuff. So I thought, okay, the first one was like, maybe it's an, is the notion of shift left? Is that movement? Is it, is it overhyped? Is that, or is it, or is shift left a thing? Like, no, no, do it, ship it. Or is it, is it? You know, that's a, that's an awesome question because you'll hear, you still hear it all the time. I think shift left was a, is a marketing thing.
00:49:32
Speaker
right it's ah It is a marketing phase, but I think the intent, like if I could summarize shift left, ah I don't say skip it. I'll say ship it but with some clarification. so um Well, maybe that wasn't even the ship it, skip it thing, but ah shift left's intent was do security sooner. And I'm all for doing security sooner. What what was hard about that is When you say left, what does that mean? And every development team works completely differently. And what was happening is these products were being developed or these processes were being developed um to fit what security teams had concluded that development teams work like. We know how developers work, and we've built a product to solve for that. It's called Shift Left, you know and we're shifting left.
00:50:25
Speaker
and it was um And it didn't always work because every team works differently, right? So the tooling didn't really adapt to their intent which was to move security earlier in the process um Which I am all for so I'll say ship skip left if we're looking for a a simple yes or no on that um but knowing that I'd say maybe 10 to 10% to 30% of developers adopted the tooling in their IDE while they were developing code. The rest relied on it a little bit further right in their source code repositories when they were doing tests against PRs and things like that. So to me, that's where it makes the most sense to live is in the repository, maybe not all the way in the IDE unless you have a really security- to-minded development team
00:51:19
Speaker
that is going to implement the tools on a on faith basis, you know? Yeah, and I'm going to give a ship it and a skip it version of this. It's kind of what I did. so if If the definition of shift left is the developers responsible for everything,
00:51:44
Speaker
um I'm gonna skip it, right? ah yes we We we we can't overload our developers that much that we already have enough to think about and in world hunger to solve so You know adding adding more tasks to our list is just not in a place. I want to be That On the ship it part if it's move a process as far left at that as it makes sense to move it Then I'm a ship it. So as as long as it's not like move it all the way left to the developer and let them worry about it, then no, that's a skip it. But if if it's where it makes the most sense, shift it as far left as it makes sense, then yeah. And for me, that is shifted left until you can automate it. That's great.
00:52:38
Speaker
That's actually a great option. There is some low hanging fruit that can be done all the way left. That puts very little work on the developer. Yeah. Some, but not all. Yeah. I mean, Aaron and I are both, you know, developers at heart. So I kind of, I agree with him on the, you know, we we just can't. Number one, like the, the, world the world of security, as you were saying, it's, it's changing all the time, just like the world of software development is changing all the time. It's really hard to stay like.
00:53:03
Speaker
completely current with everything that's going on and have to know that and no software development. and Oh, and by the way, how to run everything in the cloud. Oh, and you know, all of the things. yeah So it's really hard to do. That doesn't mean that we can't be more conscious of it. And I think we have great tools like where you have like the kind of like those Lynch or tools or the static code analysis tools like sonar cube built into your IDE where as I'm coding, it will say, Hey, this seems kind of funny. You're accepting input from a user and just putting that into a SQL string. That's.
00:53:32
Speaker
probably a little shady. yes like But that's kind of education along the way. so That's one thing I love about those tools is you're like, what why is that bad? I'm just conca hitting strings. Oh, because yep bobby tables could exist, right? So I think that, I agree, like putting the tooling in, educating, I'm always um all for educating developers to get smarter about security. Absolutely, they need to be more and more conscious of it as much as they can. But ultimately, you gotta do it. um in multiple steps along the way. You yeah put the the the rock solid scanning and I think that's kind of what Aaron is saying is like do it after the fact as well. Just multiple multiple levels. Yeah, of defense in depth. Yeah, yeah, absolutely. Yeah. All right. What's our another ship it or skip it there, Aaron? i You know, speaking of security, i I thought this was an interesting one. and This was actually brought up by our producer the other day.
00:54:30
Speaker
is two-factor authentication. Yeah. Ship it or skip it. Oh, me? My default is going to be ship it. Only because I 100% know the implication of not having it. And the the attacks I've been able to pull off as a result of them not having a second factor in place. and I also think some of the second factors, right,
00:54:59
Speaker
uh, something you have, something you are or something you know, um, are getting better, right? We have biometrics now. So it's not really just those three things. It's something you are or something, you know, something you are is fingerprint. I, you know, whatever I scanning UB key. Um, and so, uh, I think, yeah, I don't have much to elaborate on there. I would absolutely ship it. Um, I know it's inconvenient. I know it.
00:55:27
Speaker
It's annoying to pull out Authy and enter a six digit code if that's the only means of multi-factory you have, but yeah, I'm for it. What do you think, A. A. Ron? I am a skip it because I think instead of doing a primary that's considered fairly useless, that's easily beatable, just go right to the second factor to begin with. It's like, why not just say like, is like pass key authentication? Like, yeah, oh yes why don't you just do that? Then I don't have to do it. Do two different things. Like if, if I want to get into something, you know, immediately just go, go into your authentication app and authenticate yourself in. Okay, great. Done. Oh, as the second factor. Yes. As the only factor, right. Oh, right.
00:56:25
Speaker
That's my login is by going to, you know, to use my authenticator to get into something, you know, instead of why, why do two things that are doing the same thing? Yeah. Yeah. I'm a, I'm a skip it. Do it better. It's like, it's like duct taping your door closed, but then also doing a deadbolt. Yes. Or putting the hinges on the outside of the door.
00:56:51
Speaker
yeah he was a dead bull jimmy i'm open with a screw driver yeah that off yeah no No, no, I'm with you there. I think we can do it better in a way that you don't need two factor. Yep. Yeah. and i'm I'm kind of.
00:57:04
Speaker
I like two factor. I think the the the thing about two factor is like the, the, the first factor is usually more convenient. If you can make one that's convenient as, you know, just stored passwords and then you don't have to do that. But I do like the idea of second, uh, two factor for things like something, you know, the a request is coming in from a new location or a new IP address. And you're like, we're going to have to go through the multi factor here to get, to make sure you are who you are. Cause I get those emails from like,
00:57:32
Speaker
you know, PlayStation Network and stuff like somebody trying to log into your account, but you know, yeah, and two factor in, right. So that that is helpful. Um, but I would say the one thing I'd loved, there's maybe I'm going to get on a soapbox here. One thing I would love is there's people to put like the appropriate level of like, like, remember me type support. We have one package that I use it. It's 24 hours. I'm like, I'm not launching rockets here. People like, come on, like really, I really ah do this. Yeah. I think that's.
00:58:03
Speaker
Yeah. They're waiting for your background check to come back. Oh, is that what it is? Good luck there. No. but Well, the other thing I'd say is i the that I'm more upset about than two factor probably would be the stupid cookie things. Every website I have to go to, I have to like. Oh, the GDPR requirement. Oh yeah. All that. I have to go to the cookies. Like I would love it to just, and a lot of websites are getting better about it. Like they have a button that says,
00:58:29
Speaker
give me all of it or deny all or yeah strictly necessary. I love that, but not a lot of them have adopted that. I did see. um I don't remember where I saw it, but if it was like something from something from Google saying that they are working on. Not requiring cookies.
00:58:57
Speaker
Nice in, in, in Chrome browser. So I'm like, Oh, that would be cool. Because if you really look at that, right. Well, one is driven out of compliance. It's fully GDPR made that happen. That's why those pop and then everyone just sort of latched onto to it. And I think the CCPA, uh, legislation also enforce it here in United States, but, um,
00:59:23
Speaker
Yeah, but then like how many sites do you load? It loads all of its cookies and then asks you to accept or it's like, well, who cares? you I already, by visiting your site, accepted your cookies and you know, very little change can happen when when you say I accept or I don't accept, right? You know. And I think they were very, very careful about their wording, like on the Apple thing where it pops, like when I'm on my Apple TV and it's like, ask this app not to track you.
00:59:52
Speaker
I can't tell it, no, don't track me. I can i can just ask that they don't. yeah yeah right show askfully oh You can ask, denied.
01:00:06
Speaker
right Where you find out that like your Apple device is tracking, you can disable tracking for tracking you. But if your neighbors with phones can also talk to your Apple via Bluetooth,
01:00:22
Speaker
That doesn't count, right? Oh, my goodness. Right. So that they can second party track you. Oh, but they just can't directly take your stuff. Right. but So there's all sorts of legal song and dance. All right. Well, I think that's good for our shipping or skip it. Yeah. So now we move on to the highlight of the show. The thing we call the lightning row.
01:01:05
Speaker
The way the lightning round works is we're going to rapid fire questions at you one at a time back and forth. And these are supposed to be short answered ones. It's just a way for us to get to know you a little bit better.
01:01:19
Speaker
cool Some people have survived this. So, you know, it's not all doom and gloom. OK. All right. Well, I'll do my best. We'll each give you five questions. All right. Wow. And James, why don't you give us the first one? OK. I'm coming in hot with this one. Sour Patch Kids or Swedish Fish? Swedish Fish. Giving presents or getting presents? Giving presents. Well done.
01:01:50
Speaker
When you fly on a plane, do you wear a neck pillow? No. I kind of want one though. I, I, you know what? I used one for the first time and now my bed pillow is, is a type of neck pillow. Wrap it around.
01:02:10
Speaker
Well, it's it's not a wraparound. It's just kind of like a U shape, you know, but it' it's great. Especially from sitting at a desk all day and keeping my head up. that's a ah It works really well. ah Name a word that starts with the letter Q. Quasi. Is that a word? Is that a print prefix? I don't know. But I like it. We'll accept it. he does It sounds cool. It's a name. I had a friend named Quasi.
01:02:39
Speaker
um i'll ah I'll allow it. Our mirror was clammy. All right. Have you ever seen a kangaroo in person? Yes. and I'll tell you my kangaroo story later. Okay. I mean, now we got to hear it.
01:02:57
Speaker
You can't do that to our audience. Okay, well then we'll have to dive. Short story, walk through a kangaroo exhibit. They're all out in the open. There's a kangaroo covered in blood. I went up to the zookeeper and said, why is that kangaroo all covered in blood? She said it was one of the males that got in a fight with another male just a few minutes ago. And they just went at it and you missed a kangaroo fight. Wow. Yep. That would have been something to see. It would have been. Yeah.
01:03:26
Speaker
If there's a spider in your house, do you kill it or set it free? Kill it. On a scale of one to ten, how much do you enjoy garlic?
01:03:39
Speaker
Four. Okay. We would have also accepted six. I would have accepted ten as well.
01:03:52
Speaker
I like it. Just chew it. Chew it like candy. Put in my lip like it. What's something you could eat for a week straight?
01:04:03
Speaker
Eggs. Mm hmm. That's good. Yeah. That's an egg salinity. Oh, yeah. egg that was it Well, you really oh cracked that one. didnt he Oh.
01:04:16
Speaker
Put the yolks on you. Wow.
01:04:22
Speaker
Wow. that's We did not edit those in. Those were live. Oh, yeah. Yeah, I can attest. I'm right here. I wouldn't sing this. that Maybe somehow sign to say that never mind. Would you rather be able to speak every language in the world or be able to talk to animals? Every language in the world. OK.
01:04:44
Speaker
You make them a lot of money doing that. What's your favorite clothing brand? Oh, man, you're asking the wrong guy. Target. I don't know. i don't know That's a brand.
01:05:00
Speaker
nice I will accept it. I don't even know what number we're on. I'm going to. Who was your first celebrity crush? Blanken iron name.
01:05:15
Speaker
Jenny McCarthy. Oh, because you know, that era 90s, the 90s. Okay. We would have accepted Carmen Electra from the 90s as well. Oh, yes, yes. yeah ah Our tomatoes are fruit or a vegetable. I know, technically, they're a fruit, but I think of them as a vegetable. Yeah, they got no business being over there was like, All right, I think that wraps it up. I think we're good.
01:05:41
Speaker
And you survived. I did. You didn't grill me too hard. Well done. Yeah. That was awesome. Tyler, do you have any closing final thoughts or advice that you want to throw to the public? Yeah. I mean, I would love to see, um, I would love to see security become more of a part of development, not just and in the tools. And I, you know, I'd say that as a person developing a tool, but, um, or a platform, but it's part of the,
01:06:10
Speaker
process and culture. And and you know there's some bridges that can be built, I think, between security teams and development teams. both in like Both have something to learn from each other. But also in implementing you know security as part of the way we build. And really, I would encourage everybody to think about but think bad, do good.
01:06:33
Speaker
Think bad, do good. put Learn to think like an attacker. If I wanted to hurt the thing I was building or the the people that used it, what would I do? And then at least consider that as you build. doesn't have to You don't have to be an expert. There's some really easy first steps that you could take as a developer that you don't need to be you know understand every single aspect of an attack chain to start protecting the things that you're building. And so that's what I would leave.
01:07:02
Speaker
the audience with is is just start thinking about it as if you were an attacker, um and think bad, do good. That's great. I like that. I'm going to keep that as ah as a phrase. Think bad, do good. Because I've also said the same thing about software development, as you know think about how you can break it, not how you can build it. Yes. Yeah. Is there any anybody you'd like to thank? Some shout outs?
01:07:33
Speaker
Oh, sure. I mean, I have lots of shout outs. ah I will, um ah you know, I think the OWASP team for, you know, allowing me to kind of be a part of the OWASP standard project, you know, shout out to Build Technologies. they've They've allowed me to, you know, build and experiment as the as they grew into a large company. um And then you know as we built this product on the side and are now taking this um scaling this, um
01:08:08
Speaker
you know they've certainly been a help in that process. So absolutely. And for those who are interested in learning more at Untamed Theory, we are building a platform for we're calling Foundational Application Security. And what's there now is is five foundational scan types and a way to prioritize those findings ah in your development environment. It integrates very, very quickly. We have people who don't have an account sign up and get scan findings within 15 minutes. um But where we're taking this thing is so kind of the stuff we talked about. We're really leaning into the fixing and helping developers give them the information they need
01:08:52
Speaker
And as we build this thing and grow this thing, we're in the middle of fundraising right now. um We envision a future where the development team has what they need to become security experts. Is is there a website where we can learn more? Yeah, of course. Untamed duck.cloud. U-N-T-A-M-E-D dot.cloud. Thanks.
01:09:14
Speaker
That's one thing I like about the the offering is that that it provides, you know, because some of these things are are offered by disparate tool sets. Yes. Where this provides you kind of like that almost like a single pane of glass view and it's all together. I love that aspect of what you're building. Awesome. Yeah, we wanted to give it, give everything you need in one platform. That was the idea. And it it will be expanding to other scan types. We're going to be expanding to some cloud scan types, containers, and and things like this in the future.
01:09:42
Speaker
but certainly leaning on the development community to give feedback and and input right into the its usability. that our That's really, really important. Great. Well, thank you, Tyler, for thank you but all of your wonderful information.
01:10:00
Speaker
That concludes this episode of The Forward Slash, where we lean into the future of IT. I'd like to thank our guest, Tyra Welton, for talking with us about supply chain attacks. I'd also like to thank my beautiful co-host, James, and all our production staff that make this podcast possible. Make sure you subscribe, rate, and share. If you'd like to reach us at The Forward Slash or have questions, you can email us at theforwardslashatcaliberty.com.
01:10:27
Speaker
I'm Aaron Chesney. Thank you and stay curious.