Filipe Cabaco is an Elixir Software Developer who currently works at Supabase. He joins the show with Allen and Sascha to discuss his article, "Elixir Code Security: Prioritize Security in Your CI With 4 Tools". He begins by outlining how he came up with the idea for his article and how that came about. Additionally, he discusses some of the tools that may be used to safeguard your code.  

Hey everybody and welcome to another episode of Elixir Mix. This week on the panel we have Alan Weimar

 

Hello.

 

and me, Sascha Wolf. And as usual we have a special guest and this week we have with us Filipe Cabasso. And I practiced that name so many times before. So Filipe, why don't you tell our listeners why you're here and what we're going to talk about today.

 

Hey everyone. So I wrote a blog post a couple of weeks ago or months. I can't even remember. Time is a bit relative. And I've wrote an Elixir post about how to secure your code base using some things that come in with mix and other dependencies that can be useful for you, mainly focused on security and code safety.

 

Nice. Yeah. I'm not sure if you actually ever had like an episode on security on Elixir Mix before, maybe before my time, but it's definitely a topic I feel isn't talked that much in the community about. It's more of like, yeah, everybody is like, yeah, security is important, right? But I feel not a lot of people are talking about it. So how did you, what's the story behind this blog? And how did you consider to say, hey, I want to write something about this. I want to give people maybe a little bit more insight. And this is something I'm excited about. So maybe give a little bit of a backstory there.

 

Sure, so in the past I worked for a company called TalkDesk based in Portugal and while I worked there I was part of the SRE team and I started developing some tooling around secret sharing, around finding if GitHub had secret keys in the repos, in our repos specifically so a bunch of those small tools and That's when I kind of figured, okay, the tooling for this area is not that big. Um, it felt lacking at that point in time and it still feels a bit lacking. Uh, fortunately, Elixir is actually way above and beyond a lot of the tools I've worked with, um, and yeah, I just see security kind of being seen as a second thought when in reality, whenever something happens, it's way more serious than, than it should, and it's preventable. That's the other. part that it kind of drove me to research a bit more is that most of the things we hear about and most of the leaks and most of the issues we hear, they were actually preventable either by better security practices by employees, which is usually the number one cause, but also code wise security, which usually it's just relegated to a second thought of, okay, we'll do it later. The future is way more important instead of solidifying the code a bit. And I think in part it's due to the people think there's a brick wall to actually achieve it. In some languages, probably, but at least in Elixir, we live in an ecosystem with highly skilled developers that actually contribute extremely good content and extremely good libraries and we should be aware of them and just use them.

 

Yeah, that makes a lot of sense. And to be honest, I am also kind of guilty of that. So like, okay, they're thinking this is like this brick wall thing and maybe another time, right? And there's always the time pressure in the back of your neck, even when you maybe don't do like agency work, but product work. There's so much more you could be doing. So I can totally relate to that. I'm going to out myself, I guess, here, but.

 

No, no, I think that's completely normal. Everyone kind of feels that security is kind of a whale. It's a massive thing with a lot of subjects. But like everything in our, well, in our area of work, if you don't boil it down and try to simplify it a bit, it becomes way too massive to handle. It becomes way tricky to start. And I think for that stuff like... there's a list of vulnerabilities called the WASP that's released each year. For example, even starting with that, looking at the top 10 list of what are the most common and most critical vulnerabilities or considered most critical vulnerabilities, even just skimming that and thinking, okay, have I done the code that protects from this? Not even, even if you still need to keep it as a second top, because again, companies kind of... Product-focused companies really push to deliver features versus delivering something secure. That's the reality. And they also get it. It's product needs to move fast. I kind of get that pain. But at the same time, if the developer himself or herself kind of keeps in mind, okay, am I kind of protecting myself again, to a wasp? And that kind of starts the ball rolling of, okay, now I know a bit of a wasp. Can I, how do I dig deep? What can I do to ensure that my coding is better and better and better as I move on? Because then OOS becomes, well, routine. There will be another thing and you can deepen your knowledge. So I think it really comes to that boiling down and simplifying a bit the subjects and finding those lists of this is what I need to tackle.

 

That

 

Yeah.

 

makes a lot of sense. Well,

 

Yeah.

 

yeah, go

 

And

 

ahead,

 

I was

 

Alan.

 

sorry, something came to my head recently. Like, I, yeah, I think that so many people do put security kind of way back in their mind. But I think there's maybe I'm just too crazy about it. But there's some things like I don't, I don't joke around with that security. Like I get really, really pissed off when I see some stuff. Like usually, I think I'm pretty Yeah, I think Sasha is looking at me like I'm usually I'm pretty calm. But like sometimes I get some stuff. put in front of me and I'm like, what the hell is this? And they know it's like, if they didn't know any better, I'm not going to be angry at them. That is okay. Then you need to know about this, this, this. But if they know better, that's what really like ticks me off like crazy because it's like, what the hell you think you're doing? Like maybe this isn't directly security related necessarily, but could be used to take down your site. I think everybody knows that you have a finite amount of atoms you can put into your app, right? Unless you increase that limit. I know a lecture developer was working with me on a project for quite some time. He knowingly put in string to Adam, and I told him you should use to existing Adam, and he's trying to justify to me that it's okay. And this is, I mean, it's one thing if it's somewhere where you know you're gonna always get it right, Adam, you know, it's not the right thing to do. But another thing is this wasn't part of a, of an importing part of a section of a program where you're going from something to like a enum, which would easily crash your app, right? Like maybe it's not directly security, but it could be exploited, right?

 

No, in theory, that's part security, right? Because you've just opened up a door for an exploit, which would be just completely destroy your VM, if anyone outside of the company. So I can give you kind of an example of that. It's some, I think it was one year or two years ago, there was a leak for CircleCI, if I'm not mistaken, where basically a lot of repositories were leaked, private repositories. Now, I imagine someone... looked at your code and understood, OK, there's actually dynamic generation of atoms happening here. That could trigger a DDoS that actually sends you data that can destroy completely your service. It will take you quite a bit of time to fix it up, probably, if that underlying structure is being used in a lot of places. So in theory, it could take you down for a couple of days. And a couple of days in SaaS talk and business talk, it's a lot of money. It's a lot of clients that will be angry. It's a lot of customers that won't join because they heard about ServiceX being down and a lot of employees you need to give back money. So even those ideas of what exploits exist within my ecosystem. And we could say that... dynamic generation of atoms is a quirk of the beam, but it can be used as a security exploit. It could be used to completely destroy your service. So it's a really valid concern. And I would say it's a security flaw if someone uses string to atom, basically. And it's a really easy catch on doing string to existing atom. The beam even offers really good alternatives to that and just not use... don't use string to happen in most scenarios. I think it's really get away from that.

 

Well, even besides Beam stuff, right? Just another like, that's not just sorry. It's again, I got a lot of stuff happened in my daily job, right? Something else that came up was like, they wanted to let users paste HTML directly into this text editor that we have. Yeah, exactly. That was my first I just said, No, it's not gonna happen. Oh, but this is POC.

 

No, that's...

 

I said, No, not gonna happen. Like, even if it's only for us. What do you think most hacks come from from with internal I think, right? You just like, Hey, Hey, Bob, just pace this into the thing for me. Yeah, well, that's what happens, right? I don't even trust myself, right? So it's not going to happen. Unless we have a perfect way of sanitizing stuff, I'm not going to let it come through. That's why I'm super crazy about this security stuff.

 

Yeah, and I can imagine the next step where you could go, OK, now let's load all of that as an iframe. If we get an HTML or an HTTP thing, let's load it as an iframe in the next feature in one year. And everyone forgets. OK, anyone could actually have any kind of exploit here. And iframes are not the securest thing ever. It really becomes a compounding problem, because one feature might be good. that way, but then you start, we're working on products that grow over time. So you might actually add up more and more compounding problems that end up in a big security breach that you didn't expect when you first designed the first thing. So it's really tricky. It's something that should be top of the mind, or if not top of the mind, at least you should have highly, highly. And that in a top of a list of, I need to think about this when I push code. That's it.

 

I just want to point out something like Alan just said he doesn't trust himself. And I just think that's quote-worthy.

 

I, if you, do you really trust yourself coding?

 

No,

 

You

 

no,

 

think

 

no,

 

you're going to

 

I

 

do everything

 

don't.

 

right the first time? Even the 20th time I know I don't do something wrong.

 

Which is why I'm a big fan of testing, but I just felt so quote and meme-worthy. I just had to point it out.

 

If there's any developer that says that they fully trust their code, either they're lying or they're overconfident, then that will bite them sooner

 

Yeah,

 

or later.

 

exactly.

 

So sorry, just one more thing. Like you ever go to a meeting, like everybody else has got an iPad, a laptop, uh, whatever they have all these different electronic devices. And I'm the only one there besides the other developers with pen and paper. It's crazy. It's like, we actually know how bad technology is and how much it could fail. That you could see all the tech guys all have pen and paper because they know that it won't fail and we know that it's not buggy, et cetera. It's like the joke about, you

 

Yep,

 

know, I

 

notes.

 

laughed, she laughed, the toaster laughed kind of thing.

 

Yeah, yeah, yeah, yeah,

 

I

 

yeah,

 

would

 

yeah,

 

believe

 

exactly.

 

Not

 

they

 

only

 

had to toast your left.

 

I can imagine nowadays it's basically okay. Will notes sync to the cloud? Because there's probably some CRDT algorithm that will fail and I won't be able to have my meeting notes. Pen and paper don't need CRDTs and they don't need conflict resolution. They just need a couple of eyes in the pen. So probably that's why developers just go, okay, let's keep it simple. Please.

 

Yeah, yeah,

 

Yeah, I

 

I-

 

talked

 

I-

 

to this

 

I

 

guy

 

ca-

 

who actually had a remarkable tablet and he's like, yeah, it was great until I had a meeting and I needed the notes and then I ran out of battery. Never again. I'm going back to pen and paper. Sorry. Just one more anecdote.

 

I can totally relate to that. I feel like the longer you're in this industry, the more you distrust tech in general. Like everything is broken. Everything. But yeah, what we just talked about, like what's going on with Adam, it binds to something nicely, which I think is worth pointing out, is that at least from my personal experience as somebody who is not super close with security things, when I actually do read about certain exploits, it's usually a series of steps. which combined makes something happen. And each of those steps potentially might seem totally harmless. But combined, they actually open up the door. So maybe the string to add them, yeah, the worst thing that can happen, you think, is like crashing your VM. That in and of itself is also already not kind of nice. But who knows what else there might be undiscovered, which then combines into an exploit of some kind. And that is, I think, True, I feel like for every kind of elaborate exploit.

 

Yeah, it's it and that's let's imagine the following imagine that you blow up the BNVM using that exploit now imagine that your platform platform provider Doesn't handle that kind of failure gracefully and starts to I don't know just some weird stuff and and keep doors open or I don't know something weird And then the attacker knows about it so you can exploit that to get a bit more information and then the attacker can go another barrier and another barrier. So we're not working in isolated systems, right? We want to

 

Exactly.

 

believe that everything is our own code. They're not our own code. We're running our own code with a bunch of abstractions on top of someone else's code with a ton of abstractions, on top on some hardware with a ton of abstractions. It just compounds and compounds and compounds to a way bigger thing than the developer usually thinks about. And that's why... You should really take care of your garden first, then think about everyone else's garden, but be sure that your garden is taken care of before starting to shout, okay, I don't know, service X, Y, and Z are bad because they don't know how to deal with X, Z term or whatever. When in reality, probably that only happened because your garden was, well, really full of holes and really shady code and really bad.

 

Yeah, that's kind of going into the direction what I also wanted to mention is what is kind of for me, sometimes scary about security is, at least from my personal experience, there are so many unknown unknowns, you know, so many things I don't know that I don't know. I very much still remember this one time where we were building an application that was like an ad agency doesn't really matter the details, but we had one guy who was really like knee deep and heads deep into all the security stuff. And he explained, hey, this password check over there, it's actually vulnerable to a timing attack. And I was like, what the frick is that? Right? And then I read up on it and I was like, wait, you can do that? Right? If everybody is not familiar with a timing attack, this is basically, the idea is that the closer you get to the actual like kind of... like password or like a comparison, the longer the response takes, even if it's only like a few nanoseconds. And that is something you can measure of our hundreds and hundreds of requests. So you can actually figure out the closer you get to that to that particular and to a particular thing you want to compare to. And what you want to do usually in those cases is you want to have like a comparison method, which is like constant time, every time regardless of like how close or how far away you are. But those are things, when I first learned about it, I was like, what the fuck, this can be done? Like, I would have never thought of that. And that is what I mean. Like, that is something where I didn't even know that I didn't know. And there are probably a bazillion more things I don't know about, which are potentially relevant for security, some more obscure, some not. And I wanted to ask you, Philippe, also what would you recommend people do to maybe at least somewhat close the gap? I would assume 2 words like sub-a-law would be a good start, but what beyond that?

 

So first of all, I want to say something which is hackers are the most creative people ever. That

 

I'm gonna

 

if

 

go to

 

you

 

bed.

 

so first thing you can do is follow a bunch of hacking accounts because they're worth it. You'll find if you don't know any of them. I'm trying to remember there's a really good conference about hacking DEFCON where I think it's DEFCON. They have the most. hilariously dangerous stuff you can imagine. I remember some years ago they hacked a pacemaker wirelessly. You can kind of... and then you hear how they do it and it's via RF radios, via sound, via some really weird stuff that you'd never imagine. So first of all, try to put yourself in the mind of an hacker. Try to see how creative people are. to actually achieve what they need to do. So that would be the first step. Be curious about the weird stuff people actually do to achieve their goals. For research purposes, for fun purposes, it's actually quite interesting. It's a really cool community to follow. The next thing I would say, yeah, the elixir-focused. My first go-to would be really security-focused would be Sublo. So with Credo, You might actually have some tips. For example, if you have Credo, it won't allow you to do the two string, sorry, string to atom. It will see it as a dangerous thing, but usually it's just low. I wouldn't say low priority, but kind of easy to catch. So Credo has a bunch of rules that already help you out. And it's well, Credo is a low barrier because it's a really known tool and used tool within the Elixir community. After that, yeah, so below it's insanely good. It actually prevents a bunch of things, not only at the Elixir code level, but also Ecto. So you actually are able to avoid some SQL injection and some other vulnerabilities in the Ecto side. There's also cross-site scripting that can be caught in Phoenix templates. So that's another big win. And there's just a list of a bunch of libraries that are so below. actually allows you to protect against and vulnerability there are possibly to writing them. So yeah, sublow is the first one you'd go, okay, add the dependency, mix install, mix sublow. Let me see what's currently in my source code. And then when you see a list of it actually gives you a list of explaining, okay, this is medium severity, this is high severity, this is low severity, maybe filter them out by high severity. Subulow also supports that filtering and setting up rules on does this fail? Does this exit with one with an error? If it's high, low, medium, whatever. So you can set up all those rules. Maybe run it with high, see what's happening in your code. And after that, research a bit. Don't start to fix it up. Don't, don't think about fix it up. Check. Okay. What is, I've just appeared, I don't know, 10 errors, three or four of them are. Cross-site scripting attacks. Okay. Let me read about what a cross-site cross-site scripting attack is Then okay now I have two SQL injections Okay, let me check what SQL injections really are and maybe there's even an elixir blog post somewhere from someone else saying okay acto avoid acto Injection attacks. Why is it an injection attack? Etc. So that would be my first step run it in your code in a code base. You really know well see what Sub below for example gives you. And if it gives you, okay, a list of 10 high things, yeah, check them and think about fixing them. But first thing is really getting informed about what each thing really means.

 

Runaway screaming is the next step, right?

 

That's that's that cover and cry for a bit. And

 

Hahaha

 

after that, yes, start start reading and fixing.

 

Okay, Alan, I'm actually curious, do you have any, I mean, like you already shared your story about string to add in, is there any other like security related story from your from your professional experience as a developer with which there's a lesson to be learned from? Let's say that.

 

I think my big lesson to be learned is if you somebody says they have lots of experience, don't believe them. Just really, that's like I found, you know, I had these experts come in and I was told to listen to them. They bring lots of experience there. They cost two times as much as I cost. And I was just shocked at the amount of crap they bring in bad code and also bad practices and everything else. So like really, There's two sides to the story, right? One is that they could just be bad like these guys are. Sorry, I just gotta be direct. But they could also just not be informed or just not know all the things you know, right? So I think this is what you said, check out what other people have. Oh, Wasp is cool. So below, yeah. There's so many different things. There's always like new security things coming out. Like I was kind of surprised about... I think there's a couple of things in the Phoenix documentation that tell you to make sure that you renew sessions or something like that. I just read through documentation, and I just saw this. I was like, really? OK, interesting. But I think a good step is see what other people have done and break it down, too. So if you look at the Phoenix Gen Auth, that part is pretty rock solid. In fact, we're talking about timing attacks. After we did that, I started digging through the source code Bcrypt, because that's what comes in default when you're using Mac or Linux. And that one, I went actually dug into the NIF and look at the C code. And that one actually has a comment there saying, constant time to avoid timing attacks. So I was like, whew, you know. And that comes out of the default PhoenixGenAuth stuff, right? So I think look at PhoenixGenAuth, see how that one works. And a couple of these other kind of big time ones. And. If you need to use something else, yeah, really take a look at it and see how it is and compare it to others. Yeah, I don't know. Security is kind of tough because it's ever changing, right? There's all these new kinds of techniques and everything else. I mean, I wish I had some more interesting stories. It's mostly just like, wow, I can't believe this guy, like trying to tell me that a div tag goes inside of a p tag or the other way around. I don't know. It's just crazy shit this guy talks about. Sorry. Bad memories from a couple weeks ago.

 

That's not really useful. To be fair, most of the things I've learned, I was really lucky also to have a colleague at TalkDesk called Sergius Ren. I think that was it. And he was a security expert. And he was a proper security expert. Whenever I went up to him and asked, OK. Can you explain how cross-site scripting works? And he basically, instead of explaining it by words only, he told me, OK, give me one day. I'll show you an example. The next day, he had a bunch of code showing. So this is how you do a cross-site scripting attack. And he actually builds a small example with HTML and JS. Look, I can show you a cute game where you click, click, click, and you don't even know you're actually clicking on the site beneath. So there's really, that isn't a cross-site scripting attack, if I'm not mistaken. But yeah, point being, I was lucky to have an expert, a proper expert teach me, and that part should be due diligence, right? Whenever you hire someone that supposedly is an expert, reach out to your existing team to understand if, what's their gut feeling? Is it helping? Is it not? Is it money well spent? did they learn anything? Because when you hire an expert, I would expect that expert to actually teach you stuff. And if you end up in a position of, OK, I already knew that and your input is actually not that valuable, maybe the company is losing money with that person as well, while it could be hiring someone else. Also, kind of going back to what Alan was saying, the fact that vCrypt also includes constant time checking, it really shows that we're not building our code on top of. We're not building our code in an isolated island. We're building on top of abstractions and abstractions. So whenever you add a dependency, try to check issues, try to check pull requests, try to understand what's the history of that dependency, at least kind of an ILEVEL approach, even just looking at the changelog, potential past security problems, et cetera, et cetera. It's always useful. It's always valuable because you end up learning more about the tool you're going to use, about that new abstraction you're adding. And you'll see how it evolved, if there were any problems. It just becomes way easier if you start to kind of learning bit by bit and adding this kind of small, small practices that will kind of drive up your code quality and your concern about code.

 

I think there's a lot of benefit in general to be gained in having people on hand which really know what they're talking about. At least from my personal experience, those were the times in my career where I feel I learned the most. So if you can find somebody in your company who maybe like Philippe is passionate about the things, just grab them and don't let go. And then you'll probably learn more about those things than you ever could. not ever could but less amount of time learn more amount of things.

 

Yeah, it becomes a facilitator, right? It's just a way of reaching an end goal. It's just, you basically use a shortcut. It's way easier. And again, you can also find those people online. If you go to communities concerned about it, even for example, Sublo developers, maybe if you reach out to them and ask them, okay, can you give me some hints on how to improve? They'll probably be happy to help and be okay with helping you out. For example, that's why. one of the biggest things about the elixir, the elixir ecosystem. The community is really open, really helpful. Every time I reached out to someone asking for some feedback on anything or any question I had, everyone was really kind and everyone kind of just gave a bit of their input and I've learned way faster than I should. So don't be scared to ask questions. No one knows everything and don't think you should know everything. Just be okay with asking questions and be. be happy that we're in a really helpful, kind community.

 

Yeah, 100% plus one on that. And I think asking questions is also something maybe some of our listeners, I'm not sure like what the experience level of all of our listeners are, but I do remember when I started as a developer, I was assuming that maybe at some point you kind of not know it all, but you stop asking questions. And to be honest, the reverse has been true. Like I'm asking more questions now with the more experience I have. So asking questions is not even allowed. It's actually, I think, good. When in doubt, ask more questions than less. And really try to understand what you are using. It goes beyond just building things and coding things and understanding how maybe, for example, the timing of tech works. But also it goes into all the adjacent areas of asking people you're working with about things and asking stakeholders about what the you're even supposed to build and so on and so forth.

 

Yeah, I'm not sure at what point of development or life in general people think that asking questions is a problem. But yeah, that's the truth. Everyone, I've worked with multiple junior developers and the most common thing was, I'm sorry if this question is stupid, but I need to ask it. No question is stupid. Everyone was in a position in their past where they felt probably the question wasn't the most... interesting or the most direct or whatever. It might have not been the best question, but it was a question they needed to move forward. People shouldn't be afraid of asking questions and no question is stupid because everyone was on that position. And I think that seniority kind of brings that. For example, Premier Cine Developer is just one that is really good at Google more than anything else. And by that, I mean they're really good at getting their answers. They're really good at asking the question to a tool, to a person, and just condense that question in such a good way, or their doubt in such a good way, that they're able to properly convene what was the problem, properly convene what's the intended solution, or what they intend with the solution, and people are able to help them out via blog post, via issue, via talk, via anything. So for me, seniority is more on that side. It's the communication versus whatever, versus tech. tech ability, tech coding ability, whatever. It's way more important to be a better communicator to your team and to even your community and everyone else to kind of reach that seniority. That's way more important for me in terms of, as I see a senior, it's that capability.

 

Yeah, that makes a lot of sense and I could definitely do plus one on that. I'm curious, Philippe, I mean, we already talked about asking questions. We talked about potentially getting a mentor, right? Like being curious. If you could give advice to your past self about how to best start with all the security stuff, what would you tell yourself?

 

Uh, just build stuff. I think that's the main, the main thing. Um, whenever you, so you could study, this is again, big grain of salt. This is the way I learned the best. It's by building stuff. It, I have a bunch of side projects, none of them launched, but I have a bunch of repos in private, a bunch of domains that will never never see the light of day. But at least I built them. I have a bunch of things that I've used. I have a bunch of things that I've tried. And I have a bunch of codes. Some of them probably will never see the light of day. Hopefully some will. But the reality is as I build, I find more and more questions I need to ask. The more questions I need to ask the deeper my knowledge goes. And if I, if I had to tell anything to my past self would be just build stuff and not stuff for your work. Try to abstract that, try to get away from that. Build stuff for your work on your work time. but know to separate that and then do a side project you like. Even if it's, I don't know, get a list of Pokemon cards and write them by value in markets. By doing that, you'll probably need to interact with APIs. You'll need to interact with security stuff. For example, the API might need a token. What kind of token? Bearer token. What does that mean? You kind of go deeper and deeper and deeper and deeper until you find those concepts. So... I think that's the best advice I could give anyone. If it's your way of learning, build stuff. Because as soon as you start to build stuff and communicate it with other services, you'll start to find small quirks, small things you'll need to take care of. And that's what drives you to basically go that extra mile of asking more questions. That plus search for your community, again, ask the question on your community. What are the tools I can use to better deepen my knowledge on X area? In this case, probably people would point me out to Sublo, which I probably use. And then I would see, okay, I'll run it in my codes at work or in a side project. And I would see, okay, I have a bunch of high level security problems I need to fix. How, what, what do they entail? What do they mean? So I think it's that it's keeping curiosity up by building stuff. At least that works really well for me.

 

That makes sense to me. And I feel that is an answer to quite many questions in our industry. Just build stuff and stay curious.

 

It is. Yeah. Even yesterday I was seeing, do you know the PrimaGen? I think that's the way you pronounce it. There's a really famous Twitch developer now. He works at Netflix, he's in love with Rust. He hates TypeScript. He has all of those small influencer stuff, but he's actually, he's an awesome developer. And he just launched the video saying, yeah, you should build stuff. And I fully agree with that. As soon as you start to build stuff outside of your work hours or even within your work hours, kind of one hour thing, if it doesn't bother your employer, if you build something outside of the scope of your work in a different language, even if it's in your language, but a different framework, you'll learn so much and your curiosity will find new things and that then compounds to your day to day life. You'll find something. from your past time that actually fits your work. You'll remember, okay, I actually remember that using bearer tokens can be dangerous in X, Y, and Z situation. Okay, cool. I know that because I did a side project then. So yeah, building stuff is really important as long as you don't, in your off hours, please don't work for your work, work for yourself and your curiosity, and then let that kind of transpire into your work.

 

Yeah, thank you for that, Philippe. Alan, do you have anything you'd like to know from Philippe? Because I feel we got a good, well-rounded perspective on this topic right now.

 

Yeah, I know. I mean, it's just, I mean, I brought up, I think, quite a few things that people don't really think about security, right? Like a lot of people don't think about, you know, the atom getting overflown or even large binaries, things like that. It's crazy how some mundane that some of these things are. Like people always think about, oh, you know, he injected my, you know, injected my sequel with some stuff, but it could be other things, right? You don't really know. It's like, and the other thing too is like, don't forget that. We're using OpenSSL when we build our Erlang stuff from source, I think. That's been, even though OpenSSL is like one of the widest used and looked at pieces of software, it had Heartbleed many years ago, right? I think it had a couple of exploits recently. At least two I can think of for sure Heartbleed, but I think there was one or two others having somewhat recently.

 

I think there was at least I think Erlang actually had an issue with a library recently. There's a new CVE

 

Yeah.

 

there. That's

 

So.

 

actually another good reference to learn more about security. GitHub has a CVE repository, which is basically a repository for vulnerabilities, even checking, OK, what's happening in the Elixir world. You can go to GitHub, security advisory, if I'm not mistaken, Elixir, and then just see the top 10, for example, by how serious they are. Even that stuff, just that quick research could lead you to a rabbit hole of, oh, I didn't know that and I'm actually using something that is dangerous. That could be actually a good segue to the MikSaudit dependency, which is another dependency developed by the community that actually checks this list of CVEs. to see if one of your dependencies has an issue. So you can actually automate it in your CI to say, okay, there's a new CD. We need to bump up the version for dependency X, Y, or Z. So again, tooling, helping out you to build the knowledge and tooling helping you to become a better code without needing to think that much because it's automated until a certain point. So that's the other, that's why I'm really... big fan of these tools, it's that they warn you, they help you achieve the goal of making your code more secure, but they can also teach you, because then you can see, okay, why did it trigger? CVE 189, whatever, whatever. You go to the security advisory, you check what actually is happening, why that CVE was published. And then you look into the details and see, okay, okay, now I know a new thing. I know a new attack, I know a new... problem in security that I need to be more aware in the future. So yeah, that big fan of tooling, big fan of just building stuff and a big fan of just keeping yourself really curious with a lot of curiosity about this area and any other area.

 

Yeah, there's a website with the CBE.meter.org, MITRE.org. You can punch in Elixir and you can see all the Elixir CBEs that were reported. It's not too bad. The latest one is 2021. But that one's talking about Stark Bank, Elixir ECDSA library. They kind of list a lot of the stuff out. The other thing, too, that I like to do is I do consulting. And so a lot of these companies, I still use PHP out here. So I punch in Elixir and I show them, oh, look how few there is. And I punch in PHP. And it's just like endless list of CVEs on here. So it is helpful to get clients and get people interested in using Elixir rather than PHP, or most other tech.

 

doing,

 

Even Java is on here if I

 

you're

 

punch in

 

doing

 

PHP.

 

the good work.

 

Yeah, I'm just, what is it, like facts

 

Oh

 

and damn

 

for-

 

lies and stuff? This is a

 

Hehehehe

 

look at this one. I just punched

 

E-

 

in I just punched in PHP and looks like that CVE's always judge CVE dash and in the year. So it's already 2023 on here for PHP.

 

Oh, damn, yeah. Ha ha

 

It's

 

ha.

 

pretty it's only the third day, man.

 

Yeah, usually what I see is PHP and Python are usually really, really up there. But to be fair, because they're also really used. That's the tricky part. So it's way more fun to attack those vectors. But on the other side, yeah, there's, let's not put aside that Elixir is built on Beam, which has existed for 20 more years and it's solid. There's not a lot of CVs on the Beam side for a reason. Elixir itself seems to be highly secure, even with way more usage than we had 10 years ago. So, yeah, it's just a really solid language if you are in the secure side of things. It seems to be a really solid language. And even other stuff, for example, Log4j, the panic that Log4j was for the Java community. People kind of forgot that. by now, I guess, but it was a proper panic. It was one of the most serious thing that happened recently in security, and it was due to a dependency. And the fact that, for example, Elixir, the logger is developed within the core team, it's a big bonus. Even building tools, build tools for other languages have security issues. Well, Mix is built by the core team. And it's really solid documentation probably has a bunch of security issues in some other languages in this scenario, since it's developed by the core team. Even if it has issues, it will be quickly patched up. Just the fact that the core team is able to build a lot of the tooling that everyone needs to do on their daily life without adding extra dependencies. That's a major win. And even some other things were... For example, the fact that Elixir actually comes bundled with an XML interpreter by using XML, you shouldn't need a dependency there and you're using a battle-tested XML parser and constructor. There's a bunch of low-level Erlang things that you can use. You could add abstractions on top of it. Some libraries are just abstractions on top of Erlang stuff. And at the end of the day, yeah. You could remove those abstractions at a later point if you want to secure your code a bit more, but they're available. So it's a really secure stack in my opinion, even compared to others I've worked with. It's way more secure than I'm used to. I'm having flashbacks to Maven. I'm having flashbacks to NPM. I'm having flashbacks to a lot of other things.

 

Okay, I actually have one more question for you, Philippe, because we basically talked about security, like in this tech bubble right now, but I do imagine that we have probably, there's a bazillion people out there which work in a team where they don't necessarily have somebody dedicated to security and where they, I guess, like where management, people making decisions what's being built, also don't have that perspective. So is there some advice you could give to somebody whether maybe they do try out Zobolo, right? And they realize, hey, okay, we actually have some warnings. And they realize, oh damn, this is not trivial to fix. So now I gotta talk to somebody and tell them, hey, this is the thing we need to fix. And maybe management says, no. So what your, maybe you have some war stories there or some things you can give those people to help them make the argument.

 

I don't think I have a specific war story. Maybe you wait to... First of all, understand your... When you're picking a war, understand what war you're picking and against who. So imagine that you're talking with a manager and the manager kind of ignores you and say, okay, yeah, security doesn't matter that much. I just want to push this. feature out of the door because we're late, we need to ship it by QXY, because there's always that conversation of, oh, Q1, we need to deliver 10 features and we're behind that. There's always that conversation. For that kind of scenario for a manager, just show them the money loss that a security issue brings. So go to the news and see, okay, why did this company add downtime? why LastPass is losing customers, why, why Lock4j was a problem and give a specific example of a breach. I think, I think Lock4j, I think it was a, what was it? I'm not sure if Lock4j was the credit, the credit company of that, there was a credit rating company in the US that had a massive leak, but I don't

 

Equifax.

 

think that was Lock4j.

 

I think it was locked

 

Equifax,

 

for J but Equifax. Yeah.

 

was it? I'm not, I'm not 100% sure, but again, You just need to find news where hacker stopped X for X amount of time. DDoS stopped X for X amount of time and tell them, look, this is the problems we're facing. This is the kind of thing that could happen to our company. The amount of time we need to spend on this is X by my estimate. We can split it up and let even do, I don't know. the task force of security. We'll just leave two or three developers kind of cleaning up code, checking that this doesn't mess up too much the CI so it doesn't impact too much. Start with, for example, sub-low only high security issues and then move to medium and then move to low kind of step by step win their hearts by showing them that it's actually really dangerous to have a leak, to have downtime. And most of those things. If they're not errors on the infrastructure, which are probably the most common cause, for example, for downtime, there's actually downtime by DDoS. So and that's an attack vector that exists and potentially could disrupt the business. So just show them that there's money involved. That's I think that's the end of the advice is show anyone non-technical that there's money involved. There's loss of customers. There's loss of... loss of clients, there's loss of revenue. And by then they'll kind of go, oh, okay. Let's, let's research that at least. And by then they'll go, you just need to do that step by step situation of, let's be sure that it's not also too disruptive. Um, because the reality is whatever you're developing, your product is paying your bills and if it needs to be developed. That's the reality, it needs to be developed. So try to find a plan that it's not too disruptive for day-to-day life, even if you kind of push for a small team to do this and just show them that it's really dangerous to keep it as is, money-wise, money-wise and client-wise and reputation-wise.

 

Yeah, full of money, I think. It's

 

Yeah,

 

also

 

it's it.

 

surprisingly often effective. Ha ha ha!

 

Yeah, it's a mix of sad but true. Money is the end goal for all companies. Let's not lie to ourselves. And showing that impact will help you immensely on proving your point. Also, another thing, yeah, sorry. If security is tricky for developers, it's way trickier for non-tech people. So also be kind, be aware that a lot of the times the fight against implementing X, Y, and Z probably comes from a source of not fully understanding the scope of what's happening. And again, be kind, be calm. and be assertive about why something should happen. Because if you are aggressive on explaining why something needs to happen, you're just burning bridges, it won't help. So again, it goes back to that idea of communication is key to a lot of this conversation.

 

Makes sense. Thank you. Thank you, Philippe. Okay. Is there anything you would like to tell our listeners before we go to picks? And also, one last thing, how would people reach you if they wanted to talk to you?

 

Okay, so one last thing to say to the listeners. Just have fun. Let security be one of those subjects that might entertain you because there's really interesting hacks out there that some of them are a bit comedic, some of them are a bit scary. So see them as almost as a novel. You're one day you're reading a drama, the other day you're reading a comedy, but you'll find really interesting stuff out there in the community. So just have fun and see this as a subject that is interesting. and don't be daunted by the size or complexity of the fields. As for how to reach me out, I have a Twitter account, so Philippe Cabaco, all together. And that's basically the handle for GitHub, for GitHub and basically everything, I guess. And yeah, that's how you can ping me. More than happy to chat about anything.

 

Nice. Thank you. So as usual we go to pics and Alan Is there rust book this week?

 

No, actually, again, I keep playing like crazy amount of steam these days. So I just started playing with emulated stuff on the Steam deck. I've had a lot of fun. So like all these games, like one of my favorite games ever is middle gear solid, solid game. You haven't tried it out. So I've been replaying it since I don't know since I was a wee kid, right. So I got this thing called the emu deck. It's a you can software you can install on your thing on your Steam deck. You can play like nearly everything except for Xbox 360. I think it's the only one I had ever get working. But yeah, I think it's pretty cool to check it out. The product is pretty cool. Yeah, I was just looking for more games to download. I was just downloaded a couple right now because Sega Genesis games are just like less than a megabyte big. So I just tell them the bunch. So and I own these games. Okay, so don't come to my home. I own these games. I'll find them at my parents house if somebody comes find me.

 

Nice, thank you. Okay, I have two picks this week. One is a nerd pick and the second is a deeply personal pick. So, Alan, I'm gonna make you choose. What should I pick first?

 

go deeply personal. I'm going to get

 

Okay,

 

in touch with the inner Sasha.

 

Inna Sascha. Okay, so I'm gonna pick my deeply personal pick for this week is a book called ADHD 2.0 because I recently got diagnosed with ADHD and it explains a whole lot of things of my life. And the thing about ADHD is everybody knows it but it says so many stereotypes attached to it. So many stereotypes and this book is basically the the collection of what the current scientific understanding of ADHD is. It's written by two doctors from the states. It's very US-y in the way they write, but those two doctors both also have ADHD and they talk about their own lived experiences, but also what the science is saying about it. And if you know somebody with ADHD, if you have maybe somebody in your family with ADHD, or you have ADHD yourself and want to understand it better, then seriously, this book, I can't recommend it enough. ADHD 2.0. And my not big, as usual, a game, it's called Exapunks. And Exapunks is a game about hacking. And you hack these little, you write code for these little robots, which then have to do task in networks. It's a very abstracted and like, your eye focused way of doing it, like they actually move around on screen. But it is kind of coding, you're kind of coding assembly in one way or another. So, It's fun. It's also one of these games which is very much focused on optimizing. So maybe the first time you do it you solve a puzzle and then it tells you how did you rank against everybody else, maybe against friends on your friend list, but also globally. And it shows you like the statistics and then somebody solved this in like half the number of cycles than you did. And then you start thinking, oh wait, how can I cut cycles? And yeah, it gets in your brain in just the right way. So that is something I've played on and off. It's not something I can play for hours on end, but it is fun if I want like a cheap coding fix without having to dig into something too deeply. So ExaPunks, it's on Steam. It's also currently on sale maybe when we air this episode no longer. So sorry if that's true. Okay, Philippe, what are your picks?

 

Yeah, I'm going back to Elixir because it's a problem. It's my work and my hobby. So I have three people I want to shout out. So first of them is Peter Ulrich, PJ Ulrich in Twitter. He has a bunch of really good series on. Ecto and how to build stuff with Ecto. So it's really good to deepen your knowledge in Ecto. He also has a book about how to build tables with LiveView published by Pragmatic Programmers. So a really good person to follow. He writes a lot of good stuff and it can really help you out with a bunch of ideas for your Ecto exploits. My second pick, it's a book by Svillen Gospodinod. I think... I hope I didn't kill his name, but the book is called Concurrent Data Processing in Elixir. I'm shouting out this one because I've read it recently again, and it's a really good book that basically covers a lot of the things OTP is good about, namely concurrency. But then it extends to the usage of Flow, which is a concurrent... It uses Genstage to kind of abstract Genstage, and it's really good. And then it extends that into Broadway. You build up from the roots of OTP into a gen stage dependency, to flow dependency, to Broadway dependency, just kind of build out this story about concurrent data processing in Elixir, and it's really a really good read and easy to follow along. And finally, my third pick, it's from Andrea Lio Pardi, one of the core developers of Elixir and a bunch of the tools we love. It just published a video called Proto-Wackers in Elixir Day Zero, set up on smoke tests. So Proto-Wackers is a challenge where you basically have a website and you need to build a server that complies to a bunch of tests they give you. So we just see Andrea kind of going in and building an HTTP server, sorry, TCP server that for this view it's just echoing, but you can see that he uses GenTCP, which is uh, uh, included in Erlang, he uses tasks, tasks and tasks supervision. And he kind of goes through the, the, the steps to get to a echo TCP server with no, nothing other than Elixir and some Erlang libraries. So, and it seems that it will become a series. I hope so. I'm kind of pushing this, uh, this conversation so we can kind of continue. delivering on this because I'm really keen on seeing the end result of this. And as a core developer of Elixir, I'm really keen to see what kind of code it produces at the end. And yeah, those are my three picks.

 

Hmm.

 

Maybe a fourth pick go go

 

Oh

 

play

 

wow,

 

80s

 

okay.

 

again. Yeah, go play 80s again. I might be been gaming again 80s since the the announcement of the second the sequel that is coming out and It's still a marvelous game. Go play 80s again

 

Okay. So thank you, Philippi, for being on the show. And it was a pleasure talking to you.

 

Thank you so much. Really big pleasure to be here and have a really good conversation. Thank you so much.

 

And thank you all of you for listening to this and tune in next time when we have another episode of Elixir Mix. Bye!