DevSecOps - the What, Why & How

hi everyone welcome to today's webinar my name is peter quinn and i'm the manager for field marketing in apac at git lab today we're presenting on devsecops the what the why and the how by sama senior solutions architect at gitlab just a little bit of housekeeping before we get started this webinar is being recorded the presentation and slides will be emailed to you after the webinar has finished if you have any questions during the presentation please feel free to type your questions in the question box in your zoom control panel and i'll bring them up during the meeting or sorry during the presentation um and we'll also have some time towards the end of the webinar for questions now without further ado like to introduce you to today's uh presenter summer cab is a certified cloud architect equipped with over 20 years of experience in transforming business needs into workable technology solutions summer has worked for many large organizations across the asia-pacific region helping to establish their cloud-native practices setting up efficient development life cycles and allowing aligning their i.t plans to the expected business outcomes over to you oh thank you very much thank you tim and yeah welcome everybody yeah as pete said thanks for the introduction i'm samara kub solution currently a severe customer solution architect working for gitlab before git lab i have been working in the industry for almost 20 years i went through multiple different positions uh as advisory architect with pivotal which is now vmware as you all know as a cloud domain architect with nav and a cloud lead architect with oracle and many other uh positions uh so so this is you know this is the agenda for for today we will start with what is the devsecops we will try to dig a little bit deeper on the differences between devops and lipstick ups why do we need uh the sick ops uh what are the different ways of implementing difficult based on what we have what we have been exposed to from working with customers worldwide and gitlab so just to go back to the basics where that devops started from from and you know what i'm sure that most of you today would agree with me that it all started from the try to compress the cycle time which makes really the difference between winner and loser who reach or access the customer first who present the product first to the uh in the market who can expose to new markets faster also the how fast can i detect that my strategy business slash i.t strategy is working efficiently before making big investments in my in my environment so that cutting that cycle time brought to the table the need for having an automated dev devops so in my try to define the devops uh i did that what most of people would do logically when to google what's what's the box and you know what i got 66 million uh 300 000 reasons so i thought okay i'll take you i'll take the guys through the 66 million three hundred thousand results to like to define the most um i'm just kidding i can see your faces but i hope you are smiling there so so um just the most common uh let's say attributes in most of the devops definitions are between the collaboration tools culture and processes to be able to deliver the value fast to the customers or to the end users or to deliver my products fast to the market right so let's remember this having a very quick cycle delivery cycle using collaboration so devops is not only tools many people who may be referred to devops as devops tool not it's collaboration it's processes and and and cultures and tools all working together right so cool most of the organizations today have successfully implemented fast devops cycle i would say maybe efficient devops cycle to deliver value to their customers uh fast but if we look at the popular cloud vulnerabilities today most of them are coming from these client applications or known as miss configurations or vulnerability applications so these are coming not only in modern applications but also from legacy applications but things have become even more difficult to control with the new applications in other words if you look today on microservices it's all about apis and api's exposure so more service of exposure for for hackers more like the security tools used today and maybe you agree with me most of them have been developed 10 plus years ago at least and we are bringing a modern development strategy or cycle we're trying to marry that with security tools to achieve a secure delivery right the integration in our development cycle is hugely coming late or like towards the end of the delivery process so to make it to make today's session a bit interactive let me start with this uh question poll question and please uh peter and tim help me gathering the results here has the focus and this is please on the screens in front of you just give me your idea has the focus on security and development changed over the last the past three months please feel free to give me the like has increased yes 84 percent coming results coming i'll give it 30 seconds before ending the poll 62 65 i'm looking for 90 reply okay i'll give it another 30 seconds i'm just uh [Music] right okay seventy seventy one percent of yoga said it has changed or it has increased even and 40 percent remain the same and you know what this is very very comparable to what i see with the customers i'm working with and i absolutely don't blame or i can understand why this development security changed because you know what regardless of the industry you are working on you're working in modern electrical cars you are working in financial sector and even you're working in not government or tech operators nobody is safe and and the attacks are coming regardless you are working on-prem or in the cloud there is a meth here and let's let's agree on like just try to work to work this out i'm working on the cloud then i am safe because the cloud provider is taking care of my security this is a myth this is not absolutely not true actually most of the time if you are working on the cloud you are more exposed to attack tax than less exposed and the first thing you sign on when you work with or you move to the cloud as security is your responsibility mr customer definitely on the application and config and configurations level yes the tools are there but it's your responsibility to manage that overall security and absolutely your responsibility to scan and make sure your code is is secured so thanks to pirates of the caribbean there will be almost trust me there will be always more of them than there are a few there are more attackers than number of people you hire in your organization to do like security controls and and auditing and review so the idea here and this is what i want all of us to agree on hopefully by the end of decision is we want to come to come to a point where security is a behavior it is an integrated part in our in our dna in our development dna so what's the reaction for that exposure let's solve for obvious obvious cases and the obvious case is and this is like this is a typical security or development life cycle i'm a developer i send my call to a repository from there it goes through a continuous integration cycle bring continuous delivery and deploy to test staging environment maybe production and then i have these giant engines of security uh auditing and review practices so i pass my code through these engines and i sit there waiting for the feedback on my tools on my on my developed applications trust me if from what i hid in the market that waiting period goes anywhere from two hours to two weeks waiting for that review to come back because nobody wants to be shown on the news next day as our friends in in the previous slide so definitely people are doing their job perfectly and they are doing it to them to the maximum where every line of code needs to be reviewed and every change needs to be reviewed but guess what the business is sitting there waiting for that new capability to be released to the market the developer is sitting there he they already started working on the next cycle then the next cycle then the next cycle and maybe in couple of days to a week they will go back and sometimes maybe even more they will get back the results and then the developer needs to go back and remember what he has changed on that day on that change on that push request and try to fix it so so basically what's happening there many times we feel that security is a square pig in a round hole because we are trying to integrate something very important nobody denies that it is effort very vital in like but it has been developed outside like the devops idea of having continuous delivery we are trying to integrate that in our tools or in our devops life cycle you see my point the point is is not really in the like there is nothing wrong with the security absolutely this is a very required building block but what's happening here is instead of having a secure devsec ops we end up with devops plus security and there is a big difference between the two nobody wants to pay i would put it a different way nobody likes to pay taxes right but having tool or security as an extra thing in the in the tool chain we end up paying the tool chain tax we end up having more integration points more tools on the table we need more to train more users and remember the users you are talking about here are the developers most of the time not the security architects you need to switch between context because yes that like the development is happening here but remember the security tools are are already established in the organization here and there is like there is an integration there is a gap between the two which most of the time the security vendor will give you maybe some plugins to integrate with your devops to make it as it looks like as if it is seamless but there are still two two different tools right and you need of course you need to administer these these different tools can i go back to the polling and get your uh look i will bother you maybe another more time so this will be a very interactive session hopefully so how often does the security fully review the code before it is sent to production like on every chord change in every branch on every chord change in the master branch and please please give me i'm not recording those who's answering what so please give me your base on your experience on the code once it is ready for production and post-production okay another i'll give it another [Music] another 30 seconds okay 67 percent come on it's one day like yeah usually i play music in the background but um no you don't want me to sing definitely yeah nobody wants me to excellent thank you very much 46 percent which is expected it is on the code once it is ready for production this is a very thank you i really appreciate this this is a very very realistic uh uh results because i'll tell you something the point is running security itself running this security engine is an expensive financially and effort and time ones from all aspects it is an expensive practice is it required absolutely yes but it is an expensive practice practice but you know what based on the an ic survey it cost almost 30 times more to fix something if it is in the production if it is discovered in the production compared if it is discovered in the early stages of the development imagine like okay you can see the picture so let me here just rehearse a little bit we understand the value of the security uh sorry the value of the devops yes we understand why it is important take yes we understand that by having devops means you are being exposed more to the attacks yes and like there are so many market uh i mean uh uh a news and articles on uh companies who have been exposed to definitely yes so we understand the value of having security in the cycle and integrated but that like the challenges of having that yes the problem is now having another security engine means i am checking the box of having of secured code but i am unchecking the box of the key of the key purpose we set up the devops practice which is a quick delivery you remember that 66 billion results all of them agree on having quick delivery of value to the customers so we are sort of unchecking that by adding another milestone another bottleneck another gateway in one in my code release release cycle so now it costs 30 times more what happens when you find 10 000 vulnerabilities at the end of the software development life cycle and trust me 10 000 is not an exaggerated number it's like and people who have been working in big enterprises i have seen this number you they know that this number is like can be seen so you now need to go back to the early stages and fix these 10 000 up let's say up to 10 000 different vulnerabilities and let your developers work on them good luck convincing that the management that you need you need extra time so the point is what if you dealt with each one of them at the time where it was introduced oh yeah sorry i'll take it off sorry yeah so remember what if i what if you dealt with each one of them at the time where it was introduced which means i'm a developer i'm putting this piece of code i'm able to run the scanning now not one type of scanning right i'm talking i will come to that but i'm talking here about fully being able to know in my branch in my changes that things are secured being able to fix them immediately before they are moving or measured into the master master branch you know what that means means that your master branch is always deployable to the production and you're you're you are able to deliver almost at the speed of the business requirements so most important security product won't be a security product i should have a poll question here to to see you if you think uh if you if you agree with me but i would assume yes because this is from uh uh someone who's deep into security in vmware and the point is what he means that it's a it's all about practice it's all about having real dev set ups not devops plus security and and we we i think now it's clear what's the difference between the two i promised last one does accelerating development and delivery mean that you have to sacrifice quality or security do you agree with me yes no and yeah peter orton can you bring up please the polling yet thank you okay thank you i think we are almost there 46 percent no 48 33 like 77 78 there are still ten more guys who you didn't vote so and here we go it's almost a tie between no and it depends and i totally agree with this result i'll tell you something usually when this devops cycle is happening and you are sending more and more changes to the security department especially in big enterprise organizations you are talking here about things that start to be accumulate to start to be accumulated at the securities side and here the business security they have two options either or actually three options either which the business usually they don't take either they hire far more people to be able to cover that cycle but guess what the more people you hire the more release is coming the more people you hire so that would not happen especially in this like in what's happening today in the morning second the security they have to lower their expectations or standards so that the code can be released to the production faster i mean i mean they may say okay things under low to medium criticality it's okay i'll accept that for now or classes that haven't been exposed much in the last two years it's okay i'll i know there are vulnerabilities there but i'll accept them because i don't have time to go back to the development team and make them choose or use different classes or the third option the business have to lower the business sorry has to lower their expectations by accepting that the code will not be delivered in a week and they need another two weeks to be able to release the code secured in the market you see my point so just either you hire more people which trust me it will not happen or you hire or you lower you lower your security standards which is i would i'll accept a bit a bit i would be more relaxed working with security teams in and previously they turn they don't tend to lower their standards trust me they enjoy the that power or the business have to accept the lower uh standards lower expectations from the release so what if we can scan the code every time remember you told me before that most of the scanning is happening just before we go to the production so what we want to do today what if we can scan the code every time what if we can bring that even to the development what if we need we can use fewer tools and have dipstick ops developing security and operations on the same page not have devops practice and security and of course make the auditors happy which usually it's not an easy task i i most of the time and sorry for people who have iphone most of the time i have android phone right i used to have a dslr right camera watch i invested like a good amount of money and when we go we used to go out uh before used to right before the discovery thing uh if you still remember we used to go out in cars seeing places taking photos that's in the past world i used to have two tools with me big one and the other mobile each having their own doing their own business and now then trying to integrate the output from the dslr and the input of my mobile and sharing my sharing these photos and images with friends until to a point where my integrated tool my integrated platform which is this one is able to provide me with an end-to-end solution from communication from texting from taking good quality pictures and share them with with the with the with my friends you know what i did i sold my d7 and there was a good amount of money because i feel that the value of this integrated platform is bringing me to the table is far more than having an extra 10 000 k whatever resolution in that camp now in normal nor in normal dipstick ops you don't have you don't have to ditch your current security engines which are built for purpose i'm not saying that at all i'm just saying that this devops community they need to have security as an integrated practice it is an integrated part in their daily life trust me simplicity and integration always wins you want to pass that through that engine at the end it's fine but instead of having 10 000 vulnerabilities there will end up with so much fewer number of vulnerabilities which can be fixed easily by the developers and like who have have been doing the the development and by time this tool will learn from the outputs from there and most of the more you will end up having a completely stream output to the production and this is what git lab has been helping customers around the world to do shifting security lift and making it within where it fits most within the dev ops practice as an integrated practice inside the dev the sick ops as you see here we in gitlab provide the security capability to run on the feature branch not only on the master branch i'm not saying that you can run it on the master branch and by doing that i am a developer i create a mass request i do my changes in my in my branch right this is important and you are doing the security as close as possible to my changes basically as close as possible i mean once i push or commit my code to that feature branch the review will happen there the changes i will be able to see the changes or sorry the outputs or the results from that review immediately there and the same within the same minutes where i did my changes and i will be able to fix that there not so instead of having as you as you said in the previous poll instead of having most of my scans all the way closer to the production where it is 30 times more expensive to have to fix the results the findings i'll bring them all the way to the developer's side and by doing that in the gitlab we provide and actually recently we even added one more we provide container scanning on the developer next to the as a as a tool we provide static application security scanning we provide dependency scan we provide license compliance scanning and we even go ahead and provide dynamic application security scanning uh sorry testing each one of these in the security world means a totally separate engine that i need to integrate with in gitlab they are all coming and become part of the cast of the developer tool chain daily tool chain of the developer keys to the development kingdom right and even recently has been just just been released yesterday we have added the fuzz testing so what does that mean it means that i have a continuously a continuous integrated real dead sick ops right from i do the development the new comments coming into into the gate repo the scanning and analyzing is happening there on my branch i can see the outputs and i can mitigate the findings i can protect them i'll come there i can protect them once they are deployed to the production and then their development life cycle continues so do do if do you want to have once it is deployed to the production let me go one one actually two steps do you want to have another tool for for in your existing environment for extra scanning here before you go to the production please be my guest and do that but the point is we need here we need to be clear it's about having security integrated in the devops cycle to make it a real the the sick ops uh uh uh or uh cycling so you did the sas the scanning oh sorry you did the security scanning on the other side by the way here it says on our roadmap it's already on our production it has just been released yesterday the fastest so this is from pre-release once it is released we have sycops visibility we enable our customers to deploy web applications firewall container networking security and even content on our roadmap container hosts security so you can define your security policies and let gitlab deploy them to your environment especially if you are working on in a kubernetes environment so gitlab and this is this is many people know gitlab as the uh source code management or source code automation platform gitlab means is meant to have an end-to-end dipstick ops platform that starts from creating an idea or what we call it an issue or a ticket whatever you want to name it all the way through the agile project management capabilities including the development having security integrated this is what i was i was trying to explain here and then deploy that to the to the production so for people who like graphics this is a real screenshot of a pipeline developed in uh in in gitlab and as you can see the security capabilities are integrated between on them on the branch level with the security findings available for the developer to to like to see them or to check on them and i can't choose by default gitlab will can even automatically what we call autodevops can even automatically integrate for you all the required scanning based on the code you are developing or the platform you are you are using for the development and do then the review at best but let me stop here for a second and just highlight on the dusting dynamic people who have used dynamic application security testing before they know that it has special requirements than all other development tools and that's why usually this step is done on the production code because it requires a running version of my application and most of the time the license from whatever tool you are using is based on number of license of scans you do a number of scans i mean one page can have 10 links this is these are 10 licenses count inside that page in gitlab this is all under one gitlab platform and the solution is able or the platform is able to provision for you a live instance of your application and then pass that output of that instance sorry a live instance of your application based on the changes you did in the branch so this is important i am again remember this is all a branch i'm doing my changes on that branch i've changed the color from orange the background color from orange to green i want to see how green looks i don't want to integrate back into the master because in the master still the program should show background as orange i did my changes here the application will be able to deploy a live code of my green newly changed background into a testing environment and if it is working if you are deploying against kubernetes into a different name space even automatically provisioned run the dust solution that dynamics this thing there and and even the fuzz this thing there and then giving you the outputs this is very important so this is the here if you see here in the right on the left side this is the cycle i've been describing code commit code changes the developer is doing like uh uh is getting the outputs from the security scanning the das is working there is a review sample app and then deployment these people here the security team with all my respect for the people on the call but these people are most of the time not absolutely not easy to satisfy and they are most of the time suspicious of whatever is happening here their job actually is to be suspicious and their job is is to be very careful on whatever the developers are releasing are releasing in the second this is why in gitlab we provide the security team with an end-to-end view of all the findings that are happening across all the developments on the project level on the group of projects level and even on the on the whole program or enterprise level even if the developer dismissed one finding here the security team will be able to find that dismissed right uh finding so if i go back to slide number two remember in that 66 million finding we agree that devops is all about releasing quickly using processes tools and collaboration and this is why in gitlab the findings users and the security architects and sorry developers and the security architects are and even within the development community they can review and triage and commit and collaborate on these changes paired finding actually down to the line of code not only that they can also create push that vulnerability finding to the beginning and create an issue based on that to add it to the backlog and of the developed cycle so that it will be handled let me let me hear a highlight very important thing you find you get your code you pass it to the development sorry to the security the security team have their findings they pass the report back to the development i have seen it many many many times i'm sure maybe in your environment that pass back is done through google form or microsoft document being these findings either fixed dismissed or lost in the cycle because remember these are two different tools and in gitlab because it's one integrated cycle or platform the findings can be uh can be transferred back and and changed or changed into an issue and be added to the backlog as a ticket to be fixed this is this is the view i promised the security architects to provide and security auditors an end-to-end view of all the findings that happen in my security in your development environments across 30 60 and 90 days across all the projects and you can filter based on the confidence report time severity i think i don't like most of the security friends i know would be happy with that actually this is a big big issue what's happening where it's not about the truth trust me it's not about the two most of the tours in the market are good most of them are excellent even it's not about the tool it's about what i'm scanning and how i'm using this that's these scanning upwards so at the end of my session i don't want to take longer but just just i'd love to leave you with some lessons then driving fast forward with devops and here driving i mean driving like driving a car driving fast with devops means higher crash rates without proper security without proper seatbelt it means higher engineers right so so just remember that god forbid nobody would have any accident but that's that's real life it is this sick ops not devops plus security and please remember that there is a difference between the two next time you sit in a meeting and people say we have devsec ops practice try to dig a bit deeper and see what do they really mean do they really mean devops cycle where developers are releasing code and then that output is done uh as securely or monitored in the at the end of the security uh sorry at the end of the release cycle developers need to have security available as part of sorry of their daily tools their dual tool chain i'm providing the developer with the development environment with deployment environment i also need to provide them with security tools the win in the security finding is as important and i would say it's more most of the time it's more important than the what i'm scanning yes the scanning result is important but trust me a very detailed scanning report which by the way we provide in a very detailed scanning report can become sort of useless if it comes too late or if it is becoming a bottleneck in the release in achieving the business objectives so the win is as important as the what i am scanning as a compliment and thanks for your time today this is a link and as uh pizza said in the beginning we will share the slides this is a a book on uh authored by a certified uh security personnel in in gitlab and it's about 10 steps every season should take to secure nextgen it's free to download and we will pass you the links after after the session so please feel free to go through it it has very valuable real life examples on uh customers who have done their sick ops and unsuccessful and unsuccessful way and what to look for when you implement healthy devsecops what do we mean by their stick-ups i hope you found this helpful and uh yeah i'm happy to take questions peter thanks simon i was very insightful we've got a number of questions um so first off uh first questions how do you deal with a situation when security guys are not well versed in language in the language you are using perfect thank you very much thank you very much this is a great question this is where it becomes the standardization becomes very very important and delivering the report in a language that the security and the developers understand becomes import very very important i'll give you an example to a gentleman who asked assume you are doing uh java scanning right and you are doing uh on on sas scanning or security scanning right now the security team may not understand the java vocabulary i would say but they would understand that there is a high critical finding from your java code based on a package that was used or based on a vulnerability that was reported publicly and here is the link so this is the value of having a common shared platform between the security and the devops and the development team where each will have their own dedicated view on what's what's happening i hope that answers your that question right next question is what about sre is it getting integrated as part of devsecops please share your thoughts absolutely absolutely i'll tell you something sre is most of the time is all about having different roles the development or in the release the release cycle between development operations and and fixes absolutely yes and the evidence for that is in gitlab we not only are doing the scanning continuously we are also providing and maybe i should have added that we are also providing recommendations on the findings to a point where you can apply auto fixes to the back end of of that that i mean code this is one thing the other thing is we enable our customers to train the tool based on their findings and acceptable findings to have their own customized i would say life cycle for for implementation yet please uh there's just a comment from mo um he's said the sre depends on your organization size and shape not everyone is google and therefore not everyone should put should go for the same model thanks for the comment i can't agree more i can't agree more i can't agree this is uh thank you very much this is very realistic uh input yes yes i agree with you uh implementing sre also on different look i have worked with organizations who have 2000 developers and have worked with organizations with less than 20 developers that what you want to adopt from the sre it really depends on your requirements and and you don't want to adopt the practice just for the practice you want to see what's the value on having different drones yes great next question what would be the what would be good security tools um to be part of devops and is sas and that's mandatory okay that's a that's a very nice question what it would be a good security tool look i can't really tell what in your organization would be a good security tool but because it really depends on what kind of development you are doing for example if you are not using containers at all then having container scanning doesn't make any sense right but sales and does let me make it a general comment these are the most common and by most i mean 99.9 percent of the organizations have them if you are doing any kind of development right because your the vulnerability is in fast that there are always vulnerabilities in cells that you want to you need to be aware of and that's requiring denison the need for dust was way back in in time where we need we used to have um lo you know remember that only load testing tools only or like uh um was that hacking testing tools so i would say yes if you are doing publicly available applications or web applications then yes if you are doing any kind of development using development tools i would say yes but the overall answer what what are the security tools it really depends on your environment of what you are doing okay next question how do you integrate the outcomes from devsecops into the wider enterprise security picture in a way that makes sense perfect perfect thank you very much the direct answer we provide and actually we slash the security vendors the key players in the market they provide as well integration plugins with gitlab right plus all the features i've talked about today and and described are available through well-defined risk apis for for for integration right third webhooks are commonly commonly used for integrating git lab with external external i mean entities and and please whoever asked the question please feel free to approach me directly i'm happy to run you through a demo where we integrated a git lab with external external entities last thing in our gitlab integrations menu you will find a very long list of a pre-built integration capabilities with external applications maybe i would add one last one on google if you if you if you just google gitlab security integration with external tools i think the first or second link would be will show you how to do like pass the reports from gitlab to the security tools and vice versa great we've got about another five or six questions um so in general we will fix most critical and high and sometimes medium security issues and then leave the lower security issues for the next release as part of backlogs um mostly this is how we work is respect best practice okay i think i think whoever asked knows the answer i think you know he knows the answer uh is this a practice i can't say yes it's it's no uh i'll tell you something uh i okay okay let me be fair here it really depends on these findings but what are what is that what acceptable means in your industry right to ever ask so acceptable for financial it's totally different than acceptable in retail than acceptable in a uh like a normal homegrown website right so that's one thing the other thing is if you are moving these medium to low variabilities to the next round you are wearing the risk and cost of fixing them later remember fixing them like later in the cycle means it would be more expensive to be fixed developers who develop them are not always there and they are not always they don't always remember what they have changed third thing you are taking a known risk to the production so i can't make judgments here on what people are doing i can't say this is bad but to answer the question is this the best like a best practice i would say i would say no but further details are more than happy to set after the call if they are approached us and go through this cycle these findings and help setting up best practices for that for the development great moving along to the next question i think devsec ops needs to integrate with the rest of the stack as well because the stack integration is a major vulnerability if there is vulnerability in the bios and it can be inherited into application layer will any of the devsec ops effort make a difference uh i thank whoever asked that question thank you very much because he highlighted a point maybe i should have also highlighted it during the call the integration itself between devops and security is a vulnerability is a vulnerability or attack point so bringing security under the same tool means you are patching and maintaining less tools remember here more tools more integrations more things to be patched and managed even the security tools themselves they are tools by the end of the day so what we are doing here they are moving this capability inside the like the devsec ops right still it's your option to choose which which tool to change or which security uh scanning to run but by the end of the day no more sca no more integration required which means this vulnerability and less less attacks attack service uh no more individual patching and administration it's just one tool and i'm sure that's always uh up-to-date and integrated yes please yeah so i'm gonna wrap a couple questions together and the questions do we have do we have a free trial to explore this devsecops features and then also what are the tools available by default within gitlab okay excellent the first one is easy gitlab.com you can register for 30 days trial and that includes the ultimate the highest and you and from there yes you can uh start using and and uh experiencing the gitlab security offering by the way github works exactly the same on-prem i would say okay exactly the same with asterisk okay because there are some details which we need we can go through after but with it's the same source code between on-prem and the sas offering so just go gitlab.com you can register there and start your 30 days free uh i mean plus you can approach us peter tim or myself and we are more than happy to help you set up trial of of and and go through your requirements and even help you uh like piloting these these changes and test it in your environment uh the second part what are the security features uh let me wrap up with this uh static application security testing dynamic application security testing compliance testing license scanning fuzz fast testing and dependency scan and they are all available on uh if you go on gitlab.com security then you can see all of them hope that answers both questions yeah so there's a couple follow-up questions relates to that so does does gitlab have a an inbuilt security scan feature um or does it depend on other tools like fordify appscan for sas and das and then also what are the security scans done as part of ops cycle excellent excellent thank you very much so the first part the second part of the first part is no we we are not depending on uh uh these two but for the sas scanning and this is all documented on our success scanning tool we use open source tools to run most of our sas scanning not any open source tools these open source tools most of them are highlighted and mentioned and and to some certain extent recommended by the standard organizations for uh security scanning and and vulnerability testing and we maintain them and we provide the customer keep the customer up to date with all the vulnerability vulnerabilities databases so this is for that one what was the second part sorry peter what are the security scans done as part of devsecops oh sorry devops cycle uh maybe i've partially covered that the security scans would would do the static scanning the dynamic scanning the dependency scanning the license scanning compliance and first fast testing scanning do you have to run all of them no it's your choice which which one which one to run can they be dynamically even using the tool integrated absolutely yes you can start within half an hour uh sorry within five minutes you can build a new maven project and have all the security features running on on your code and uh yeah i hope that answers you the question okay and what gitlab um or do we have gitlab plugins to connect to commercial security products such as um ibm appscan and veracode okay it's it's a case by case we have a lot my i haven't worked on to be honest i haven't worked on the ibm tools okay i'm happy to if they the gentleman who asked if he can reach out i'm happy to dig into that question and see the integration part as i said before i never found it difficult to integrate with any security uh tool available at the customer side because we have all of them as as integrated apis just let me a little bit go one step back to the previous question so i answered for the tools for sas for the for dependency scan or other security scanning tools we use for some of them we use our own security testing tools like git lab or security testing tools like for dependency scanning we use gymnasium for fast testing we use the new solutions we acquired in gitlab so it's a mix between open source and gitlab solutions but all of them are supported through one vendor and integrated through vietnam okay and and how does the remediation recommendation look like in the ui i wish i had yesterday maybe i removed that slide but uh it's basically and especially for dependence scanning it it is in the same dialogue as this one right if there is a remediation uh i mean recommendation it will show up here as a button or as a link and you can apply that directly to the source code especially for now mainly it's supported for container and and dependency scanning for example for container scanning if there are patches or upgrades that need that can be done to overcome or solve that vulnerability the recommendation the bottom will be here and that can be like just click and apply that recommended remediation to the to the back end solution okay just a couple more um so is cuban that is overkill when we're a team of five people and are only running two apps uh look uh before answering a disclaimer i'm a cuban nether certified administrator so i am a bit biased with kupernetes it really depends on the uh your organization requirements i won't measure the humanities efficiency based on number of people necessarily i have seen organization with like two or three people and still they have cuban letters and it's adding big value uh it really look look i can't really say it is an overkill no uh i'm happy to have that discussion please please approach us and i'm happy to have that uh like a casual discussion on and to understand more of what you are trying to do does cubanet make people life easier and certain extent yes does it complicate if it is misused does it complicate people especially the developers like yes how we can help in gitlab uh i don't have screenshots here but gitlab is an integrated can integrate out of the box with kubernetes cluster and even you can use gitlab interface to create kubernetes cluster in aws and and and google and deploy your application directly to that cluster without i know without opening that black screen which people may not really like great um yeah we've just had a few people ask about hands-on sessions and workshops these are in development at the moment we do have um a number of training elements on our website so you can go there and have a look at the videos on how to get set up but we are as i mentioned we are looking to develop um some hands-on labs or um technical sessions to be able to work through these types of things and we're looking to do that on a quarterly basis so be on the lookout for that and then also there was a question around a comparison in terms of our um our um offering um so obviously the free and the the additional tiers um so we've got i think it's a bit much to go through but we do have a um a page on our website in terms of the feature comparisons um for all our tears so feel free to have a look at those um and i'll add these links to the chat so that's the feature comparison and then we've got the training page as well um great so that's the last question thank you very much sama for presenting and thank you for everyone for joining in on tuning in um hopefully that was uh insightful and valuable to you uh just a reminder that the slides or the presentation recording will be emailed to you um within the next few days also um we're running our next webinar on september 16th which is around get ops so we hope to see you there thank you very much thank you thanks bye

Channel: GitLab

Views: 3,252

Rating: 5 out of 5

Keywords: Product, git, server, version control system, CI, Continuous integration, pipelines, git repository, Conversational Development, collaborate, integrate, integration, software development, tutorial, open source, on-premises git solutions, developers, programmers, code, VCS

Id: G1l56vDDqVk

Length: 60min 52sec (3652 seconds)

Published: Sun Aug 23 2020