Season 7 Guests — The best of Season 7

0:00Chris RomeoHey folks, this is Chris Romeo, CEO of Security Journey and co-host of the Application Security Podcast. This is our final episode for season 7, and we thought we'd share some of our favorite clips with you. We've covered a lot of ground in season 7, from featuring OWASP projects to talking about DevSecOps, pen testing, AWS security, same-site cookies, crypto, and that just scratches the surface. We hope you enjoy this wrap-up episode with A whole bunch of Season 7 guests. At Security Journey, we believe security is every developer's job. We work with our customers to help them build long-term sustainable security culture amongst all their developers. Our approach is to provide security education that's conversational, quick, hands-on, and fun. We don't do lectures. Instead, we let the experts talk about what's important. Modules are quick, 10 to 20 minutes in length. We believe in hands-on experiments, builder and breaker style, that allow your developers developers to put what they learned into action. And lastly, fun. Training doesn't have to be boring. We make it engaging and fun for the developers. Visit www.securityjourney.com to sign up for a free trial of the Security Dojo. Season 7 started with Sebastian Dieler-Snyder and Bart de Wynne answering the question for us, what is OWASP SAM?

1:37Robert HurlbutSAM is a model that's driven by the community and built for the community. And so we're actually trying a lot to involve as much as possible the community, among others, for instance, by providing guidance on how to use the model. And that guidance can, for instance, we're currently building with Rob van der Veer a guidance on how can you build, how can you use OWASP SAM for agile development, or how could you use it for DevOps-oriented companies? Because again, this is like a theoretical structure, but you have to apply to a particular context of your organization. Just as everybody, every company doesn't need to get all trees for all practices or activities, you don't need the way you apply it in your organization differs depending on your context. So we want to give as much as possible guidance and advice from within the project to companies, how can you actually apply this? And this is why we're having these user conferences to share experiences. And because we know the more you talk about it, the clearer it becomes on how to use this model at best in your organization.

2:48Chris RomeoIn episode 2, Janek Hollenbach, Prepares us for the future of MultiJuicer. So when you think about the future then of MultiJuicer, what, uh, what are some of the features and things that you have on the roadmap that we'll be able to do in coming revisions, coming versions?

3:07Robert HurlbutOne feature I'm really looking forward to is like a dashboard view to see who or which, which teams have solved which challenges. To give trainees or trainers, mostly trainers, a better overview to how far the participants got along, which challenges did they solve, which challenges are they having problems with right now. And just also for instances of MultiJuicer where not like catered to like a 2-day or 1-day trainings, but basically like long-running MultiJuicer instances where you just say, okay, We at company XY have like this Multijuicer installation, and whenever you want to learn something about security, you can just go to Multijuicer, go onto your G-Shop instances, and learn something, and give like the security teams a better insight about what challenges individual developers have already solved, and a better insight to how far their security training's got along.

4:05Chris RomeoIn episode 3, Cindy Blake from GitLab answers how security fits into development in a DevSecOps world.

4:16Robert HurlbutWhen you think about the processes for development, security really hasn't historically been part of that, part of that phrase, part of that workflow. You know, it's been a very siloed effort. With DevOps, you know, you've got, you've got changes in roles where people are more cross-functional in nature. And so, security has a, you know, a natural fit into that because while traditionally security people, professionals, are the ones who would find vulnerabilities in code, it's the developers that have to fix it. So, you know, in the spirit of, you know, being more efficient and doing things once as opposed to redoing them, Wouldn't it be great if you could empower the developer to find and fix vulnerabilities while they're working on the code? And so, that's the holy grail. Getting there has been very challenging for people because, you know, application security has been around for quite a while and there's some ingrained, entrenched methods and, you know, that being a catalyst for change. DevOps has pushed in the right directions, but it's fighting a bit of a battle in terms of tools and workflows and roles that have been entrenched for some time. So bringing all of that together to have a united workflow is really important.

5:59Chris RomeoUp next is episode 5, where Aaron Guzman explains how the IoT Goat project is working across the industry to have a bigger impact.

6:09Robert HurlbutI think all around in the industry, there's a lot going on within IoT, and I think that can also be an issue, and what it's becoming is an issue. Everyone's doing their own workflow and not really collaborating. And that's also something that the IoT project is focusing on in addition to the projects that we have internally, working with ENISA, for example, cross-collaborating on their publications. as well as the Cloud Security Alliance working on the IoT working group. I'm a co-chair there, and I invite folks to peer review some of our work and vice versa as well. So we cross-collaborate, send out on how we can work together. Even with the ISVS, there's plans to incorporate some of the IoT control framework that the Cloud Security Alliance put out. last March, which some of the requirements have originated from there. But anyhow, that's again, that's probably one of the goals of the project from a high level.

7:11Chris RomeoIn episode 6, Drew Dennison explains how Semgrep works from the inside out and its advantages. It sounds like you're mostly code agnostic then, you're not—

7:24Robert Hurlbutbecause you're running outside of any IDE, out of any environment that has a dependency on Java, it's .NET, it's Python, it's whatever. You have patterns that still match certain code constructs as well, right? Right. So we do care about the language because we need to understand the syntax of the language. So there is a universal abstract syntax tree for those who kind of like to geek out about programming languages. And we're starting to move in the direction of using Tree-sitter, which is what GitHub uses for their Atom code editor. And that lets us support like every language that Atom supports. But you're right, the fact that you don't need to have compiled artifacts. I don't need to understand how the Java bytecode is built, if you've ever used a tool like SpotBugs or something like that, because you're just looking at the Java source.

8:09Chris RomeoRight.

8:09Robert HurlbutAnd it doesn't even technically have to be a valid or buildable project. We just need one file or something, because you're just going to look for, from java.spring.webhandler import you know, servlet or whatever the— I forget the exact, you know, Java pattern that you'd want to look for. And then from there you'd say, okay, cool, we're taking a request, we're getting like the user data, and then we're going to send that directly to like, you know, exec or something, or like a file opener or database query. And so is that safe? Well, who knows? So you can kind of look for these little simple code audits, right, when you think about just at a file level.

8:46Chris RomeoThat's very cool, that example you had earlier there about the scale with which you're going to be able to scan things, like being able to scan 100,000 JavaScript repos at the same time. Like, I just feel like there should be diabolical music playing in the background while we describe that. Like, it sounds like a Dr. Evil kind of move, you know, like, you know, like you should be like having your hands up like this as you're telling me. No, that's very cool. That's, that's got to be like the most, you know, it's got to be a problem Or a solution that will really resonate with people who are scanning lots and lots of source code, because I know that is the biggest challenge people have with static scanning, is the timeframes that go into it.

9:29Robert HurlbutYep, yep. And that's why we were like, most of this stuff should be— especially if you kind of don't have to depend on building the entire project, it should all be very embarrassingly parallelizable. You know, I can get a Spot instance for an hour. It has 1 CPU, 2 gigs of RAM for a third of a penny. So I can do a lot of code checking in an hour for very, very cheap amounts of money. And so, yeah, having that scale is important. And I think oftentimes, like, the trade-off that I was unhappy seeing a lot of my AppSec friends and myself is you either say, I care about third-party dependencies and I'm gonna go buy a really cool tool, let's say Snyk, or there's Dependabot or SourceClear. There's a bunch of third-party vulnerability databases, but they're typically just looking at, does this version match the CVE database?

10:12Chris RomeoYeah.

10:12Robert HurlbutOr, I'm going to say, well, what's the code I can control, and I'm going to write? And it's only the companies like Google, and maybe Dropbox, and a few others I've talked to, who actually go and vendor all the third-party code, and bring it into their monorepo, and actually care about the security of their third-party libraries that get built into the final application. And I think everybody else just throws their hands up and says, well, if there's some crazy JavaScript package that has a hardcoded initialization vector, someone else is going to have to fix it and find it.

10:39Chris RomeoIn episode 7, O'Shawn Marshall joins to describe the frustrations people have with AWS security. When you, when you think about AWS in terms of security, uh, what are some of the frustrations that, uh, that you see?

10:55Robert HurlbutSo frustrations, uh, one of them, of course, many ways of skinning a cat, obviously. And another one is, The built-in— the reason why a lot of S3 buckets— I'll go S3 buckets, 'cause that's a red herring, and that's easy to beat up, beat up and kick people for having open S3 buckets, but the tooling is sort of— we've gotten to this point in the cloud where a lot of the stuff is proof of concept, or POC software. It's really easy to get running, it's really easy to get started, and then, In the blurb, in the documentation, and this is without fail, Microsoft, Amazon, everyone does this. It's like, in a production system, you might want to do it in a slightly different way than this. And that's the frustration. The security part, we haven't gotten to the point where the security part is easy. We've gotten the functionality part is easy, but we haven't gotten to the point there. There hasn't been a real demand to get the security part to be easier than it should be. Because— and one reason why I say this is because if you're adding a new AWS service into your web app, if you're adding something new, one of the first things that you have to do is use— you think, okay, I'm going to use a built-in role and The IAM policy. You're going to use a built-in role. Usually that's full read-on access, full write-on access, or full admin access. There's not a lot of gran— there's not a tutorial on how to do the granularity. It's all JSON when you actually dive into the technical details. It's just writing key-value pairs and understanding how to connect the different parts together. But in terms of quick POC, click through, let's get this to work, usually to get something to a point where different parts at least communicate with one another, the easiest way is still throw on a full policy.

13:10Chris RomeoIn episode 8, we speak with Graham Holmes on how to address risk and ensure trust in an artificial intelligence machine learning world. What are some of the things that companies that are trying to roll out these types of solutions right now, how should they be addressing risk, ensuring trust? Like, what's the solution to this problem?

13:34Robert HurlbutSo, one of the things I've proposed, and it brings together a lot of thinking in the industry and academia as well as government policymakers, is you think about a trust framework. that as you develop, you need to have. One of them is it has to be secure, right?

13:51Chris RomeoCustomers are expecting anything we provide them to be secure.

13:54Robert HurlbutSo is it— is your solution robust and resilient? And the standard OWASP mitigations and things like that need to be looked at. And as you understand unique attacks against your machine learning processes, you need to come up with mitigations against that to ensure that they're robust and resilient. The second thing is, is an expectation that What you've created is explainable, that the results that come out of it comply with or conform to what you expect to see, that they're— that you can prove that that result is logical and likely to have been a correct decision, right? So they're gonna want to see proofs of that. How do you provide tests that show them that this explains how it works?

14:39Chris Romeoand how the results match what you expect to see.

14:42Robert HurlbutYou know, maybe there is bias in the system because you expect that. You want to have bias against certain types of traffic, but you want to be able to illustrate that this is the bias we expect and this is the bias we actually see. You know, the third element is critical. Is this solution fair? And this one's probably the more difficult one. Fairness gets back to ethics. It gets back to cultural expectations. You know, we have different different ways of thinking things are fair based upon where we might live, the region that we're living in, or even our own cultural biases. So how do you explain that your algorithm is fair? That it's biased where you expect it to be biased, but it's impartial where you expect it and should be? Is it protecting human rights? Is it protecting your privacy? Is it protecting your data? So that's kind of the fairness algorithms and proofs that you need to be able to provide. And then I think the next 2 elements are kind of the backend processes that you need to expose, which is you're transparent about what you're doing. You share these results about security, the security of it, the explainability, the fairness of it. And finally, you're accountable to it. You know, when you find problems, you deal with them, you are transparent about the problem, and you hold yourself accountable to getting the solution, that problem affected and fixed.

16:06Chris RomeoRight.

16:08Robert HurlbutSo, that framework— secure, explainable, fair, transparent, and accountable— I think those are key things that you should be doing no matter what, but have some unique elements when it comes to AI and ML. And I think the net of this is, is you want to ensure that your customers understand what you're doing to protect them, protect their privacy, their human rights, and the safety of their customers themselves. Okay.

16:34Chris RomeoIn episode 9, Elie Saad of OWASP WSTG, Cheat Sheets, and the Integration Project tells us about his introduction to OWASP. What was your introduction to OWASP that brought you to where you are now?

16:51Robert HurlbutOkay, so while I was getting into cybersecurity, um, I started to join communities and mostly on Discord. I first joined it because a couple of friends were there, so they invited me, and I was kind of interested. Hey, I'm interested in security, so could there be some kind of servers that relate to these projects, to security overall, and similar things? And I slowly started to join multiple servers, and OWASP always was mentioned somewhere when people were describing application security. And if you even write how to do application security, one of the resources that you're going to find on Google, it's going to be related to OWASP. So all you need is just, hey, I want to learn application security, and just click OWASP anywhere you find it, which is almost everywhere. It's just at the start, it was a little bit difficult to choose which project to look at because it contains so many. And will you choose a mid-level, a flagship, Which one are you going to choose? What focus are you going to focus on? So there's mobile, there's web, there's tooling. Like, whenever you come forward as a starting person, it gets daunting. And you start to look, all right, I know zero of this stuff. Where do I look? What do I start with? And that's why I started to dig deeper into it because I saw, okay, this is a very huge world. I better start from somewhere. And I decided to start wherever I loved most, which was kind of testing and development. And that's how I chose the first 2 projects.

18:29Chris RomeoIn episode 10, Grant Ongers discusses gamification in threat modeling and how to connect with developers.

18:37Robert HurlbutTell us a little bit about that approach to gamification and how that is helpful. So, I guess starting with gamification and why that's particularly useful for developers. Security is often seen as this very black magic, dark area of the IT world. We tend to keep a lot of our particularly focused ways of doing security things, we don't tend to share that outside of this community. Either because we think people don't care, or we think that it's not interesting, or because we like having some, I don't know, mysteriousness around our— the world that we work in. But gamification takes away a lot of that, right? It makes it very simple. You have to simplify things in order to make it a game. Otherwise, the game is very complicated and really hard to learn. Cornucopia is anything but that. I mean, it is— it's literally a kind of like a trump card game where you try and beat the previous card ahead of you by finding a card that's higher, that happens to be in the same suit, that is also a potentially valid attack against the product that you're trying to target. So it's a very simple concept. The way that the game is played is very easy to understand. The complicated things are understanding what those 5 things are and Once you've played 1 or 2 cards, you begin to understand how they interact with each other. And then really, the cards are just how badly can you affect data validation, or how broadly could you affect it but with very little impact. And that's kind of how the cards are spread out. Cornucopia does a really good job of that because it doesn't require a developer to take on the concepts of Dread or Stride or any of the other methodologies that we've, that we've created for threat modeling. It puts things in very simple terms that they can understand, in terms that are easy to pick up on, and terms that actually tie in quite well with their development process. So I'm creating an input form, I know that I have to validate the input that comes in there, primarily because I need to make sure that when I ask them to type in a username, they actually typed in a username. When they type in a password, I know I've got to star that out. So I understand what validation of the inputs is about. I understand what authorization is because I built an authorization module, right? You know, I'm allowing users to do certain things there because they've logged in and I know who they are. They've authenticated. Usually somebody else has dealt with that aspect of it, but now I know that, right, you've authenticated, you belong to a particular group, you're allowed to do a certain function. And because that's functional work, the concepts translate very well. So I find that the gamification methodology that the Coincopia uses, which is simplify everything, bring it back to the functional work that you're going to be doing within the code, makes it really easy for them to start seeing how those functions they're building can be abused.

21:44Chris RomeoMm-hmm.

21:45Robert HurlbutBecause the cards go into a great deal of detail. They also tie into a whole bunch of other really good OWASP and other projects like the Secure Coding Guide or the ASVS. So, there's really good connections into other OWASP projects and into SafeCode projects outside of OWASP that also really do bring you some more details. And it allows developers to go from, okay, I understand basically what I'm doing with data validation, to, hey, this is quite interesting. Let me learn more, without expecting to know everything before they start building something.

22:16Chris RomeoEpisode 12 was with yours truly on the current state of the security industry.

22:24Robert HurlbutWhen I think about historically, things haven't changed a lot since I started in the world of security as far as the classes of attacks. Buffer overflows still exist even though the first one, or one of the early ones, was the Morris worm back in the late '60s that was kind of the first real security incident that has any amount of fame or any amount of publicity.

22:46Chris RomeoWe're still dealing with that problem. here in our current year.

22:50Robert HurlbutWe haven't eradicated it. Another one that I always laugh about, and so in the world of application security, I don't know if you guys are familiar, there's an organization called OWASP, the Open Web Application Security Project. Yeah.

23:00Chris RomeoIt's a not-for-profit.

23:03Robert HurlbutIt's volunteers all over the earth coming together and saying, hey, let's try and put information out to help people.

23:09Chris RomeoThe document they're most famous for is the OWASP Top 10.

23:12Robert HurlbutThis is the top 10 application security risks.

23:15Chris Romeothat you have to be considering about from a web application perspective. They've done 4 revs of this list.

23:22Robert HurlbutThe first one, I think, was in the early 2000s, and then the latest one is 2017.

23:27Chris RomeoThe funny thing is the number 1 thing on the list, injection, hasn't moved. It's still there.

23:34Robert HurlbutIt was there in 2004. It's still in the number 1 seat in 2017, and my guess is that when they put out the next one in 2021, it's still going to be in the number 1 seat. The point here is that we're not fixing the things, we're not moving things farther along fast enough for my liking.

23:53Chris RomeoAnd so I don't even have to worry about the things of the future.

23:56Robert HurlbutI have to— I'm still worried about the problems from the early 2000s and trying to catch everybody up and all applications up from that perspective. I really like that idea.

24:05Chris RomeoSo one of the tools we use in networking for kind of keeping ourselves up to speed is this idea that once you figure out how the protocols work at a base level, the new things are just like the old things.

24:15Robert HurlbutThey're just sort of repackaged.

24:17Chris RomeoAnd that's something that helps network people kind of accelerate and learn things that are really fast-paced. I'm really glad to hear you say that, that the threats are still in the same classes because the same leverage can then be applied to the security world and you don't have to constantly relearn everything from ground zero.

24:33Robert HurlbutIt seems like a, yeah, seems like a true principle to me.

24:35Chris RomeoIn episode 13, Michael Furman introduces us to SameSite cookies and the origins of SameSite cookies at Google.

24:43Robert HurlbutGoogle has changed and introduced a new policy. By the way, I do like Google, and I take— I want to take off my hat and to thank Google, to Chrome, to increase security in the world because, you know, there's zero project and They do a lot of issues to increase application security. So they have introduced the new policy. It means any cookie, if you have in your application have cookies, so in this case, cookie without any attribute will be treated as cookie with SameSite=Lax attribute. We will, maybe we will discuss about SameSite in details in a couple of seconds, but the importance of policy is that, let's say you don't need to do anything and one day you will deploy your application in Chrome and all cookies in your application will be treated as cookies with SameSite attribute. It means it will protect against the— against CSRF attack.

25:53Chris RomeoOkay. In episode 14, Anastasia Voitova explains the challenges with data security. What are some of the other challenges that you've seen in data security in particular?

26:05Robert HurlbutWell, right now, I believe that cryptography itself, it's more like a challenge in academia kind of thinking, because we have already these industry-proven ciphers and typical scenario that's kind of fun. Nothing important going there. But at the same time, we do have the regulations that are changing. And as companies that do something in the market, we have this pressure from data privacy regulations, which actually mean that, hey, we need to take care about users' data more and more and more. At the same time, we want to build easy, scalable, scalable, understandable systems, right? So sometimes these regulations versus typical engineering approaches, they're different. And in terms of cryptography, for example, we start talking about searchable encryption, right? Because regulations have this pressure that the data should be protected, encrypted, and it would be nice if the data could be encrypted all the time, but still, as developers, as architects, we would like to search through the data to do all this computation, but leaving the data encrypted. In a perfect world, leaving the data end-to-end encrypted. Imagine having a system with normal standard end-to-end encryption with ability to share data, with ability to search through data. I believe these are current challenges, and this is something that companies start to explore right now. I mean, at least it looks this way from my perspective because I'm into data security.

28:05Chris RomeoEpisode 15, Aaron Davis covers the threats of attacking the Lavamote tool itself.

28:15Robert HurlbutWhat are the, what are the potential threats about how somebody could actually attack Lava Mode itself embedded in an application? Yeah, there's, there's a few different things. There's like, uh, if you are— it depends what kind of package you're like trying to hijack in order to perform this attack, or however it's set up. If that package is already positioned to like, uh, deal with something like the network, then it wouldn't seem strange if it had network access, something powerful like that. Or, like I said earlier, a native module, something where it's trying to call out to C for the sake of performance or something like this. One thing that Lovemode does not do a good job of protecting against is things that don't require any fancy platform APIs like network access or exfiltration, but they kind of sit in the middle of your app and mess with the data as it flows through. And an example for MetaMask, we have transactions that are going through an approval phase and then eventually get cryptographically signed and sent off to the network. If you sat in the middle and you could mutate the transaction parameters and say, no, don't send money to them, send it to me, you didn't need disk access or network access to do that. You just messed with really important application data and it's throughput, and then, you know, the rest of the system carries off the attack for you.

29:38Chris RomeoIn episode 16, Caroline Wong discusses the perspective of pen testing from across the industry and the role of pen testing in modern security programs.

29:48Robert HurlbutI observed different behaviors at different organizations depending on their level of maturity. The vast majority of organizations— and while I was there, I did more than 3 dozen or so BSIMM assessments. The vast majority of folks that I met with were doing 2 things. They were doing pen testing and they were doing some secure coding training. Now that is not a bad way to start. However, if I look at folks on the more mature end, they've actually got security activities throughout the software development lifecycle and pen testing is not the whole thing. It's actually a check at the end to say, look, if all of our previous security activities were working the way they're intended, then we'd actually like to prevent or eliminate security defects before we get to production. And then what I see is mature organizations using the results of a pen test to actually indicate Where did the process potentially break down? So that it's not so much like an instance of like whack-a-mole, you know, find a bug, fix a bug, find a bug, fix a bug, but rather find a bug, examine the process. How did this bug get through? How did this get created in the first place? And then not only might you incorporate some sort of automated testing into a regression test, to try and eliminate that from coming up in future iterations, but also putting a step earlier in the process to try and prevent it from being created in the first place. So I think that it really depends in terms of an organization's investment in application security. It depends on their stage of maturity, but regardless, Pen testing is a way to try and break something before the bad people do. I'm really excited to be at an organization that is focused on pen testing. I find it to be endlessly interesting.

32:04Chris RomeoIn episode 17, Dmitry Sotnikov compares and contrasts the security between a REST API and MVC applications. Can you compare and contrast the security of REST API versus an MVC app?

32:24Robert HurlbutYeah, sure, absolutely. So in the good old MVC days, so you would have, again, that model-view-controller split. And so your browser would basically get HTML from the backend, from some sort of a web server. And so the server would have all the logic, like when I'm clicking something in the browser, the browser sends that information that I clicked something to the backend server. The backend server would have the code, would work, would have something, some code getting executed on the server, would work with the database, create me a new HTML page, send that new HTML page to the browser, and that's how I would get my new page. And so to protect— so that is a fairly safe architecture if you think about it because your clients don't really have access to your logic and obviously to your data, right? The data is behind your server and the server Just talks HTML to your browser. And so obviously there were attacks like whatever, your SQL injections, etc. But you could be relatively safe as long as you had like a reasonable web application firewall, WAF, where you would have some sort of rules that would detect those attacks, basically the signatures of different kind of SQL injections, etc., etc. And so you had a fairly well-defined edge and a fairly well-defined product and approaches to control that. In the modern world of IoT, as you mentioned, Chris, and single-page applications and mobile applications and microservices, it's a much, much difficult— different picture. Because now all of these clients are smart clients working directly with the APIs, but they have their own data cache. Like if whatever, if my mobile app, my mobile phone goes offline, I might still be able to continue playing my game or doing something. And when my connectivity is back, it will get new data from the cloud, it will sync back to the cloud, etc. So it will talk directly. APIs. And then my APIs often, again, it's just if I'm exposing data as a developer, if I'm exposing data to that client, to that mobile app or web app or IoT device, and there's another team working there, it's just much more easy for me from a design perspective to just expose all data and give access to all my functionality because that's sort of a clean separation between what I do and what the other team does. So it's very easy and natural for me to just give them more before they even ask and just rely on them being my security boundary. And so that means that people often don't realize that, that their security boundaries are now at the component level, on the API level, and that brings us into a much, much different picture when it's very easy to expose your sensitive functionality. It's very easy, extremely easy to expose your sensitive data without realizing that.

35:57Chris RomeoAnd our final clip comes to us from episode 18, where Frank Rietta covers the usage of Ruby on Rails and why it's not just for early-stage startups. And when you think about Ruby on Rails, A lot of people will say, that's just for early-stage startups. It's something they use to be able to build and deploy apps quickly. What's kind of your response to that? Is Ruby just— Ruby on Rails just for early-stage startups?

36:26Robert HurlbutI would say no, but I want to go back to another lesson. If you're a student of computing and you go back to the '80s, Microsoft Excel was not the spreadsheet. of the day. VisiCalc was, but then Lotus 1-2-3 was super strong, but then Excel took over. And the story goes, if I recall correctly, was Lotus was in the middle of a rewrite of their application for various reasons, and rewrites never happen as fast as you think. And in that time, Microsoft slipped in and gained market share, and Lotus never recovered. So rewriting your software as a mid-stage or growth-stage startup can be a very bad idea for all sorts of reasons. So if you start on Ruby on Rails, you're very likely to wisely choose to stay on Ruby on Rails unless your scaling issue is really unique. So Twitter famously started on Ruby on Rails. But then got off of Ruby on Rails because— not because Ruby on Rails was slow, but it turns out you can't run Twitter at scale as a web application backed by a relational database. They had a very, very niche-specific communication platform need that had different engineering approach needed. There are other companies. Basecamp, obviously, is on Ruby on Rails. and others that they've created. Square, the credit card startup, is on Ruby on Rails. Shopify is on Ruby on Rails. I mean, you can go down this list. I don't know exhaustively off the top of my head, but these are some massive companies doing a lot of business, continuing to run on Ruby on Rails, and that is not an issue for them. It's still a good technology choice. I am— I can't name names, but I am directly aware of enterprises that have Ruby on Rails as part of their infrastructure. It may not be that they have a ton of stuff written, but some of their web services were written in Ruby on Rails, and so those are something they have to support as part of their portfolio of applications. I am aware we have on our client base several government agencies, state government agencies that had custom software written in Ruby on Rails, and now their agencies utilize this software heavily. And so supporting it over long term is something that we help them with to make sure that it's kept up to date, that it's secured, you know, that it continues to function as, you know, new Rails versions come out. So it's all over the place. I don't have like market share figures in front of me, but it's out there and it's only growing.

39:22Chris RomeoAnd just like that, we've reached the end of season 7 of the Application Security Podcast. We hope that this wrap-up episode's been useful, perhaps as a pointer to some other episodes that you might want to go back and listen to the entire interview. We also have a YouTube channel, Application Security Podcast, where we have video-based versions of many of the interviews we did this season. And we want to thank you as our listeners and let you know we'll be back very soon with season 8 of the Application Security Podcast. Thanks for listening to the Application Security Podcast. You'll find the show on Twitter @AppSecPodcast or on the web at www.securityjourney.com/appsecpodcast. You can also find Chris on Twitter @edgeroute and Robert @roberthurlbut. Remember, security is a journey, not a destination.