 Hi everyone, it's 11 o'clock on the east coast, we are the 21st of February 2018, and I'm Philippe LeFoucaret and I'm going to present to you the functional security update, functional group update for security products, sorry. This is the agenda for today, I will try to be brief because we have a lot of things to see. First of all, this is the new team for the security products, most of us are coming from the Genesium acquisition, so I'm Philippe LeFoucaret, the engineering manager. We have Fabio with us, which is with the interim product manager coming from the CIECD team and is helping us since the creation of this team. Fabio Encato is coming from Genesium as well. He was the leading developer at Genesium. We have Gilbert Roulot and Olivier Gonzalez with us. As you can see, it's a pretty senior team. Coming with some challenges, the first one is the transition from being synchronous to asynchronous. We had a very different way to solve things in Genesium, we were using the chat a lot, even if we were on different time zones. We used the chat to figure out things regarding issues and where everything was sorted out, we created the issue with the conclusion of the chat. It's a lot different in GitHub today, so we need to move to this asynchronous mode and it's pretty new for us and a big challenge. We also used to do CD, so continuous deployments to genesium.com. The way we used that was, again, a lot different from what GitLab is doing with the GitLab.com. Actually every change was pushed directly to master and then to production. We used genesium.com as a test lab for our enterprise customers. We did releases as well in Genesium, but genesium.com was evolving all the time and was a really great way to figure out issues before releasing things for Genesium Enterprise. Everyone is running at the same time, that means we can't or it's harder to ask questions to each other because we are on the same page on the onboarding process. The end book, as you know, is huge, it's more than 1,000 pages now or so. It's pretty much impossible to integrate the war end book in less than a month. I would like again to say a big shout out to Fabio because he's doing a lot to help us and he's everywhere and I know he's already doing a lot of things for the CI CD team. So again, thank you Fabio for the episode, I appreciate it. Just quickly for our objectives, as you know, we are migrating everything from Genesium to GitLab. So I won't go into details here, the idea is we want to make sure that the users from Genesium have the same experience in GitLab, so we are moving as much as possible. It's going pretty well because tomorrow we are going to have the 10.5 release of GitLab.com. And it includes a lot of things from Genesium already, so we are really happy with the accomplishment that we're going to see in the next slide. And also our objectives include making better security products that includes mostly SASD for now, but we're going to improve DAST as well. So far, we have succeeded in integrating the Genesium dependency checks into pipelines through the SASD job. That means for the user, a better Ruby support because we have mostly the same database as RubySec, but we have improved some adversaries and we have a little more adversaries than what they have. The same goes for NPM. We have a better support for NPM now. For Python, we have a better support as well because we are checking dependencies, which wasn't the case before the security products team integration. That's the big news. We have Java support in the SASD, so for now it's just dependencies checking, but that's a great step from what SASD was able to do. And again, it's an iteration, so that's the first iteration for Java. We're expecting for the next release 10.6 to have more than that. We want to have some static code analysis in SASD as well. And we also added a support for PHP through the Genesium because we're again checking dependencies there. We also added multi-languages detection in SASD. The job was stopping at the first language it was detecting. So now if we have a Ruby and NPM, for instance, in a project, both languages are going to be detected and managed by SASD. We have created a client and a server for SASD to use Genesium, so it's very specific to what we did in GitLab. It's already working and going to be shipped in 10.5. And we are removing the duplicates from the output because we're using many tools in the SASD and we might have some CVs several times in the repo, so that's a bit useless. We also updated the widget in the Merit Request. I won't take all the credits for that, I guess. The frontend team did everything. And it's really nice what we have now. As you can see, we had something with a lot of colors. It was a bit aggressive for the users and we have something very clean and we're working a lot with the UX team and the frontend team to improve that. And in the next weeks, you're going to see a lot of improvements there. And we have some great expectations for this widget and especially for the CI view, you're going to have that kind of report directly in the CI view, so for each commit. We have a few concerns as well since we joined GitLab. We have seen that GitLab does not use our tools. We have seen many projects using quote quality or RubyCop or the tools that we are using inside SASD, but in very custom configurations. So we need to figure out a way to make sure that everyone is using the SASD tools and the SASD jobs. And if it doesn't fit, we need to figure out why it doesn't fit and improve that. So that is going to be used in GitLab first because our users will have the same issues. We try to use SASD as well from the omnibus package, but unfortunately we can't do that because omnibus is using a lot more things than just packages dependencies. And we don't have that kind of data currently, but we really want to be able to secure everything inside GitLab and to enforce security requirements as soon as possible. And the last concern that we have is we don't have any metric. That means if we have that something in SASD, the image is going to be pushed directly to the registry and that image will be pulled for each new job. That means every time we change something, it's a kind of continuous deployment. So we're pushing directly to production and we have no feedback directly from the platform. We could have some feedback from the users, but that's all we're in. We shouldn't wait for the users to yell at us because we have break something. And that's it for today. Is there any questions? Could we talk about genesis and competitors and possibly explain the return or we compare? Right, that's a tough question. The main difference between what we're doing in GitLab and companies like checkmark is that we are leveraging some open source software to do SASD. That means we don't have anything in-house apart from Genesium to do SASD. So we're using code climate, we're using bundler audit, we're using Bandit for Python, etc. That's for me the biggest difference. And the company like checkmark, they are doing that internally. If you are using Codesc, for example, they are doing that internally. If you are using code climate, they have their own engine. So that's the main difference between the two. Do we have more questions? We're going to have a lot of presentations for non-engineering teams, especially cells. And so you will learn more of Genesium in the future. Yeah, I have great new t-shirts. It just arrived yesterday. That's a good timing. Okay, if, yeah. When I said I don't use these tools, can you elaborate? There are many, many, many projects inside GitLab, not only GitLab C and GitLab E. There is a SASD job in GitLab CE. I need to check that, really. But so far, on most projects that I've seen, we don't use SASD. And I don't want the developers to use SASD and to copy past the definition. I want the developer to be able to enable SASD. And in the future, we want to enable security requirements enforcement. That means Katie would be able to define, and Katie and our team would be able to define some requirements. And we should be able to enforce that on many projects with different levels. Okay, we don't have any more questions. I will give you five more seconds if you want to ask us something. And yes, if we're using autodevops, it's going to be enabled for every new project. But I suspect every new project is not using autodevops. I need to double-check that for the next FGU. After integrating into GL, are there any future plans? You can talk about future features. When you talk about future, I suspect you don't talk about gymnasium features. Yes, we have credit plans. But actually, what we want to do in the security products is to make the life of the developers easier. So we want to move that information that we have currently in the database to the eyes of the users. And most of the features will include reporting and dashboarding. Currently, we're just listing issues. And we want to make a lot more than that. Mac has made a great presentation, a great video a few days ago, about what code quality and SASD should be in the future. And we should really bring that information directly into the code. That's really what we want to be added. Yes, we have the auto update, but it's going to be on a very long term. I will leave that for the next FGU. Okay, thank you, everyone. I guess we have gone through all questions. Yeah, no more questions. So thank you again. And I will see you in the team call. Bye-bye.