 So yeah, just a bit about me. I'm a developer advocate at Cisco Developer Relations Team. I'm actually from Austria. So speaking from Austria there, and usually like coming from a software, eclectic software engineering and networking background there. I also have to say, so I am taking most of the part over from my colleague, Christopher Fandamate. So maybe you see in some sample codes like his name. So just would like to mention him who can't like present today, but I definitely can talk to you about this as well. What do I have planned for you today? So the agenda is pretty simple and I hope it's you get as much out as possible with these scenarios there. So at first I would like to static stage about okay, where we are, or like what this is about. Then I will go through five common vulnerabilities and you can see, so I'm staying here completely at the coding level. So basically on what can you do or what kind of mistakes you shouldn't do, especially when you code in Python. Of course, in a container environment, in a Kubernetes environment, and then I will end with a notable tool set for you. So the main part of the presentation of the session will be about classic coding. And then of course there is a help there, especially like after deploying the application, there you have monitoring tools, especially for cloud native environments, especially for Kubernetes environments, which I definitely want to mention here as well. Cool, if you have any questions, I hope it's fine like to take this after a couple of minutes or in the chat if this is okay. All right, so setting the stage. So first of all, should I be worried about my HelloPython, HelloWorld.py script, right? So not all of our scripts or especially when you're testing our top priority, right? So this is basically best practice to write secure code that's for sure, especially with testing, but at minimum, and this is more important, you should know your code's weaknesses. So basically it's about, you don't need to secure your HelloWorld.py script and so on, but since you are like interested about this field, I guess you have already written some Python code and this is now you would like to take this one further and this is where you would like to implement it. And a classic quote is from Confucius and I think this really sets the setting, the security here is about to know what you know, but what you do not know, this is actually true knowledge. So you have the field on what you know, like what runs and then to do what actually you do not know that you are actually mentioning it or that you notice, this is actually that you have some really powerful knowledge there. And with that being said, I would like to also go through the OS list. So I don't know if you're familiar with that and we'll make, let this be, and I want to make this as interactive as possible. So if you, and I'm opening here now my web browser, you can see here that there's a website OS.org if you are not familiar with it. And this organization is actually bringing out the top 10 security issues from software engineering or like from developer application. So you can see here, there is a list. So like with the top 10 list of 21 and there's also like a really cool list like what has changed. So you can really see like what kind of issues are going up and which are basically number one there. And I, like no worries, I already checked this list here and you can see the top 10 list is actually broken access control which went up actually for five places up to number one. This will be covered. So then injection will be covered like you can see just a bit of example of the OS.10 list. Then vulnerable and outdated components, classic one and number nine as well, especially in coding security, logging and monitoring failure. So you just can see the bit that this, the basic the vulnerabilities which are there, they are actually based on the OS and based on specific research what mostly Chris and I did. So yeah, so one other important thing like when it comes to the OS top 10 is about before going into the vulnerabilities the speed of development versus security. So it's a classic thing that where should we focus on? Or where should you focus on? So basically the developers, you have to develop a point of view where they are focusing on a useful language creating useful features. So they collaborate with security teams only if there's some investigation if there's some bugs and so on. But this is basically it. And then you have the security point of view where you have hopefully, and this is, it really depends also on the environment of course, EBS security, EBS secure where teams where they ensure developers hate write secure software, right? So like check out your dependency, do some training, do some testing, create some test lines there. Most importantly, of course, create a pipeline even for that. And then on the other hand, it's like the stack ops team, right? Like this is really a team which is like from the operations part of view which is going more into the investigating the events like that could be like security incident or preachers or this plastic. And with this together, of course there's some tools that's out there. And tools that I will talk a bit later on and in between on what developers can also focus on. But now I really would like to focus on just the vulnerabilities in the code. And then again, more on the security side. Hey, like with application security and then of course with the operation part. Cool, so let's start with a classic one of the first one. And this is just like an arbitrary number, arbitrary order, so arbitrary code execution. So what is it exactly? So an attacker's ability to run commands or code on target machines in a target process. So this is actually a classic most like a common vulnerability in Python. And you can also do this like when a user has some input there. So a classic if there is a database in a query like with SQL, if there is a command injection, like if there is an input there, right? And if it's not possible elsewhere, like otherwise there is like a user input which had directly passed into the function. And usually it's like a lack of input sanitation. This is a classic reason for that. But I would say let's actually look at the demo there. So I'll open here now my Visual Studio Code and going to the first one here. So this is, and I will make this a bit bigger and then you can see it. All right, so you can see this, this is a classic input. So like a classic input screen. So when I press something, type something here to compute. So two times two, the result is four. So this is pretty easy, right? What else you could do theoretically is that especially you can import the operating system package there. So like again, when I run this here, I import it and I actually can see, hey, this is actually the whole file system list there. And another thing what I guess you don't want to do in a way you can also execute some stuff. So a classic would be for example, to get the config there of your Kubeflow settings. Again, yes, let me, yeah, I don't have the Kubernetes installed, but for that it should work. So like you can also get the Kubeflow setting there. And now how can we solve this? And let me just go back to the slide there. So as before, as I said, it's like sanitize and validate the user inputs first before passing them to the system commands, right? So classic or like what are good examples of Python libraries what you can use is the SD Python module there, Schlax for example. So these would be some some classic like modules what can be solved if that. And let's also check out the solution for that. So with that, I actually put, so here this is basically the main commands there. So here you have again the input and then this input will actually be validated here. So we have a function there which validate the user input and it uses actually the SD library. So basically what it does, there again is like a function within the function with arithmetic. And here actually what it does, it actually parses the user input and creates some kind of like a tree, a tree there and check for each value. Hey, is this like a string? Is this a number like whatever? So if we compile this, so like if we execute this, then we type you something for compute. So let's do three times three. So it actually the three multiples of three actually says the results there. And then you can see here that there is the tree of the module and you can see like on the left, there is it analyzes, hey, there is on the left, there is an integer, the operator is to multiply and on the right side, there's again a constant with this kind of value. And you can also, when we tie this again, we can also like expand the tree and just do it like this. And then we actually adding a node there, we adding a connection there and you can see, hey, the tree is actually growing, right? So you can see like where is the offset and so on. So these kinds of like this kind of SD library is super easy, super cool to use. Also, once you know it easy, then you can actually see, hey, this is my string, this is an integer or this is like where I would like to have my users to go in there. Cool, and once again, so I will check it here. So this is the second, the next one is directory traversal attack. So maybe like from the, from the, what is it called like from the name, it's like again, always number three. Sorry, just to mention, like just to have the relation there. And this is usually caused by improper user input validation. So again, this is about something, hey, what you can definitely like clarify, especially when it comes to, in which directory the user should have access to or can save files. So what is it? So like it can lead to the sensitive files to be exposed. And then of course, you can do remote code execution, which is not that uncommon actually. So what happens? Like the path of the file, which is accessed by the Python script, this is not properly checked. So you can see here, the attacker actually can manipulate the path. So it's like going to a password file or like, you know, having some, some kind of unique characters there so that they can actually access the path there. And yeah, let's check it actually out in the demo. So if we go again to the vulnerability here. Hi Flo, would you mind increasing the, oh yeah, sure. Yes, code a bit more, thank you. Right, yeah, sure. Thanks for the feedback. All right, so you can see here now that we have again, simply file location input, then we open a file and we have the file content there. And I guess you already know, so like on the left side, you can see like I can type in here foobar, which is totally fine. This is this file we would like to access so we would like to say something in there. We execute it and it's the hello world part, but you could also theoretically do the same and exploit like here the cube config. So which is definitely not the best way. So what can we do instead of it? Like with these kinds of things, and this is not like with ASD, of course we can work as well. However, there are some other best practices there. So basically a good thing is to maintain an allowed list of files, especially like if you want to access it, or especially when you say something in a directory, like, you know, users uploading something, then use definitely a static save directory. So a classic thing would be, of course if the user cannot change the path, for example, so that you just selected, or the user is just selecting the file name and that all the files will be stored there if this is okay. But this would be the same if it's not possible, then there's also a solution what you can do. The other thing is about don't store, of course a sensitive configuration files inside the web route. I think this is the classic, but still some people are unfortunately still doing it. And validate the user input by accepting only specific and good data. And good data or like especially unknown file paths, I will show it, like the best practices actually not to sanitize the data with the ASD file tree, do it like this. So again, I'm opening here the number, three, it was, and here you go. So what it does actually, and you can see it's like this is a save directory and the save directory is actually from the parent path, like this is because of demo purposes slash foo and this is the save directory. And when the user is asking, hey, the input location, so I will just execute it, I actually say, I don't know something else, like slash etc slash slash slash or slash etc just, then you can see that the input file path is etc. The real file path is private etc, longest common path prefix. So this is like where it's like the input and the actual save directory, they are being compared. It's like only the root basically one is the common file path. And then you can see, hey, a request directory is not same as the save directory. So what would be a good input part, like the user can only do again foo slash bar txt. And then you can see that no, it's not in this save directory. And it should be there. Okay, I moved something around before that, I shouldn't have done it. That's the thing, but usually what the classic path is, is that with pathlib, and then again with the exception or with the prefix, you are actually saying, hey, if the prefix, and this is what you're checking against it, is the same path as the save directory, as the save here on what you have actually set up there. Then this is like, this directory is not the same, right? But if you actually check against it, then the file content, then the user is allowed to read it. So this is the classic path to say, hey, select a save directory and basically change it with the prefix on what you have there. All right, so then let's go to the next part. To the next part. So it's like what you can do. And this is like the outdated library. This is also I think a classic one. So keep in mind, like it's a classic, like libraries are written by humans and we do mistakes. And mistakes especially are getting exploited, mistakes are getting patched. So we forget to update the codes, we have like dependency and so on. And this is also like always number six there. And what is important here, like here's an example that always updated and always also check the changelogs. But usually you need to work like with you need to work in code something. So before checking the changelog, there are also like some other tools what you can use, which are coming a bit. Before that, this is a classic example, like requests you can see like from 2.19, there is like, it's like not secure. So definitely use the request library. I think everybody knows it is like 2.20. So basically what is, like there is a vulnerability. This is happens, like there is some HTTPS to HTTP redirect, which is like not so good for Sniffer's there. And what is the, how you can you solve it? So there are actually some capabilities of on how you can solve it. And I would like to go now into the two things, which is the static application security testing SAST and also run them application staff protection RASP. So this is basically what I would like to, would like to propose as a solution. And SAST, I would like to demo with GitHub. So with GitHub, maybe you're familiar, there is like code and security analysis. So if you enable all these settings there, then you actually get a message like this, we found a potential security vulnerabilities in your dependency. And this is pretty cool because like when you go to GitHub and I'm going now to my GitHub account and I check, go with the requirements and I changed the requirements to, we saw it like 2.19 and then we commit the changes. Then you actually see directly, hey, we found security vulnerability there. The same you can do with a packages like with Node.js and so on. But this is basically like a really cool thing that you can see, hey, there is something happening. And also there is, you can like define a bot there where you get an email, where you get like a messaging request there to say, hey, there is something wrong with my code there. Cool, and yeah, like other things are there, you will have like alerts and so on. And this didn't happen right now, but like there will even be a PR to mitigate the risk there. Yeah, then what else is there in order to save it? Like this is classic code, but just for you to mention, there is also like a runtime application staff protection. And I used Cisco AppDynamics for that. So based on that, you can run this on a Kubernetes cluster, for example. So just to have like some visual screenshots, I think these are the best that you can see. So on the right side, you can see, hey, like the AppDynamics is a runtime installed when you're executing your application. And you can see, hey, there are some security events happening and this is actually happening during runtime. So there's no nothing happening like on GitHub before that. So it actually, this is happening like when the application is actually executing. And you can see at runtime, hey, there is the vulnerability library or hey, there is some outdated code running. And there's also like a calculated risk factor there. And of course you can go more in detail, hey, what is this about? You can see, okay, is it super severe? Like, is this like a really public knowledge or is there something like this has been solved like for ages? So you definitely should do something there. And then, yeah, like the StackOps team, Confuda attack, like this is a bit from the StackOps team. But then again, they can check with the owner, with the application owner, hey, like the responsible code, hey, where is actually the details there? Cool, then yeah, let's go to number three, which is then incomplete assertions. And I don't know if you're familiar with assertions, but these are especially for debugging. So just like upfront, this is mostly for debugging, which is also like a really important tool, especially when you would like to check, hey, like, is this actually, like, is this the right code? Should it be executed? Should the user actually come this far when this error message is being displayed? So what does it mean? It's like, so when a Python assertions are used to evaluate the condition, so like a classic Boolean expression. So if the condition is true, like if you can do it with the expression here, like in Python, you'd be asserted and then the expression. And then actually, if this is true, the execution, a Python will actually, the interpreter will go to the next line, but otherwise it will actually show an error. And this is especially good for debugging. And I have here like also brought here a classic example. So when you go to, so we, under the code, by the way, I will, it's shared on GitHub, so I will share it anyways. And you can see, and this is pretty, like once you understand it, also good to know. It's like you see, hey, the variable to assert is like a foo. We define foo, the string foo. And then we just type in here assert and say, hey, like is this string or bar to assert? Is this actually foo? And then if this is true, then actually nothing happens. It will just print the next line, right? But if it's the answer to assert is like bar, then actually it will return an error. And I will just run it and you can see it. Like we actually print next line one, but then you can see here that to assert the variable to assert bar is actually assertion error. And you can put in there anything you like, right? Like you can put in there a number and say, hey, number one, is a third number more than zero? Or is there, is it like a specific error code you would like to have? So this is all what's assert what you can test there. All right, then let's actually go to the next part. And how to solve it or like a classic part is like do not confuse like partner search and for logic. So like if and else statement, this is like only really for like testing environment and usually when you run Python code, like there are no assertions happening. So this is usually only for happening for debugging. All right, which brings us to the last one, which is then a broken access control. And this is, again, I set it here, the number one actually that you can see here. So you have like here, 94% were tested for some broken access control. So it's really number one. And there is some examples. So like the valuation of the principle of the lease privilege, then a key identifier change where I will check this, I will have a demo like in, or like a showcase in the next slide and the privilege escalation there. So a classic example would be, hey, you actually have the account details you write in here like just via the parameters ID, access key and access secret. And basically you can or the attacker can then give out the open secret there. So how do we solve it? So this is very important, it's like validation and verification of requests, but I think this is also a given. And then robust permission is an object level permissions so that the authorization, they need to be verified like if this is an authorized user and if this is like the same request there. And important thing is like the authorization and accounting, so AAA, this is very important because once you authorize the user, not the user, not all users can do the same action, right? Like an admin user can change something in the database where just the operator or something it just can do like can do a read only or like can only go to specific parts of the application. What is the best practices for sure? Like especially in the beginning, like use a pre-built authentication system framework. So Flask has one, Django has one, which is pretty extensive. So before you write your own, definitely check out these examples there. All right, so yeah, with that being said, I would like to close it with like a notable tool set there and with a graphic. So it's like a pretty extensive graphic there, but like- Running out of time, I think. Yeah, all right, I will just close one of this here. It's like that we started here, like with Python with the applications there, but there is so many other things like around it with Kubernetes with happening like between the containers like outside of the cluster. So all in all, we started just with the Python part, but all in all there is a huge other ecosystem around it. But yeah, with that being said, I hope you liked it so far. We covered all these vulnerabilities there and a bit with the tool set. And yeah, thanks for your attention. Thank you everyone. Maybe we have time for maybe just one quick question. Do we have any remote questions? No, anyone want to ask a question here? No, can you use the mic please? Hi there, great talk. Would you advocate using tools like mod security and BAF technologies as an extra measure? I would say so. So it's like, it really first of all, of course it depends on your setting. But I would say so, that this would definitely that you can leverage that. And for some other things, it's like it depends on where exactly, like do you run it in a Kubernetes cluster? Do you run it remotely? Do you need remote access there? So these kinds of things you definitely need, like need to have in mind. But for that, I would say go for it, yeah. Okay, thank you very much. Thank you.