---
title: "Matt Konda -- OWASP Glue"
url: https://appsecpodcast.com/matt-konda-owasp-glue/
date: 2019-01-18
duration_seconds: 2147
guests: ["Matt Konda"]
topics: ["OWASP Projects"]
audio: https://www.buzzsprout.com/1730684/episodes/8122656-matt-konda-owasp-glue.mp3
transcript: true
---

# Matt Konda -- OWASP Glue

*January 18, 2019 · 36 min*

with [Matt Konda](https://appsecpodcast.com/guests/matt-konda/)

on [OWASP Projects](https://appsecpodcast.com/topics/owasp-projects/)

[Audio](https://www.buzzsprout.com/1730684/episodes/8122656-matt-konda-owasp-glue.mp3)

## Show notes

Developers need useful findings in their workflow, not another collection of security tools to operate by hand. Matt Konda explains how OWASP Glue grew from that problem: run multiple tools, normalize their output, and make the results usable in a build or development process. He shares his path from software development into AppSec, the thinking behind Jemurai, and why OWASP’s community appealed to him. The technical discussion compares Glue with Gauntlt and DefectDojo, examines integrations and extensibility, and considers how open-source projects can work together. Matt closes with a straightforward way for an individual developer to try Glue. Throughout, the focus is on connecting security work to engineering habits and making automation produce information people can act on.

The Application Security Podcast is brought to you by [Security Journey](https://www.securityjourney.com/).

About Security Journey  
Security Journey provides application security education for developers and everyone in the software development lifecycle.  
→ [Learn more about Security Journey](https://www.securityjourney.com/)

Connect with Matt Konda:  
→ [Matt Konda on LinkedIn](https://www.linkedin.com/in/mattkonda/)  
→ [OWASP Glue source code](https://github.com/OWASP/glue)

Mentioned in this episode:  
→ [Gauntlt](https://github.com/gauntlt/gauntlt)  
→ [OWASP DefectDojo](https://owasp.org/www-project-defectdojo/)  
→ [Brakeman](https://brakemanscanner.org/)  
→ [ZAP](https://www.zaproxy.org/)

Chapters:  
00:00 Connecting security tools with Matt Konda  
01:09 From software development into security  
04:34 Bridging the gap with development teams  
08:55 The story behind Jemurai  
10:34 Tools, processes, and useful security signals  
13:33 Finding a community in OWASP  
17:08 Why OWASP Glue was created  
19:52 Comparing Glue with Gauntlt and adding tools  
26:01 How Glue relates to DefectDojo  
29:48 Improving commercial tool integrations  
31:59 The easiest way to start using Glue  
34:47 Final thoughts

## Transcript

*6,369 words · assemblyai*

**0:01 Chris Romeo:** Hey folks, season 4, episode 24 of the Application Security Podcast. On this episode, we're joined by Matt Konda, who talks to us about his experiences in OWASP and also about the OWASP Glue project. You're gonna have to tune in here to understand what the OWASP Glue project even is. We hope you enjoy. The Application Security Podcast. Here we go.

**0:53 Robert Hurlbut:** Hello friends, and welcome to another episode of the Application Security Podcast. This is Robert, and I'm joined with Chris, and we are also joined by Matt Konda. Thanks for joining us, Matt.

**1:04 Matt Konda:** Thanks for having me, Robert and Chris. Good to be here, and, uh, been fans of yours for a long time.

**1:09 Robert Hurlbut:** Great. Well, glad to have you here. So tell us about your security origin story.

**1:16 Matt Konda:** So I've been a developer. I still consider myself a developer. And I built primarily business software. And then I went to a security company, um, Trustwave, and I worked on the sort of infrastructure for a lot of the security tooling there. While I was there, I had my apps beat up by the pen testers there, and I realized that I didn't know nearly as much as I thought I did. I considered myself to be a pretty good developer, but I didn't know a lot. I didn't know anything about cross-site scripting. I can tell you how I thought. I saw the first, you know, popup and thought to myself, well, who cares? Like, why does that even matter? All kinds of stories like that. And I realized that there's sort of a big gap in communication between developers and security professionals in a lot of cases. And And so, um, I ended up working with a guy named John Rose, um, a fair amount. We did this Builders Versus Breakers talk at AppSec USA in 2012. So that was kind of where— that was like a splash into the OWASP community for me. And I didn't really know that much about it even then, so you might be surprised to hear that. Um, but I, I was getting deeply involved In that talk, we basically played the, hey, what are the developers' incentives and what are the pen testers' incentives? And the developers' incentives are really not really aligned around security. It's usually around timeline. It's usually around features. And, you know, whether something is secure isn't black or white. So, you know, stakeholders can't say, I want it to be secure, and that means anything to either the security or developers, right?

**3:07 Robert Hurlbut:** Yeah.

**3:08 Matt Konda:** So we were trying to sort of dive deeper into the detail around how you break through that problem, right? How you start communicating between those teams and so forth. And through that process, I got involved in OWASP in Chicago and did a few more talks and started doing training. And then in 2000— early 2013, I started Gemerai to basically try to focus in on that specific problem, to go after companies that needed training, and not just sort of, you know, classroom training on SQL injection, although that is important, but also like, well, how do you do stuff in your SDLC? How do you break down process? How do you build better capabilities? And so I think that's really the origin story. I did do, it's kind of funny, I did do a lot of math when I was in college and before, and—

**4:03 Chris Romeo:** Oh, wow.

**4:04 Matt Konda:** I did a master's degree in computer science and I was really interested in cryptography. But then when I finished, I realized that the types of security jobs I wanted, which was— this was about 2000, you know, there really weren't a lot of developers doing security that I knew of at that time. You had to go be sort of a sysadmin or something kind of that I thought was different than development back then. And so it was really kind of cool to come full circle around. I'm sorry for the long-winded answer. I hope that makes sense.

**4:34 Robert Hurlbut:** Oh no, no, absolutely. I can relate. You know, my background was software development as well, and getting into security and what are the options a number of years ago, it did seem that most focus was on network security. So I'm with you on that. So whenever you started to make that transition from development into security, one of the things that you mentioned, I kind of caught on because I've had similar experiences in making that transition and then going back and talking to developers. What are some of the things that you've noticed? I know you mentioned you also started a company to help you do that sort of thing in terms of training and so forth, but what are some of the things that you've noticed in terms of bringing security information to developers?

**5:22 Matt Konda:** Well, I like to approach that whole problem, and I think this is very aligned with the work that Chris does, although I'm only tangentially aware of it. I haven't had direct experience, but I like to think of it as we're empowering developers, and developers are really smart, right? It's just that they're sort of— it's almost like if they're wearing a miner's hat with a light on it and they're in a cave. It's like they're looking over at one side where there's a feature and they need to go figure out how to make the payment go through faster so that the whole system goes— works better, or, or so that they know what the user needs, right? And if we just sort of get them to move their head around a little bit and look in the other direction where there's like a, I don't know, some monster sitting in the dark, they might be able to actually build something defensive or at least proactively safe. And so the approach that we— that I try to take is you know, actually communicate a lot, overcommunicate, talk with developers about, like, what's the significance of this issue? Because, you know, I'm one person. It's much more powerful for me if 5 developers walk out of a day-long session, like, really motivated and, like, they're looking at a lot of code over the next couple of weeks, right, before we meet again, maybe. And, like, that amplifies the impact of that session and that education, right? I can go find a bullet list, as I'm sure everybody who's listening to the podcast can, go find a bunch of problems, Right? But if I can sort of enlist developers and get them motivated and on board and teach them maybe how to have the conversation with the stakeholders about, well, what are the expectations about security? A really good example of that— and cut me off anytime— but a really good example of that is, you know, in the security community, we tend to say, okay, multifactor authentication is always good, right?

**7:19 Robert Hurlbut:** Yeah.

**7:20 Matt Konda:** And I've worked with clients where the stakeholders will say, our users won't tolerate multifactor authentication and it's a business system, so we're not gonna do it. And my position on that is that's their decision to make, right? As long as I've explained to them what the risks are, then I don't— I can't bear the responsibility for the choice that they make, right? The problem in a lot of cases is that that conversation doesn't happen And that sort of weighing of risk doesn't happen. And so part of the developer engagement is getting them to think about, well, what could go wrong? What are the risks? How do we make sure the stakeholders know what they're asking us to do? Does that make sense?

**8:00 Robert Hurlbut:** Absolutely. Yeah, and it is an interesting dynamic. As you said, that a lot of times developers may be thinking about performance or timelines or other kinds of things like that. And thinking about risk or thinking about what could go wrong, the threats and so forth, I mean, that is definitely different. And so it's, you know, when you have developers or architects or anybody who is involved in software development start to think about that and start to integrate it in, I mean, we always talk about trying to get security in early. I mean, that's one of the things that we can, I think we can do. Certainly, you know, one of my endeavors as well, but, you know, curious to hear your take on it. Thank you. So here's something we were talking about before we started recording. We were talking about the name of your company, Gemurai. Tell us a little bit about that, where that came from.

**8:55 Matt Konda:** Well, so, you know, it's actually not very easy to go get a 7-letter top-level .com domain anymore. And I reserved Gemurai in, I think, 2002. And it's the combination of Jedi and samurai, which I thought was really cool. Initially, I had intended to use it for actually like a volunteer site, to be honest with you. It was like, oh, let's make this like a way that people can like donate their very specialized skills to things that need them, right? So you could take your cyber skills and apply them to, you know, a nonprofit down the street, or an attorney could do that or something. That was the original vision, which I'm not actually sure anybody even on my team knows that. But then when I sort of stopped and wanted to, to be more of a company, it actually still fit because at the time everybody talked about ninjas. Um, you know, I remember going to DEF CON and it's like ninja this, ninja that, and I, you know, kind of— it's kind of a cool thing, but I sort of always was drawn to the samurai who had this sort of specific code of ethics. And I lived in Japan for a year and So I had like a reason to be interested in that sort of cultural concept. And so it means a lot to me, but it, you know, it doesn't necessarily mean as much to our customers 'cause it doesn't immediately convey all that. And I thought the Jedi part was cool because then you're like, you bring technology or sort of, I think of them as, I think of Jedi as also having sort of principles, but then being like, you know, it's science fiction, right? So it's like way in the future, they can do all these things and they have lightsabers and all that. Yeah.

**10:31 Robert Hurlbut:** Very cool.

**10:32 Matt Konda:** Not necessarily the answer you're looking for.

**10:34 Robert Hurlbut:** No, no, I mean, everybody has a story, and so I was just curious about that one in terms of your origin story there. So very cool. And through the company, it looks like you've again worked on helping bridge gaps with developers. I mean, are there tools or anything like that, processes that you've helped introduce as well?

**10:58 Matt Konda:** For sure. So we do, I mean, we actually are building, we're building cloud tools. So we have a tool called JASP, which is an AWS sort of security analysis tool that we're building as like a stage 1 of a security integration platform where it's sort of API first, you can publish findings and so forth. I'm not necessarily intending to come and talk about all that. I mean, I'm happy to talk about it, but I'm not trying to push it at all. But we do tooling. We're actually trying to figure out if we can open source, and maybe we'll be able to donate them to OWASP. I'm not sure. Kind of depends on if we can get them to be good. Some validation libraries and something that we end up working on with a lot of clients is security signal. So people who want to be able to see sort of the A10 types of things, you know, failed logins or exceptions being thrown or validation failures, like somehow they want to see those in their regular security stream. So we end up, you know, basically bridging app logs into syslog or whatever and annotating accordingly so that they can track those down. Trying to think of other things we've done. We've done a bunch of training. We'll do— we'll help people build AppSec programs, including sort of starting with inventory, breaking down like, well, what applications do you have and how do you find out, right? We've seen everything from Google Spreadsheets to manage that to custom systems where, like, larger companies with thousands of services have, you know, these sort of service registries that they want to use to be able to automatically engage and know, you know, what their applications are. So, if you're building something over here and you need an API, you don't have to, like, you can figure out who owns that other project and how to talk to it. And obviously, it's better for security if we can piggyback off of those existing infrastructure pieces. And then, of course, sort of judoing that into how do you take 1,000 services and do security on that, right? Like, you know, obviously, one part of that is breaking it into tiers and figuring out what matters the most and then what kinds of things are expected for which tier. So, we like to break it down that way so that you've got, you know, okay, we're gonna do training for everybody, or we're gonna do training for everybody who works on anything that ever touches sensitive data, or...

**13:10 Robert Hurlbut:** Right.

**13:10 Matt Konda:** However you slice and dice up those tiers and applications, you have to have a way to do that because you can't do everything for everybody. So that's kind of, I guess, kind of the main thing we do. I mean, we do do some of the classic things like pen testing and code review. I actually really like doing code review. It's one of my favorite things to do, but yeah. Okay.

**13:33 Robert Hurlbut:** Yeah, thanks. No, I'm just curious about, you know, in terms of your story and so forth. I'd like to also turn our attention to OWASP. I know you've been very active in OWASP, in the last number of years. You said you started around 2012 or so when you actually spoke at AppSec USA. I mean, what attracted you to OWASP in particular?

**13:53 Matt Konda:** Well, so out of all of the conferences I went to and the communities that I found, OWASP had both. If I went to the conference, the talks seemed relevant to me, and I could go to a chapter meeting and meet people who were struggling with the same things I was. And there's sort of this open information. So whenever I need to go find out a solution to something, you know, there are good— lots of good resources, but OWASP is consistently a very good resource. And that's kind of what drew me to it. I also saw a community that was rich with people who are contributing a ton, right? Like doing all kinds of different things. And I felt at the time like there was just this gap between like the AppSec practitioners that were in OWASP and developers. And I actually surveyed, I think, 200 developers that I worked with. Um, I live in Dallas, Texas now, but I lived in Chicago for most of this time. And so that's where I did the survey. And I surveyed something like 200 developers and not just at the company I worked at. So like I tried to get outside of the security company about how many people knew about OWASP. And out of the 200, it was something like 6. It's like 3% of the developers. This is back in, you know, 2010.

**15:14 Robert Hurlbut:** Yeah. I was wondering what, when that was that. Okay. 2010 or so.

**15:17 Matt Konda:** So it was like, this, this is, you know, not 10 years ago, but almost, you know, and, and I realized that, that, you know, maybe there's a way to amplify or to get across that bridge. And Now, I think that number would be much higher. I think it's become, you know, we've, we have been in certain ways, we've been effective. I think there's lots and lots of opportunity to do better. Believe me, I'm not at all satisfied with where we are, but I do think that, that, you know, if you went to AppSecUSA this year, you would have seen Facebook, Apple, Microsoft, you know, one of our big sponsors, Allstate contributed $100,000, right? It's like, and it's not to call them out as like a specific thing, but these, it's not a security company, right? People see the benefit of the OWASP community outside of, you know, the traditional security vendors who were the sponsors of OWASP for a very long time. And again, those are important people. I'm not necessarily trying to take away from that in any kind of way. I wanted to get to the Apples, to the companies that are building the software that we use all the time so that we could sort of see the ripple of application security knowledge go out to developers, you know. Netflix is another one. I didn't mean to leave them out.

**16:29 Chris Romeo:** After the break, Matt explains more about the OWASP Glue project. The Application Security Podcast operates with support from Security Journey. A security belt program provides the 3 pillars of successful AppSec training: learning, application, and experience. Visit us on the web at www.securityjourney.com to learn how you can teach and empower your developers using a new kind of security training. Matt dives back into what is the OWASP Glue project.

**17:08 Matt Konda:** Yeah, so Glue originated when we were working with companies that wanted to do— originally they wanted to do static analysis, on languages that didn't have good coverage in commercial tools, and they wanted them to integrate into their developer's toolset. So, the use case was, hey, like, I wanna build, I want this to run either in Jenkins or in some kind of build system, and I just wanna know what the issues are. Like, I don't care what the tools are, honestly. Like, that's kind of the idea. So, and at the time we were working with a couple of companies, their main languages were actually Ruby on Rails. And we had Python companies and there was a fair amount of Java, but really Ruby and JavaScript were probably maybe the biggest. And so we thought, oh, okay, let's make Breakman and Bundler audit and some of these tools easier to bring in. And then how And then let's make it so that we can push those results out to Jira or TeamCity or Pivotal Tracker and make those— make that sort of easy because that process is abstract. There's nothing about that that's unique to each tool. And I don't know if this is a fair critique, but I feel like a lot of the security folks that end up writing a lot of code end up writing sort of cool exploit things or, you know, neat hacker tool things. And so it felt like there was an opportunity to do something that was less glamorous, in a way, like more just everyday kind of stuff, but that fit, pulled those tools together. And that's why we call it Glue because it kind of, it just pulls those tools together, runs them and does the work so that you don't have to sort of know how they work, right? So now you could take a Docker image of Glue. You could run Glue by just saying docker run owasp/glue at your Git repo. And it'll run a bunch of security tools against your Git repo and pump, put, put out text. You know what I'm saying? And so you don't actually have to know how to set up any of stuff. You don't have to set up Python. You don't have to set up Ruby. You don't have to set up Java. Like it'll just do all that. And that Docker image is bloated. There's a bunch of reasons why it's not ideal. I'm not necessarily saying we've solved the problem perfectly or anything, but it represents an example and something. And I don't know if you're interested at this level, but I would be very happy to go one level deeper into like sort of the technical design of it, because there are some interesting abstractions that we made that might be sort of conceptually interesting even outside of Glue. Is that something that you would like to hear? Yeah, I would.

**19:52 Robert Hurlbut:** One quick question I do have, just thinking about different tools that are out there. I mean, I'm familiar with Gauntlet, which also pulls together a bunch of security tools that you can run. You can, you can call it and then it runs all these other tools, but I'm curious about the similarities or differences between something like this. I mean, it looks like these tools that you pulled together, Brakeman, as you mentioned, Retire.js, and so on, are definitely security tools, application security tools. Is that one of the differences? And maybe if I'm reaching here in terms of comparison, but I'm curious about that, as well as how do you add additional tools Or can you add additional tools to it? I guess there are a couple of quick questions I have.

**20:39 Matt Konda:** Yeah, that's a great— those are both great questions. So Gauntlet, we've actually considered adding support for Gauntlet to Glue. I'm a fan of Gauntlet and James Wickett. He's one of the people who got me, maybe not even intentionally, got me excited about the OWASP board. But Gauntlet, I look at it as, it's very cool. It's, I think of it as being sort of, you're writing behavior-driven sort of test code and it's resulting in the Gauntlet tool running the tools you want or doing the things you want and then checking the results. And so I think, I mean, I think Gauntlet is cool. I think Glue is a little bit different. I think Gauntlet's more like something you'd run, at least all the times I've used it and the examples I've seen are sort of, you're running Nmap and you're seeing that, you know, the test fails at ports open that you don't intend to have be open.

**21:33 Robert Hurlbut:** Right. SQLMap and so forth, right?

**21:36 Matt Konda:** Exactly. So, it's kind of wrapping those sort of almost live tools and giving you sort of expected results, which is very powerful because it reduces false positives, right? So, if you know that everything that comes out of Gauntlet is real because you wrote that test, it's cool. I think Gauntlet was there when we started writing Glue, but it seemed different. I live-coded a task in a 30-minute session, a new tool, integration of a new tool into Glue at AppSec USA. And during, like, one of the project days, like, these half-hour project showcase slots. And one of the actually most exciting things about working on Glue for me has been the emergence of other people who wanna work on the project. And in particular, there's a guy in Israel, Omer Hevroni, who has— he's become a co-project leader. In fact, he's in a lot of ways leading the project week to week now. And he, you know, he— they— so they invited him to do it and he couldn't do it. So I jumped in and did it, but we basically in a half hour live coded a new task. We integrated a Python dependency check type of tool. So there's a tool in Python called security check, I think, which seems almost like so generically named it's hard to know what it is, but it's checking to make sure you're not using older libraries. And so we did that live, like, in the session. So it's very easy to add tools. That's sort of the intent of the architecture, is to make it so that you can add any tool and you could add any output. And So, I sort of think of it almost as a pipeline where there are stages of work that Glue's gonna do. And in the first stage, we're sort of mounting a file system somehow, right? So, we either need to get source code, or we wanna look at a local file system, or we wanna open a Docker image, or we wanna open an AMI, or like, there's a bunch of different ways of getting what we wanna analyze, right? And so, I think of that as the mounter. And I, I could point you to slides for that that you could put in your show notes if you would like.

**23:46 Robert Hurlbut:** Okay.

**23:47 Matt Konda:** that kind of show in a picture what this is. And then there's sort of file-level things that we can do. And so file-level things might be antivirus or Hashdeep, or there are a couple things that you could do just sort of purely based on file signatures without even knowing what code is there. And then there's sort of a code phase where we're running any kind of security code analysis tool. And then there's a live phase. So we've actually driven ZAP off of this tool where we can, you know, basically run ZAP in a Docker image, connect by the API, start a scan, get the results back out of the scan, put them in Jira based on what the 2 stages I'm about to describe. So that's kind of the live stage.

**24:30 Robert Hurlbut:** After the—

**24:31 Matt Konda:** those 3 stages run, you basically have a collection of findings. Um, and one of the things that's, you know, the work is running the tool and then taking whatever it puts out. Usually it's like XML or, or JSON or something like that, and turning it into a standard format, right? So that we can do whatever else we're going to do with it. And then there's a filtering phase where during the filtering phase, we basically dedupe, we remove certain classes of things, and you can go write whatever filters you want to be able to essentially take the noise out. And then there's the reporting phase. The reporting phase is the thing that actually takes each list in your each item that's in your collection and pushes it out to whatever tool you want it to go to, which, again, I keep saying Jira, but that's the one that seemed to be in the most demand. And so, again, Glue is like, it's not a really, it's not like technically groundbreaking in any kind of way. It's just sort of trying to be the thing behind the scenes that pulls these different tools together and makes it easier to put security into your build process. And we ended up building, a GUI that was around it at one of our clients, and it's a tool called CodeBurner, which you could go find on GitHub. And so it would basically control Glue and then give you a UI to manage the findings that came out of it if you wanted. So there's a bunch of neat things there. Again, I feel like I've talked a lot, so I don't wanna—

**26:01 Chris Romeo:** Yeah, so Matt, I've actually got another question here about So when I, when I'm hearing you describe Glue, it's sounding a lot like there's a lot of similarities with Defect Dojo as well. So is there overlap between these 2 tools, or, or kind of what's your, what's your kind of take on Defect Dojo versus Glue?

**26:20 Matt Konda:** So it's funny, um, I'm a fan of Defect Dojo. I think it's good for everybody that there are different projects doing different things. We were not building a UI at all, so if you want a UI, you can go get DefectDojo. That's, that's going to be better for that. If you want to extend DefectDojo, I believe it's written in Python, so it's probably better if you use Python. If you're interested in using Ruby, Glue's written in Ruby. Again, that's not a good reason to have different tools. It's just sort of looking at the differences. I think of Defect Dojo as being more like where I want to manage my issues, more so than where I want to run tools. But I understand that that has probably eclipsed my even understanding. And I mean, this is an interesting— I don't want to segue away from Glue too fast, but it's an interesting challenge for OWASP in general where you really want people to go make projects. And so I have energy, I'm going to go do a project, I'm going to do something that's really interesting to me, right? And I'm going to do it my way. And whether that's a winning project is not really my decision, even if it's my project, right? It's going to be how the community receives it, how useful it is, how well it's done. And it may or may not have anything to do with any of the technological underpinnings of that system, right? So It's not like one's better than the other because of X, Y, and Z. You know what I'm saying? And so it's weird because it's good to have diversity in that toolset, right? We, we, we wouldn't have sort of evolution of, of tooling if we didn't have people like coming up with a crazy idea and then doing it and then having it turn into something. Like a good example of that is like take mod_security, right? So mod_security, the rule set is a, is an OWASP project, and that's now become such a common tool that everybody knows what it is. It's kind of just there, right? But I'm not sure that would have emerged and become as widely used if OWASP hadn't been there behind the scenes kind of thing, you know what I'm saying?

**28:31 Robert Hurlbut:** Yeah.

**28:32 Matt Konda:** So, it's like, it's good to have this diversity of projects, but then what the, like, end users need is, hey, I need the really mature project I can go use, right? And I think it's likely that DefectDojo is more mature than Glue in certain ways. And so I'm not necessarily— I would never say use Glue instead of DefectDojo. I don't know that you can run DefectDojo sort of in your build process. I might be wrong, but I'm not aware of that. We were really aiming to fit into CI/CD. That was kind of our main goal.

**29:05 Chris Romeo:** Yeah, and I see that as— that's what I see as a difference. I mean, I've I've talked to— we talked to Matt Tesaro a few episodes ago and kind of heard all about Defect Dojo and where it came from. And based on how you're describing Glue, how he describes Defect Dojo, it seems like Glue is much more CI/CD in the pipeline, very well integrated. Defect Dojo, like you said, gives you that bigger enterprise kind of management side of the different findings and things that you're getting. So yeah, I don't see them as competing. I see them as complementary to each other. But like you said, diversity is good in the OWASP project world, and we want to have a lot of people building cool stuff. And in an open environment like OWASP, sometimes there's going to be some overlap, and that's okay because cool things are coming out of it.

**29:48 Matt Konda:** Exactly. And like, I look at it as even like we did an integration with Checkmarx with Glue, right? And I'm not endorsing any product here. We did it because a client was using it, right? The cool thing is, you know, we get to go say, hey, you know, your API kind of sucks. Can you like actually improve this SOAP API? And maybe give us a JSON API. Like, we're gonna do an open tool around this, right? So I look at it as, you know, whether you use Glue or not, like, like there's little micro steps toward pushing vendors or other people to do more open APIs that we can integrate better with. And again, whether you're using the tool or not, hopefully you're gonna use the API for those tools because nowadays you can't, I mean, hardly anybody's just, I don't think hardly anybody's like just running the security tool in the, security tools environment and never wanting to get data out of it with automation, right? Automation's the whole, like, like the thing that, that's like the holy grail of what we want to do earlier in our process, I think.

**30:45 Robert Hurlbut:** Yeah, I agree. That's, I mean, that's, that's what's attractive, right? If you can, if you can automate it, if there's a way to automate, if you can, whatever tool that anyone may be using, it's good to know what options are out there and how can they be managed or updated or automated in some way. So I think that's always a win just to know if that's available.

**31:09 Matt Konda:** Yeah, it's like I'm a fan of ThreadFix too, right? But it's sort of solving a similar problem but from a slightly different angle, right? They're all a little bit different. It's ingesting all these things and pushing them into, you know, deduping and putting them in another place. You could look at it as having a very similar goal, but it's also much more UI-driven, right? So, and it's probably more sophisticated in certain ways and not doing other things, right? But, but I look at it as, hey, it's good for everybody to have these things pushing each other to go to get better.

**31:44 Robert Hurlbut:** Right.

**31:44 Matt Konda:** Personally, just like when I'm on a project, I'd rather use something that I can just open up and hack on and then, you know, give somebody the solution rather than a commercial tool I have to go, you know, Figure out how to break it to do something different than what it's supposed to do.

**31:59 Chris Romeo:** Yeah. Matt, so maybe one way to kind of help bring this all together here for our listeners, a lot of them who are developers and are always looking for new tools. If somebody wants to go out and use Glue today, very simply, how would you recommend they start using it in the easiest, the least path to resistance for them as an individual dev?

**32:24 Matt Konda:** So, hopefully Docker is not a big hurdle. And so, the nice thing about using Glue from Docker is that it takes away a lot of the setup work and a lot of the context. And while I would like to see everyone run Glue in Jenkins or Travis or whatever, the details of that, especially with Docker and credentials, get to be— like, there's a little bit of a devil in the details there, like, to go solve that. But you can get immediate feedback by running, you know, literally the command I mentioned before, docker run, docker space run space oasp/glue. And if you're using, like, if you look at the docs and you know which tool you want to run, you can do like a -t breakman or -t bandit if you're using Python or you know, so forth. And then it'll basically go run that tool and show you the output. So you can get sort of immediate security feedback without having to do sort of tool setup. And if you don't put a tool in, it's going to run essentially anything that applies for that kind of code. So it doesn't actually inspect the code to know, so it's not very advanced, but it will run all the code tools against the directory you give it. And just to kind of, I don't mean to, sorry, it's a little bit of a tangent, but I was working with a client today where they have a project that's all Elixir and Phoenix. So, Elixir is, like, a new cool language, right? And there's a static analysis tool that's open source for it. So, I thought to myself, well, of course, we should integrate that into Glue, right? Because now we can make it super easy for everybody who's doing Elixir to get static analysis. It's not hard, to do it yourself, but it's just, oh, now I can add that static analysis and I can get the results somewhere that I care about.

**34:14 Robert Hurlbut:** Yeah, definitely great stuff. I mean, I think this is something that, again, as Chris mentioned, developers want to know about. And if they can, I think— and when you said about Docker, I mean, that seems to be almost the standard these days that developers need to know about Docker. Most developers I know today they know about Docker, or at least they're aware of it. So I don't think it's a hurdle as it used to be. But good stuff.

**34:45 Matt Konda:** Okay.

**34:47 Robert Hurlbut:** Well, Matt, thanks for joining us. Is there any other last thoughts or comments that you'd like to leave for our listeners?

**34:54 Matt Konda:** I would just— I mean, I think you were both very involved with the last call. I would just encourage everybody to be To get— just to get and stay involved, find projects that you're interested in, go to chapter meetings, you know, to the extent that you're interested, pay attention to what's going on at the sort of community level and help us. It'd be great. Thanks for listening to the Application Security Podcast. If you enjoy the podcast, please do us a favor and visit the iTunes Store and give us a 5-star rating. Our intro music is 8-Bit Kung Fu by Born Lauren and TJ, and the outro is Southern Delight by Stefan Cartenberg. You can find us on Twitter @AppSecPodcast or on the web at www.appsecpodcast.org.

---

Source: https://appsecpodcast.com/matt-konda-owasp-glue/