 My name is Harold Smith, I'm one of the co-founders of a company called Monkton. At the core of what our business does is we developed a platform where government agencies can build mobile applications that conform to NSA's NIAP standards. So NIAP is mandatory for national security secret and top secret systems. Our goal was if we can build a product that satisfies TS environments, that can roll all the way down to FO, UO, CUI, SBU kind of environments as well. So by going, tackling the hard problem, it's a lot easier to solve the simple problems. Along with that, we have built in support for NIST AAL-2 and AAL-3 credentials. So AAL-2 and 3, it defines hardware tokens, like so if you work for the government, your CAC PIV card, we can support those tokens, the soft cert versions of them, as well as Yubi Key and a few others. So we actually were part of Yubi Key's recent iPhone support, so they rolled out or rolling out the 5CI keys, which can go into the Lightning ports. We can do PIV, NFC and OTP off that, or I think it's OTP off that. So our whole goal is, could we give this SDK platform to the Candy Crush developers and could they build classified mobile applications? That's sort of our criteria of how we actually do all of this. So to prove our claim, since any vendor can claim conformance to anything, we decided to take our product through the NSA's accreditation process, which is called NIAP, which is an extension of common criteria. It's a National Information Assurance Partnership. So if you want to be a component that can run in an NSA secret or top secret environment, you have to go through formal validation with the NSA. So that involves hiring a common criteria test lab, which is authorized by NIST. They do an evaluation on your product, and the NSA then validates that evaluation. It takes about, you have to be done within 180 days, but the average is about 90. If you aren't done in 180 days, the NSA kicks you out, and you have to start all over again. So it's a lot of incentive. How many people are here with federal government? So all of you commercial people have it so much easier, because when you get into FedRAMP and the fun things like that, 180 days would be unheard of in FedRAMP to go through. So collapsing that timeline down for us, especially on the software side, is really important. We took our iOS version of our product through that process, and we're going to be taking our Android version through that process as well. We don't have to do it. We just like to do it because it's a good part of our story. So I'll just read through my slides or bullet points anyway. So what was our life like pre-GitLab? We were using a lot of what I consider hodgepodge tools together, so I'm not trying to slam on their competitors, but we were using Jenkins. Runners for Jenkins are, I can't think of the right word. I know Master Slave is the wrong terminology anymore, but agents, yes. It's of GitLab to run, compile. It was tedious, I think, is the right word to use. It felt like we were trying to keep the plate spinning 24-7. Getting runners up and running on hardware was pretty difficult. For to build iOS applications, you need a physical iOS or macOS server. So you have to install the Jenkins software on there, set it up, and then sort of manage it. It just became tedious in many ways. So we even deployed this in AWS and we ran into some issues of just trying to keep instances running, databases, security. It was just unmanageable for us, being a small company, trying to be lean, trying to automate everything. So we started using GitLab earlier last year, and that really became our path of how do we help automate everything for our customers? Getting away from the traditional process of build it, submit it somewhere. I don't have to sell the whole CICD story to everybody in this room. I would hope not. How do we go from a very tedious manual process to something that's completely automated? And most important of all, we wanted to build out a process that our customers could leverage. The end goal was we want to eat our own dog food that we're going to sell to customers, and that was really important to us of a planning goal of our migration to GitLab was how do we ensure that what we're doing is something our customers can use? And that was where sort of base lining with FedRAMP was our table stakes of we have to do this in order to move forward. So as I said, our table stakes were, it has to be a process that our customers can leverage, from deployment to disaster recovery to, yeah, there we go, finally. Thank you all. For deployment, disaster recovery to setting up runners in an automated fashion. Within AWS, we use a series of cloud formation scripts that we built so we can just say here, launch this, it's up and running where we want it to go. Reality, it did take us a little bit longer than we wanted and that wasn't because of GitLab, that was more of constraints on our side. We thought we'd be done in about three months or about five months to get everything over and get a lot of the automated process done. And one big lesson is not everything needs to be automated. So there are a few things that documentation, scripts, there's just no need to automate some of this stuff. So one of my takeaways for everybody is look at what you're trying to automate and what are your end goals. Is it a project specific set of goals that you have out of it or is it a group of projects specific goals and really define what needs to be automated, why are you automating it, what tools are you using to automate it and sort of wrap your head around where are you trying to get. For us, the process is much, much easier. We are doing things that I wouldn't been able to do about a year ago from some of the automated testing we're doing. We've actually built some of our own CICD tools for command line. So if we want to do dynamic application testing, there's a company called Now Secure which we partnered with where they can actually test your mobile application on a physical device that's been rooted so they can inspect web traffic, what secrets have been stored in key stores, all those good things. And with other CICD tools, it was very painful to integrate with them. In a few hours, we wrote a command line tool to be able to upload the binary. It takes about 15 minutes for it to scan, so it'll just sit there and wait for the results to come back. And if the results fail, it kills the merge. So it allows us to put those controls in when I'm going from feature branches to dev master to master branches. We can really control that. And the same goes for some of our static testing. We're using some of the built in Now Secure static analysis, but we're also using third party tools like check marks to continue building upon that. So as I look at regulated industry government, it's not just what one tool am I going to be using to do static testing or dynamic testing. It's what suite of tools am I going to grab so we can get a better picture. Because I don't believe any scanning tool that's going to give you dynamic or static scanning is going to give you all the results you want. But if you layer those tools on top of each other, you're going to be testing for a lot of different things. And in reality, one of the big things we did as a company was, so part of our platform is a server hub that gets deployed into Amazon or Azure. GitLab really enabled us. We decided late last year to get rid of as much technical debt as we possibly could as we start to scale out in 2019 and going into 2020. We were deploying everything with Docker. It worked, but that really wasn't where we wanted to be. So we've made a big push to serverless computing. So for anybody that doesn't know, serverless is I just throw code somewhere. Amazon manages it, deploys it, sets up servers. You don't have to really manage anything. In my opinion, it's the one cloud technology. Nobody's really leveraging yet. Everybody's going Docker containers. But serverless is something completely different. So if you're thinking about serverless, I entirely recommend it. So as I said previously, we've integrated third party static testing, dynamic testing. And those really, so our build process is developer checks and code review. It begins the code quality analysis after code review, static testing, dynamic testing and then deployment. So that static and dynamic testing, after you get through code quality checks, that's really a determination for deployment. What we've really tried to show our government customers is, this stuff really isn't hard. There's a lot of fear, uncertainty and doubt out there of, it takes a long time to build and deploy something and it just, it's simply not, I think probably everybody in this room knows that deploying anything really isn't. You know, unless you really want to make it difficult, it actually isn't difficult. So our overall benefits, our real goal is we want to eat our own dog food. So what we're building out from how we configure and deploy build servers for iOS applications, we're automating that. We're even going down the path of, Apple has this program called device enrollment where I can, when you order a device you get the serial number for that device. You can put it into an MDM and then you can automatically configure it. So we're trying to go down the path of, can I just register that Mac OS build server with Apple when I turn it on, it downloads Xcode, downloads all the build tools, downloads the GitLab runner interface. So it's just automatically deployed. That's a lot easier said than done. There's no real easy way to do that. But it also goes to, we learned a lot of lessons on building GitLab runners. So how many people are using runners to build things Docker with Docker? So for those that might not know, GitLab runners are where code can be compiled or you can run tasks within GitLab. So we have a series of runners, we have one for .NET. So it's a custom Docker image that has some extra tools built into it. It's actually been hardened a good bit beyond what you get from the Ubuntu images. We have a custom Android runner, which is horribly bloated. It's about 10 gigabytes, which is a lot, but that's just the tooling for Android. So once we check in code, the GitLab runners pull that Docker image down, compile everything in there. The beauty of that is, now you have an environment where I could debug locally and figure out, okay, why is this not compiling? Maybe it's an issue with the environment. But then you're getting that repeatable result when you have it in the cloud. We were exclusively using within AWS GovCloud, Amazon's container registry to register those images. It just made it a lot easier for us. I know GitLab has some of the tooling to be able to be its own registry, but that was just easier for us. Yeah, so one of the other things, we can go from app code, check in to live on a device in 15 minutes. So I'm going to beat up on the government on this one. There's a government agency we're working with, well, indirectly working with. For a mobile application update, it takes between one to two months to get it from submission to live on devices. I know it's like everyone's like, what is that? But it's just the reality. They have a very manual process. They have integrators on site, inspecting the applications, looking for vulnerabilities. They have nothing automated. We did a demo with our partner NasaCure using GitLab about two months ago where just went and changed the color on the application, checked it in. It ran through NasaCure in about 10 minutes, published it to MDM. And within 15 minutes from code check into deployment, we had the application updated. So I really like to push back on people that say a lot of this stuff is hard that it really isn't. It's just a, what is your determination of risk? I think with a lot of this automated deployment stuff, it's going to be education for executives on how do you determine risk for this system? Some things you might want to take a month to dig through, but probably 99% of the solutions you're going to be pumping out, it can be pushed out automatically. So I think the deployment process for GitLab is going to be, what is my risk? What's the risk to the organization and how do we mitigate those things? There's a lot of interest in the government right now, software factories, and if you can't determine what your risk is for your project, you're not going to be able to automate anything, in my opinion. And my favorite right now is with serverless, we can deploy in a minute and seven seconds production ready from code check-in. Now, if you tie in more testing, that obviously takes longer, but I love serverless from that aspect of, I can just, our website, all our documentation, our blog, are all serverless and we can just update like that. I can sit here on my phone and make a change. So with tools like that, you really are starting to get, in a CICD process, you're really starting to see where we can actually go when it's not a process. We're not worried about process anymore, we've solved all that. What problems can we solve? So I know I have another five minutes to talk. I figured if anybody had questions or comments, criticism, sorry, it took a while to get everything sorted, but yes, sir. So when you mentioned the entire process of developing the application, in terms of the risk management piece, you mentioned you're doing SAST and DAST. How much of that are you sharing with your government customers in terms of, you know, compliance and governance? Yeah, so everything, I mean, we give them all the reports, they have access to all the reports, when we originally deployed the application, we actually had one of the NSA labs dig through and try to find vulnerabilities as well. DISA actually also had people dig through it. So it sort of validated our, well, here's all the automated tools that are giving us this output. So, you know, why do we have to add these other controls on top? And then, you know, the risk came down to, you know, what's this, what backend systems are we integrating with? So our Air Force project, Bryce, this was, you know, nobody laughed. It was the air, we deployed it in December of last year. It was the DOD's first mobile application that used cellular slash Wi-Fi that connected to a legacy mainframe going through the cloud. It's phenomenal that that was the first, but it was. So, you know, there are, at least our government customers are still trying to come to grasps of, you know, even though it is a managed device, even though it is an application that they've run through testing, what's the risk of having some of that airplane data on the device if they get, one of them gets lost? They already, there's about a pilot of 200 Air Force maintainers using that. They've already lost, you know, one of the devices was stolen out of their car already. So, you know, it's all, you know, what is the risk of that data getting out there? Okay, well, we're encrypting it on the device with the key the user enters when they enter the application. So ideally that mitigates most of the risk, but, you know, it's really dependent on the project. So, you know, how are you building that risk mitigation into your pipeline? It's probably a good question. It's probably independent, you know, maybe that's a good feature for GitLab to add of, here's your risk score of this project and, you know, so feature requests. Yeah, so, and I will say, so our Air Force project started off before we were migrating into GitLab and now that we're in the process of migrating it to it outside of contract, simply because it makes everything so much easier to use, obviously under contract, but it wasn't a deliverable, but now that we have these tools available, it's really how do we automate, how do we make things faster? So our customers can get to that point when they finally get some of their processes figured out where we can deploy this stuff in a day versus two months because that two month life cycle or that two month cycle of deploying is a killer of agile development. I mean, you can't develop agile anything with a two month deployment cycle, so. Could you talk to the governance aspect? So part, what we've run into some time, okay, technically that's feasible, but I have authority to operate or I'm a financial, could you maybe talk about any of the lessons learned you had about incorporating the governance process so that it could take advantage of this technology that you've done? Yeah, so some of the governance came down to of, you know, who it, you know, from the level I look at, who has access to those repositories. So, you know, it's control of, you know, there are some organizations where if you're part of the organization, you get access to all the code. I'm not a big proponent of that. You know, I'm a very much a proponent of need to know. So if I don't need to have access to that mobile application or server stack, I should not have access to it. How are you doing your code check? So, you know, what developer is doing your code check? What are you doing for static and dynamic analysis? You know, our customers have to accept that those reports are valid, you know, that's up to them. That's a determination we can't make. But it's trying to show the government, here's how we're trying to limit the risk that the solution, you know, these integration points are presenting. So there's no silver bullet from it. I mean, we're still arguing with our, you know, some people or some of these things. So, you know, it's so a little bit surely. And, you know, especially for our government customers, you know, a lot of this stuff is very new. So it's just trying to get them to come to grips with, you know, commercial industries and doing CICD for years now. There's no, there's nothing really scary about it.