Chris Swan and Olivier Jacques

Chris Swan

Hi, and welcome to our breakout on the DXC online DevOps Dojo. I'm Chris Swan. I'm CTO for delivery at DXC. And so for those of you that know DXC, it's the combination of service companies from HP's Enterprise Services and CSC that came together a little over three years ago now. Some of you might have already seen Olivier present in the past. So Olivier, do you want to talk about what you've done before and kind of what's different about what we're showing this time around?

Olivier Jacques

Sure. Thank you, Chris. Yes, I'm Olivier Jacques. I'm working as a distinguished technologist at DXC and accompanying our customers on their DevOps transformation. So back in 2015 when DXC was not there yet, we were invited to share our journey with HP IT at the time. And then I attended a talk by Ross Clanton from Target at the time, and Iza Mickan, I believe, on their DevOps Dojo. And this really clicked with me as a way to articulate the DevOps transformation. So really something that hit home, I believe. And then we came up with this online DevOps Dojo, which as we needed to scale our DevOps skilling and reskilling within our company and for our customers. We turned or we complemented our DevOps dojo, which was really a face-to-face format and still is, with online trainings to support this transformational scale.

Chris Swan

Yeah. And from my perspective, there's work I'd done in the kind of year before we became DXC, where we developed an infrastructure as code workshop that had reached about 1,000 people by the end of the year. But then I came across the Katacoda platform and realized that we could really kind of make this thing web scale and take it to a much larger audience. We've got over 100,000 people in the company in delivery that kind of need to be reskilling towards DevOps, and that's what it was intended for. And subsequently, what we spent the last few years working on is some more great content that Olivier and some of the team have put together. But also now this open source release, which means that it's available to anybody that wants to access it. And also because it's open source, they can build from the material that's been put together here. So Olivier, do you want to jump in?

Olivier Jacques

Yes. Well, this is really what's new, right? So I think, in the later years, we were again invited to share about our DevOps journey, and we shared about our own version of the DevOps Dojo and what we have done with it. And we came to a realization that open sourcing it and making it available to the rest of us, to the rest of the industry, was probably something that would be best for us to do. So here it is. This is the online DevOps Dojo, which is not meant to be a full DevOps dojo, but covers parts of the training and the training aspects of it, at least. So it's open source. You can see the URL, and we'll post it also in the video. But you go to github.com and you look for the online DevOps Dojo, and you will see this repository. The intent of this DevOps Dojo, if you have not seen the earlier presentations at DevOps Enterprise Summit, is really to guide and to go through a set of modules and a set of trainings and learnings that our people and our customers have to go through to understand the DevOps practices. So we start with a story, and we believe that storytelling is extremely powerful. So we have our team, which is the Petclinic team. The Petclinic team has Charlie, who is a CEO of the Petclinic company. It has its own story, and we will discover later in the training modules that it has dogs as well. Chan is a DevOps coach, change facilitator. We have Paolo, our product owner. We have Adam, who is a sysadmin. We have Dan, the developer, Tina, who is our tester. But the intent of this putting together a story is to bring the knowledge home, right? So often the learnings have to come from where you are and what you know to something new, something different, and that's what the characters are here for. They are here to tell you, "Well, I'm Tina. I'm doing testing, so that's who I am. Let me see what is changing for me and what I need to do differently." And this is a cast of characters that's very much inspired by the IT revolution books like "Phoenix Project" and "Unicorn Project." And also, the Petclinic kind of comes from the app that we're building, the continuous delivery pipelines around, which is the Spring Petclinic sample app, which really kind of gives us a good foundation for doing all kinds of things with an application. Exactly. So the Petclinic is really an interesting, I guess, showcase. Now, talking about the modules that we have released in open source, right? So, the modules that we... And we are going to go through one because it's kind of a different presentation. It's not going to be about slides. We don't have slides. But we are going to do a kind of a live demo of one of the modules just so that you can have a feel of what it is and how it works. And again, you can follow along because this is open source, so you can just go to the site and follow and go through the modules the same time as we are. The modules that are there are, it's just an abstract of a set of modules that we have available and ready and that we use for us. They are coming from practices and patterns that have been described in the "Accelerate" book, because we believe that this study from DORA initially and then which moved, actually is really interesting to connect the patterns with business outcomes, and that's what we want to explain and share. So we have five modules. The first one is the welcome and setup, which I already went through. Leading change, which is really more about the cultural module on how to change and how to lead a DevOps transformation. So indeed, we have both cultural and more technical module. One module about version control, and how to do that. It's not only about version control, it's about version control peer reviews and integrating then the continuous integration together with version control. And the module that we are going to go through today is shifting security left, which is a very interesting module as to explaining what developers can do to embed more security practices as they do their development and deployment activities. So here we are. I just clicked on that. So what you can see is that I did not have to install anything. We are actually totally in the web browser, and this is working outside of the box without any type of additional activity and effort. This welcomes me with a welcome message explaining what the goal of this module is about. So I told you, it's about shifting security left. And I'm going to start the scenario. So the scenario starts with a story, as I said. So, hey. Oh, wow. We are making the team is the pet clinic team. Actually, this pet clinic team is making the frontline news with owners information leaked from the pet clinic. So this is kind of a panic mode in the pet clinic team. We have been hacked, and we have our characters, Hal, who is the hacker there who explains a little bit how he hacked the database with a SQL injection and was able to dump the entire table with all of the pet owners, who obviously are not very happy about it. So I won't go through all of the story and the drama that builds there, but bottom line is that this is a high visibility issue, obviously. And this is something that we need to resolve. Now, continuing on the module, the first thing that we are going to do is set up the environment. So I'm here with my own environment, which is there. It's a window that's available. Now, I'm going to... Yeah, sorry. Wrong typing. I'm going to set up the environment. So the first thing that I'm asked to provide is a personal access token. The whole lab here that is being created in front of our eyes takes advantage of GitHub. So we have forked a copy of the pet clinic project, the pet clinic environment for the team. It's now under my own GitHub profile. And what's happening right now is setting up the environment for the rest of the labs.

Chris Swan

And do people have to stick with the script here, Olivier? Or can they kind of try out things and explore a bit?

Olivier Jacques

Yeah. Well, this is the other thing. We really believe that scripts are good, like videos are good, and you should go to a video on Udemy or other learning platforms. But they don't go far enough, and there is nothing better than actually practicing and trying out yourself. So the script is the guidance. It's there to help you go through the value steps, and I'm going to continue there. But you don't have to follow the scripts. You can navigate around, explore, and this is what you are going to do here. This is your own environment for an hour, and it will disappear after that. And this is basically training as code that has been developed and that you are going through right now.

Chris Swan

And do you want to just talk a little about what's kind of going on behind the scenes here in terms of the Katacoda training environment and how we've put this together?

Olivier Jacques

Yeah, absolutely. So, the Katacoda is essentially what you get is an environment just for you for an hour. And this leverages Docker massively. So what happened at the very beginning when we started this is that for some of you may have recognized is that I pulled a Docker image, which fetches my entire pipeline and Jenkins environment, which is now live. And it also connected my own GitHub repository, which is therefore for me to explore and to connect to, which I'm going to show you in a second. All right. Here it is. So this is my own pet clinic repository. And what happened is that at the time of the setup, the pet clinic GitHub repository was connected to the Jenkins environment, which did not exist five minutes ago, which is now live and that I can connect to. So I'm just going to connect to this environment. All right. So I have a fully up and running Jenkins box, which is not a box, it's a container, which has been connected with my credentials, which I entered at the beginning of this module to my GitHub repository so that we can do continuous integration and other activities.

Chris Swan

So Jenkins is really there kind of providing the pipeline, connecting this sample application to the underlying source control and the things that we're about to interfere with to make some changes for this security problem, right?

Olivier Jacques

Exactly. Jenkins is there. Remember, the purpose of this module is about shifting left on security. So we did not want the student to do yak shaving and spend the time on understanding how to provision Jenkins, add plugins, configure the repository, connect the web hooks, et cetera, which are not important for this learning. They are the purpose of another module, but not this one. Here, we are trying to do everything automatically, and Jenkins is one of the mechanism to implement shifting left on security. It's a very popular mechanisms, but there are other alternatives to Jenkins like GitHub Actions or CircleCI or GitLab CI. There are many other mechanisms to do that. So following. Now this is after the drill. So we just set up the environment. So this is the team dialogue. So a week has passed. Now that the fire drill is over, this is the story that we are going through. We are thinking of the team, which Selma from security is thinking to implement more security as part of shifting the security left. Meaning that shifting the security back in the hands of the developers, so that it becomes a concerns very early in the life cycle. So she mentions about static, and that is application security testing, SAST, and dynamic application security testing, DAST. And then there is a dialogue between the characters about the concerns that this may introduce. Also how to implement that, and we eventually have our Chen, our DevOps coach, suggest that, "Hey, we can do that using OWASP plugin that will be able to check if we have vulnerabilities in our dependencies for the PetClinic project," which is essentially a Java project, which has a lot of dependencies. So we could do this some other ways. What else could we have been doing here, Olivier? Yeah. So what you're going to do right now and what is suggested here is to introduce this vulnerability analysis as part of the pipeline, which is based on Jenkins, and we have what is called a Jenkinsfile, which describes the pipeline. In fact, it can be done in multiple ways. We can shift security left with multiple ways. GitHub themselves, and I think it's true also for GitLab, but GitHub at least, they do have a mechanism where they scan your vulnerabilities or your dependencies. So they support multiple languages for that. And they will be able to tell you, "Eh, this particular dependency that you rely on for your project is going to be a problem. You have a vulnerability of high severity or critical severity." And that's one way to do it. So there are indeed many ways to implement the same need. Here we are just focusing for the sake of this example, leveraging Jenkins files or Jenkins pipeline, and the OWASP plugin that does those security analysis. So what I'm going to do right now, just following the steps that Dan, our developer, explains. So we navigate to the GitHub copy of the PetClinic to something that is called the POM file. So avoiding all of the details there, but the POM file is what describe our environment, our dependencies, and some of the things that we need to do. And here, I'm asked to add the OWASP plugin as part of basically the dependencies and the POM file. So this is what I'm going to do. Add that after the /plugin.

Chris Swan

And do you have to write it this way, or could you just go about that any way you liked?

Olivier Jacques

Yeah. So right now, what I'm doing is just simply using the GitHub UI, the web UI, which is not what many developers do. They have an IDE or development environment that they leverage for that. They may better use Vim or Visual Studio Code, whatever, and use their own Git client. But just again, for the example there, I'm going to use the web UI to edit. So I just added my plugin, which is the OWASP plugin. One thing that is interesting to note here is that I'm going to fail the build if we exceed a severity of seven, which is critical, which is what I want to do. For this example, I don't want to care about the other severities. So adding OWASP dependency checks. I'm going to add that, creating a branch so that I can create a pull request for that. Okay, so this is my pull request. This is going to add, let me see, checks as discussed. Check being our DevOps coach. All right. So I did my commit. What you see there is that immediately now I have something that is pending. So the commit is being built. Remember, we wire this repository with the Jenkins. So in fact, if we continue the instructions we can see that the Jenkins is already going through the checks and we have a build ongoing.

Chris Swan

Which has a lot of steps going through, right? So right now it's all green because, well, there is nothing. We just added the OWASP plugin and we didn't say analyze this. So we just go on with the step six out of eight.

Olivier Jacques

So now we are going to add the scanner in the pipeline. What we mentioned is that we leverage Jenkins and the Jenkinsfile for that. So again, Dan is asking me to go and find the Jenkinsfile and add this step in the pipeline which is what I'm going to do. So I go to my Jenkinsfile. Here it is. I'm in the branch where I need to do the change in the pull request. And I'm going to edit this Jenkinsfile. Again, leveraging the GitHub web UI. I'm going to paste what I had in my keyboard. But bottom line here is adding dependency check in the pipeline.

Chris Swan

And do you just want to kind of give a summary of what the purpose of a Jenkinsfile is at a high level?

Olivier Jacques

Yeah. So the Jenkinsfile is a mean. So, well, in the past you would be creating jobs in Jenkins, which are basically a set of actions orchestrated to do some actions. But it was kind of configured manually in Jenkins. Which is good, but as CI and CD pipeline became more important and more, I guess, critical to our businesses something came out which is called Jenkinsfile. Which basically is a way to programmatically program a pipeline and describe the value steps in your CI or your continuous delivery pipeline. So that's what a Jenkinsfile is. It's basically as code describing the value steps and explaining what to do as part of your pipeline.

Chris Swan

So it looks like something's broken. Do we want to dive in to see what's happening there?

Olivier Jacques

Yes, indeed. So something broke. So it was fine before. We have a red cross now, so something broke. Let's have a look. Yes, indeed. So dependency check. We see that the very step that we just added is failing. And this must be because of something that, well, is not quite right. So let's just follow with the instructions. So indeed, we are told that the dependency check should fail. So we are going to switch to Jenkins classic view which I'm going to do right now. Going to go to the classic view. And then navigate to the OWASP dependency check report, which tells me exactly what happened. So increasing the size. So this is just the dependency check plugin that we just added, and it went through 170 dependencies, 118 of which are unique. And we can see that there are multiple severities, multiple vulnerabilities that have been found here. Most of them are medium to low. And we have one which is critical which exceeds the score that we said we are going to fail the build if we do that. So that's a mean for the developer to say, "Well, this is critical. I really want to fix that dependency and use a dependency that is more up to date." So that's the point, right? So Selma from security, we continue the story here and the script. I say, "Well, according to the OWASP scan, indeed, we have one dependency which has a critical vulnerability." Have our hacker say, "Well, I know. In fact, it's not because you do changes in your application that you are going to have vulnerable dependencies." Vulnerabilities can come because of dependencies outside of your own changes and from things that are not because of you. So it's important to constantly scan your dependencies, your libraries, et cetera, so that you don't become vulnerable without you knowing. And then our developer say, "Oh, that's right, I remember. I had to pin this dependency to 9.0.29 because we had an issue. But I remember this was fixed sometime back, so we can update and go to the latest version." So the next section, we are going to explain how to find a dependency that is not vulnerable anymore. So I'm just going to go the dependency Tomcat Embed Core. Here we are. We see that there are 10.x versions and also a bunch of 9.0.0 version. In fact, for this pet clinic, we are on the 9.0 branch. So let's try and see if we can use the latest 9.0, because it's guaranteed to be obviously, hopefully, with less impact on you and without breaking interfaces. So let's try to go and adopt 9.0.36.

Chris Swan

So what happens, Olivier, if there's other vulnerabilities, as well as the one that we've deliberately put there that kind of crop up when people are going through the training?

Olivier Jacques

So guaranteed it will happen. It happens all the time. But that's part of the game of the story. And that's the part I think I really like when this happens, because-- So just as we talk, updating the dependencies. And it's part of the thing that you cannot do with a very simple script, right? Things will happen in real life. You will have new dependency issues and vulnerabilities. So how do you address those? So what we have done is that as part of the module, we expect to at least have one dependency. So I just made the change. But the pipeline may still fail, and it will fail in real life, right? So we explain how to do that and how to fix other vulnerabilities here, which amounts to working through the dependency tree and get those dependencies documented. I'm just clicking the button, but I might as well type the same command. And showing the developers in that case on how to find a vulnerable dependency and address it because dependency tracking is not easy. In that case, I just created the dependency tree that I can see there. And if I were to spot a dependency that was vulnerable, I could highlight it with this grep command and show that. So indeed, totally expect the new dependencies and new vulnerabilities to be found. So we also explain how to manage these. So we actually did the change. Let me go back to the pull request. I updated my dependencies. Well, okay. So the pipeline already has executed. So let me go there. Let me close some other windows here. So in this case, the dependency check this time is all green. We can in fact look at the OWASP dependency check. So again, this is not a video, so I can check the report. I can see now that my dependency, I don't have the critical vulnerability anymore. So I can go by and just stay as I am, or if I were to say, "You know what? Maybe I want to update bootstrap." I could do that as well. I could see actually what the vulnerable dependencies are. See one from 2016, some from '18, and this one has a lot of vulnerabilities, even though they are not high. But again, I can continue to navigate and explore, and see what I could do with Jenkins. I can see my multiple executions of the pipeline. So the first time, which failed at the dependency check. Second time, which passed. I can see the test results. And if I go back to the Blue Ocean UI, just making sure. I mean, this just makes it a little bit more visible. I can see all of my tests that went through the pipeline and seeing what was kept, what was passed. Again, exploring the realm of the possible for this exercise.

Chris Swan

So in this final step, we're kind of asking people to think about deployment frequency and to automatically script this testing so that it's happening, if they're not doing kind of daily pushes. So I think that's one of the best practices that we're trying to encourage here. And as we kind of get into the final minute of this run-through, we've pretty much run through all of the steps of the module here. And we're available in Slack for people to ask us questions about what they're seeing here. And we'd really love people to not only try this out, but kind of let us know through issues and pull requests about things that can be improved with the modules that we've put out there. And we're hoping to open source some more later on. Any final words, Olivier?

Olivier Jacques

No, I think, so it's something we have used internally for some time for ourselves and for our customers. We are super excited to make this publicly available and open source. We think that skilling and reskilling for DevOps is a key topic for our industry. So we hope that this can help. We actually hope that indeed we can create a community around this online DevOps dojo as a mean to complement the face-to-face DevOps dojos, and that we can improve as a community and the learnings and skilling for the people who have to do DevOps.

Chris Swan

Great. Thanks for watching.

Olivier Jacques

Thank you.