DevOps and the Future of Information Security

cool okay I this is weird like I feel like I'm a singer on stage or this thing and I tend to use my hands to build a straight thing so I'm good so I apologize in advance clicker works so actually before I do you can get into this you saw the title DevOps in the future of InfoSec this is a huge topic I'm very interested in it because well I actually am a software engineer by profession DevOps is something that's very relevant right now I don't know how many people in this room actually do DevOps actually on that note I've done this talk once a DevOps tears kept on and I did it again at Microsoft's

community meetup it got better wasn't as good at the first aisle biggest challenge is times a lot to try and cover and I need ideally to have a understanding of who's sitting in the audience and like what you guys do because I don't want to talk about things that aren't relevant to you DevOps happens across the entire lifecycle of building software so or any system so everyone has a different role to play and everyone has a part to do in DevOps so can I get a quick rate at what one please participate put your hands up when I ask you to put your hands up don't be shy and then the the other thing is in who here are professionals

people who do software development for a living or IT infrastructure and who here are hobbyists people who are just interested in this sort of thing and I'd be sides because it's really cool so let's start with the professionals hands up okay what about half people here obvious I assume the other half that's not half okay so I'm going to probably focus more on professionals because to be honest this is actually primal relevant to you so what is my what about aim today we're gonna be talking about in general just things that I have been thinking about around DevOps and security in general and the software driven lifecycle and in particular what it really means to do

DevOps because I think that's like I don't know how many people did a jille here or know about agile development works but it was invented way back in like 2000 2001 essentially and there's a lot of this is a misunderstanding about a disagreement about how it actually works and DevOps I think is signed to suffer from the same thing so I think it's important for a whole host of reasons that we start to speak with a common language and we don't use buzzwords that's like I hate buzzwords it's useless meaningless and then of course we want to talk about like hardest day of doing DevOps actually affect or impact doing security and you'll notice I say data and computer

centric information systems I was that I saw interviewer function last night I don't if you know Osaka it's the information systems audit and Control Association fun was actually but I met one of the original creators of COBIT which is a party governance framework and we were chatting I was doing a talk he's one of the key key speakers and he actually made the point that technology actually isn't IT it's not just computer and digital based technology if you think about it and this is like I believe as well he's one of the few people I've heard speak about it publicly technology is a pin it's a piece of paper it's a filing cabinet technically speaking all right and

technically that's the kind of information technology I guess we can argue about the definition but I would argue that that's actually what it is and it is important when you're looking at this holistically because we're an organization trying to build software or any system you're not just looking at the a key component it's a huge component the especially building software right but it's not everything so if you want to be a secure organization it's important to take into account all the other physical aspects that can kind of an impact but I'm not going to focus on that too much I just want people to be aware of it so yeah let's let's move on okay coming back to the

motivation for my talk lots of reasons I think a big part of this is our industry IT industry isn't regulated quite as much as other industries you know you're not like an accountant or a lawyer or a medical practitioner there's no bar for us there's no psycho counsel there's no Med health professionals counsel for us there's an organization which I am a member of called the Institute IT professionals of South Africa they act in kind of in a similar fashion the difference is you legally mandated to be a member but I think it's important we are seeking to be more professional what we do because it has massive impact on the people who use our products I mean

you can have a website for mom-and-pop store goes down who cares guys down for a few hours it's fine no one dies but if I think V last year did a talk on pacemakers and how they can get hacked if you build software it's easy to get into that system you can kill someone you know if you're building a life-support system you need a bit of both saying that your bus that's that's gonna work it's not gonna fall over so depending on what you're doing how complex and harm power impact it has it's important to be more professional oops guys hand-in-hand idea that we want you know business needs software to be of a higher quality and need to be

delivered faster right if you want to be competitive we want to pull things that are meaningful we needed a quicker and like I say the DevOps philosopher Lassa fee enables that that culture enables that it's not the tool as I will argue yeah I think there's a an idea it's kind of quite pervasive that DevOps is about the tools that you use mark level does that help cool sorry singing can we turn the mic up a bit do you think that would help sensitivity I don't know all right well we'll just just shout at me if I do it again cool so I just like I said the philosophy is important and I think that's the crux and you'll see that's

the point one of the main points I'm gonna be making also I think most people here probably know this security is often an afterthought if not almost always in a lot of places and it's better to as they're saying nowadays shift left I think it is chef left closer to the beginning of your development lifecycle and right up at the point where you are the idea your ideation stage even when you're thinking about should I should should I or shouldn't I do this let's think about security right and coming back to one we need common language so as I say I'm quite opinionated about this stuff I'm usually right sometimes I'm mistaken then about that

but you know I just want to make the point that do your homework as well what I'm going to say today I've done a fair bit of research my job is required that I did I just have an interest in this sort of thing and I've been in a lot of meetups this year just talking to people I think on average I've done probably about two minutes a week since January if I include conferences and general meetups a whole bunch of different groups so I've got a few opinions and act a little evidence for things but check for yourself right okay and then as I said this is a lot of stuff to cover so Keegan's going to put up the

five minute and the 10 minute the 50 minute marks and warn me when I get too deep into this and I'm probably not gonna cover every last thing so maybe if this questions later you're more than welcome to Austin either one I'm up here if it's time left or we can chat afterwards all right so let's get to know each other what you guys have to get an idea that I actually know what I'm talking about and kind of where I am where I'm from just get over context I'm sonic or native from Cape Town born and bred been here most of my life that might be a bit of a joke for some of you guys first

language so I didn't he show his programming with Java back in high school jdk 1.3 yeah c-sharp Microsoft's McNair dev guys shut up krysta and even with pentium one with Windows 95 I can't I'm technically and if you're under 35 you're technically a millennial and that's sorry guys alright cool so that's basically a bit about me and then my professional background I made the mistake awesome of talking too much about where I've worked in their names it doesn't matter my point was ready to kind of give you an idea of where works and also to kind of inform that everywhere I've been the principles from what I've seen anyway they apply exactly the same way like it's not different for

different businesses doing different software development right but I consider myself a technologist I don't want to label myself a kind of developer or any particular role because things change so fast in this industry and also we had to solve problems and provide solutions and I think that's that's actually more important I've been a founder for two startups my own one straight out of high school got to venture capital funding very lucky did that for Miss ten years got a bit bored but other reasons started another kind of business didn't work so well and then I've worked for the last five years or so in kind of small to medium sized business as well as a co-op one or two

corporates FinTech document automation riveting stuff with SharePoint content management systems Public Safety software which I'm currently working in now a marketing automation and that's nice so quite a wide range of different businesses and I've worked in different heats team size as well tiny guys supporting the one place all guys just repeated across the world different cultures different languages different time zones I've been a full-stack Dave most of the time although when I was running my own business I had an Operations job as well so I had to do the finance and the marketing and the sales and yeah support and everything else but I'd be mostly focused on the web side of thing so then mobile or desktop

as much as I've done web and card base stuff I think that's where things are nowadays it's the most important software I could be wrong maybe there's some disagreement but that's what I enjoy this may or may not matter certifications and and degrees any matter so much in my opinion I'm a self-taught I straight out of high school didn't go to varsity or anything like that maybe another reason to check me but I have over the years picked up a few certifications so I am Microsoft certified I am a technically a scrum master and the process of doing the CRP which is I don't know does anyone know I see two I presume people in audience

must know them right security consortium I'm doing a application security certification and testing and I thought which I don't know on that note how many people do ISIL here at least know about it okay cool so a few I'm not gonna talk too much about it but it will kind of be touched on and I'm yeah yeah and then also I'm a member of a few professional bodies and kind of organizations so I was member a soccer member and Institute of IT professionals that's basically me so enough about me more about you so this is gonna be fun and you might laugh so he does sales and relationship management in this room we have someone

I'm impressed okay next one is your just marketing okay no fair enough offers in I mean make sense oops finance anyone okay I'm gonna try and move this long foster because I think I'm gonna take too long anyone in c-suite the c-suite leadership okay to people anyone else no yeah so three people okay human resources that business analysts big data analysts that sort of thing one I'm making a point yet I don't worry general admin like just that needs to get done no one anyone is a in a steagle personal wire okay cool so we get to the interesting parts now yeah okay I lied project protocol manager coordinator anyone anyone even just certified as a

project manager of any sort than its course no okay all right product manager oh no I'm gonna presume anyone yeah yep software architects there must be some in the room yeah couple software engineer okay cool test engineer anyone doing QA this definitely has to be more of you like again less and this somehow these other ones are more provisioning managing IT infrastructure okay cool yeah about the same one dedicated security compliance people okay well make sense anything else that I've missed that anyone wants to raise what are you vicars general that's an admin person okay the one-man shop you have all of these actually DevOps days I asked like who does x y&z in the same guy keep putting his hand up

for everything I'm like you must have a startup okay cool so let's play a game okay so for this game might not be the funnest game dev update it won't just looked at me funny Oh quiet but I have I have a button and you if you want to run up here you can call me out as well but I'm gonna call you out if you get it wrong so and I don't know if I only hear this hopefully you can I'm gonna ramp it to the mic but basically there's three questions true/false they've also need my technical stuff okay let's do it this way put your hand up so I can then I can you cuz

I don't know if he was saying wide right now true or false so who think true put your hand back up okay I'm so sorry not true you know I'll make the point now it's not so I think the answer sorry false true or false divorces are all who says it's true you're learning from me and you would be right to say it's false it's not at all true or false what he said Eliza you're very clever you want a job there we go Davos is a way of thinking about how we do work true or false yeah also a little bit obvious feel like I should just both press the buzzer button for fun okay cool so the point is

this DevOps is not give IT ops okay and that's why I ask the questions about who's in finance who's legal he's in Edmond who's an HR person busy sweet you find that terminology like words are being invented like dev those DevOps dev test ops ops dev dev sick ops and in a kind of a small context of a limited context I think it's true to say that yeah you could use the term if you wanted to write you can make it mean whatever you want but it's not practical that's not what it was dev ops was originally basically designed or created to do DevOps is a holistic framework what ideology philosophy right it's the dev side of things meaning

anyone who's involved with building software on a technical basis as well as the people who are part of implementing that technology that's been bolts in a production environment right getting it out to a customer and that includes the decision-makers two people who are going to finance your project people are gonna sign off on the legalities of it people are going to find resources for it people who are going to market it people are going to sell it they all have a say at the end of the day and if they don't there's a good chance you're not going to get the funding you need you're going to find that you run into compliance or legal issues and then the product is

going to be taken off the market or not a lot into the market or some other issue or you put in the marketing you'll get sued or something if you're not marketing it we're not getting marketing xinput they're going to sell the wrong thing and they're going to market the wrong thing so it's important that if the whole organization plays a role it's not just the technical guys building something and saying they got it done all right although there's a real big component of this talking about how do you take your code that you've built and put it into a production environment and often infrastructure and ID people well no one is what I do but

infrastructure people are responsible for that so alright oops the things that are associated with DevOps I mean this is just a very limited list but I think these are the common ones what does just look familiar people just our interest I mean does anything here stick out as not being right or not making sense you people in your tools [Laughter] wrong both very appropriate okay but I think going to that point oops you wanna laser point on this thing first time I've had this game backwards there yeah these things monitoring measurement empiricism that's that's saying that I think everyone understands everyone generally knows that's important when you do DevOps right that kind of goes Hana experimentation

automation also things everyone knows about DevOps things that people don't maybe think about quite so much or the continuous delivery okay that is kind of there but the things like three ways flow culture being lean and then the other systems thinking and I mean people might have an innate kind of understanding of these things but it's not saying that we typically speak about if you're sitting on the floor with your dev team or IT ops team or anyone else people experience don't tend to speak about those things it's talking about what tools can I buy to make my life easier what process can i implement in those tools and then I'm done DevOps is finished ok so what is DevOps really

so I've got a couple myths which I have pulled out from DevOps handbook which make perfect sense to me and I think these a good a good place to start to kind of understand what DevOps isn't what it isn't how many people here do agile who have worked in agile environments just out of interest to get an idea off so DevOps is if you go read the literature divorce is almost a natural continuation of agile it's not something different if the difference is that you've gone from building out software to giving it to the IT guys or the infrastructure guys to put it into the production environment right and so all they've done is instead of like

building the thing using agile maybe and then getting your artifacts prepared and thrown over the wall to the infrastructure people you are essentially working with them like a software team would with with the rest of their team and you are essentially building increments towards your infrastructure so as software's built out you talk to the guys say oh we need another server or we need more RAM or we need a firewall all we need whatever it is to to bother it out and a lot of that also automated so you both API is rather for helping devs to help themselves right so you're almost acting like an internal customer to the idea operations team and so it's actually just agile for

IT ops if that makes sense i tol I won't touch on the switch along but essentially the idea that it's not compatible most of the kind of things that are mandated nights or at least what I've seen so far are automatable like everything can be most of it can be automated you don't have to do this stuff manually it's a lot of it's just paperwork it's deciding what the process should be and how are you gonna get people to do it okay this is a more interesting slide I think the idea that give officers incompatible in four second compliance I think probably most people in this room would innately say that's untrue so it's really just integrated at every civil

live all the lifecycle I mean you've got I mean this is a diagram I got from company with check marks which does scanning of static code analysis and dynamic analysis and that sort of thing and they've tools which integrate directly into IDs and into your continuous bolt service and its deployment servers that can kick off scans and tests and that sort of stuff as you go right so it's saying that you can integrate something you do after you've bolt everything and then throw it to the QA guys and it's in security teams test it's part of part of what we do daily infrastructure people tend to be scared of this idea because they think that DevOps means no

infrastructure in their ops at all it's not true your job just changes your doing it slightly differently so there we go really the case you're collaborating more with people and much early on that in the lifecycle you're enabling developers with a BIS and other self-help tools so they can deploy code and monitor things themselves and you act as a service provided to the development team

infrastructure as code so I found this code for you Chris dude oh jeez this is like the perfect time to like make funny he is the Lee is the director of DevOps at aprea infantry company I work at and he was also speaking at a DevOps s conference and he sent me this and I thought it just made perfect sense because I mean I've never a meme so this is my meme for the for the talk everyone thinks it's tools it's not tools it's not as infrastructure develop you can use infrastructures codes and tools to achieve things but it's not the definition right I like this quote DevOps isn't about is about sorry DevOps isn't about automation just as astronomy

isn't about telescopes does that make sense all right I like that so what it really boils down to I think the gentleman over here not not watching what I'm doing is free on his phone it's terrible is it comes down to culture and I like to say it's it's it's about teamwork that enables efficient value creation because that's what we try to do the end of the day right we're trying to create something that people can use and they add value to their lives all right is anyone unconvinced at this stage because if you are that's those are the people you want to talk to you and the books you want to read Jays humble that read

watching him the other guys I don't know so much about but they seem to be the kind of originators of DevOps they've written some really fantastic books I cannot recommend enough that you read at least read the Phoenix project that book changed my perspective of software development in a whole nother level just reset me and it just like it's so realizable every single thing you do as a software developer someone working at IT is it's covered in this book all the pain and suffering you go through I mean there's Carrie that's a novel so there's characters you just want to punch but you can't because they're in a book but it's it's very relatable so please please don't make

the time to read it's not expensive to buy I got the audiobook if you like with your books go to audible one of those places cool so interesting part again where does security actually fit in security is fundamental by managing risk I think I prayed only to saw most people on this place on it and you'll never be 100% secure so basically you you could you could have a house you can have a little white picket fence and that's your security or you can be a house with a big wall and a guard dog and ADT and electric fences and you've got to put the things that you need in place to make your organization your environment

secure for the context you're in and you've got to work that out based on the kind of risk you have secondly mitigating risk is about maintaining integrity availability and confidentiality I think if you get those things right those are like the call security principles I think anyone who works in security you serious knows about this and yeah it's if you get this right at a fundamental level then you already covered I think most your bases and again this happens throughout the different pipelines that you put up for your develop and lifecycle so basically principles haven't changed that's another thing we're thinking about have those change no definitely not I like this kind of analogy I've gone

from this to something like that where does high tech now so it's the way we implement things that have changed but the principles remain the same if you get the principles riots you'll be fine so these are the kind of principles that some of them anyway I'm sure they're more that we can focus on I presume again most people in this room are familiar with these so I went I won't spend time on trying to define them explain them but if you have any questions more than welcome to ask and so again coming back to the point where do the compliance stuff where does all that fit in it's everywhere that's the entire lifecycle okay I'm a

key takeaways as I said I'm pretty much done now I think I'm doing right in time man primarily about culture of teamwork enables efficient value creation and it's clear principles haven't changed if you get those rights you can implement practically in whatever environment you in I think that's it questions if any how'd I do on time I don't lie probably probably yeah I think a DevOps day is over 35 minutes and I literally ran out of time all right yeah sure how many slides would you like

all right so it's a couple so I've been doing my certification for sorry terrible I've been doing certification while studying for certification with IC to the certified Secours software lifecycle professional certification and a lot of the servers covered in that course also a wasp it's a very good resource on that sort of thing so basically it's just a mix of these things but I find that across all the literature I've read all the studying that I've been doing even in things like I thought you find these principles are are they're like it's very consistent does anyone want ask any questions about what they mean

yeah I agree yes ah yes

hmm

right

yep yeah I I think that's quite true I don't think that the roles changed I think maybe companies might be trying to find excuses to cut down and they solve complement that could be very valid depends on the company I don't know all of them obviously but you're right like it's it's not a role and I find a lot of people are spoken to I've generally kind of hire more senior level management kind of levels don't like when I say to them it's a philosophy stop it with you're all like it's nonsense like it doesn't exist everyone does DevOps and they don't like that and they try and hire people who can do a bit of everything like you say

but what should happen is you should just make better use of the resources you have and do more with them because you can't that's all point it's meant to make you more efficient and to do more meaningful work and automate away the things that are menial and and they don't add real like significant value so I don't know how to solve that it's the sort of thing you kind of maybe have to have a discussion with your management or the people who are blocking that who don't agree either by forcing them to go and do the homework and read this stuff and then couldn't you know convince themselves or to have that discussion and slowly implement things that would

convince them at a time and then over time you get them to do it I mean I struggle all that as well I retain people who I work right now because also a start-up and sort of Suites you do what you have to do as well it's not you know corporally rigid structures in place yet so not that DevOps needs to be rigid you know you've just the minimum you need to do to be productive but yeah it's a problem I don't know there's anyone here who's maybe experienced that you would like to share their experiences on that night and add to this any other questions maybe

can I better give your mic

okay so just coming back to your question about sharing so the company I work for is a European based company but they call em a CSP when its services security provide a service provider and what we're doing we got I'm part of a team that does a lot of development and research and stuff okay so it doesn't really fit in with the core business process but what we are doing at the moment is inside that tightly controlled ISO 27001 process and all the other stuff around that we have our own internal team that we running on the dev ops spices well everybody in the team he's doing DevOps so and DevOps not necessarily what you're saying is the

engineers doing everything and the other guys sitting on the side but well you're involving all the people on the peripheral just explaining them the way we're working stuff it's a bit different from the external let's say core business we still have to comply to GDP our we have still have to comply to all the other cab meetings and all the other stuff they have but what we're doing is just we just orchestrating our workflow in a way that fits something similar to this and it's just not just not myself or my colleagues that doing one little bit everybody's contributing everybody's being involved from the monitoring team from the deployment team from the guys are doing the infrastructure so it's it

fits perfectly in that this is example we're doing is lots of mini DevOps inside a big organization and they basically leaving us to do our own little ecosystem a little sandbox because we can't just go through their whole process cuz if we just have to wait for them and all the process it takes too long if they're lying as that little freedom so it can work we have a little mini DevOps running inside a big organization as long as you just feed into their processes into their little tick boxes if I can it can work as well in that little let's say ecosystem

I agree with that I think again it's like agile I say adapt to your environment you know there's not like 100 hard rule it's just the underlying principle and essentially it sounds to me like you're doing DevOps as an organization because you you're only bringing the other departments and teams and people into the process of making decisions about what you're building you achieve what you set out to do how you do that in practice might be different yeah sure sure it I mean might take time and also depends okay so how big is your organization like if you've got thousands and thousands of employees spread across it's gonna be very hard to implement that if you don't have someone

at the top maybe forcing it down and I don't know how many c-suite people all that cleared up about this all that all that you know it's not a priority for them long as the work gets done and they can make money it's fine doesn't that be perfect although I would say everyone should be pushing to adopt the best practice so yeah cool Thanks anyone else with any thoughts questions I'm I'm pretty much done so I'll take as many questions as you have yeah I I've been through quite a few different employers and corporates and ways of working and there always seems to be things that work always seem to have a sort of common

principle and to me it seems to be communication yeah I worked on fifth generation languages of you know code generation stuff when I first came to South Africa in 92 and we were doing things like joint application development meetings and you got these users and you got your technical and you got everybody together it worked we as long as the team work together and people were on board and we communicated I've worked in an agile depart and development and again if you get a good team in people communicate it works I'm working in a very small company now where we all know each other and we know what each other does we communicate well and it works where it fails as where you

don't communicate and I think and that seems to be the common thread it actually for me it doesn't actually matter which system you use I don't know yeah maybe I'm a bit cynical about all these names that come up and it's like yeah we're going to call it this and and this is the way you must work but yeah I think you know if you get people on board and you get people who are passionate about what they're doing and you communicate things just tend to work it's yeah yeah I think you again you've nailed it I mean that's that is what fundamentally that culture philosophy of DevOps is actually trying to do its front implement processes that make

communication easier and better and you get people talking to each other more regularly more incrementally not just having big meetings at the end of things and what's interesting you talk about the names DevOps is a kind of an unfortunate name in a way it was Patrick Dubois who was the kind of first I suppose founder if you like or creator of DevOps initially and he did almost by accident because there was kind of a general consensus within the industry they think this is around Silicon Valley and Patrick do bars based in Belgium but point is that there was consensus across the Atlantic and so he organized the first Dave upstairs conference and they called it

dev ops days because it was they were they were like well we know that they have an ops there's a lot that can be brought together that we can do better we can communicate better we can be more efficient so let's get the dev guys and the ops guys together in one room and have a conference and talk about it and how are we going to figure this out and in inadvertedly he kind of invented that term DevOps it was just the typical IT thing we do we just take a bunch of ways that we kind of relate and we just put them together as an acronym or something and there you go new term so and it's

stuck which is another reason why I'm very kind of concerned about allowing words of terms like they've SEC absorbers ops dev or whatever like coming into existing because they didn't mean anything they become buzzwords and if they do have any meaning it's only in a very limited space so that that's not very useful I think for the industry as a whole I mean people move around companies I mean things I mean I mean most IT people suazo know and I'm sure this applies to other businesses as well in this modern age but people don't stay in a company more than maybe two to five years and more often than not two to three is so

when you when you leave are you taking knowledge and skills and language that can be applied somewhere else are you going to spend a year arguing with people at the next organization about what should be or just doing whatever they say and not being miserable because you don't know what they're talking about and again not being as efficient as you can be so I think it's important that we try and develop a more consistent terminology so I agree 100% yeah any other questions no MIDI you so much Ovitz a question or comment the psychological acceptability I'm guessing it's more under control so if you're saying here you will use two factor auth or you all have a password

that's 26 characters long and you will change it every month and then you can have the sticky keys etc cool can you tie that into DevOps there's a couple of examples or that's a real thing that's real thing I mean I deal with it like so we're using very good right now in our server lifecycle to scan Dussehra code analysis and dynamic code analysis or dynamic scans right so a very code and like a lot of their competitor tools they have a plug-in for your IDs we use visual studio.net house mostly and basically it enables developers to basically just scan directly into from the IDE now that's one more step a dev has to do and it's a manual step so it's

a bit like code review you know you put in a poorer case we also having to use get see windows house using gets crazy so you're asking guys to do another manual step is they got to remember and I mean people fallible human you get caught up with what you're building often you really like to be run yourself because you have been given proper specs upfront you you're not sure you're gonna meet the deadline because it wasn't reasonable maybe to begin with that happens a lot so you're more concerned about building something that just about works by the time you got to get it out and so every step you gotta remember to do like to just can do the

extra dev testing communicate with the Quality Assurance people like dedicated testers in that sort of thing it's just it's a problem so psychologically they don't accept it you know you want to pack it back there that it's hard to get them to just do it and every step you force someone to do it's it's you adding an efficiency in a way it's it's efficient in the big picture but in that little space they feel like what I could be doing the thing that I'm good at more than the stuff that you asking me to do so you trying to get convince him but I think any way you do that is to get them on

board the whole organization's aim and goal and that is to say well you're here to do your job yes and to enjoy it into the wall but we're a team and we're building this bigger thing that we're all pays our salary the end of the day and so you know you need to accept this as for what it is if you don't want to do that then you need to work for yourself as an individual consultants or very small company where the sort of thing isn't as much of an issue the bigger you get the more corporate you get the more teams you've got to work with the worse the problem generally so yeah just to follow

up on that same question and one of the other approaches could be you're going to take that step and automate it so as they push the code in because using it then it kicks off the get hook or something and kicks off the build process and part of the bulk process is to run it you know so in terms of tooling and automating and I think that's the other way to address at least the psychological problems you do you have to take them into account and that might be the reason why you do it that way I can ask another question about something else well did you on that note we do both so we sorry if there's one

might be user to pass it around - but I've got a spare mic no it doesn't matter basically we do both so it's part of our bulk pipeline or CR C D pipelines we do have integrations with verrico there as well so it reads directly out of our source control and then does a scan of the binaries and that sort of thing so we do look at that but it's also again comes back to this point about shifting left or doing security earlier in the last cycle the last thing you want to save to bold stuff and then be like cool it's ready it's integrated doesn't break anyone else's stuff it's in QA now and

then follow your QA or testing process you've got security automation test running and it's others like wholeness of vulnerabilities that could have been sorted when you were part of checking your code so we do both because one helps catch stuff that was missed and two were being more efficient and also getting people to think about the fact that you need to be doing security as well because security again on this night actually you don't have traditionally arguably you've had security organizations you've had teams which are dedicated security and it's not to say that there isn't a need for the stole but the idea that you need to have a security team doing all the security work it's nonsense because

everyone's responsible for quality everyone's responsible for security everyone's responsible for things working on that level and so you play a little role in that process so your security team then just does the last big stuff like pin testing and running these scans and checking the reports to see what's there and getting back to the dev team and saying I fix that so yeah both are important anyone else as a question I'm gonna give him a turn

thank you so I'm you've referred to a few times he used verrico to do code reviews what about codification as a principal codification so I don't I basically it is you've got what seems to be you know look I'm principals obviously but also the practicality side of it should be included in my view where you know the code that you deploying gets verified and checked that's part of a principal so yeah so ultimate may be actually right on that so it is about the vetting of the code from a sort of a simple repository of the proof and for example libraries so when you deploy you're using secure libraries and secure code would that be

considered as a principal so yes short answer yeah so having like an artifact repository in place where you can control what libraries and packages you have available to devs or any one organization that might use it it's important because when you can control security like what what time ago sounds that what what people can actually get access to from a security point of view but you can also control functionally what people can use it's also quite a nice plus so it devs like to try the latest and greatest packages not because you know it's more secure because that's got a feature that I need what fix the bug and you want to control that to some

extent you don't wanna like limit them every sprint like four months now you can't have the latest bolt and this is a really good justification for avoiding it because maybe some critical issue which affects the bigger application but you do need that that's one part of it and the other part of it is from a code review point of view when you do functional code and you're just making sure that it does its job someone should review that before it gets checked into your dev branch or your QA branch or whatever it is to make sure that it actually plays well and that you haven't missing you said that second pair of eyes looking looking

everything and again that second pair of I should also be security minded and I should be looking at it from the point of view of functionally but also looking for things that are obvious security issues I mean I find code reviews tend not to be extensive you don't find people enough time it's really a team lead or someone who's been given a the role for this week or this sprint to be the person reviewing and they've got their own work as well and so they don't really sit there looking line by line reading your code as if they were writing the code themselves so they give it a quick once-over and then a lot cool didn't see

anything crazy and it goes in and that's also a bit of a risk but it you're wearing a practicality between getting something art and you then can rely on things like your set of code analysis to hopefully pick up anything serious that's been missed or your customers eventually if the worst-case scenario

interesting anything anyone not using verka like a different tool or is it just a everyone using checkmarks oh really where'd you work Juma okay I think they got like two clients here it's a standard bank and probably Gmail I don't know it's interesting and no it's not it's not a judgment cool I hope that answers the question any other thoughts questions wrap it up cool you get along a brick thank you mm-hmm thank you guys okay thank you very much down so we're gonna have about a half an hour break the next talk starting at 10:30 okay see you guys see you guys at 10:30