 So, hopefully you're all having a good morning. So let me give you a little bit of background on the topic today. I think we're all sort of managing the deployment of applications on a regular basis and the constraints and the pressures that are being put on it are impents, right? The complexities are getting more and more on a regular basis, right, in the SDLC process. If we think about it, things like cycle times are changing on a regular basis. We're being pushed to put out more of the application, pushing it into a get repo, getting it out in the deployment perspective. And in doing so, we've got to balance out a lot of things, right? Got to balance out the deployment times, think about cost, security. We have to constantly make sure that the deployment of that application is efficient. And that pressure is immense, and in a lot of cases, we think about doing some of the checks that we need to do on a regular basis, sometimes pre and post, and I'll be honest, I think a lot of people will take some, cut some corners if we have to, right? And that's just part of the process. It's, there's a lot of pressure these days. But that leads to us spending more time remediating issues, right? And they will occur, potentially post-deployment. And that really kind of takes a little bit of fun out, right? I like to call it the reduction of my mean time to happy hour, right? Not going to have a lot of time to spend it on actually fixing problems. So the concept of shift left is to help you kind of alleviate some of that. And so start thinking about how to make the process a lot more efficient. And specifically in any of those checks, right, there's lots of things we can do around cost, security, performance, et cetera. And today we'll talk specifically about security and the aspects of shifting left with security into the SDLC process. And we'll talk in general really about what that process is like and getting that started, what collaboration means and how to kind of implement that at a business level, right? And today we have a great panel with us. And I'd love for you guys to just kind of intro yourself and give a little bit about how you interact with SDLC. And we'll start with you, Jeremy, at the end. So, my name is Jeremy. I'm a solution architect at my data model. It's a company that use small data to generate some predictive model. And this model I use for business experts to help them to know and understand their data. What, how I interact with the SDLC. It's at the specification and the implementation. The whole stack, I expect the first one, the input of the SDLC. So, I have a lot of, sorry. With the shifting left, we prevent flows into the production at the early stage. So, it's a big step for us. Sure. Thank you. Hi everyone. Sorry for that. We're all awake now. Okay, let's adjust the levels. Perfect. Hello everyone. Philippe, I'm a distinguished engineer at GitLab for security and security. I joined GitLab with an acquisition. I was the CEO and founder of Gymnasium. So, this is how I got started with security a few years ago. We were acquired by GitLab last year. And this is actually how GitLab started, there are security features. As for the SDLC, we are dog fooding or features at GitLab. We are drinking our own champagne, as I like to say. So, we are living by the SDLC pretty much every day. We are transforming that. We include security as much as we can, especially since some part of security and defense, so I'm pushing that as hard as I can. Yeah, that's it for me. Sorry. Yes. Hello everyone. My name is Sotir Aixima. I work for Goldman Sachs. My job is to run application security activities. But since the organization is going to more fast delivery of asset in production, we found ourselves to be interacting constantly with the engineers which they have, the DevOps or the DevOps engineer of the organization to introduce these tools. So, day-to-day, my job is to push the security part of DevOps. So, we call that DevSecOps. My primary responsibility is to engineer this solution, to make the solution available to the whole organization given the size of Goldman Sachs itself. Thanks, Sotir. Let me give you a little bit of background on also myself and my interaction with SDLC. I lead a developer advocacy team at VMware and we talked to a significant amount of enterprises. And, you know, I think we all think about what the shift left means and there's always this concept and we'll talk about it today of adding the security bits. One of the things that we constantly see is that there's a lot of day-to-based operations that are occurring that just now we're starting to think about getting added in on the security side. And it's not as obvious. It's also a little bit of a surprise when we talk to them about it. So, we're seeing that also when enterprises now as cloud operations and security and DevOps with security is sort of getting combined, right? And I think we have this general notion of shift left as being dev-centric, right? But I think it's more than that. It's also a little bit of cloud ops. But it now starts specifically with, I think, the developers and getting the teams, whether it's security or development or the operations people, to buy in on that, right? And so, you know, being a small company, right, Jeremy? I think it's interesting to understand, you know, how you thought of that and how did you actually get your development teams to start buying in on that because they have to add more bits now, right? And more components into the process. So, I'd love to hear a couple of examples of what you've sort of been through in convincing the developers to kind of go down this path. At the high level of the security, it's quite simple to convince the dev team because if there is some seniority in the team, they use some best practice at the early stage of the designing or at the early stage of the implementation. So it's quite simple to get buy-ins from this. When you go deeper, it's more complex because if you don't have some skills into the team, no one will have the, or will shift naturally through the security into the design stage. So it's quite complex. During a design meeting or a refinement meeting, we have to decide which one will be the paranoid man and raise some questions about security. So it's an everyday exercise for all of us. So it's a process of getting them to buy-in and that process takes some time, right? So speaking of process, I mean, I guess initiating that process is interesting, right? Once you convince them, you talk about some of the benefits and kind of work through that. In the business, I guess, and at Goldman, I think so too, that you've kind of been through this, right? We'd love to hear a little bit about how you have actually initiated that process, what it's been like setting up that kind of that structure and posted convincing and actually getting that moving and what are the hurdles that you've sort of seen, right? Sure, yeah. So that is really a tough problem to solve. You cannot take the organization of the size of Goldman and deploy a static analyzer tools across everyone overnight and you expect next day the process to work. So what we did inside Goldman is to provide an adoption plan. The adoption plan was generated by a core engineering team and by technology risk team, which is my team, and we tried to inject these small scanners, allow me to call that impurely way, small scanners, sass, dust, dependency checking, in family. We call that in family, meaning we deploy inside TechRish or a small group of engineers and we see they are the problem. We see by deploying a static analyzer, we'll see that the developers will have the problems of that, we'll have false positives, we'll have people complaining or we break the DevOps pipeline. As soon we see this problem, we start to figure out how to resolve each of them before we go into higher scale. So from 10 people we go to 100 people, then to 1,000 people and then film-wide. That is the only way that we can see that adoption and the process to working and we do that for each tool. As you can understand, each tool has different characteristics, different output, people receive that differently. And so now you're, how long is that, just curious, how long is that taken and where are you on that process now? You're still moving through it or? I cannot disclose very much information how we're doing Goldman Sachs, but allow me to say in different way that even if we have a product for static analyzer today, after two years we need to engineer again with a new product that is coming in market for new technologies, new tools, et cetera. So I think that is constantly way of adopting the new processes and the new tools that we do regardless if we have something that we call today, Matthew. Sure, yeah, so you're constantly visiting that and then revisiting it, right? Yeah, yeah. So as that process gets started, I think one of the main questions around this is now, how do we go through and actually pick what some of the security components are that we're going to add into that process? So Philippe, I think it would be interesting to get your perspective on this and what do you pick? What are some of the baseline components that actually should be there initially and then what are some options on top of that? Every business is different, right? And everybody's going to pick what they need, but would be great to get some examples from you. Yeah, sure, so first of all, I think that security should be a shared goal between not only the DevOps team, but the DevOps and the security team. And I think that we are still doing security today as we were doing QA 15 years ago. We are doing security on very specific platforms like a staging or a QA environment. And if you think about that, we were doing exactly the same 15 years ago. We didn't have any CI CD by the time and we created that maybe, I don't know, 12 to 15 years ago. And we started there to automate the process. We started to stop relying on the quality team at that point. And we are doing exactly the same mistake today. We are relying on a security team on a different timeline, on a different SDLC loop, the security team has their own loop actually. They are acting on a different timeline. When they have some results, they have to disrupt and to disturb the DevOps teams. So when it comes to components, I would say that automation is the key there. So as Sodi said, starting with very simple things like SAS, that's dependency scanning, everything that would cover the security checks of the code itself and the code that is shipping to production that your team is not especially writing like all the dependencies. That's something that you definitely need to take care of because most of the security issues that we're seeing are not only coming from the code that we are writing but also from the configuration and everything. And I can also mention someone else from Goldman Sachs who told me yesterday and I really love that code. We are one policy away from being public on the S3 buckets. And that's true if you automate and if you have a security team that is able to really have a deep understanding of what you are doing, you are able to scale that security team. And again, automation is the key there. It's the only way to scale the security team so that they can have more time to deal with that kind of issues. Now that's right. I think I mean, adding that automation is important, right? And I think he says something interesting there, which is I think if we think about adding security components as they've kind of evolved SAS and DAST and doing image verification, sort of comes to the top of the mind a lot of times in the CI perspective. But as you indicated, we're sort of going into public cloud on Amazon, Azure, Google and the ability to also double check. And I think things like, hey, do I have my policy set up in S3 or do I have my policy set up correctly for this user? Are there any issues? We got to start thinking about and I think it's not natural right now, but it needs to be, which is to start checking for those types of issues in your environments that are going into public cloud because they're constantly changing and that's kind of in the CD portion of it, right? So it's a, doing the shift left is actually fairly comprehensive on both, I think the CI and the CD piece, right? And so as we add these, and we talked about some of the pressures that are coming in, in ensuring that we have an ability to kind of deliver rapidly, right? Those pressures change the metrics and one of the issues is how do we now with all of these additions ensure that the metrics around actually delivering the applications is consistent, right? And how do we keep that? And being a Goldman, I think so, it'd be interesting to hear some of your take on this and as you've kind of gone through that process, how have you ensured that those metrics are a little more consistent than how do you get to ensuring that you're still meeting them, right? With all these new additions. Sure, so metrics, we definitely take the advantage of having centralized systems and DevOps via GitLab, for example, is a centralized tools for us to look in a single place. We think Goldman will have, or at least I have, two specific metrics. One is the effecting of security controls, seeing every pipeline has or not have scanners from my team and therefore to see the output of the scanners. But there is another metrics that the leadership of organization wants to see from my side. We transit from traditional application security, manual activities, manual penetration test code review, which meaning people doing the work, delivering the outputs to more automated things. So how we can take the output of these metrics, the effectiveness of the security controls and to prove to the business how we save money, how we, now that we have DevOps or better say in DevSecOps in this case, how we can do less code review. And specifically when you go to the organization which you have thousands and thousands of developers shipping code every day. And to Goldman Sachs, this is the two key things that I'm looking after, like the effecting of security controls, thanks to the centralized DevOps solution that we have and small engine or scanners outside GitLab that are integrated with GitLab and then how all of these activities that I'm doing actually can be scalable and can save some money from money or time, however someone want to quantify this, from manual activities that previous was doing. We're still doing, but how we transit to that more continuous DevSecOps. Great. I think we've got a few minutes left. Thank you for that. I'm gonna ask one last question. I think we'll open up for questions with the audience. But Jeremy, it'd be interesting to understand, now that you guys have implemented and you're going through this, what are some of the benefits that you're seeing now with the addition of this? Yeah, the big one is less frustration for the dev teams or for the security teams. More synchronized timeline. But the really big one is less frustration. Sorry, Phillip, you will answer that on the benefit side? Yes, actually, the less frustration that Jeremy say that is really key to us, like we deal, like we went from manual activities into automated activities. So if you had one problem before, now we have 10 problems. And this is really difficult for us to manage. So when we deploy a new tool or a new process, we look very carefully what the engineer organization will tell us to take that feedback as the first citizen feedback rather than what we think in isolation as a security team. Thanks. Phillip, yeah? Yeah, I think that I will agree with Sodi and Jeremy. The main benefit that we are seeing is less frustration from the development team. But also we are seeing the security team scaling really with that. With automation, we are catching the longing fruits and that leaves more space in the end for the security team to deal with the very three key cases like authentication problems or that kind of things. So yeah, it's definitely beneficial for us as well. That's great. Well, I want to thank you guys for some of the questions, but I think we've got a probably a minute left or two, so we'd love to hear any questions from the audience. Anybody? We have one there. I'm interested in the topic of security vulnerabilities and open source libraries, which can be quite buried deep within projects. I'm wondered if this has been an issue for any of you and how you've addressed it. Yes, so sometimes we call that dependency checking or software composition analysis. I think every organization should have that capability, specifically if it's using open source. I think everyone currently is using open source if we don't call that, but facing down a library from outside, whatever language is that, you have to check what the world is saying about vulnerabilities within that. So we have tools to do that. We have automated tools to do that. You know more or less the name. I'm not going to name the big players on that. Also GitLab has the security capabilities to do the dependency scanning and Philip can speak more about that. We take that tools and we try to integrate to the DevOps. So there then we expose these findings back to the developers or the engineers, however you want to call them, to fix that directly or to speak then with my team to find a middle ground if something cannot be fixed. Let's say that we have a latest version of that library and has a vulnerability or zero day, which was we don't, no one have a patch, which is the open source path. So then we find a mitigation solution until a new version with a patch is presented. Philip, do you want to add something on that? I think you covered it well. Dependencies are really a big deal today. We are seeing that, for example, at GitLab directly in the source code, we have 100 first level dependencies in GitLab and when we install GitLab, actually we install more than 1000 dependencies. So that means the portion of the code that we are shipping from GitLab is really tiny compared to the portion of code that we are shipping from the third part is that we don't know. We do nothing about them. So we track down with dependency scanning. This is one of the automated tools that we have at GitLab but we also have the security team being very vigilant to any new dependency that we would introduce. So that's why we have something in our process in the merge request directly. We are showing the new dependencies that would be introduced by a change so that very early in the process we can take the decision if we change something in our dependencies' exposure. Anybody else? Do you have manual eyes on every new dependency so you actually look into the source code or do you rely on third party checkers to check that for you? Can you repeat that? I think we had a hard time hearing. Could you repeat that? Sorry, I did not hear your question. So do you actually manually review the code that you're creating a dependency to or do you rely on third party dependency checkers to check it for you? That's a great question. I would chime in if you don't mind. Two different things. If it's a very regular dependencies I would say we rely on the tools that we have. So it's basically matching the version of the dependency that we're using with our databases. We have a public database of adversaries for all the dependencies in many various languages but when it comes to something very sensible like authentication or that kind of things then we like to have the security team being involved to review the code, review the dependency, review. If the dependency is still maintained, the algorithms, everything related to cryptography and we can just rely on the visitors for that. We need to have a deep understanding of what's going on there because that code again is going to ship to production with our code and running there. Thank you. Thank you. We're out of time but I wanna thank the panel here for the answers and we'll be around for some questions after this. Thank you. Thank you. Thank you. Thank you. Thank you.