DEF CON 29 - Rotem Bar - Abusing SAST tools When scanners do more than just scanning

00:05 - I’m playing with SAST tools because part of my job and part of my actually interest is how to secure code and then the best way and doing so, we always start by playing with SAST.

00:21 - After SAST, the much more highest than SAST but we’ll focus about static tools and I turned to play with them and abuse them in different ways.

00:34 - I will show you how. So, who am I? I’m Rotem.

00:39 - Nice to meet you. I am the head of marketplace at Cider Security.

00:43 - It’s a startup I joined a few months ago. But more important, I’m a bug bounty researcher.

00:50 - I play with lots of different programs over the years and I’m a Cyber Paladin for the last 20 years now.

01:01 - So I started my InfoSec career 20 years ago, and then I’m just playing around with different, some application testing to infrastructure testing to developing a different SAST tools and now playing and abusing the SAST tools.

01:19 - I will show you what I’ve done. So, first of all, who is my target audience? So I’m talking to the different type of people, and I think this will interest also security engineers who want to fix problems and they have to tell other people where they have gone wrong.

01:41 - I’m talking to DevOps people because they are in charge of large scale deployments, and everyday we have more and more automation and more automated deployments going out everyday.

01:57 - SAST Builders, of course, it’s a different, like this talk is about SAST so I’m talking with you guys.

02:04 - And I bet the bad guys, people who have decided to harm other people for a living.

02:10 - I hope none in the audience here, but if you are, please go to the good side and start helping people.

02:18 - So a bit about what we’ll be talking about.

02:21 - It’s SAST, how it works. I’m going to give a brief intro about how we can get the works and why I started this research.

02:31 - I will show up the hacking and what I’ve done, and that will wrap up with different conclusions and what is the impact of all of this.

02:40 - So SAST 101. What is SAST? SAST is static application security testing.

02:47 - This means that we are testing applications in a static manner.

02:54 - So I went to Wikipedia and Wikipedia says very, very easy, that static program analysis is the analysis of computer software that is performed without actually executing any programs.

03:11 - This is very important because static analysis can happen on different targets with different types of class and we don’t want to execute any programs.

03:24 - Let’s say that we have different puzzles that do execute programs and their sandbox environments, but SAST was supposed not to execute nothing.

03:37 - So why do we run the SAST? The first thing is to stop bad security practices.

03:46 - We want to make sure that nobody and so it’s a bad code into an organization.

03:56 - We want to prevent infrastructure mistakes and now we have lots of infrastructure as code and we want to assess code.

04:03 - So if we have like a big security test, sometimes I will run a bunch of SAST tools to check the code.

04:13 - And they want to create standardization and consistency across lots of codes.

04:18 - So let’s say, there was no eval in our code.

04:23 - We can create a rule. No eval and we run it and it would be standardized.

04:33 - So why SAST? And we have different pros vs cons.

04:38 - But the pros, it’s very fast. It can run on code.

04:44 - Different SAST have different like times, but it’s much faster than SAST and much faster than other fuzzing and various solutions.

04:53 - It’s safe. It doesn’t execute any code and it’s easy.

04:58 - We can run on the code. We usually don’t need any other resources.

05:03 - Sometimes we have inputs and stuff like that, but usually, it’s inside the same code based and we don’t need external resources for it.

05:14 - About the cons, we have lots of false positives.

05:18 - Like SAST can do as much as looking at the code, but it doesn’t know what’s the logic and it doesn’t know how was it use.

05:28 - It’s very hard to track a flow control. So if you have lots of complex flows, SAST will be a nightmare over you.

05:41 - Not why SAST, but how do they work? How does the scanners work exactly? So, first of all, the scanners take the code.

05:49 - They pass the code and they look for different, let’s say, job script.

05:53 - So they look for job script files and then they start converting these JavaScript text files into AST structures.

06:02 - AST is a structure of how to template code in a way we can process it later.

06:09 - So after we create the say, standard, we’ll show you later how it looks like.

06:14 - We start processing it. When we process the code, in basic, we have different rules and different findings where we want to look for.

06:28 - And then the more complex SAST, we have flow control analysis, and we start looking for sources and sinks.

06:34 - But then we have all the results and we’ll create a result based on SAST.

06:39 - Usually today, we have SARIF. It’s a really fun format that lots of tools are starting to adapt.

06:46 - And we are working with this and we are creating the results, so other systems can not consume them.

06:54 - Let’s take an example. If we have a Log one plus two times three.

07:01 - It’s a very simple function that does a arithmetic computation.

07:05 - And how does it look like in AST? So, first of all, if we look at the binary of the tree, so we see the program, the CallExpression is Log.

07:17 - It has a plus expression. And then there’s a split like one, and because times is before class, this is a basic math, so we have split over there and then there’s the two and a three.

07:33 - Sometimes these AST are by ANTLR. It’s like the structuring tokenize of a language or by other means, it doesn’t matter how it created it but then it creates this too.

07:48 - From this tree, we can create JSON or XML or however we want to represent it but we are creating the data that we can start looking up on it.

08:01 - So let’s say, we have here a CallExpression in the identifier.

08:04 - Again, we have a callee and arguments and you can see the binary expression, so now we can start walking the two and start understanding what’s happening over here.

08:13 - If we take a basic rule, let’s say, if this is a CallExpression and we have a log and the length is above zero, we have arguments, then we can say there’s a log function with more than one argument.

08:34 - It can get complex. We can have more very flow control and a very complex architectures.

08:44 - So let’s say we have this if and then, and all this goes into a variable we call source.

08:50 - We target as a source. And then we create another argument, another look up forward sinks.

09:00 - If we using nil for JSON or some other graph database, we can start connecting sinks and source and seeing the whole trace, and then if data source, we can report a finding.

09:11 - So it can get very complex and very fast, but still it’s very functional, it’s very static.

09:23 - We never executed the code. So as Wikipedia said, it clearly doesn’t execute the code.

09:32 - We don’t have any execution over here and we are good to go and we can start using the SAST to assess even the most malicious programs and malicious code areas.

09:46 - So my hypothesis and my question was, what if I could write code that will intentionally abuse a scanner once statically scanned? So this means, can I create a method or way with these areas to change the behavior of the scanner? To abuse it or change it though.

10:19 - So I looked up at different previously researches and we had in the past, there was a Checkov remote code execution.

10:28 - It was fixed. And then I Checkov 2 one day created it.

10:31 - Someone could create a malicious terraform file.

10:35 - And with this terraform file, it could execute code inside Checkov and the one executing the code had access to the whole environment of work was executed.

10:48 - And there was a very simple Checkov walkaround.

10:50 - Do not run Checkov on terraform file from untrusted sources or pull requests.

10:56 - But I want to run Checkov on untested sources.

11:00 - This is why I’m doing it. So it’s a bit of a mix.

11:05 - So they fixed it and now, I feel I’m okay, and I can run again Checkov.

11:13 - But I was playing with, it was a repo, but you can use it also as a SAST.

11:22 - It’s a Clojure repo that you can use also as a SAST tool and create different types of rules, and I will expand about it a bit later.

11:30 - But I opened a bug about it that it actually evaluates code.

11:36 - I will show you exactly what it does and how it does it, but in the comment I got, I talked to the guy over there and they said, “okay, but this is how this kind of works. ” And we have nothing to do about it.

11:51 - Maybe add the computation. So I’m looking at terraform.

11:58 - Terraform was actually, it’s not SAST, I know, but we do have different SAST scanners like Snyk or Terrascan that do rely on the terraform plan.

12:13 - So one of the recommendations inside CI/CD environments is before running like Synk IaC is to create a TF plan, and they show here in the documentation, run terraform plan, and then terraform will show.

12:31 - So we have terraform. Terraform has a plan and then apply.

12:36 - And in the apply, it does actually do stuff with the environment and executes code, but the plan shouldn’t do anything malicious.

12:50 - Hiroki Suezawa, someone I talked with in one of the cloud forums and he pointed that actually terraform plan can run code.

13:01 - You can create a terraform provider exec and you can run code with it.

13:06 - So if you’re running any SAST that is relying in terraform plan and the other terraform plan before the SAST, then you should know that someone can create a provider and you can create even an unofficial provider that will download it from our HTTP server and execute.

13:32 - So you can see also Alex Casso has created a very nice blog about it, but this is other.

13:41 - So by the hacking time and now we are going coming into different stuff.

13:46 - But first I want to have a small disclaimer.

13:50 - I believe in open source and I think that makes the world secure and it makes our life easier with open source, but we need to use it responsibly, because open source is not a full blown commercial tool.

14:12 - It didn’t have the use of development and lots of clients.

14:21 - Maybe it didn’t have lots of clients, but it doesn’t have enough resources to always to be in the best security maturity level.

14:30 - And we need to understand this, ‘cause when we use open source and I believe in using it, but we need to make sure that we run it and we treat it as something that it’s not fully baked or it’s not like some are more mature, some are less mature, and we have to know about these areas.

14:55 - And one of the parts of my mission and what I want to do is to make sure that it will be safer and safer to use open source in companies and in real life.

15:10 - But for starters, we have to make sure that we are running in a safe environment and that everything is configurable, then we know how to configure it properly.

15:23 - So that’s about that. But my experiment.

15:28 - So my experiment is very simple. I looked at different scanners like collected through my experience.

15:41 - And then I started looking at how they will execute or what can I do with them? And they created different kinds of evil files.

15:50 - What is evil files? I will show you in the experiments there now, but I’m adding these evil files to the repo.

15:58 - I’m letting the environment clone the repo and then assuming the scanner will walk in the same working directory as the repo clone.

16:11 - Now, this is a assumption based on different levels of knowledge in companies and they saw in lots of places, the scanners are running inside the same working directory as the repo and scanning themselves, scanning the repo itself.

16:29 - Then executing the scanner and they want to see what’s the outcome.

16:33 - What can I do? So experiment number one, Checkov.

16:39 - Before we had the rce on Checkhov and this is why I started looking at it.

16:45 - And they started looking and edit the commendation and they saw that Checkov is actually running against, you can run it against the directory.

16:54 - Against a working directory. The same working directory or the home directory, and once you are running against the directory, it looks for a. checkov. yml file to load it as a config file.

17:10 - This is interesting, because it’s actually how you need to work with Chekhov or with other SAST tools.

17:18 - The SAST tools as you develop different changes and different types of levels of maturity inside the code and developers are able to skip rules and optimize each repo according to what they want to do.

17:39 - But this means that also, if I will take a repo, I would scan it.

17:48 - And I added the checkov. yml file into the repo, I can say, check none.

17:56 - I can give it a check none file. What will happen is that the Checkov will pick the configuration up if there’s no forced configuration and it’s big if but most or lots of places I saw don’t have force configuration.

18:19 - So it will actually not scan the code. It will give you everything is okay.

18:27 - This is in a philosophical way, a question.

18:34 - If this is how we should run code, because we are giving the developer lots of permission and lots of ability to configure properly what he wants to do, but at the same time, we are giving him the permission to do nothing.

18:56 - To say, just skip it. Let’s bypass security altogether and just leave me alone.

19:05 - This is a good question about what is the security team I should do? Let’s look at a demo.

19:13 - Here we took TerraGoat, a TerraGoat is, let’s see if we can see it here.

19:22 - (Rotem speaking faintly) We talked TerraGoat.

19:24 - TerraGoat is a repo that has lots of problems for the Checkov, and you can see, we have lots of fair checks.

19:35 - Then the echo, this is a very important thing.

19:38 - The tone code is one. One means there was a problem and if it was in a CI/CD environment, it would fail.

19:49 - Now I’m echoing again the same thing, but I’m adding the bypass checks into. checkov. yml and running again Checkov.

20:00 - Nothing. Everything is good. There are no errors, no nothing.

20:04 - Their code is zero. Everything is awesome.

20:08 - So this means with a very simple adding of the rule, I think of this file, we bypass the whole scanner configuration.

20:21 - So after we saw what we can do with Checkov, I looked into different other tools and they all, as I say though, by definition or not all, but lots of them give you the same configuration, the same ability.

20:40 - They have a different configuration file. You can create it and then bypass or create different rules.

20:48 - And we can see here, PHP Stan, Tfsec, and KICS, and Bandit, and Brakeman, Checkov and SEMGREP and I’m sure there are more that I didn’t check.

20:59 - We have the different configuration. If you put this different configuration, tell them bypass our rules, they will bypass all the rules.

21:07 - You can see there’s so many stars on the scanners.

21:10 - I think it’s about like 12, 15, we have 25.

21:16 - We have lots of get up stars. Over here, let’s say get up stars we are looking at.

21:25 - Before we went more, I want to emphasize and talk about the scanners hijacking.

21:33 - So what have we done? We were able to add all the source code in a manner that we were able to manipulate and abuse how this kinda works, this kind of behavior itself.

21:47 - So if someone adds a file inside a repo and I’m running it, I’m able to tell them now everything is okay, just skip skittling.

22:03 - Sometimes it’s good that we can do it and sometimes we don’t know about it and we don’t have the proper visibility if someone really did it.

22:11 - Like I don’t look at all the files out there in my 1,000 peoples inside my organization and start looking did someone manipulate and abuse and bypass my scanners.

22:27 - Like this of what I’m doing. The scanners don’t tell you, ah someone bypassed me, please check this.

22:36 - So that’s a good place to think about and understand what we want to do with this for the future.

22:43 - Let’s go, this is DEF CON. So I’m going into experiment number two, and this is much more interesting.

22:49 - So I continued to look inside Checkov and I saw there is external checks there.

22:55 - Now does a directory for custom checks to be loaded? I like custom checks, because custom checks means code.

23:05 - So looking at the different what I can do. So again, I created a repo that I can clone it, scan it.

23:13 - It has. checkov. yml inside. I load the configuration.

23:17 - And inside, I tell it, go to external checks, so inside the directory checks.

23:23 - Now I can call the clone, I can call the repo.

23:26 - So I created a directory with that checks with init py, and then inside, I can create any Python file I want, and it will load it.

23:37 - Like one Checkov will scan, it will first load my files and execute them.

23:46 - So now not only I’m able to bypass the configuration.

23:51 - I’m actually able to execute code inside the environment that the scanner is running.

24:01 - And let’s see a demo about this what we have in demos.

24:05 - So I created here like I have my pipeline that is waiting for an event.

24:10 - I have a rce file over here and I created a. checkov. yml file with different tunnels.

24:19 - Inside the tunnel, it just creates it, cause the rce. sh with Checkov.

24:25 - Rce. sh just send something to my pipeline so I get on call, I don’t remember.

24:31 - And as you see, at the moment I run checkov, I see a post.

24:34 - I got something from Checkov. I even see it had a picash complied to my files, I side it’s stuff.

24:43 - So it’s actually pretty cool. Now with this command execution, I can execute.

24:48 - I can access environ variables. I can access different networks.

24:53 - I’m actually running as the scanners themselves.

24:58 - So that’s important. Experiment number three.

25:03 - Now I talked about Kibit before, about Clojure.

25:06 - Clojure is a very interesting language. It’s very, very dynamic and very fun.

25:14 - This is better from the source code of Kibit.

25:18 - Those are read file, and this is how it reads the files themselves the source code.

25:24 - It uses a function called read. Now we have a warning inside the source code that you should not use clojure core read or its string which is weird, because every junior developer will try to read string and read data from untrusted sources.

25:47 - So this means that the question is why. Like you may be asking why is this a warning? What read actually does is reads the Clojure code and evaluates it.

26:03 - And then Clojure, we have something called like a self-evaluating form and I will get to it in the later slide, but this is Kibit.

26:13 - Kibit it as a static code analyzer. It takes some code and then when you run it, you run it to your applying user.

26:22 - It’s lein is like the npm of the Clojure. You want it to apply and it tells you, okay, this is a problem.

26:29 - We’ll consider using when instead of if. But then if you use self-evaluating form, that’s #= something.

26:43 - This will actually run if you run it through read the function.

26:48 - So I created, again, I load different libraries because Clojure is very dynamic.

26:54 - I can load everything I want, and I did a print line to a shell to run again the same rce Kibit and then shut down agents just to exit nicely.

27:07 - So I run it line, Kibit, running code and then I see the exit code, exit 1: out success.

27:13 - I’m able to run my code. Experiment number four.

27:20 - We see we have pre-processing. So Rubocop for instance has a configuration file that is very cool and very dynamic and so dynamic.

27:36 - Once it sees, it’ll be contemplating, it executes it.

27:42 - I saw in the documentation. Yeah, let’s do get status.

27:47 - So I just did run rce Rubocop, exit. It worked.

27:53 - So the moment I load Rubocop, it looks for. rubocop. yml, executes my codes and exit.

28:04 - Great success. Experiment number five.

28:08 - And this is a bit different than the others, because I didn’t find a PMD any way to have a configuration file, but it looks for so much environ variables and one of the environ variables is the Java Opts.

28:25 - So you can tell that what options to give Java one running PMD.

28:32 - So I told them, use jar. Use my jar instead of your jar.

28:39 - You can run an Eviljar, it works and you can load the another jar.

28:43 - But the question is how can I tell it, the environ valuable? So in some CI environment, so in some areas I know like even I know my sh, you can create a plugin that if you see a. env file, load it automatically.

29:02 - So if I also submitted that. env file, ENV, sometimes it will load in the environ variables before running the scanner.

29:16 - So it’s a good way to do stuff. I played with it.

29:25 - Some areas I will able to put a. env file into lower the different environment variable and they executed my code.

29:35 - So if I am concluding and I have much more scanners in the pipeline to check and I have different areas, but this is a bit about the stuff that I talked about.

29:45 - We have Checkov. For the configuration of file.

29:48 - Checkov, PHP Stan, Rubocop for the configuration file.

29:51 - We have Kibit for code. I can create code that will execute.

29:57 - I have PMD and cdxgen and Dep-Scan. I didn’t talk about them, but same thing with environ variables.

30:08 - Every time someone shows me now study cos. I’m checking what the configuration file? Does it have some kind of a loading of rules, and more, more and more.

30:24 - Every day I’m finding more and more. So what Wikipedia says is correct.

30:33 - It doesn’t actually execute the program over the static program, but it does execute programs.

30:43 - So I am able to execute programs for different, we can call side channels from the configuration or from other methods of the scanners themselves to be dynamic, but except Kibit that does execute programs.

31:00 - So normally, but all the others are really for the ecosystem of different work that we are using.

31:12 - So I’m saying like your code will probably be able to execute other programs.

31:19 - This is something we need to understand and know and live with.

31:27 - Big question is what is the impact? If I’m looking at the impact and then trying to look at what it can do to my environment, then I need to understand first where I’m gonna get.

31:48 - So I can run static analysis in development machines usually except if someone will do a get clone from untrusted sources and just load into his idea or some other areas, and the security team automatically analyzes it.

32:05 - He decides to analyze it. This is a risk.

32:09 - We have security researchers. If I want to scan untrusted code, how do I do it? Because SAST may execute code and I don’t want to execute the code on my computer.

32:23 - But my environment and what I am researching mainly in the last couple of months is the CI/CD.

32:33 - So inside the CI/CD, how does it work? First of all, developers commit and push to development branches.

32:45 - When you commit and push, lots of systems do CI checks on every push.

32:52 - They do it in their internal cloud or in Jenkins or in other CI environments, but they run different types of security testing on the code so we make sure that no code will be insert into production.

33:10 - But maybe we can attack the systems themselves.

33:14 - The next place is the pull request. I never pull request.

33:21 - This is the request I want to merge this code into production.

33:26 - We are doing lots of checks and lots of checks usually also done against the production environment or against staging environments that have really credentials into areas.

33:40 - And lastly, we have merge into production. So the merge into production, we can merge from people that by mistake or by intention, push directly into the master branch.

33:55 - And for the pull request. But the same, we have to have the CI checks, and then we need CD deployments to deploy.

34:03 - Now, this gets tricky because sometimes companies forget to separate between the checks and the deployments or give too much formations to the checks.

34:14 - The implications over here. First of all, I can extract sensitive data.

34:20 - We had different attacks in the last couple of months, that running code inside our CI/CD environment, extracted sensitive data and like environ variables and different AWS keys and even code and send them back home.

34:38 - If you have access to the internet, it’s problematic.

34:42 - You can bypass protections. Let’s say we don’t even have command execution, but we do have the configuration bypass.

34:53 - We can create like a policy to bypass the code, to say, skip security.

35:04 - I don’t need them. I don’t want them.

35:06 - They were just making it harder for me to deploy into production.

35:14 - We can infiltrate the network. We can go and use this as a stepping stone inside the network itself.

35:22 - Lots of good teams I’ve done. I played from one place inside the internal network, you can stop nmapping, you can stop going our SNMP.

35:33 - You can do lots of stuff into other areas, maybe it’s connected.

35:42 - The last, but most important, maybe you can deploy as production.

35:46 - You can skip the CI checks. You can false deployment through the CI and this is problematic.

36:01 - Assume code will execute. This is my assumptions.

36:06 - We need to put around this code as much guards and lasers and boxes and sandboxes and different areas we can, that eventually someone will find a way to execute code.

36:22 - If it’s from a very small open source SAST tool to a very large commercial SAST tool or some other things like let’s say, code coverage tools.

36:40 - I don’t know. Someone can hack a code coverage tool.

36:44 - It can be awesome. We assume the code will execute, and if the code executes, we need to be prepared to make sure that it can’t do nothing and we know about it.

37:04 - A bit about before I showed the workflow, the CI/CD workflow, but in this attack flow, I can add code execution to a scanner configuration file.

37:18 - We can push new commit into the branch and then create a PR request.

37:23 - This is every user inside the organization can do it.

37:30 - Sometimes we can do it from the outside, even let’s say, and get up from folk.

37:36 - Actually get up, fix this problem or I don’t know, fix but made it much harder, because now today, new commits don’t execute the workflow automatically.

37:50 - And this is lots of attacks, got stopped in this area, but other areas are less mature and do execute code if you push it to the branch or the PR.

38:06 - But then one repo will be scanned by a scanner and the PR, it will execute.

38:12 - This execution has access to our network. Sometimes also it’s the same network and same environ variables that the deployments and the CD deployments have.

38:29 - We can also just skip the whole check and tell the scanner all is good.

38:35 - Continue on into production even that we introduced very bad code practices back those or whatever you want.

38:45 - A bit about high level possible solutions. I don’t want to go into much here, so just gonna scan this.

38:53 - A bit the network protected, deny photos, deny access to the outside, isolate only what you need inside the host.

39:05 - The same great content knows and pods and run everything and list play permission, and then verify everything is deleted.

39:14 - Sometimes if you have a part of designing for 10 hours, maybe it’s a crypto mining, maybe it’s just stealing the data.

39:24 - Monitor everything, just monitor everything that you can do and then look for malicious activity.

39:32 - We need to understand the risks on running unverified code inside our laptop and inside our CI/CD environments.

39:40 - We need to educate ourselves, educate the organization, educate the DevOps in what’s the best and the how to do it properly.

39:51 - Do what teams on the CI/CD. We want to verify the tools we are running are good, but we don’t have enough resources to do it, so we need to create a framework.

40:02 - To check that how we can ensure that the execution is running in the most secure way.

40:14 - Just ensure that your scanner aren’t doing any malicious stuff, try to stick to SAST, to static and deny any execution possible.

40:28 - If you can make sure configuration is really picked up by your configuration.

40:33 - How it code in the configuration. Lots of tools have option to hold coded configuration to something specific.

40:41 - So it won’t pick up the default configuration files, also environment variables and set them if you don’t need them, and the list goes on and on.

40:52 - I think that security needs are getting bigger and bigger every day.

40:57 - I think I see it and we are getting into massive automation.

41:04 - We’re going into a DevOps deploying different production features every minutes, seconds even.

41:16 - We have to be proactive and understand the next generation of attackers and how they will abuse our infrastructure, our automations.

41:26 - How they will attack us from side channels, from internally, just abusing automation that we are doing in order to make our lives easier, and secure them.

41:48 - Other study code SAST tools. It’s not only security.

41:52 - It’s also linters. It’s also code coverage, testing frameworks.

41:57 - We have much more automations coming on. We need to deep dive and understand the different SAST scanners.

42:06 - We want to analyze the Wrappers. Let’s say we have GitHub actions and then talk about it over here, but different GitHub actions or Wrapping or Orbs.

42:19 - Wrapping all scanners and creating it more difficult to add configuration files.

42:30 - It’s more difficult to check if there is a configuration file to run security.

42:38 - We need to analyze them. We need to create a standard for security working with code analysis tool of any kind.

42:48 - I would want the standard, not only for the output like sorry for that, as for input How am I running security code tools? Maybe do a SAST for executing security tools.

43:04 - I don’t know, it’s a bit meta, but we have much more to do.

43:11 - First of all, I want to thank you guys for coming to my presentation, and I want to thank all the open source developers out there for creating the awesome tools they are developing.

43:24 - It’s tons of work. We have millions, thousands of companies working with these tools and you’re helping them in so much ways.

43:38 - I created a bit of a POC about what I talked about, CI/CD lamb.

43:43 - You can check it out over here. This POC is running great.

43:49 - Once scanned with different scan tools, it’s time to execute them.

43:54 - You can just pick it up, try to use it. Don’t attack nobody.

43:58 - Just do it for research purposes and start to understand how can you run it by then? I started creating a community, I called it Security Tools DEF CON.

44:12 - This link code goes to a Slack and they want to start connecting between the open source developers out there.

44:23 - I don’t know, anyone else that wants to join and started thinking about how can we standardize our tools, how can we create better recommendation and better ways to make sure that once people are running our tools, they’re doing it in the most secure way.

44:46 - Also, I want to raise awareness about this.

44:48 - You can pick me up on Twitter. You can pick me up in the Slack and I will be in DEF CON.

45:00 - I will be going around. Just send me a message.

45:04 - Hey, let’s meet. I have an idea. I want to talk.

45:07 - I will be happy to talk with you and have a beer, go to a party.

45:13 - I don’t know. Just hang around. Thanks again and we’ll see you at DEF CON. .