**The Importance of Network Policies in DevOps**

Many developers get all worked up about network policy, thinking it's very complicated. However, it's really not. It's just all about setting rules about what pods can talk to each other and what can't. On and on about TCP or UDP ports and Neal ports, etc. I'm a big fan of the zero trust pattern, which is no pods can talk to any pod know any other pod except for what I explicitly put an allow list. So nobody can talk to anybody except my pods in the front end namespace can talk to the business tier labeled pods on port 8080 TCP.

**Enforcing Security with Tools**

If you do that, make sure you open up egress traffic to your DNS, because if you don't, then you have no service lookup and that crashes everything. Pretty much. Finally, all of these things I'm talking about enforced that use a tool like Opa, gatekeeper, or Hive or not, there's also a pod security policies, which is deprecated, and going to be replaced by pod security admission. But that's still in beta as of 123. If you're watching this from pod security admission is out of beta, you know, by all means use it, but use any kind of these tools to make sure that deployments that break the rules, the policies that your organization uses, can't be deployed.

**The Feedback Loop is Critical**

The key takeaways from today's talk are critical. Just like with CI, coming on the scene and became a big buzzword, letting me know that the build was broken me as fast as possible that feedback, that fast feedback loop enables continuous integration. Well, it's the same thing with security, finding out that I added security vulnerabilities or somehow weakened my security posture of my application on my own workstation. That's critical.

**Practicing Defense in Depth**

Having that fast feedback is great, because you can fix it now. While it's still fresh in my mind of what I've just did, and it didn't get out and you know cause impact to other people. Secondly, the whatever tool you end up using for scanning and whatnot, make sure that it allows you to be proactive, it gives you good information that allows you to attack now, rather than just scratch your head and say, Well, I have no idea what this means. Make sure that it's giving you good, proactive, actionable information.

**Practice Defense in Depth**

There's always going to be new vulnerabilities that nobody knows about. Except for that one hacker that found it and if you make it harder on the hackers life, they'll move on to somebody that's an easier talk target. That's just how it is. So I want to thank you for watching. Secure your containers. Guys. Thanks. We've reached the end. You should now have a better understanding of DevStack ops and be able to start implementing some new security tools in your workflow. Check out the description for additional resources, and thanks for watching.

"WEBVTTKind: captionsLanguage: enIn this web security course you will learn all about dev SEC ops from me Beau Carnes,  you will learn how to take advantage of common web vulnerabilities, how to fix those vulnerabilities  and how to use DedSec ops tools to make sure your applications are secure. For the end,  Eric Smalling from sneek will talk about securing containers and more about dev SEC ops. Soon I'll  be showing you how to implement common hacking techniques. But first I'll give an overview of DEV  SEC ops. Dev SEC ops refers to the integration of security practices into a DevOps software delivery  model. In a dev SEC ops model, security objectives are integrated as early as possible in the  lifecycle of software development, and security considerations are important throughout the  lifecycle. Later, I'll be going into more details about what this actually means in practice.  But first, to really understand dev SEC ops, it can be helpful to first understand DevOps and also  vulnerabilities. Thanks to sneek for sponsoring this course, their resources made this possible.  Let's start with vulnerabilities. The whole point of security is to protect against vulnerabilities.  So let's understand the different types. And afterwards, I'll discuss DevOps, the average  cost of a data breach in 2020 was $3.86 million in global cybercrime costs are expected to reach  $6 trillion. By the end of this year, it is estimated that 90% of web applications  are vulnerable to hacking, and 68% of those are vulnerable to the breach of sensitive data.  In 2020, there were over 1000 data breaches in the United States, according to the identity theft  Resource Center, and over 155 point 8 million individuals were affected by data exposures.  When thinking about security, it is important to understand the difference between a vulnerability  an exploit and a threat a security vulnerability is a software code flaw or a system  misconfiguration that hackers can use to gain unauthorized access to a system or network. Once  inside, the attackers can leverage authorizations and privileges to compromise systems and assets.  An exploit is the method hackers used to exploit a vulnerability and exploit is typically a piece  of custom software, or a sequence of commands. There are even exploit kits  that can be embedded in compromised web pages, where they continuously scan for vulnerabilities.  As soon as a weakness is detected. That kid immediately attempts to deploy an exploit,  such as injecting malware into the host system. A threat is the actual or hypothetical event in  which one or more exploits use a vulnerability to mount an attack, only a small amount of  known vulnerabilities will be used to hack into a system vulnerabilities that pose the highest risk  or those that have a higher chance of being exploited, and therefore should be the ones that  are prioritized. security vulnerabilities can be found in all different areas related to software.  Here are some common security vulnerabilities in applications and websites. There are two  different important lists of weaknesses and web applications. The first list is created  by the Open Web Application Security Project or OWASP. They have a popular list called the OWASP  Top 10 that features the most commonly exploited vulnerabilities. The second list is CW IE or  common weakness, enumeration, which is a community developed list of common software and hardware  weakness types that have security ramifications. This list is run by the MIT or E or MITRE  Corporation, which is a not for profit company that operates federal government funded r&d  centers. They create the CW e 25, which is their list of the 25 most dangerous software weaknesses  in the CW e 25. There are three major types of application and website security weaknesses.  There's porous defenses, risky resource management and insecure interaction between components  see porous defenses weakness is one that could allow users to bypass or spoof authentication and  authorization processes. Authentication verifies the identity of someone trying to access a system  well authorization is the set of access and usage permissions assigned to the user. Porous defense  weakness examples include weak password encoding, insufficiently protected credentials, missing or  single factor authentication. insecurely inherited permissions or sessions that don't  expire in a timely manner. All of these porous defense vulnerability types can allow hackers to  successfully access sensitive resources exploits that leverage these vulnerabilities may include  credential stuffing attacks, hijacking of session IDs, stealing login credentials, or man in the  middle attacks. The next vulnerable category is risky management of resources such as memory  functions and open source frameworks. The types of vulnerabilities in this category are out of  bound read or write, which is the same as buffer overflow. The application can be tricked into  writing or reading data past the end or before the beginning of the intended memory buffer.  Also path traversal This allows attackers to get to path names that let them access files out of  restricted directories. I'll be showing an example of this later. exploiting these vulnerabilities  allow hackers to gain control over an application or damaged files or even access  sensitive information. And then the final major weakness area is insecure interaction between  components. Many applications today send and receive data across a wide range of services,  threads and processes. The way different components interact with with each other can  introduce vulnerabilities. weaknesses that expose a web application or website in this manner,  can include cross site scripting. This is when user inputs are not handled securely,  it can open up the possibility for cross site scripting attacks that enable attackers to inject  client side scripts into web pages viewed by other users. This is a very common vulnerability.  There's also cross site request forgery. This is improper verification of whether a seemingly  legitimate and authentic request was intentionally sent. These attacks are often mountain via social  engineering vectors such as bogus emails that trick a user to click a link, which then sends  a forged request to a site or server where the user has already been authenticated. If apps  and websites don't properly implement security controls for interaction between components,  this leaves them vulnerable to backdoor attacks, scripting attacks, worms, Trojan horses, and  other exploits that deploy malicious code to wreak havoc on infrastructure data and systems between  the OSI 10 and CW e 25. Lists, it is clear that broken access control is the top vulnerability  94% of applications have some sort of broken access control, access control,  make sure that users cannot act outside of their intended permissions. So if this is not set up  properly, it can lead to unauthorized information disclosure, or modification or even destruction  of data. Now let's talk about DevOps, which is an important part of DEV SEC ops. DevOps is a concept  that has been talked about and written about for a long time, and many definitions of DevOps have  emerged. DevOps is basically a set of practices that combined software development, the dev  and IT operations, the ops, it aims to shorten the systems development lifecycle,  and provides continuous delivery with high software availability. So you can see in the  DevOps pipeline, it basically goes on infinitely going through all these different steps.  Most modern DevOps organizations will depend on some combination of continuous integration and  continuous deployment or delivery systems in the form of a CI CD pipeline. As part of the  lifecycle, a variety of automated security testing and validation can be performed without requiring  the manual work of a human operator. And this is all part of the software development lifecycle.  Here's an example of a common DevOps flow. First, a developer will write code and push it to  a repo. At that point, the CI CD pipeline starts. There are automated tests, then a version is built  that's eventually deployed to production. There are tests every step to assure code quality,  but in this module, security is sometimes only considered right before deploying to production.  DedSec ops follows a similar flow, but adds automated security considerations throughout  the process. Security is integrated with the DevOps, that sac ops codifies security objectives  as part of the overall goal structure. This shield represents all the places we test for security.  Different tools are used for different steps. And I'll talk some about the specific tools later.  Def SEC ops should be thought of as the natural continuation of DevOps,  rather than as a separate idea or concept. activities designed to identify and ideally  solve security issues are injected early in the lifecycle of application development,  rather than after a product is released. This is accomplished by enabling development teams to  perform many of the security tasks independently within the software development lifecycle.  To integrate security objectives early in the development of an application, start before  the first line of code is ever written. Security can integrate and begin effective Threat Modeling  during the initial concept of the system, application or even individual user story,  a static analysis linters and policy engines can be run anytime a developer checks in code,  ensuring that any low hanging fruit is dealt with before the changes move further upstream.  Later, I'll be showing you how to use a tool to check code for security issues.  While you're writing it. Software composition analysis can be applied to confirm that any  open source dependencies have compatible licenses, and are free of vulnerabilities.  I'll be showing you how to use a tool to check software dependencies for security issues.  It can be very helpful to get immediate feedback on the relative security of the  code you've written. And this helps individual developers take ownership of security issues.  Once code is checked in static application, security testing or SAS tools can be used to  identify vulnerabilities and performed software composition analysis. SAS tools should be  integrated into post commit processes to ensure that new code introduced is proactively scanned  for vulnerabilities. Having a SAS tool integration in place enables remediation of vulnerabilities  early in the software development lifecycle, and it reduces application risk and exposure.  After the code builds, you can start to employ security integration tests. Running the code in  an isolated container sandbox allows for automated testing of things like network calls input  validation and authorization. These tests are often part of dynamic application scanning tools,  or deste. These tests generate fast feedback, enabling quick iteration and triage of any issues  that are identified, causing minimal disruption to the overall stream. If things like unexplained  network calls or unsanitized input occur, the tests fail and the pipeline generates  actionable feedback in the form of reporting and notifications to the relevant teams.  Next to things like correct logging and access controls can be tested.  Does the application log relevant security and performance metrics correctly, is access limited  to the correct subset of individuals or even prevented entirely. Finally, the application makes  its way to production. But security tests continue automated patching and configuration management  ensure the production environment is always running the latest and most secure versions  of software dependencies. special techniques and tools can be used to secure containers.  Later, you will learn how to do this in a real world environment.  Using a dev SEC ops or CI CD pipeline helps integrate security objectives at each phase,  allowing the rapid delivery to be maintained. The entire approach helps minimize vulnerabilities  that reduce production, thereby reducing the cost associated with fixing security flaws. Dev SEC  ops aims to build security into every stage of the delivery process and establish a plan for  security automation. When thinking about security, you should remember that your code is just the tip  of the iceberg. In an average software project, only 10 to 20% of code is custom code. Yes,  it is important to make sure your custom code is secure. But there's a lot more to think  about 80 to 90% of mini code bases consists of open source code modules and libraries.  The frameworks and libraries that you import can themselves import more frameworks and libraries.  This is code that you didn't actually write yourself, you know, on average,  80% of vulnerabilities are found in direct dependencies. It doesn't matter how good you are  at writing secure code. If you import vulnerable dependencies, then there are containers. These  often consist of hundreds of Linux packages inherited from public sources, again,  code that you didn't actually write yourself and you can't forget about infrastructures code.  This opens up a bunch of new attack vectors for malicious actors. misconfiguration is the number  one cloud vulnerability. Dev SEC ops properly implemented should cover all of these areas. So  it should be becoming obvious. But let's talk more about why def SEC ops practices are important.  As companies get larger, there's often more software cloud technologies and  DevOps methodologies. More software means more of the organization's risk becomes digital,  making it increasingly challenging to secure digital assets. Cloud technologies means that  many of the IT and infrastructure risks are moved to the cloud. This raises the importance of  permission and access management, since everything can be accessed from anywhere.  As you've seen dev SEC ops bring security into DevOps, enabling development teams to secure  what they build at their pace, while also creating greater collaboration  between development and security practitioners. Security Teams offer expertise and tooling to  increase developer autonomy while still providing a level of oversight. So here are six benefits  of the dev SEC ops model. Compared to the traditional DevOps model. faster delivery,  the speed of software delivery is improved when security is integrated in the pipeline.  Bugs are identified and fixed before deployment, allowing developers to focus on shipping features  improve security posture. Security is a feature from the design phase onwards, a shared  responsibility model ensures security is tightly integrated from building deploying to securing  production workloads, reduce costs, identifying vulnerabilities and bugs before deploying  results, and an exponential reduction in risk and operational costs, enhancing the value of DevOps.  improving overall security posture as a culture of shared responsibility is created  by the integration of security practices into DevOps. Improving security, integration and pace,  cost and time of secure software delivery is reduced through eliminating the need to retrofit  security controls, post development, enabling greater overall business success, greater trust  in the security of develop software, and embracing new technologies enables enhanced revenue growth,  and expanded business offerings. It's about to get practical, I'm going to show you how to exploit  some common web app vulnerabilities. And I'm going to show you how to use dev SEC ops tools  to make sure your software is secure. We're going to learn some hacking techniques, as well as learn  how to prevent hacking. By using this goofy app. This was developed by sneek. And it's  a vulnerable demo app, it was created with some common vulnerabilities. So we can learn how to  hack those vulnerabilities. And also even better how to fix those vulnerabilities.  So the whole goal is to make sure the apps that you develop do not have vulnerabilities. But we  can also use it to figure out how to check for check vulnerabilities and other programs and apps.  So let's download this we're going to I'm going to copy this. Now I've got my terminal open.  And I'm just going to clone that project. So git clone, and then I'll paste in the link here.  So after you clone it, there's two ways to get this running. You can run Mongo on your local  machine like this, and then we already cloned it, then you can do NPM install and npm start.  There is actually a simpler way to do it, I think, which is to use Docker Compose, you can use either  method, I'm going to use Docker Compose. So to install Docker compose you can follow the  instructions on this website for whatever your operating system is. I'm gonna install on Mac.  Okay, I'm just gonna copy this or you can just remember this Docker compose  up build. Now you can see I'm in the directory, no GS goof and then we'll do Docker compose up build  Okay, this looks like is running. Let's check it on our web browser. I'm going to open up a new tab  and it loads the goof To Do app. And this is just a simple app. It's not really fulfilling  featured or anything, but it has enough as part of it, that we can test some hacking  techniques. And then we'll also be able to see how to fix those and how to secure our app.  So it can't be hacked. So let's just do some tests. To do let's see, buy milk. Finish tutorial.  Eat ice cream. Okay, well, this To Do app looks pretty good. Before we start hacking it, I'm going  to actually open up the code for the app. So we can look at the code. And we'll be going kind of  going back and forth between the actual code used to develop this app, and the way that we can hack  the app. And then we'll go back to the code and see how we can fix the things that are vulnerable.  Okay, so just open up the the no GS Gouf directory in any code editor. I'm using VS code.  And if we go into views, we can see that it's using the EGS extension.  And then here's the view we're on right now,  where you can create a new item in it's going to return each of the two dues here.  But you can see there are a few other views here we have an admin view, account. And then we have  index layout. So we're going to start our hacking by trying to get into this admin page. So if I go  here and do slash login, we want to figure out how we can log in to this admin access.  So a hacker will possibly do some sort of social engineering, or some or maybe just searching on  websites to find out what the admin username is it could be admin, or in this case, it's admin,  at sneak that IO, because this was developed by snake.io. So there's a few ways we could try to  figure out how to get into this page. But using a different tool than just a web browser is going to  be helpful, we could use a command line and use curl. Or we can do it in a more kind of visual  way. And use something called Burp suite. Burp suite is is a tool that a lot of penetration  testers and hackers use in Burp suite has a lot of features that make it easy to test different  things about websites and change things and really try to hack different parts of websites.  So I'm just going to type in download Burp suite into Google. And I'm going  to download the free community edition for my operating system.  Okay, just open up Burp suite for the first time. And I'm just gonna click  Next to create a temporary project and start burp.  And what we want to do is be able to intercept the HTTP requests that we're sending to the website  and change them, we want to modify the requests that are going to the web sites.  And we can do that by going to the target, you know, going to the proxy tab, intercept.  And now we have intercept is on. But to actually intercept the things,  we need to intercept the things on a web browser. It's kind of complicated to set it up to use  our built in web browsers like Google Chrome or Firefox. But Burp suite has an embedded browser,  that makes it a lot simpler. So we're going to open up this embedded browser.  And here's the Burp suite embedded browser. And I'm going to make sure intercept is off  for now. When it's on, you're going to have to click forward in between each request.  But we will do that later, but not quite yet. Now I'm just going to get the URL localhost 3001.  And then I'll paste it into the browser. Okay, great. We can see the website right in the Burp  suite browser. Now I'm going to go over to slash login. Okay, so we're now there at this  page. I'm going to turn intercept on and I'll move this over to the side here.  And so we'll use the username we already know which is admin at sneak  that IO. And then I'll just put anything for the password and then click Submit. If  we go over here it has actually even though I click Submit, it hasn't tried to submit it yet.  It it's going to caught this request. It intercepted the request right here.  So So as you can see it has the username. It also has the password I was trying to  type wrong, but I spelled it wrong. And we can now change what sent to the backend,  we can change what values are sent to the back end. So at this point,  if I just clicked forward, it's just going to send that those values.  Now, I already said that this wasn't a fully complete app. So when you log in incorrect,  it doesn't currently have a page that shows you when you log in and correct. It just says this.  So we know we've logged in incorrectly. If we've logged if we had logged in to admin correctly,  it would actually go to the admin page. But we're going to go back to the login page, and  turn intercept off. And then I'm going to type the in one more time. And I'm just going to type  in a password one more time, I'm going to turn intercept on, we're going to attempt a no SQL  injection. Now what a hacker would do would be just to try a bunch of different methods.  And eventually they're going to try a no SQL injection. So this is the method I'm going  to show you right now. So if we go over here, to our request, right now, the password is a string,  we're all passing in strings. But what if the password wasn't a string? What if it was an  object? Could an object actually be harmful or considered an issue? Well, let's try. If we're  going to be sitting in a JSON object, we're going to actually have to change this request a bit.  We're going instead of accepting text, there's not going to be a JSON object. So we're  going to change it to application slash JSON star slash star q equals 0.5. That's how we're  going to accept JSON objects. And then we're also going to change the content type. So where's that,  so this is going to become application slash JSON. Now, we can just pass in instead of this text down  here, we're going to pass in an object, and the object is going to have the username and password.  Username, it's going to be the same thing as before. But this time, we have to put  in strings because this is an object. So this is going to be admin at sneak that IO.  And then we'll have the password.  Remember, we're doing a no SQL injection, we're not going to pass the string here,  this is going to be an object. And the object is going to go like this. Let me just type it all in  really quick. This here, in this no SQL injection, it's passed in as is to the password property,  and it has a specific meaning to MongoDB. It uses this dollar sign GT operation,  which stands for greater than, so we in essence, tell MongoDB to match that username with any  record that has a password that is greater than this empty string, which is bound to hit  a record. So this is a no SQL injection vector. So let's try this. I'm going to forward this on.  And though afford it one more time. And now you can see,  we are now in the admin admin access granted, we're now logged in as admin. We're going to do  a few more of these. And then we're going to go into the code and see how to fix some of these  problems. So there's another URL on this page, once you're logged in, called account details.  So since we're logged in, we can get to the Account Details page.  Oh, let me turn on intercept or turn off intercept, so it goes to a quicker so we can enter  these account details. I'm just about to show you a code injection. This is rendered as a handlebars  view. Let's see if you if we go back over to this code. So this is a this is created in handlebars.  And the same view is used for both the get request which shows the count details,  as well as the form itself for post request, which updates the account details.  So it's, it's basically server side rendering. So the way the forum works is that it receives  the profile information, and then passes it as is to the template. This means however,  that the attacker is able to control a variable that flows directly from the request into the  view template library. Now a hacker isn't going to know all this, but they're going to try a bunch  of things to figure out if it just happens to maybe have one of these vulnerabilities.  So if you just do like normal, we can just type in everything.  And it's going to save the account details to the database. So to do this code injection, instead of  using Burp suite, I'm going to show you how to do with curl. Okay, I'm just going to paste them this  line here, this is going to use curl to login to the website using the administrator account,  we have the administrator. And now we actually are using the real password super secret password.  You could also use some of these other methods, other methods we showed before to try to hack in  without knowing the password. But in this case, I'm showing you a different vulnerability. So  we're just going to use the real password, just don't tell anybody what it is. And we are going  to save this cookie to see that txt, that way that we can do another curl command and still be  logged in with this administrator cookie. So let me just hit enter here. Okay, so we're logged in  to the administrator, it says we're redirecting to slash admin, because I logged in correctly.  Now I'm just going to paste in another curl command. So you can see the end of this curl  command is the URL we're going to which is the Account Details page. This is the one  we were just looking at on the web browser, we are doing a post request, we're not trying to  get the file, we're not trying to get the page, we're trying to send data to the page.  And we are going to log in using the see that txt file this was stored on the computer when we  logged in with the administrator here. So we're still the administrator when we do this action.  And if you see here, this is the information that's being sent over. So you can see we have  fields for every field on that page, we have email, first name, last name, country phone.  So those are all these details on here. But you can see there's one final thing,  there's layout. If we pass layout, when we pass it to a template language like handlebars,  this could lead to a local file inclusion or path traversal vulnerability. So let me show you what  happens. You can see what you lay out. And then we have with path in the file path to get to a file  on the server. So we're going to see if we can actually get information from the server. And yes,  it's it's returning the package that JSON file. So you could use the same concept to try  to return the text of any file on the server. This could include passwords, hash passwords,  or any sort of any sort of data, you may be able to figure out by using this this hack.  Now let's look at another vulnerability. We're gonna see this one first right in the code,  and then we'll go and try it out in the browser. So I'm on the admin view. And if we go down,  we can see that it introduces a redirect page query path, the redirect page is rendered as  raw HTML and not properly escaped. Because it uses this dash instead of it should be an  equal sign. So this introduces a cross site scripting vulnerability.  Let me show you how you would take advantage of this vulnerability. Okay, so I'm going to go to  the normal login page. And now I'm going to add a query parameter. It's going to be redirect page.  But instead of adding a normal URL or page that we're going to, I'm going to add some JavaScript.  And it works, this alert came up. So we've been able to successfully inject JavaScript  code into this page. Okay, I'm going to show off one more vulnerability, and then we'll  start looking into how we can find and fix these vulnerabilities. So I'm at the main to do here.  And I'm just going to try some different things like let's see if we can add markdown. Hello.  Now that I see like in Markdown, maybe there's something else I can do. Now,  there's different libraries that can be used to add markdown like this. In this case, we're using  the marked library. And a hacker may know that certain libraries have certain vulnerabilities.  But even if they don't know about certain vulnerabilities, they may just try a bunch  of different things and see what they can figure out. So let's see if we can make a link appear.  Okay, we can make it show a link right here. In this case, I supposed to put http colon slash  last, but you can see it still works here. And now let's see if we can get it to run JavaScript.  Well, that's good, it's not vulnerable to just typing in JavaScript in there.  There may be something else we could try though, let's see if we can make another link.  And just put in some JavaScript right in here.  Okay, that's gonna work, which is good. But one thing that is common is to represent that in a  different way. So So I got the same one we just typed in. But I'm going to make  a few slight changes, we can actually replace this colon with the HTML entity for a colon.  So it's going to be like this. And then this final parentheses we can represent with HTML entity.  So let's test this. Well, it didn't run the JavaScript, but you can see something different  happened, it doesn't look the same as this. So we now know that the sanitation is happening  in a different way, when we put these other symbols here, and like I said, this is using the  open source library markdown, so anybody can just run, just read through that code. And they may be  able to figure out vulnerabilities just by reading through the code. So the reason why this isn't  working is because the people who created marked are actually sanitizing this out and looking for  something like this and removing it. However, we can actually take advantage of something that a  browser does, a browser actually tries to fix your JavaScript code. So if it sees something wrong,  it actually tries to figure out, figure out what you meant. So we can type something like this,  like the actual word, this here. And the browser is just going to try to try to try to figure out  what this means. But the interesting thing is the mark library, when it's trying to sanitize things,  it's not trying, it's not looking for this set of characters, it's only looking for just  this set of characters. So if it seeds, this full set of characters, it's not going to sanitize,  it's not going to replace it with anything. But the browser will still build try to figure out  what this means. So let's just put this in here. And now we have a link, if I click the link,  now it's running the JavaScript code. So we're able to send JavaScript code that can run right  in someone's browser. And in this To Do app, this could be something that other people to view the  to do's and you could actually make someone run JavaScript code. So this is a cross site scripting  vulnerability, right in our application, just because of this library that we're using. So let's  see if we can go about finding and fixing some of these vulnerabilities. Let's go back into our code  editor. There's a program called sneak code, which is a static application security testing  software, or SAST. And there are plugins for a lot of different IDE s, there's a VS code  plugin that we're going to use right now. So let's install this plug in, this is going to help us  find our security vulnerabilities and fix their security vulnerabilities.  So I'm just going to search for sneak.  And I'll just install this once sneak vulnerability scanner with the 12,000 here.  Okay, now that this is installed, we can see a new icon here, this sneak icon  is going to work better, we're going to actually connect it here.  Okay, so I got my account created, and I'm logged in, and I can authenticate.  So we're already searching the open source vulnerabilities up here. And then down here,  code scan and quality, we're going to have to enable it. So click this link, and then enable  and then save changes.  Okay, let me go back over here. And now it's just it's analyzing the code from this project.  This analysis runs automatically whenever you open a folder or workplace.  And then also when you save, it's going to scan the code automatically.  So we can start clicking into these. So these are our open source dependencies, things that are  different packages we have. And then down here is the vulnerabilities and our actual custom code.  So I click one of these issues here. And you can see it's going to go right here is  going to underline it is going to tell you what the error is. And then it's going to give you  some more information about it. So actually, let's let's look at this issue in particular  So this is for the login unsanitized input from the HTTP request body flows and defined where  it is using an SQL query. This may result in an SQL injection vulnerability. And this was  one of the vulnerabilities that we were able to take advantage of. So we now know where the  vulnerability is. And it's going to over here, give us some information about how to fix it.  So it's showing here it's showing some it says this vulnerability was fixed by 255. Projects,  here are three example fixes. This is similar code from other projects,  showing what people did to fix this mistake. So if we go,  we can actually go through these to get different examples of what people did. What  so we also can get more information about the vulnerability by clicking here more info.  And we can see it's the the SQL injection vulnerability. So here, what if the login handler,  it's actually going to take whatever password the user entered, and then it's going to  this user, that file is going to pass that everything directly to the back end database for  validation. And it's going to pass the exact text that the user entered, or in our case, remember,  this is where we pass an object, we were able to pass an object with the owner with the greater  than, and this allowed us to log into the administrator account without knowing the password  just by passing in an object. And because this is just passing in, whatever the user types in into  the database, that's how we were able to do the SQL injection. It's all because MongoDB uses JSON  to query the database. So it's the SQL injection where in this case, actually a no SQL injection.  So the very absolute simplest way to solve this problem would just be to cast this to a string,  the password. So if someone puts in an object, it will actually when it gets cast to a string,  it will look like this. If you cast an object to a string, it just looks like Object.  Object, which would not, which would not be the correct password. There are this is like a  simplest way. But there's much better ways such as there's different libraries that can help you. And  there's different ways that you can, can make sure this is not a problem. But this would just be like  the simplest way to make sure someone cannot pass an object in for the password. So we'll just  ignore that even though there are better ways to fix that. We're going to ignore that because we're  going to use this, this way to fix this problem. Not only can you see all your code security issues  by just clicking here, if we actually go to our file explorer, any file that's red is actually  going to be a file that sneak is found to have security issues. So we can close that. And we  can see that it's finding security issues in this file. And these are all things if I click on here  have you problem, it's going to show right in here, avoid hard coding values  that are meant to be secret, found a hard coding hard coded string using the Express  session. So we're actually the secret is right in here. You don't want to put a secret right  in here, you want to use an environment variable to go here, we can click on quick  fix. And then the So the suggestion. So here are some examples of how people fixed it.  This person didn't they change the secret to just a variable it hasn't been defined  yet. Really, you want to use a, like I said, an environment variable to fix a problem like this.  So we can actually go through each of these issues in the code security here.  And then change them one at a time. So here's one we just talked about.  But the hard coding and we have another the secret token is right in here.  So that's how sneak is going to help us fix our issues. So let's see what this one is.  Well disable X powered by header for your Express app, because it exposes information about the use  framework to potential attackers, and then it tells you what to use. Consider using helmet  middleware. Some of the vulnerabilities that we were able to exploit wasn't even in the code  that was written for this app. It was in the open source dependencies. So let's go to this  open source security section. And one thing I mentioned is that these are covered coded.  So if it's in red, that means it's basically one of the worst possible things that could happen,  you know, and then orange is bad, but not quite as bad. And the yellow is the mildest. Or I  guess gray would be the mildest. So anything that's red, you definitely want to fix, one of  the issues that we exploited was in handlebars. So if we fix the hand, if we click handlebars,  it's showing that we're using handlebars four point 0.14. And suggesting to fix this issue,  we can upgrade to four point 1.0. And then it's going to go on to show us exactly what the problem  that's happened that happened. So the problem related to prototype pollution,  and then the unsafe object, recursive merge. So once I know about this handler thing,  there's a plenty of things I can do to just kind of upgrade handlebars.  So one thing is that I can go right into my package json. And you see we still have it here.  HBS. Now I can actually just change this to four. Point  1.0. Like is recommended. And if I just close some of these here,  you can see that it's showing right in our package that JSON file, it's showing all  of these different vulnerabilities. And if I click here, show the most severe vulnerability.  Now it's saying, for jQuery, I should upgrade to 3.5 point zero. So I can just type in  3.5 Point Zero to upgrade that. And then we can go through every single one of these.  And just try to find just try to find all what what's vulnerable.  But something we may not want to upgrade. But some things we may want to upgrade just depending on  the severity of the vulnerability and how it's going to impact your app. Another way you can  go about doing this is using the command line. So I'll just open up a new terminal down here.  And I don't have sneek installed quite yet. You just do NPM install. Sneak.  Yeah, latest. So this idea if you have NPM.  And now I can just run sneak test. Oh yeah, first I have to authenticate sneak sneak off.  Okay, I've authenticate. So before we authenticated for  VS code. Now we're authenticating for the command line. And then sneak test.  And this is going to find all this these things and it's going to so  you can find it right in VS code. Or we can just use the command line  and see all the red things are the high severity. So this is kind of nice to find out all the high  severity issues. And these are basically all dependencies. And it's showing what we need to go  through. So you'd want to go through and especially all the high severity, things  you want to go through and you want to upgrade to the version that's not going to have these issues.  And then there's also sneek code test. So before I was showing all the things that are dependencies,  and now it's showing all the problems in our actual custom code is part of this project. So  that's just the saying that so the first command would be stuff from this open source security  panel up here. And then the second command we'd run was from this code security panel here.  So and we can see that there's three really important issues that we should try to make  sure we fix. Another cool way to kind of find vulnerabilities is just through the  web interface. So let's go to the snake website. I'm going to go to my dashboard.  And it's showing that we can run sneak monitor here, right in our here. So if I do sneak monitor  and it's showing a website we can go to I'm going to copy that, copy that.  Okay, now we're in here, we can actually see all these same issues, but now it's actually easier  to get more information. So this is one of the our dependencies we have and we can show more detail.  It's going to show how we fix that. And then we can also actually get more information like CW 29  This is a path traversal issue which is one of the things we exploited, if you can remember,  if you remember, so we could actually fix that issue just by upgrading to 4.11 instead of 4.7.  And then if we want, we can also get more information about the library.  And it goes right to the NPM website for the library.  So we go down here, and you can see all the things that are definitely need to get fixed.  So the high priority critical priority, and so marked, oh, yeah, I saw Mark yet. So this is  another this is one that we exploited. If we just upgrade to mark zero, point 3.18, then the one  where we were typing in to do items, and we were able to get JavaScript into there, if we upgrade  this, and that won't be a problem. We can also go here, where it's suggesting very specific fixes.  So def is saying, definitely upgrade these things. And it's going to fix all these different issues.  And then if we go here, this is just going to show all of our dependencies. And you can see  if we click into here, body parser is a dependency and inside body parser. There's another dependency  this Qs here. And if we click into Qs, well, this has a high severity issue. So that's something we  definitely want to know about. So this is pretty great. It's a way to figure out all the security  issues and all the dependencies on your, on your on your app applications. There's no way to  be able to know all these on your own, you pretty much need a tool like this, to make sure your your  application isn't using these these dependencies that have different vulnerabilities like this.  Now, this is outside the scope of this course. But there's also a way to set up on sneak. So  anytime you push your code to repository, it's automatically going to run all these tests. And  before you even merge a pull request, it will show all the security issues that could be in  the pull requests that you're trying to do. And then you can be required to fix them before you  actually merge that pull request. But now we're going to talk about containers. Eric, Smalling is  going to teach the next part of this course about securing containers. He has a ton of experience in  this area and is great at explaining everything. He'll also give another quick overview of DEV  SEC ops. Everybody, Eric here I am here to talk to you about containers and security and all the  things that we have to look at now that we're containerizing our applications a little bit  about myself, so you know where I'm coming from. I am a software developer for the past 30 years,  give or take. I am a senior developer advocate now at sneek, a software's security scanning company.  And the last decade or so my career really been spent more around the CI CD build automation  tests kind of a world and during that I discovered Docker Docker, I've been using Docker since about  2013. Back in the early early days before we had any orchestrators or even composed or anything.  Today I am Docker captain and I'm certified in all three of the Kubernetes certifications  means anything to you. And you can get a hold of me at that Twitter address or LinkedIn or whatever  all the socials. So what are we going to talk about today? First of all, we're going to get into  how does security play with DevOps? Is it is it a vs kind of a thing? Or do they work together?  Next, we'll get into what are the challenges we face specifically as developers making,  putting our apps in containers and I'm going to get into a demonstration to show you what  can happen if you don't look out for these kinds of problems. And we'll get into this you know,  how can you be proactive to avoid the situations you'll see in a demonstration. And finally,  we'll wrap it all up at the end. So DevOps is interesting term, it I mean,  literally is just a a melding of development and operations and everything else in between,  to cooperate to work together and to automate things together until to work well together.  Unfortunately, it's turned into kind of a buzzword in our field and it's kind of gone the way agile  did for a while there were consultants will sell you agile, they'll also sell you DevOps,  or you'll have a DevOps team or DevOps tools. But really, it's more about the concept of making sure  we're all working together towards fast, repeatable builds and making sure that everything  is done well together as a team. And often DevOps is visualized with our software delivery lifecycle  pipelines. The pipeline was kind of popular Back when the continuous delivery book was written,  and this is a simplistic pipeline, showing here, yours may look more complicated than that. But  generally you look at ideation to production from left to right. And it's like an assembly  line. In this diagram, I put our company's old patched logo on a couple of blocks where we  historically have seen security applied to our pipelines in production, first of all,  and that's kind of table stakes. We've always had some kind of security being applied to production,  whether it be firewalling, or role based access control,  tripwire, tripwires, they all the all the things that you think of when you think of hardening  for production. We've had security around that. Well, we also started as the security intern.  And when we started doing pipelines and started doing continuous delivery, we saw it applied as a  stage as security audits would happen. And usually they'd be a late stage in that pipeline. Because  oftentimes, it was a manual process. And it was like a gating kind of a thing where some team  would go in and look at your application and determine whether or not you have  increased your vulnerabilities or in some in some way made things less secure. And they would  pull the cord stop the line, and you'd have to go in and then figure out what it was. And usually  this was after functional testing. So it was like a late bug in the now you got to put your mind  back into the state of what was I doing when we worked on that code to move forward since then.  Or it could have been automated, there were automated tools that been around for a while,  but usually they were so slow, or their licensing was so onerous that you could only run a few  copies of it, or you could only run it on certain hardware that your CI pipeline would use.  And so again, these would be late stage things that cause you to have to stop  and figure out what happened and hopefully get fixed and quick for the release.  Or unfortunately, often it would be put on the backlog for a new release, you know,  coming down the line, and you get to production with known vulnerabilities, which is never good.  As containers started to come in, and we modernized the way we did security against those  you saw scanning coming in at the registry level. So you'd push an image to a image registry. And  it might have a built in scanning functionality, and would grind away for however long it took. And  it would come back often with just a big list of here's all the CVS have fun with that. Hopefully,  you also had similar things that were able to be done similar kind of scanning in your CI  as your repo change. So as code is merged into the mainline, or whatever branching strategy, you use,  something we kick off, do your builds, and one of the automated tests that would happen would be  that security scan, so you'd build the image might be able to scan it, or send it off to something or  scan it, you can before it gets to the registry, that's kind of cool, because now you can break the  build, without having to rely on some kind of callback from the registry to you know,  break the pipeline after it's already been going. So that same kind of tool, if it's fast enough,  could actually be applied, pre merge. So if you're doing Git, for instance,  you have pull requests, often where you have a short live branch and you come back into your  main or master or whatever you're using. And you can have one of the automated tests that  happens as part of the validation of that pull request, be a security scan, again, now that  tool needs to be fast enough to do that. Because otherwise, people are gonna want to wait a day,  for a pull request to get reviewed, they want to get it in and be iterative and get it done. But  the Holy Grail of this is really to get that kind of scanning capability to be so fast and so useful  that a developer will use it day in and day out on their workstation. He wanted not only to be fast,  but you want the output of it to be actionable, so that the developer can be proactive,  and not having security and and that team be an adversarial relationship,  you want to be able to say, hey, issues have come up, here's the information I have. And then I can  act on this information. Or I can at least go to the security folks and talk to them intelligently  about what I'm seeing and get, you know, cooperation there instead of an adversarial role.  And this is where we get the term dev SEC ops. Now dev SEC ops, in my opinion really isn't a thing.  It is more of a reminder that between Dev and Ops, security needs to be part of that thing.  Security needs to be invited to our little DevOps party. Right? They need to be just  integrated, if you will. Now, that talked about container, you know that they're  challenging. What is it this challenging about containers? Well, for developers,  you we are increasing our scope of responsibility, sometimes greatly. This is an area where,  historically, you know, we've dealt with securing our code and maybe the libraries we pull in.  But containers are writing operating system level things, things like, what base image  are you using? What is it bringing along? What distribution? Is that base image built? On? What  packages? Are you installing on top of it? How are you installing your application? What file  system permissions? Are you using? What user ID are you using all of that kind of stuff,  which we've known about as developers, but we might not have really dealt with it much  because the teams that deployed our software or or built the systems that we deployed to  dealt with it. And so we have a bit of a lack of expertise around how do you harden a Linux,  Ubuntu versus a CentOS? filesystem. Distribution. These are things that other people did for us  before. Now, hopefully, we're working with those teams as we build our Docker files,  and Kubernetes, Yamo and everything else, so that we're crafting these files correctly.  But I need to know as a developer, if I need to tweak that file, but I'm doing it right.  And I don't want to have to open a ticket every time I want to change a Docker file  to my ops team, to say, hey, let's work together to fix this. I mean, if it's something  complicated, sure, but if I'm just changing, you know, what package I need for something,  there's got to be a better way. And on top of all of this, any security practice, you  add to a developer's day to day can't impact their velocity business has bought into and given us the  ability to do these iterative CD pipelines. All is because it's all about velocity getting from  ideation to market in front of the customer, as fast as you can, we're not gonna we don't want to  introduce something that's gonna slow that down. In fact, they'd probably really like us to faster  if we can. Okay, so let's go back to talking about what developers know about containers.  We know our applications, you know, when we write them that we have to pay attention to  the the code itself, the code has to be clean, you can't be introducing in SQL injection issues,  or whatever, we got to write secure code. And we know also that our libraries need to be cleaned as  well. But what's new is these Docker files, like I talked about a, we're dealing with the operating  system issues now. And for instance, looking at this little screenshot, I know what Python is,  because maybe I'm a Python programmer. And I know that version three of Python is what I'm on. But  do I know what minor version? This is? Do I know what Linux distribution is? On top of  do I need to know? What about the packages I'm installing? And am I doing it correctly? Or am  I installing them in a way that's putting things on the file system that doesn't need to be there?  All sorts of questions like that come up. And then of course, we've got infrastructure as code files,  like TerraForm, or cloud formation. And the big granddaddy of them all would be Kubernetes. And  this is, you know, if you're in an orchestrated container land, you're dealing with Kubernetes,  most likely nowadays. And this is an API that changes every three, three times a year  and has a lot of knobs and switches on it. And it's very easy to make a mistake and  cause a problem that you didn't even know you're making this mistake. It's enough to get your app  running on these various technologies to make you hyperventilate, but hardening the app for security  on top of that, well, that's that's that's asking even more. Okay, so that's enough talking  slides and hypotheticals, let's actually look at a demonstration of this in action.  So let me stop the scene. Let's say we're at a company, we have a Java  Enterprise application that we've had running for years and years. It's our big moneymaker.  But it's in a kind of maintenance phase. We're not we're not doing active development, or anything,  just bug fixes here and there. And so a couple years ago, when it was time to,  you know, when containers came on the scene, and we got access to Kubernetes servers, we decided,  hey, we want to do that. We want to take advantage of containers, and the standardized packaging and  deployment mechanisms would get with with the orchestrator. So we lifted and shifted our Java  Tomcat application into a container. We've been running it that way ever since. So if you look  at this Docker file, this is a multistage Docker file, which means that there are multiple  different from lines. And for each one of those, that's a stage. So here we have two of them. We  have the initial one, which builds our application that's based on the official Maven image from  Docker and the Maven folks. And then we have a second one that is the official tomcat and from  Apache Tomcat. And anyone who's done Tomcat for a while, then this is November of 2021 right now,  and this is still eight 521. That's a pretty old version. But the attitude for a lot of folks is if  it ain't broke, don't fix it. This is the version we were at in production when we containerized and  we're sticking to it because we didn't works and we're not making changes that need anything new.  We'll look at, we'll come back to that decision in a second. The rest of the file is pretty basic.  It's just set up a couple of configuration files, and then copy artifacts from the build  stage into the main stage of that final image we produce is Tomcat plus our application and  a couple configs. So let's take a look at this running. This is the top level sample servlet,  that you see right here. And you can see I pull this up so that you can see that eight 521 is  definitely the version we're running. Just to make sure our app is running, I'll pull that  up. And there it is, there's our beautiful To Do List makes billions of dollars for us or so.  But honestly, the AR app is not what I want to talk about today. There may be problems in it. But  that's not the discussion. Let me switch hats now and put on my black hat hacker hat. Now I may be  looking for vulnerable servers to exploit as a hacker. And in doing that, I'll do my studies. And  I'll see you know, I'm actually looking at tomcats release notes for vulnerabilities they've fixed.  And you can see there's a bunch of fixes they've done. And throughout here, we're seeing all sorts  of things. There's denial of service attacks, there's, oh, gosh, incorrectly documented CGI,  all sorts of stuff. But the one that's interesting to me are these remote code execution ones.  This means that if I'm able to exploit something that has one of these vulnerabilities in it,  I might be able to run my own code and somebody else's server pretty bad. This one we're looking  at right now is fixed in eight 523. That tells me that anyone on eight pipe 22 or older,  might be vulnerable. And as you saw that, that company is running eight by 21.  So I could dig into this by go into the vulnerability databases sneaks vulnerability  database, and very similar mitre, we add a few extra pieces of information to it.  But what I could dig into this, and I could find out what is it about Tomcat util that has issues  and what what is it there are the issues and craft something. But I'm in this first feed,  and I just want to find something quick. And I see that there's a couple of exploit DB links,  I'm going to click on one. And what this is his code, this happens to be Python code that  I'm not a huge Python coder. But I could read this and I can tell Oh, this has got  two methods. It's a proof of concept script that will check for and exploit against that CVE to  prove whether or not you have it or whether you're patched. So I'm going to copy that. And I have a  couple of me set this up to do this before the call. So I'm going to run this shell script,  this is going to basically it's going to take that Python script, it's going to wrap it in a  container and alias it for me. So it's easy to run for this demonstration, I'm out. And that's done.  And I'm gonna run the check side of that. And you can imagine this would be automated. If I  was really going after a bunch of server, I might have a ton of IPs and ports that I'm ping, ping,  ping, ping, kind of like the old WarGames war dial are going through looking for vulnerable  and I found one that's my local IP, I'm just running this locally on a Docker Kubernetes  Docker desktop Kubernetes. This works, any convenience I want to run it on or any Docker  executable. This is saying it's vulnerable. And it's stuck a POC JSP onto the server.  So let's jump back over here. And I'm going to add POC and JSP. And there's a bunch of A's  there. I guarantee that was not there a couple minutes ago when I showed you the site earlier,  what I've done, and now the A's that's not very nefarious really, but the ability to take a JSP  and push it to somebody else's server and have it actually be there.  That's pretty bad. Let's take a look at the other side of the script, I'm gonna run the phone side,  which will inject a different JSP up there. Pull that one up, I'm gonna pull the form.  I just ran ENB on a shell basically, but in the environments that the Tomcat servers running in,  and I can look at this, shrink it a little bit here. And I can see there's my Java home,  there's a bunch of information and oh, look at that there's Kubernetes port. That means most  likely, I am running in a Kubernetes server, which means most likely I'm on a container D or Docker  container. And that's interesting. That's the API server from the point of view of the pod that I'm  in. So if I wanted to maybe I could start tickling the control plane of the Kubernetes cluster on it  and seeing if there's anything available to me. In order to do that I need cube CTL  or be easier if I increase your netus but it'd be easier and it doesn't look like I have that  I have curl just to curl help. I do so I've got curl at my disposal.  Now I'm not going to go through in this demonstration hacking a Kubernetes cluster but I  will show you a couple other things. Oh, I'm root. So that's nice. That means I can do things like  get in the field Ella ltr et Cie password. And oops, not LS ltr.  That's not interesting. This is more interesting Etsy password. Now I'm going to container.  So these users aren't that interesting to me, but it is I can get out of I can see him,  what can I do? What else can I do? Can I do this, touch Etsy foo. That works.  The bottom and sure enough, I was able to create a file in the etc, top level directory on this  container. That's because I'm root. And I have right access everywhere in this container.  That means I could go into the other web app, the to do list and I can modify, I can also go change  out things in the JVM itself, I have curl. And if I have external network access, I can bring  down my own scripts, I can bring my own my own JVM that has maybe other code baked into it.  But honestly, most most of the time, what's going to happen now, if I'm root on a white double file  system container, I'm going to sit down and I have curl and or some other tool, I'm going to download  a script to start crypto mining or something and use all the CPU I can on this node. So  that's interesting. And hopefully you're in a real server, the production, intrusion detection  or other alerts are going off now, because I'm doing things that shouldn't be happening. But  we don't really want to just have a reactionary posture to this, how could I, as a developer,  have proactively avoided this situation, or dealt with even unknown vulnerabilities that might be  out there. Let's take a look at that. So I'm going to go back over here to my Shell kill out of this.  Now, I've already built this image locally, let's imagine I'm the developer working on  this application at some point, and I'm building locally to check a bug fix I did or whatever.  And I built my image so that I can run it somewhat similar to the way it would run in production.  And what I can do though, is before or during that process, I can go ahead and run I'm going  to run our scanning tool, there's a lot of different scanning tools out there, I'm going  to run the one that I know the best sneaks into container test. And the image name is Java goof.  Tag, one. And I'm also going to feed a metadata into this command, where I  say file is Docker file that lets it know that this is the Docker file that built that image,  which gives it a little more information about it. So you can kind of correlate what's in the layers  and what the base image is, and all that kind of information. So the tool, depending what scanner  use, the way this one's working, is ripping through all the different layers of the image,  looking at all the packages that are installed looking at the base image, and then it's  going to go start querying the vulnerability database on the internet for the very latest  vulnerability lists and come up with compared to you and letting you know what's in this image,  and what vulnerabilities might be there for the given versions of everything that's  installed. So as this goes, we see that there it goes, querying the vulnerability database.  And there we go. So we can go up here and we could take a look at this list of all the different  things that went wrong or that are could go wrong, such as this. There's lib curl has a bunch of  vulnerabilities in it saying if I were to upgrade lib curl to that version, we could get you know,  get past those. But honestly, the more interesting thing when it deals with dealing with containers,  from my point of view, is down here at the bottom we're saying hey, you're on base image eight 521  of Tomcat, which we know has 66 critical and 88 high vulnerabilities 635 total,  if you simply upgraded to a newer version of Tomcat, and this changes every time I run it  because the vulnerability database is constantly changing. And saying if you went to this version,  you would drop 222 Total vulnerabilities for high eight, or sorry for critical and 18 high.  If you are willing to upgrade to a newer version of Tomcat family into the Tomcat nines, you could  get even less. And then if you were willing to actually go to a whole different JVM, this is  the Amazon corretto JVM, I do believe you could actually eliminate all known vulnerabilities.  So at this point, even as a junior developer who doesn't know squat about Tomcat itself,  and the image, the base image that it's coming from, I have some good information. I know that,  you know, I've got this many vulnerabilities and I can have some quick hit fixes. And I can  go to my lead engineer and make my app set person say hey, here's what I'm seeing. Which of these  makes the most sense to go to and you know, it's putting them ahead of the the architect  Well, you know, we can't really run on Tomcat nine yet because we depend on things and eight, five,  so that's not really an option. And I am not ready to drink the Kool Aid of the new corretto JVM. So  let's at least move to a newer version of Tomcat in the eight, five family. Let's go to this one.  And we'll take a look at what vulnerabilities are there and see if we have mitigating concerns. Or  maybe they're they're not, we're not using that piece of code that's in them.  But I can we can take an educated path towards repairing vulnerabilities and getting past them.  I'm not going to go through the trouble of rebuilding this all in showing you I just  guarantee you that if I rebuilt with that, and tried to do the hack I just did. It won't work  because the vulnerability has been fixed. Let's talk a little bit about what about vulnerabilities  that we don't know about that the the analysts have not found zero days things that people are  holding on to for bug bounties, whatever. How would I deal with that, because the scanners  not going to know that? Well, that brings us to a conversation about defense in depth. This is good  for both known and unknown vulnerabilities. These are practices that make it harder for bad actors  to take advantage of your systems. They're good all the time. So there's three errors,  I'm going to touch on the image, the runtime, and then some Kubernetes specifics. When it comes to  the image number one thing that we recommend is to minimize your footprint. And you saw me doing  that a bit when I used a multistage build prior. That's good, because I'm not including Maven or  the source code of my application in that final image. But we could minimize it even further.  There's no reason my application should have curl available. It doesn't use it doesn't need it.  So we should get rid of that. And the best way to get rid of things like that is to use a smaller  base image first. In the Tomcat world, there are tags that have the word slim on the end. And this  is true of many base images. And these are built on in a way that are going to carve it down to  just what you need to run a Tomcat app. Now, it may not be enough for your application, in which  case, you might have to add a package or two to it, you'll have to manage that. But generally,  if you're just running a J EE application, you're not doing anything fancy. The slim versions are a  good choice. There's even further swimming you can do by going to say the Google Open Source  distro this base images, there's some these have just like the Java one just has a open JDK JVM.  And nothing else that's not needed to run that there's no shell, there's no package manager,  none of that. And that that's really secure, it makes it a little harder to support. If you're not  used to using modern tools, if you're wanting to exec in, that's not going to happen. Because you  don't have a shell to the executive, right. You need to understand how layers are built  and the housekeeping around that. So we couldn't just do a run RM curl, for instance,  to get rid of curl, it would hide it from the containers filesystem. But savvy hacker that  gets access to the root filesystem through other means, whether it be a bind mount or something,  can still find those layers because it's just hidden, it's just marked as deleted, not it's  still in the prior layers. And all of those layers exist in the container runtimes file system.  So just understand how layers work and how they're built and how to optimize  for for your running builds, and build strategies. So multistage is is a strategy for  doing your bills is a good one to use. There's other tools you can use though. And other  practices, you want to make sure your builds are repeatable, so that every time you pull  the same commit or source code you get the same image constructed from and you can do this by  making sure you pick specific tags on images, you can even put a SHA hash into that image  into that front line and you'll get you're guaranteed to get that image that had some other  complexities. The people have blogged about the pros and cons of that, but at least use a specific  image of a version like Tomcat, eight 568, or 71, or seven, whatever, is better than eight five,  because eight five or eight is a moving target that will go to in the latest build every time  you you you pull it. There's things like Docker labels, you could you could use to add metadata  to your image to the image itself that's not used at runtime, but you use it for fact finding about  what's in an image and there are other tools. In the Java world there's jib which is a great  tool for building images that doesn't need a container engine at all to build the image.  There's if you're in the Red Hat environment, you've got builder and the pod man suite of tools  and Khyber. No, I'm not Carter or sorry, and Calico and so many names getting mixed up. Then  we also have the secure supply chain. Now entire conferences are built around this topic nowadays.  But what I want to kind of hit on is the fact that you need to know where your images come from.  Don't just be deploying anything and Eric Smalling building an image on his laptop, that image should  never get to a production server because you have no idea where it came from what was put into it,  you don't have a chain of custody. You don't know where it's been and how who's touched it along the  way. If you We're interested go look into things like store and the work towards software bill of  materials and things like that are quite the topic right now, nowhere near enough time to  talk about that here. When we get to runtime, this is where the real meat of this comes to,  you can make sure your containers don't run as root, you can use a user line on on the command  line or in Kubernetes, there's a setting for that, you can make sure that they're running  as something else. In fact, you can specify in your Docker file, the default user is x,  do that running as root is dangerous, even though you're in a container, as you saw I was UID zero,  so I can modify any file in that container. Also, if somebody heaven forbid, were to bind mount a  host volume into that container, I'm UID. Zero there too. So I can read and write to host files  that are mounted in. Depending on how its privileged containers you should never use  unless you're doing something really low level like Kubernetes monitoring, monitoring software or  writing a CNI, plugin and convenient work in plugin. Generally, this gives you root  access to devices on the host system. And it's just a terrible thing to give it just more most  applications. Linux capabilities, these are features of the Linux kernel system calls  the process can make to do things that are a little bit escalated, but not quite root.  Ping has Netcat add to it in order to create ICMP packets, for instance, things like that.  The early Docker teams, and other Container Engine teams whittled down the good set  a small set of these that most applications should be able to live with. But business applications  and stuff that a lot of people work on day to day, don't need any of them, because you're not  doing network, low level stuff and whatnot. So I would I like to drop all capabilities, and then  just just add back any that I might need. And there are blogs, written all sorts of  information, just Google for it on how to find out what capabilities you need to use tools like  s trace, or falcoda. Dig into it. Next we have the read only root filesystem. This,  when you start a container up the Container Engine basically takes all the layers of the image,  which are read only compiles those up creates the virtual filesystem that the process sees.  But then it adds another rewrite layer on top. And any modifications to the file system are  done in that readwrite. Later, if you change a file that's in the image, it basically does a  copy on right brings it up to the readwrite layer and then makes the modification there  any new files get created there as well. You can however, start this is the default mode, you can  start the container without that readwrite layer, effectively making it a read only filesystem.  This is very, very good. If you can do it, if your application can run in that mode,  do it this is makes it immutable, which is one of the 12 factors which we should all  be aiming for and container land anyway. If you are app needs to write things to  persist to disk temporarily ephemerally like a tomcat server. And to use that example, again,  has the work directory and some logs and things. Use the temp Fs like the Kubernetes Empty Dirt  and mount that path just for that and it will get it'll get thrown away when the container gets  destroyed. Or mount in external volume and make sure you set permissions correctly for security  for that. But don't. If you can at all not run in Read Write mode that can greatly enhance security.  Many of the things you saw me starting to hack at and talk about, if it was read only, it would have  been very hard for me to do. Bitcoin mining, for instance, on a read only file system would require  me to be able to pipe like curl down my script and pipe it it would just be harder to do. And I'd  have no local cache to store things. And it just it's a great tool to make it harder for the hacker  deploying for unknown sources. This kind of calls back to what I said before about secure supply  chain. Just make sure you know where your images come from. Don't be deploying from the internet,  you should probably have your own registry, whether it's a mirror or your own hosted registry.  Use that. And then finally, if you're running on Kubernetes, and many of you probably are,  there are tools that Kubernetes Kubernetes adds that you should take a look at for instance  secrets if you have credentials or other sensitive information, do not build it into your image.  Do not include it in a flat file that you just, you know bind route in. Don't use config maps,  though none of those are secure. Secrets can be secure. They by make sure your cluster admin is  encrypting those secrets at rest because by default, they're not you have to do that if  you're rolling your own Kubernetes clusters. But if they are secrets allow you to have your  own role based access control applied them and it keeps things nice and clean and separate.  Speaking role based access control our back, use it learn it it can can be a little complicated  and hard to understand at first, but learn the ins and outs of it and you'll be happy that you did.  security context. This is the specification for the pods and containers in Kubernetes that  implement a lot of the things I talked about on the prior slide, things like running with a read  only root filesystem. Running as non, you know, changing the user you're running as an enforcing  to not be rude. Things like that are in play, are implemented in Kubernetes, through the security  context, and you should learn about those and use those network policies are critical. Many  developers get all worked up about network policy, they think it's very complicated, it's really not,  it's just all about setting rules about what pods can talk to each other and what can't,  on and on what protocol TCP or UDP and whatnot, Neal ports and all that,  I'm a big fan of the zero trust pattern, which is no pods can talk to any pod know any other pod,  except for what I explicitly put an allow list. So nobody can talk to anybody except  my pods in the front end namespace can talk to the business tier labeled pods on port 8080 TCP,  so that traffic specifically is allowed. But other traffic between front ends are Oh isn't. And you  should look into that. If you do that, make sure you open up egress traffic to your DNS, because  if you don't, then you have no service lookup and that crashes everything. Pretty much. And finally,  all of these things I'm talking about enforced that use a tool like Opa,  gatekeeper, or Hive or no, there's also a pod security policies, which is deprecated,  and going to be replaced by pod security admission. But that's still in beta as of 123.  If you're watching this from pod security, admission is out of beta, you know,  by all means use it, but use any kind of these tools to make sure that deployments that break  the rules, the policies that your organization uses, can't be deployed. And just just do it.  It's it's it simplifies life. And if you apply it across all of your environments, then a developer  won't be surprised by the fact that, you know, in production, I can't deploy as root what,  because I haven't been able to deploy as root on any of our clusters. So it's just a common  rule set that I've used everywhere. So the key takeaways from today's talk, the feedback loop  is critical, just like with CI, you know, came on the scene and became a big buzzword,  letting me know that the build was broken me as fast as possible that feedback, that fast feedback  loop enables continuous integration. Well, it's the same thing with security, finding out that I  added security vulnerabilities or somehow weakened my security posture of my application,  on my own workstation. That's, that's critical. Having that fast feedback is, is,  is great, because you can fix it now. While it's still fresh in my mind of what I've just did.  And it didn't get out and you know, cause impact to other people.  Secondly, the whatever tool you end up using for scanning and whatnot,  make sure that it allows you to be proactive, it gives you good information that allows you to  attack now, rather than just scratch your head and say, Well, I have no idea what this means.  Make sure that it's giving you good, proactive, actionable information. And then finally,  practice defense in depth. There's always going to be new vulnerabilities that nobody knows about.  Except that that one hacker that found it and if you make it harder on the hackers life, they'll  move on to somebody that's an easier talk target. That's just how it is. So I want to thank you for  watching. Secure your containers. Guys. Thanks. We've reached the end. You should now have a  better understanding of DevStack ops and be able to start implementing some new security tools in  your workflow. Check out the description for additional resources, and thanks for watching.\n"