We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

The World of Rails Security

00:00

Formal Metadata

Title
The World of Rails Security
Title of Series
Part Number
81
Number of Parts
94
Author
License
CC Attribution - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
Learning to keep your Rails application secure is an often-overlooked part of learning Rails, so let's take a trip through the world of Ruby on Rails security! The journey will start with an overview of security features offered by the popular web framework, then we'll detour through dangerous pitfalls and unsafe defaults, and finally end with suggestions for improving security in Rails itself. As a bonus, we'll talk about how to integrate security into the development process.
InternetworkingSupremumPresentation of a groupInformation securityMultiplication signMetropolitan area networkComputer animation
CASE <Informatik>Search algorithmSeries (mathematics)Execution unit
Cross-site scriptingView (database)Escape characterInformation securityHacker (term)TwitterHTTP cookieNatural numberWebsiteBitWeb browserMereologySheaf (mathematics)Key (cryptography)Degree (graph theory)Pattern languageDefault (computer science)Exploit (computer security)Content (media)Token ringSynchronizationWritingCASE <Informatik>Generic programmingSoftware frameworkTerm (mathematics)SoftwareVarianceCartesian coordinate systemTheoryQuery languageInterior (topology)Arithmetic meanFood energyPhysical lawSurfaceData managementInsertion lossMultiplication signLevel (video gaming)Software developerWordExecution unitIntegrated development environmentSolid geometryBit rateResultantData recoveryState of matterCorrespondence (mathematics)Raw image formatFrequencyStandard deviationData structureComputer animation
Endliche ModelltheorieRight angleAttribute grammarInjektivitätComputer configurationContent (media)Form (programming)InternetworkingHTTP cookieMessage passingWeb pageSoftware frameworkType theoryConfiguration spaceQuery languageMeta elementDefault (computer science)Information securityToken ringLink (knot theory)AuthenticationDifferent (Kate Ryan album)Goodness of fitDirection (geometry)MassEmailConnected spaceoutputImplementationGroup actionExecution unitTime seriesOrder (biology)Set (mathematics)MathematicsInsertion lossPhysical systemMereologyComputer programmingFormal languageMultiplication signSparse matrixVolume (thermodynamics)Residual (numerical analysis)Parameter (computer programming)Shared memoryTask (computing)DemosceneComputer animation
Web applicationEscape characterGreatest elementException handlingLink (knot theory)HTTP cookieCross-site scriptingSoftware bugDefault (computer science)Token ringParameter (computer programming)Form (programming)BlogGoodness of fitMoment (mathematics)Client (computing)Optical disc driveMatching (graph theory)Revision controlResultantElectronic mailing listFormal grammar1 (number)Video gameOnline service providerNatural numberCASE <Informatik>Lattice (order)Term (mathematics)Right angleDatabaseMusical ensembleMultiplication signProcess (computing)Arithmetic meanNetwork topologySystem callCore dumpGroup actionComputer animation
Semiconductor memoryFocus (optics)Domain name1 (number)State of matterRight angleOntologyAreaDialectResultantRootPoint (geometry)Square numberMedical imagingParameter (computer programming)WebsiteMassGroup actionMultiplication signQuery languageClosed setWordTotal S.A.CodeTraverse (surveying)Server (computing)QuicksortComputer fileCodierung <Programmierung>Validity (statistics)HTTP cookieBoom (sailing)Structural loadElectronic signatureDatabaseAuthorizationMobile appInformation securityInjektivitätFilter <Stochastik>Web 2.0Software frameworkInheritance (object-oriented programming)Row (database)Keyboard shortcutData managementDirectory serviceData storage deviceEndliche ModelltheorieComputer animation
Classical physicsBitElectronic mailing listQuery languageInformation securityMereologySocial classParsingCore dumpCodeInjektivitätRight angleException handlingoutputEndliche ModelltheorieTheory of relativityResultantBit rateSystem callSound effectWater vaporSource codeVideo gameUtility softwareForm (programming)Group actionProduct (business)TrailAreaTransportation theory (mathematics)Time zoneView (database)Computer animationLecture/Conference
DivisorExecution unitComputer-assisted translationDigital photographyProcess (computing)NumberMusical ensembleComputer animationLecture/Conference
FrequencyRight angleMathematical analysisRule of inferenceElectronic mailing listMedianProcess (computing)Bit rate1 (number)Point (geometry)Library (computing)Information securityLine (geometry)Reverse engineeringSpacetimeRevision controlMereologyProduct (business)WordGradientAreaState of matterTask (computing)MathematicsVideoconferencingUniverse (mathematics)Power (physics)Orientation (vector space)Stability theoryContinuous integrationVulnerability (computing)EmailFluid staticsPlanningSoftware developerInclusion mapType theoryGraph (mathematics)Digital rights managementCodeMultiplication signSoftware repositoryGoodness of fitCondensationGreatest elementQuicksortCommitment schemeComputer configurationPlug-in (computing)Analytic continuation
Transcript: English(auto-generated)
My name is Justin, at President Dean, we want the internet everywhere, it's talk to me. I'm going to be talking about Rails Security, as indicated by the title of the talk.
Quick announcement though, there was another security talk scheduled, containing the same time slot. Everything has changed throughout that talk except the room, so the title changed, the presenter changed, and the time changed, but it's in that same 204H.
So if you're like, oh man, I wish I were going to that other security talk, you can still go to that talk and sit through this one too. I just want to make sure you know about that. In case you're wondering what my credentials are to stand up here and talk about security,
and if you came to this talk wanting to know how to hack, I got it right here for you, I figured it out late last year. Turn off the lights in your room, turn on the backlight on your keyboard, and start hacking, that's all there is to it. If you came to this talk and learned how to hack, you're done.
Okay, I hate agenda slides, but I thought I would do one anyway. Because I want to make sure that you know what this talk is going to be about. This is not going to be a talk about the OWASP Top 10, it's not going to be an in-depth talk about how to hack Rails,
or anything of that nature. This is really kind of a very broad overview of what Rails gives you security-wise, what it doesn't give you, that's actually the bigger section, and it's really more like me complaining about what it doesn't give you, and then a very short section at the end about what to do about this situation.
So, first up, cross-site scripting, you always have to start cross-site scripting. Rails 2, who's using Rails 2?
Yeah, see, never goes away. So, back in Rails 2, kind of a bad situation, you had to make sure you manually escaped everything in your views. Rails 3, everyone rejoiced, escaping was the default.
Yes, I'm sure some people were upset that they had to go through and remove all those Hs from all their views, but this is way better from a security standpoint. Everything gets escaped by default. In case you're unaware, this is what it looks like to write views in Rails. If you don't do anything, it's escaped.
If you use raw, it's not escaped. If you use .html save, it is not escaped. What happens when you don't escape things? You get cross-site scripting. My favorite one looks like this. This is a super neat attack calling alert 1. That's my favorite one.
A little bit more complicated, you may have seen this. Quite embarrassing, middle of last year, TweetDeck had an XSS problem. Someone managed to fit this script into a tweet, affectionately called part-tweet, and essentially what it did was it would click its own retweet button,
so if you saw this tweet in TweetDeck, it would retweet itself. As you can see down there, about 84,000 tweets. When this screenshot was taken, well, I don't know when this screenshot was taken,
it was during a little incident, and that part is not actually extraneous, it's the key to the whole thing, and I can tell you about it later if you'd like. If you want to scare yourself and your friends, you can use BEEF, which stands for Browser Exploitation Framework. It's not related to me in any way,
but it's actually a Rails app, not a Rails app, sorry, it's Ruby, and it's built on Sinatra, and you can do horrible things if you find cross-site scripting on site. Check it out if you're interested. Rails gives you a lot of pretty safe helper methods, which you should use.
It's kind of nice, you don't have to write a lot of HTML by hand, but you can use these tags, they're safe-ish, I can't vouch for their total safety. Certainly things like content tag, or other generic tags where you just drop in your own HTML,
probably not very safe, just be careful. Alright, next is this. I love this example, because this is an example everyone uses for cross-site request forgery. You have your bank website opened in one tab, you go to some evil website, it makes a request to your bank,
and you just transfer some money. Now, I want you to notice, though, that my bank account has so much money in it, I wouldn't even notice if $100,000 disappeared. So, you know, but other people, you know, they probably care about that enough money. Does anyone find this attack kind of strange?
Like, why can one website make a request to another one, and like, it affects your logged-in session? Is that weird to anyone? It's kind of weird to me. Does anyone know the answer to why that happens? Why does this even work? Yes, who said that?
I like you a lot. The one weird answer is cookies, yeah. So your cookies get sent along, so if you're logged in, the request will be as if you're logged in. You're probably all aware of this, but I just want to make sure that we're on the same page here. So Rails, out of the box,
it's offered this way all the time. It's really nice. It gives you C-cert protection. I'm going to say C-cert because it's way shorter than cross-site request for a degree. The fancy term for this is synchronizer token pattern. You have a token in your session. You have a token in the form, and the form gets submitted. You validate that the token in the form is the same as the one in your session.
It probably came from that user. You're all good to go. It kind of looks like this. You probably all know this. It adds some meta tags to your page so you can pull it out in JavaScript if you need to. You use the form helpers. It gives you this hidden input with an authenticity token.
And it all just works. It's all great. Other frameworks would, I mean, some other frameworks would love to have this kind of thing. Other frameworks have other frameworks. Mass assignment. It's awesome because everyone knows about it because of GitHub, and it's sad for GitHub, but it's good for the Rails community as a whole because people found out, hey, this is actually a problem,
not just a cool feature. So this was the old way. So just drop your grams in and save. And if you do that, someone can drop in admin equals true, and it sets it on the model, and now they're in there.
So now we've got to revisit some history. Okay, so Rails 2, you could whiteboard-blacklist the attributes that you can mass assign on models. Then in Rails 3.1, it became an option that you could put in to say all my models must have a whiteness.
That was a nice improvement. Rails 3.2.3, if you generate a new app, then that configuration was set to true by default. Also very nice. Rails 4, strong params came along. Now you have to whitelist on assignment, which is also pretty good.
There's different philosophies, and if you still want to use the old way, whitelisting it on the model, there are gems that will allow you to do that. But all in all, this is good stuff. It's moving in the right direction, right? Towards safety. That's the way we want to go. Looks like this, or I don't know.
If you require a parameter, you can permit a parameter, but anything else from that comes in, it's not going to work. Rails, by default, will use a cookie session store, which means all your session stuff goes into a cookie. In Rails 2 and 3, that was a signed session cookie. It's nice, so it used a secret value, signed it,
and basically, yeah, even though you had this cookie sitting on your machine, you couldn't really chain, right? Because that would be really bad if you could just arbitrarily set values in your session. That would be quite bad. Rails 4, they switched to encrypted session cookies, which is also a good move,
and they switched to using JSON, not marshaling and unmarshaling. So also a good move. So again, moving in the right direction. These are all good things. I'm telling you all the good news up front, right? SQL injection protection. I actually just like saying injection protection.
Injection protection. All right, so, Rails 2 and 3 have your nice parameterized queries, that's the way to do it, everyone knows, parameterize your queries. Rails 4 introduced R-roll, or error-roll, or cave-roll.
As far as I can tell, if you use that, it's safe. I haven't, and I could be wrong, if you're here and you know that I'm wrong, please let me know, so I stop saying that. But it seems like it's pretty safe. If you build your queries using that, it's basically safe from injection attacks.
So, cool. Rails will give you all these nice, nifty security headers. So, x-content-type options, set to no-sniff, so that Internet Explorer doesn't try to guess what content type you're sending, which always ends badly. X-frame options set to same-origin,
so no one can eye-frame you, and for quick-jacking attacks. XSS protection, turned on, set to blocked, tell the browser, hey, if you happen to implement automatic XSS protection, use it. All good things. If you set force-ssl to true,
then you'll get just yes headers, which basically tell the browser, hey, never use a plain HTTP connection to connect to me, always use SSL. Even if you click a link that isn't SSL, use SSL anyway. So that's nice. Oh, we got through that pass. Okay.
So like I said, this is kind of, this is mostly me complaining, and hopefully you take some of this. I'm hoping that people here will take some of this and say, I'm going to commit fixes for this to Rails, and everyone will be happy.
Back to cross-site scripting. I'll give you a moment to read this slide. Okay. If you think no one gets this wrong, you are wrong.
I have talked to people, and they said, oh, it doesn't make it safe. So, I mean, you got to think about someone coming into Rails, they've never used it before. They see this method, looks like it makes it safe. It doesn't make it safe. Makes it unsafe. This I just found out this week. I don't understand it.
If you understand it, please let me know, because I'd like to be wrong. But it looks like even in the latest Rails 3.2, it does not escape JSON when you call to JSON. I don't understand. But if you do, please let me know. Rails 4, it's awesome. It encodes it with a backslash U.
It's totally safe. On the client side, it doesn't matter. It's interpreted the same, but it's safe from cross-site scripting. You know what would be really nice, though? Is if we had contextual encoding, because who knows what all these methods do? There's one called sanitize.
Sanitize what? From what? To what? I don't know. I mean, I do know, but you can't tell from the name, right? And then you have HTML escape, escape once, escape JavaScript, escape once, escape, like CGI.escape. I don't know.
I mean, I do know. Could you guess what it does? Probably not. You know what's nice, though? Contextual encoding, which tells, it can tell where you are on a page, if you're inside a tag, if you're in JavaScript, if you're inside an attribute, and then it does the proper escaping.
It's really cool. It would be nice if someone would implement it. C serve protection is pretty awesome in Rails, but it's not as awesome as it could be, right? So you have to make sure that actually you're using Post or something like Post. So if you're using Git, you know you don't need protection.
And you have to make sure that you don't allow Git, right? It's just because your web app is using Post doesn't mean the endpoint won't accept the Git. If someone sends a Git request, you don't get C serve protection. Another thing that's kind of, you know, just fact of life,
is you've got to use the form helpers if you want those automatic tokens inserted. Otherwise, you've got to do it yourself. Another thing to be aware of, C serve tokens persist per session, so they kind of hang around for a while. It's not necessarily a bad thing, but you can kind of imagine that you might want that to be less long-lived than a session made.
What happens when there's a failure when you get a token and it doesn't match what you expected? If these look like odd version helpers to you, they did to me too. So, Rails 2 through 3.0.3, it would raise an exception.
You know, and you've probably seen it. Rails 3.0.4 through 3.2.21, which is the latest 3.2, it calls a method called handleUnverifiedRequest, and then it just resets the session. But the request still gets processed.
It's just the session gets reset. Rails 4, the default if you generate a new app, is to raise an exception. If you don't give protection forgery options, though, it goes back to this, oh, we'll just clear out the session. So what? Why am I talking about this? Imagine you had an awesome method like this,
where all I'm doing is taking the parameters and transferring monies. I believe transferring monies looks like this, or something. I don't know. I'm not a pig. So there are two links down at the bottom. The first one was from GitHub's bug bounty.
They just published it this week. They paid out a bounty because of a bug where they were actually caching the session. So Rails would clear out the session, you know, like when you actually use the variable session. That was cleared out, but they had cached those values somewhere else, so it did no good.
The second one is a blog from Invisium from last year, in some client's code. The client had implemented the sessions in a totally different cookie. So it wasn't in the Rails session cookie, it was in some other cookie. So yeah, I cleared out the Rails session cookie, but not the one that they were actually using. So that's bad.
I mean, ideally, when you have this kind of failure, just stop the request. Like, why would you ever want to continue processing your request when it seems like someone's performing an attack? So, raise exceptions. Speaking of sessions, this one still blows my mind. Service-side sessions are not the default.
You may be saying, yeah, but Justin, like, cookies are so fast, and they're so lightweight, and it's awesome, I don't have to have a database. But did you know that when you install Rails, you have to install a database? So, we're using the least-safe default,
which is using sessions, or sorry, using cookies for sessions, when we could just be using a database because we have to install it anyways just to, like, run Rails new. So what? Well, Rails session cookies are forever. If you get a session cookie,
and we're talking about using the cookie store here, it lasts forever, it's valid forever, unless you code something on the server side to deal with that. Otherwise, they're valid forever. The probably even bigger problem, though, is that you can't manage it on the server.
You want to tell your user, hey, you have, like, five sessions and one is in China, and you're in Atlanta. That's something you'd like to tell your users as a security feature, but you can't because you don't know what cookies are out there until they actually get sent to you, and you have no idea. By default, this is the default, right?
Pre-Rails 4, when cookies are encrypted, they're super simple to decode. So if you came to this talk and you're like, I want to be a hacker, if the keyboard in the dark thing wasn't good enough for you, here's the second step. This is how easy it is to decode
a session cookie from Rails. You just split it because the second thing after the dash-dash is the signature. We don't care about that. Basically, 64 decode it, load it with Marshall, boom. There's your session, right? That's the whole, like, that's like the major problem with storing sessions and cookies is that you may accidentally put something sensitive in it.
And that would be bad. Probably you're not actually putting this stuff in it, but you never know what someone's going to put in a session. So, that kind of sucks. This one. So, who here has a Rails app
and it doesn't have a user model? It does not have a user model. I'm seeing, like, less than ten hands. Okay. But Rails doesn't have any, like, account management stuff built in, except for it has secure password, which, like, you know, okay.
It's good to have. So it's kind of crazy that that's not built in to me. It would be nice if it was. No authorization framework. I guess you can, you know, build stuff with your before filters. This is an even bigger problem, though,
that Rails doesn't provide you any protection against directory traversal. So it will happily render any file that you give it, no matter where it goes. And you can send any file, you know, if you have code that looks like this. And remember that it's, when you render a file, it's actually executed where you can put it.
So keep that in mind. This, though, depends a little on your server setup. Your web server itself may actually have this kind of protection. Hopefully you're limiting what your Rails app can actually access, those kinds of things. But out of the box, it doesn't give you anything.
Am I complaining enough? Alright. And again, this isn't because, like, I'm trying to dis-Rail for anything. Do people say dis still? Dis-Rails. Just made me feel really old. But because I'm hoping someone will fix it. And I'm hoping that someone's not me.
Anyway, I double checked. Last night, all these methods are vulnerable to SQL injection on the latest Rails. You may be surprised because they look very innocuous. I made a website, railsfsqli.org. It lists a whole bunch of methods, active record methods,
with some example queries, and you can go look at it and see what not to do. But what a lot of people don't realize is that you could clone that, and you get a Rails app, a very horrible Rails app, where you can plug in whatever queries you want and play around with this.
And it gives you sort of like, okay, this is the code that's gonna execute. You can put in the parameter value for, you know, for this parameter, and then you can run it and see what happens, and check out the query, and see the results, and just kind of play around with it. The site hasn't really been updated for Rails 4.
I went through, I think, with 4.0 and updated some things. What I would really love is someone else would go through and update it with like Rails 4.2 information, because there may be new methods, or there may be old ones that are gone, or there may be old ones that have now become safe.
It's possible. So just go there, download it, send me a pull request, that would be awesome. This is the most begging I've ever done in a talk, by the way. But sometimes queries are so complex that you can't use the SQL methods that are provided by Rails.
That's a joke about this query, okay. But you know, sometimes you end up building these giant strings, and you're like, well, how do I even sanitize this input? So you might go look at the docs,
and be like, well, sanitization, that sounds good. And you know what else sounds really good? Sanitized SQL. That sounds like exactly what I want. So you put it in your code, because you don't actually read the docs, that's important. You don't read the docs, just put it in your code.
You put it in your code, and you run it, and any guesses what happens? Nothing? More than nothing, I added a method. What happens? You get this. All right, a defined method.
But let's say you did a little bit at the beginning, you're like, ah, it's on the class. All right, so I'll just get the class and call sanitized SQL. What happens? Does anyone know? Private method. You got that one, not the first one.
So protected method. We're Rubyists here. We don't believe in protected methods. All right. So you're right. This is protected method. That sucks. If they don't give you an API,
just make your own. All right. So classic SQL injection input here. We're going to pass it in to sanitize. That's on what happens. This is the most interactive part of the talk.
No one knows, because who knows what happens? Wow. Correct. Correct. Why? Because you didn't read the docs. It's actually expecting something like this.
It works. It's not fun, so I'm not going to ask you. This is what escaping single quotes looks like in SQLite. Just kind of doubles them up. So, okay, we got that working. There's also this form, which gives you a slightly different query. That's cool.
That was way harder than I think it probably needed to be. And probably some of you in here are like, yeah, but that's because you were in an instance method. If you were in a class method in your model, that would have worked just fine. You're correct. But, I mean, come on, I just looked up the method and tried to use it, and it was really hard.
That should be better. Easier stuff. You've got to do it yourself. Protection. Really awkward. You could, like, use URI parse and get the path, but actually you have to do something more like this
because it'll raise an exception if it's not a valid URI. Go and do this everywhere in your code. So I wish there was just a safe redirect. That would be nice. Who in here is a Rails core committer?
Does this look familiar slash dangerous to anyone? That home URL probably came from user input, and therefore it's not safe and it's not escaped. Yeah, it's not safe, but I'm sending it to link too.
Isn't that safe? Yeah. Yeah, exactly. It's unprotected, so I'm going to just put this in, and as soon as someone clicks the link, there you go. XSS. My favorite one, which is alert one.
Post and a couple talks. Apparently a couple years ago, I didn't realize it was so old about Rails and secure default, so there's a whole other list of things that Rails doesn't give you, some of which have changed and some of which haven't.
So you can check that out. You're all waiting. Where's the cat picture? When's he going to show us his cat? I know you will. You can follow my cat on the internet, at the photo of the cat. He's very lonely, he wants more followers, so he asked me to throw them in here.
Okay, to wrap this up, I'm going to go through this kind of quickly, because people probably have questions or corrections that they would like to shout at me. So, what to do about it. First step, learn about security. You've all taken the first step.
Congratulations. Good job. Next step, fix all the things that I just mentioned. That would be nice. That would be nice if someone did that. That would be really nice. You can use some libraries. This is not like a comprehensive list,
or even necessarily recommended libraries, but these are some libraries that exist that you might want to check out. Rack-attack for rate limiting, secure headers for secure headers. But in particular, if you want to add content security policy to your site, which you do,
you can ask me later about it if you want. Access control, you're probably familiar, there are libraries for that. Everyone uses on the off and the bias, so you're familiar. That's a good idea. You might want to use some static analysis tools. There's one called Brakeman, and I don't know, it's kind of good. You might want to try it.
Some guy wrote out your dependencies for known vulnerabilities, and it would also be kind of cool if more people sort of jumped on that and contributed to the, I didn't look it up, so I forget the name of it,
but the Git repo that it actually pulls the vulnerabilities from, I think that actually needs more people pushing stuff to it. Nice thing about static analysis tools, I don't know if you've ever seen a graph like this, well, at least 50 of them on the internet, and they all kind of look like this, right?
And the idea is on the left, you probably can't read it, because they're all so small. On the left, that's like when you start developing, you're doing your planning, your design, that kind of stuff. On the far right is you've already deployed. And the graph is the cost of fixing problems at any point along that graph. Problems could include security problems,
or other bugs, but we're in a security talk, so security problems. If you fix it way on the left, it's cheap, right? If you are typing code, and then you backspace, backspace,
and then type new code, that costs almost nothing, right? What about if you're in a design meeting, and someone's like, hey, maybe you don't do it that way, you do it the safe way? Would that cost almost nothing? That's awesome. That's when you want to do it. At the other end, and you're at home, asleep,
on the weekend, at 1am, you get paid, and you have to get up to fix the security vulnerability. The cost is through the roof, right? Not to mention, you know, if users are affected, and the business is affected, and all of that stuff. So the cost is very high. The point is, you want to fix stuff early as possible. The nice thing about static analysis,
and I get unbiased, but the nice thing about static analysis is you can do it really early. This is a plan that we kind of came up with at Twitter, which is where I work, which I didn't even mention, but sorry, forgot. This is the plan that we came up with, it's not a bad plan. The plan was use static analysis
so that we can do stuff early. Look at all the code all the time before it ships, right? That's a good thing. And then my personal favorite, don't fix vulnerabilities to prevent them from whenever possible. Just get them out of the code, don't ever ship them to production.
That's the ideal. There's some options for doing that. You could use something like guard or guard breakband and run, you know, as soon as you change code and save a file. It's pretty cool. You could get it into your commit tools somehow.
Commit hooks or something. It's a good place. Continuous integration, maybe with the Jenkins plugin for breakband. It's not maintained though, so just be aware that people tell me it still works. Or you can just, whatever continuous integration you use, it's really easy to throw breakband in there.
Lots of people are doing it, it seems pretty good as well. And then if you can kind of get it into your release process somewhere, like maybe right before code ships, you run breakband on it, or bundleer on it, or some other tool, that's also good. So just some options for you.
If you're interested in more about that kind of thing, this is extremely self promoting, but you can watch these two talks that I either gave or was involved in. The first one was at Netflix, and it's really short. And it's a good condensed version of kind of lessons learned with trying to get security into the software development lifecycle
and stuff. And the one on the bottom is the one that people got really excited about a few years at a conference. Myself and my co-workers talked about automation and stuff. If people really like it, you might like it too. That's it. Be safe.
I'm at PresidentB at breakband, and you know, don't spread it around or anything, but we're working on a commercial version of breakband if you're interested, come talk to me. That's it.