Gartner®: Avoid Mobile Application Security Pitfalls

GET REPORT

Gartner®: Avoid Mobile Application Security Pitfalls

GET REPORT

Webinar - Secrets Management: How to Scale Your Tech Teams’ Knowledge

Join the webinar with Cédric Teyton, founder and CEO at Promyze, to learn about the unique challenges of managing secrets in large tech teams and the importance of secure practices to prevent breaches. Explore how Promyze facilitates successful knowledge dissemination within large organizations.

Video Transcript

all right i think that's it i think we are live hello everyone and welcome to this webinar uh my name is mackenzie jackson i'm one of the developer advocates here at get guardian and i'm super excited to be joined today with cedric titon so cedric uh welcome to the webinar and uh can you just introduce yourself for a little bit to everyone yes hello everyone thank you mackenzie for the invitation i'm celerik i'm one of the co-founder of promise i'm also the ceo of the company so promise is a startup uh french startup working on a quad quality and and working on a solution for sharing best coding practices excellent all right let me just share my screen here and we'll dive uh straight in so okay there we are that's what i was hoping would happen all right so just to let everyone know this is going to be a participation participation-filled webinar we want everyone to join in on the chat we have a section down the bottom called polls we'll be asking some questions along the way and we also have a q a session so if you are participating a lot you can win the chance to win a get guardian swag bag we will announce the winner at the end of the uh webinar and so and just remember in the ask a question section this is the best place to be able to kind of uh interact with us and you can also upvote other people's questions so if there's something that you want to uh to know someone else has asked then make sure you give that up vote so first of all while we're still waiting for a few people to join in let us know in the chat whereabouts you're tuning in from so i'll start uh i am in paris at the moment but i'm originally from new zealand cedric where abouts are you tuning in from from bordeaux in france bordeaux that's the if you're not familiar with france bordeaux is where all the wine comes from it's a great place to visit you need an extra long weekend all right so we have someone from india welcome noel welcome welcome to the stream where's everyone else from saint paul minnesota usa vietnam bangladesh bordeaux too yeah we have we have a another person from bordeaux denmark atlanta chile germany florida yeah a lot of places ah a lot of people from france fantastic another one from bordeaux excellence it's great to see everyone coming in from here right so we're going to uh keep moving through so today's going to be all about secrets management we're going to talk about the different secret management solutions that are available uh we're going to talk about some pros and cons of them and then we're going to talk about why this is so difficult to scale in a large organization and talk through how we can try and uh achieve this so in the poll center let us know down there's no shame in this we all uh we're not expecting everyone to use the best practices before the webinar but let us know how you're currently managing your secrets in your organization or for your personal projects are you managing them inside your get this could be uh with an encrypted file or with a env file using a cloud kms service like aws kms or aws sequence manager a vault or anything other let us know it's going to be very interesting to see how everyone is managing the secrets currently so just to get everyone on the same page we're first going to talk about what are secrets now if you've been to another webinar you might have seen this slide but this is the only slide that i have in there that's the same but uh when we're talking about secrets in software we're typically talking about digital authentication credentials so these are uh api keys these are slash kind of infrastructure keys there might be database credentials they could be your security certificates it's really anything that's been made to be used programmatically uh these are kind of collectively what we call secrets so these can be really highly sensitive but they also need to be widely distributed so it's a bit of a challenge when we come with kind of handling these and how we distribute these to all the developers that we have and we're working with so how do you store secrets so this is a really challenging uh challenging problem for the reasons that i talked about before so our secrets need to be kind of centrally stored they need to be tightly wrapped with layers of authentication around them but then they also need to be widely used by various developers they need to be used by our application by our servers so we end up with this problem with these sequels end up sprawled all over the place so uh cedric have you had much kind of uh if you have much experience dealing with these secrets in your team you're the ceo of uh of a software company what do you kind of see and and how these secrets are kind of stored on your perspective um we've seen many different contexts and different methods to um to to to share and manage secrets the one that we unfortunately see the most is a gnarly secret management system because this is something that developers share you know in slack or something like this and sometimes you can find these secrets on directly on the git repository so unfortunately i think you have there are so many teams doing like this and uh in in some of our contexts we saw some more advanced solution like volts but i think you will discuss about it later yeah what about you at git guardian how do you manage those secrets if you can tell yeah we can so yeah we use so we use volt we use a system called hachiko volt like a guardian but we also actually use a hybrid of other uh systems to predominantly vault but we have some some other systems in place which allow us to kind of share not sensitive secrets but still kind of in that category so we'll kind of get into that but uh i think as you kind of grow then it it what starts off maybe as a as a common solution ends up to be quite uh quite complex so if we look at i guess the types of of ways that you can store secrets so uh the one that that cedric just mentioned that he sees the most of is the kind of storing secrets unencrypted in places and we see a lot of people that store their secrets unencrypted and get so maybe a private git repository um in a env file and uh i mean the logic here is that it's private is password protected so therefore that's safe well i'll get into that in a minute but uh just generally please don't do this it's a it's a it's a bad practice to get into then uh we also see that i get it's a great central place i mean i'm sure i'm sure you would agree cedric that where people get is kind of central to all developers it makes it easy to share information yes so so when it comes to small teams and projects storing them and get makes sense or at least from a convenience point of view but if we can encrypt them we can add another layer of security but for for bigger teams for organizations i think i'll get into this too but this is generally not a great practice to to get into and then we start getting into some sophisticated solutions so secrets managers and some kms and and using using volts and uh so i'd say that kind of vaults what i'm call putting under the category of vaults which are kind of these dedicated systems uh they're they can be quite advanced and cumbersome to to set up so i mean cedric i'm sure you would agree and you've seen this you're dealing with uh sharing best practices in in the you know in your and how you're doing and what you're doing at promise you know these large systems they can be uh quite cumbersome to set up yes because um maybe we will discuss about it later but uh this is a huge uh system and you need to configure actually correctly in order to uh to really uh benefit from this tool and this really become like a central uh system um in your application because it manages all your secrets and uh if you decide to manage uh a vault on your own it's become really it becomes really critical so you need to make sure this is highly available and so on so this is a good strategy but you need to make sure you are ready to deploy and to manage the whole system on your own yeah i think that's a good point and we even had a question that before the webinar started asking for a kind of talking about this problem that vault is very complex uh very cumbersome to set up it's very kind of uh has a high technical cost to it to do it right and asking for some alternatives so i will i will get into that as as we go through but but let's have a look at some of the options that we had and go through why these these are kind of uh less than ideal practices let's say so the first one that we have up here is you know we have uh storing secrets inside your git repository say in a emv file maybe it's a config file a yaml file uh in these password protected these private repositories and this makes it really easy to share with your team right i mean i the convenience of this is fantastic but there are some serious problems yeah yes because as you say it's very easy to manage but uh i'm curious to to better understand why is it so much about practice well i guess uh i i think one of the reasons why this is such a common practice is that uh it's it's it's not widely understood why uh good repositories are not good for storing secrets so one of the main reasons is that when we're dealing with these highly sensitive and these highly sensitive strings we need to be able to keep close eye on where they end up and and where they sprawl to so we need to have audit logs who's accessed them and where they've ended up if they end up in your git repository it's going to be cloned onto multiple different machines so all developers working in the program project so immediately you've lost visibility over where your secrets are immediately you have multiple versions of this.env file and you know git keeps a history of everything so you know you could be a thousand commits down in your in your project and you may inadvertently open source twitch recently had their open had their source code inadvertently open sourced and you know deep in the history you might have some dot emv files that were once upon a time managed here so it's really important that when we do store secrets that we have auto logs on them so i i think but but the reason why it's such a common practice is i guess kind of a lack of understanding of why that of why that is particularly in junior developers and it's something that i used to do a lot of too you know i mean i i stand on my soapbox now preaching about it but you know i was once a developer storing secrets and git as well so uh i mean moving on uh we can store our secrets inside a private kit repository and this time we've encrypted our secrets so we have a ciphertext file that you know can't be easily broken and i mean and this and then we can share this and anyone with the master keys to this can decipher this so uh i i think what i'll do is i'll just show you a little guys if you're not familiar let's have a look at what this actually looks like so i have a a project here on my screen we have a dot env file with some these are fake credentials so don't try and uh don't try and exploit them but if we're wanting to share this.env file we can use a project called getsecrets and and we can create some files in here one thing it does to automatically add is a dot git ignore file so great practice to always have one of these but let's say we want to encrypt this.env file what i can do is add myself as someone that can access this and just like in a git i can i can add this.env file and then we can hide it get secret hide and what this does it creates this file here dot env dot secret which is just a kind of a binary file it's unreadable but we can actually delete this and we can share we can share this file in our git repository and then people that have the master key can then reverse that so then we kind of regenerate back our.env file but so this is okay it's okay if you're working in a small team it's okay if you're working on a personal project um i think any cybersecurity professional will tell you that it's not but as a developer in me will say that i mean if you're not we're not always going to set up a vault right so this this can be okay for storing certain secrets yes so does it does it means that if you have a like 20 or 100 of git repository this solution is not really uh suited uh for this context uh absolutely absolutely i think that you know we're really talking about kind of being able to share small projects because not only do you have to share this master key you have the single point of failure and your ciphertext file although it can't easily be broken right it's going to end up sprawl and again you have no visibility over this and then you've also got the chicken egg situation which we deal with in sequence management which is like where how do you distribute the master key so if you have remote developers you know so it's and then and then when you when you're talking about multiple git repositories it can quickly kind of get out of control and there is uh there is kind of like a hybrid system between this and a kms which is coming out um called sops and it kind of leverages uh aws kms to be able to do this and this is like quite an elegant solution but again it doesn't have that power that we're talking about managing secrets in a team then we this is certainly not the solution uh for that okay so then we can become a little bit more complicated and we can start talking about using key management systems and secrets managers so uh they're slightly different things like if we're talking about aws kms usually this is this is designed to store uh data and transit at rest but it can also be used to store uh secrets and then aws has a dedicated kind of secrets manager that we deal with so um here we have a similar scenario what we have where we have these developers that are connecting to the cloud provider and they're encrypting they're accessing this encrypted database full of secrets but we also have our services here so like our server can connect to it so i mean if you really quickly want to look at what to see what this looks like is that once our secrets are stored in our in our kms or our sequence manager in aws we can call this using an api and so and here i just have i'm calling the secrets manager and i'm asking for my aws secret key and when you execute that then it will return to me my secret value but there's an important component here when we're dealing with this which makes this so much more secure than anything that we've discussed about and that is because we can actually get rid of the developers the humans handling the secrets themselves so this is an important concept when we're talking about managing secrets at scale so right now our application kind of connects to the cloud provider through its authentication service and it can access the databases but there's a valor that developers never have to actually handle those secrets so this is an important step along the way of kind of reducing the human input into this and reducing the kind of amount of handling that a developer has to do on on their on their secrets so limiting limiting that does that is that i mean does that make sense to cedric does that kind of resonate with you and what you all have been kind of dealing with and trying to get through these best practices yes completely and i've seen um i'm not sure but i think also there are some apis that you can use there are some sdk implementation for gs java piton php and so on can you confirm that yeah yeah i mean and certainly in like different services have different features of this one of the great things about using a cloud provider and the built-in like sequence managers so as your application is hosted on uh aws then you know you you have this streamlined connectivity where you aws can provide you kind of code snippets and it kind of works very very intuitively and that comes through the problem comes though if you're using multiple services if you have something hosted in aws or different components hosted in gcp or you're trying to communicate with a gcp application google cloud provider then then this kind of all becomes uh it can all become quite cumbersome but uh there's certainly some great benefits and be able to get things connected quickly and when we're talking about the languages that we're using moving quickly kind of through these and getting getting everything set up uh quickly so we have one more kind of category and i in here and i've called this volts now volt isn't really a technical term it's just kind of yeah hashicorp vault was one of one of the first really purpose-built products in and of itself that uh that is used to kind of manage these secrets and we also have some competitors out there such as a keyless which is kind of like a sas version of of hashicorp vault and these can have these kind of manage what the secrets managers and the kms does but there's a conceptual difference where these are a dedicated like application in and of itself that you can host they're agnostic to the technology that you're using it doesn't matter if you're hosting it on aws or gcp this is certainly uh it's a lot easier to kind of connect all these different systems the problem is though that when we're talking about kind of hashicorp vault particularly and it's alluding to what one of the questions was at the start was that like these are very cumbersome to set up so uh you know a solution if you are looking for a solution to vault that has all the same features then a keyless is an interesting solution it's a kind of as i said the sas version of that but has a lot of the the same functionalities and then we're talking about really kind of some of the differences here is that i'm not going to list all the features that everything has but the one element that i really find uh very useful in kind of categorizing these this is concept of having this dynamic secret here so we have the same architecture where our developers are connected to our application or our server they're authenticated and to the vault which has access to the to the secrets but we also have this area of this dynamic secret so what that means is that vault can generate volt can have uh let's call it a master key to aws an aws kind of master key which allows it to create secrets of itself what this means is that when we deploy or if we're running live we can create temporary kind of access tokens so when we're talking one of the major things about kind of managing secrets we have to rotate regularly we have to kind of we don't want to have long live secrets and the best case scenario is having secrets that expire after their use and with vault we can actually do this so to use the example you know of what a lot of people do is when they deploy their application they generate their their tokens and when once the application is deployed again they remove those tokens and generate new ones so that every time you deploy i mean this could be every day or every week you're generating these new tokens and the old ones are expired so this is a really fundamental thing of when we're talking about is having these short lived credentials in here and the other thing is let's say that an attacker gets access to your server to your applications maybe your environment variables it's able to export them then we're able to really quickly and really efficiently rotate all these credentials uh and move forward and limit access there or same being said if they find old credentials so this is a you know like a a big problem if anyone's had to deal with rotating a large amount of secrets after a breach or an unauthorized access then it's a huge pain and you can break a lot of systems but with vault if you have this set up so that it it's auto rotating secrets uh in the vault and it's generating temporary secrets then you know we can solve a lot of these problems but uh very high technical setup cost in terms of trying to get this this running and you almost need kind of dedicated people to be able to run these like you can do uh certifications to kind of generate to kind of become a vault expert so i mean we kind of come to an interesting point and cedric this is where you're really going to be able to provide some interesting inputs because i mean uh if we look about if we look like this we've kind of almost solved secrets for all right i mean if we look at what we look at the architectures we just head out we have these dynamic secrets the developers never never never touched secrets so uh there's really no no reason why these secrets sprawl so i mean i was wondering do you have kind of thoughts you alluded at some on the on the start of why secrets if we're using this kind of architecture would still be released out into the wild i know i'm putting you on the spot but because you meant earlier i feel like it's okay i i think uh we can still uh one of the main mistakes comes from some human actions uh even if uh secrets are protected within a system like worlds you still have a risk that some human get the secrets and somehow share it make it public even inside the company in a chat chat tool like a slack or something uh you can't prevent stuff like this so invest yeah there is still a kind of risk unfortunately it is a perfect example because i i literally have the slide for the example that you just said is that uh getting secrets this way i mean we still need them as a developer we still need to test systems so you can imagine a scenario where you need access to the database uh you're trying to debug something you need to work quickly or you need to find information and going through this cumbersome process to get database credential from the vault uh can be horrible but if someone already has that then you can ask them to share them on slack maybe that person has kept them because they remember the last time they had to deal with them so we still have to have these these handling of secrets and uh you know not all secrets are created equally we like to talk about amazon accounts and secrets we like to talk about stripe keys and these highly sensitive things but there's also a whole range of secrets that we need a lot of access to they still need to be tightly wrapped and secured but developers need to be able to use them let's say a slack box token it's it's something that we need to physically have our hands on to be able to test test something we can use sandbox keys but we want to test it out when we're running as well so we're always going to kind of bypass the best practices approach to to be able to do this especially if we don't know the sensitivity behind it another scenario could be that you're building a feature you're working on a development branch you're building a chat feature you generate some keys for this you're not following the best practices because you don't know that it exists you commit this maybe it gets cleaned up but that uh but that pre-commit history still kind of get pulls in and that key is then exposed even if it ends up in vault and secured in there then it can still cause massive problems uh kind of moving on from that so then then we get to this this kind of next slide which is where uh i'm really going to lean on you a bit here cedric is and that is kind of scaling our best practices so i mean one of the one of the things that we have seen is that we have the technology we have the tools and the systems to be able to protect our secrets uh effectively and efficiently yet it still doesn't need to be uh still doesn't seem to kind of solve these problems and that is kind of because we're not all following the best practices junior developers may not understand the risks associated with kind of leaking credentials never taught the best practices in universities we have engineering teams that have no consistent secrets management strategy or don't fully understand the risk of of secret sprawl and there's these difficult processes being set up on how to obtain these keys uh this is a big one no central point of documentation who has had to write documentation and it's uh it's a it can be a horrible experience when you're writing internal documentation it can take a very long time uh and the minute that you finish writing it it's outdated so yeah you have to so we can have these outdated documentation and processes that no longer work uh and if we're not continuously updating that then that that can fail so we can bypass this and then of course we have a lack of tools to be able to do all these things to be able to uh not just manage our secrets but to be able to share best practices to be able to kind of have have these processes in place to catch them when the secrets leak so this is something yeah so i just wanted to add that indeed junior developer this is something uh which is uh constantly evolving because uh the all the severe security concepts are more and more taught at school and university and this is a good thing but most of the developers when they they have finished five years of study they have no no consideration about security and so they really need to be trained and we need companies really need to uh to focus on these people to make sure they understand what is a sensitive data and so on yeah i mean that's absolutely right we're getting where we're getting better at teaching this and understanding these concepts but uh when there's a lot to learn as a junior dev uh that first job that you get is pretty overwhelming there's a lot to learn at university there's a lot to learn when you're entering the door uh i don't know where managing api keys like securely it falls into this learning program but i mean it's a huge it's a huge risk but i mean when you're getting out the dates and you're getting ready to start your first job is it's not the first thing that pops up into your to your head all right let's have a look at the the you know i just gotta get screen open up in here okay so we have in the uh in the in the polls here how do you manage your secrets other is 52 so most amount of people manage it in other can you let me know in uh in the chat section how are you managing your uh how are you guys managing your your secrets it's gonna be really interesting to see but whilst we're waiting for that uh vault and cloud kms are kind of equal uh and we have another poll in here that i'm going to be curious about and that is how do we all share best practices in your organization so is it to use wiki tools do you rely on oral transmission do you have a readme in your git repo uh you don't have any best practices or let us know in the in the chat if there's if there's some other way that you guys that you guys share share your best practices and get the whole team team on board all right i'm gonna quit sharing my screen and i'm gonna hand it over to cedric who we're gonna talk a little bit more about uh there we are cool i found the right button so cedric i'm gonna leave it over to you and we're gonna talk about uh sharing the best coding practices and and exactly what you guys are trying to achieve over at promise thank you sorry it's coming yep okay so as i mentioned earlier promise is a collaborative platform designed for best practices definition and sharing so in a few words what is the the main concepts of premise well today we are mainly talking about security uh best practices how do you manage secrets and other developers developer how do you manage secret in your code you don't want to hard code some credentials some happy eye keys and so on so how can you make it so this is a this kind of best practices we can record impromise so i will just take a few minutes after to to show you the the tools i will be very quick but you need to understand first what are the main concept of promise so this is mainly a three-step process that will happen in promise so imagine you are a team of developers you are going to use promise uh with our set of plugins who have developed some plugins which are very integrated to developers tools like your ide or your web browser so you can use it in vs code for instance or also in gitlab or github if you are doing your code review and the basic idea is to identify easily in in your code in your project some example and control example of best practices uh that have been followed according to you or not so you are like contributing to promise just with a quick snippet selection and identify it as a best practice example and then at some point in the week every two weeks your team is going to gather all together and have a one hour session is that this is something we call a craft workshop in our context and the idea is to discuss about our best practices should we do like this should we instead do in another way and so we are building a repository of best practices that can be shared with other teams in our company and then the first step is the third step of promise is that thanks to our contribution promise is going to help us directly in your our ide or during our code reviews in order to make some recommendation of best practices because we are running we are learning from the code examples we have identified previously so this is a continuous process and thanks to this one we can easily enrich promise with some best practices so just to show you quickly how does it look how does it look like here uh on premise um i have a space from for my team okay so i assume the guardian backhand team is working with promise okay uh we are going to have a craft workshop here okay so just so that you you imagine how a craftworkshop happens this is quite simple uh we are we are seeing here some snippets that some developers have identified a few days ago before the the workshop so here in my context i have quickly identified uh some examples of best practices that i've named don't have code credentials for third party services identification so as you can see there is a huge problem here but i have some credentials that have been hard coded okay so this is something i may have catched using the promise web browser plugin okay so thanks to uh my web browser plugin i can simply do something like this right click and tag selection as a practice example and i can also do it with my vs code for instance so i assume in the same way as soon as i identify a good example which according to me doesn't follow best practices i can identify it with the promise plugin and again it will be sent to promise okay so you can do this during a code review process if you're conducting a code review and you're seeing something you can add that immediately into that that database of what's poor practice yeah as soon as you see something that's according to you has not been followed and could be done differently you just catch it with our plugins it will be sent supremized and we will discuss all together with our team during the craft workshop and so this is a concept and we are we are going to either validate delete the practices uh edit the practice if we are not really if we don't really agree uh about uh the the practice to follow so really the idea is to make sure everyone has the same level of knowledge or what are the best practices to follow so we're going to decide together how what to do uh how things should be done so i have in this example something which should not be done and i have another example of something that should be done according to me so if i have to use credential i have some preposition here to use some kind of global config that uh that contains all the configuration credentials and so on and there is something uh we were talking about aws kms this is an example of how we should use hydro vs kms in our node.js code for instance okay so the idea is to build a global config object okay with all the info by the database connection and all these elements are computed thanks to the iwbs kms sdk and thanks to this work at the end of the craft workshop i i have created some some concrete practices okay so in this example i have three practices if we take this one i can have a description and i will have some example and control example okay so we are building a repository of best practices with promise and you can imagine and then i can build like a public catalogue of best practices for my company so that everyone in the company new developers existing developers and the company will have access to this knowledge how to manage secrets in our code so that's basically the the idea of uh of promise i i have a question kind of around uh what we're talking about and you know managing secrets from that and uh because it all relates so much back to these best practices why is it so difficult uh or what have you seen why is it difficult to share best practices amongst your engineers amongst your developers why is it something that's really hard to scale specifically yes first of all within a team uh it's not really easy because um it's complete it's very complicated for teams to to find um a framework uh where we can discuss and have efficient interaction about our best practices how to improve our best practices and it's even more difficult within a company because you have plenty of teams and it's often agile teams with five six seven people within teams so you you may have in some companies dozens of teams and they are not working together every day so you need to find a way to to generate technical interaction within all these teams so that they can uh discuss together um what are what should be the best practices how how are you doing um how do you manage secrets in your team and so on and so it's very hard and that's why more and more you can observe some a community of practices that gather some developers that are very interesting in some topics like security javascript uh whatever you want and it's very difficult because we are mainly focused on our team on our project every day and um the the global you know uh aspect this uh this global perspective on uh what should be our best practices in the company who should decide uh of these best practices and how to to spread to disseminate this knowledge to into every team this is something very difficult actually yeah well i think that's evident in what we see and kind of i mean i i'm obviously focusing on secrets management but it's something where uh i mean if you have the tools and you have the best practices the problem shouldn't exist i mean of course we know that it does because uh because of this but i mean and that's kind of why uh what i love about promise is this that it uh uh as someone has had to write documentation i love that it can kind of be an ongoing task forever and not to not just kind of horrible daunting thing that uh of of maintaining these best practices uh uh throughout uh i have one more question uh when we're talking about uh managing best practices what what can promise really be utilized for or like is it is it can it kind of kind of replace the internal wiki completely can it uh does it kind of circumcise the the other elements like what what what can we really use you can leverage it for promise actually can be used to record best practices um that really related to to source code test code it can cover a large wide range of best practices so we can define some some best practices for clean code architecture and some design patterns some rules related to security accessibility green id performance tests unit tests end-to-end testing and so on so it's very we really can cover many aspects of best practices so this is mainly the main goal of promise well we are not here to to replace uh some technical documentation about uh about the code how it works and so on it's more how you should do such thing and what you shouldn't do and uh this is something it's which is very hard to to maintain as you said because you're constantly evolving your your methodologies your ways to to do search or something to implement search or such thing so um we really try to add some some features to to make this repository up to date and make sure everyone in the company has a the right knowledge of the best practices to follow all right so so in a way if i understand correctly kind of extrapolating some of the best practices out from this documentation making it much easier to update maintain and share within the organization yes because it's very integrated to developers ecosystem all right so we're we're we're coming down to the uh to the kind of more q a section uh in now i know we had some problems with the stream i think some people lost us but uh i think uh i think it should all be back to normal now i'm not sure what happened i was getting messages uh but let's have a look at the poll uh the the winning the winning tool of how we share best practices in the organization is with internal wiki tools which is unsurprising and uh and to be frankly from from everything that uh cedric just said uh the goal is not to kind of replace these completely the goal is to extrapolate some of the the best practices and make it easier to update so uh very interesting thanks for everyone that's participated in that poll so i mean just before we get into the the q a section of this uh i want to talk about kind of combining some of these things together so i mean how do we scale secret management so we know from what we've seen that that using the tool that having a kms having a vault is not enough uh the solution itself we need to to build on so it's a very important part of component but we also need to add uh be able to share best practices so something which promise can do to be able to kind of create this and make sure that everything maintains updates a very important element of being able to share that information in secrets management uh and then we need tools that really kind of kind of enforce these and catch this so obviously get guy in if you don't know about uh get guardian we detect secrets in source code so we can do this uh on the developer side so we can scan commits before they reach your git repository if there's secrets in there we can block it so this kind of like it enables people to follow the best practices that have been set up using the tools like from eyes so this is really quite powerful particularly for developers and then the last step that you need is that if we do all of this perfectly we're still dealing with humans and we're we're not going to be able to capture everything there's still a human component in here so secrets are going to leak particularly in large organizations so we need a tool that can scan these uh in real time to be able to pick them up and that's the geek guardian's core product is being able to scan public and private repositories and alert you when you have a secret that has been leaked in there so that you can rotate it and move on and the earlier that you pick these up the less of a problem that it can become because yeah once once an attacker breaches into a system then uh that then we have a multiplying effect of the amount of systems that we need to then kind of go through and work out so i mean just quickly on git guardian make sure you check out some of our developer tools so on our client side that we can help with developers is we have a tool gg shield so there'll be links for this there's a takeaway document that i will share in the chat where everyone can can view further readings but gt shield is a great tool it's free uh you can install it in your cli and it will automatically scan for secrets when you make your commits and then we also have free versions of our server scanning which you can plug into your github account or gitlab account and immediately scan them and detect secrets the most important thing is that you're going to get visibility over these secrets so i mean this is what that product looked like it's a sas tour and it's a sas product and you can sign up for it on getguardian.com so with the sponsored messages out of the way uh we can move on to some questions so we already have some questions in here uh quite a few actually so uh first one we kind of already touched on hashicorp vault is really complex what are some solutions there so i mean achilles is one that i mentioned but uh there's also some others that have been come up here uh like keepass and and other areas so i'm not here to tell you which solution is going to be the best but there are solutions depending on what you're after hashicorp vault is a fantastic product that's open source but it's cumbersome to set up there are alternatives out there and i think you really just need to look at your situation and what features you're looking at is it acceptable to have a sas platform manage your secrets such as what ak-list does or do you need to have control over that data and and so on so uh here's a great question um that i see that you've already seen this that it does does promise to detect any best practices there was not followed on its own or doesn't need to be trained with some examples so uh i mean what i like about this is that i think this illustrates kind of the partnership uh between guardian and promise is that uh uh you know like we're where there's there's setting up best practices um and be able to share these and and find out and then also uh using tools like gg shield to be able to kind of detect when these in case the secrets have have you know do you have more to add to that i know you you're looking for an example in that is there any more to add about the kind of promise solution to this question no i think you you you're completely right and indeed we were providing some recommendations for developers while they are coding but then uh clearly with uh ggfi chief and guardian in general you have clearly a really highly efficient solutions to detect some best practices related to security leaks and so for other kind of best practices promise just we just need some examples at least once to start providing recommendations for over topics like your clean code or something like this great yeah that's really cool so another question that we have in the air um do we do i consider do you consider hsms as vaults so hsm stands for hardware security module uh something anyway it's a physical it's a physical heart piece of hardware that encrypts information so uh the the the the answer to this is kind of i would consider it possibly a component of a vault or even a secrets management system so for instance aws has what they call their virtual uh hsm so we're the you know where i i'm and to be honest i'm not actually sure about the integrating of what products do you want but i believe that aws does have hardware components in how they store their secrets so what i consider the hsm i i wouldn't consider it a vault and a vault is a category that i kind of made up based on some more advanced uh features because uh they all had the kind of word vault in them uh so i think this comes down to what features would be important for you and what would you consider so i would consider if a hsm i mean if you're really serious about some encrypted information then you're probably going to want to have some hardware components in there and then you can actually integrate these into two different areas you can integrate this as part of your vault for using hardship for example but i would consider it a component of and not necessarily a vault in in itself all right wilder session have a recording available later yes we will you will be able to listen to this session after after okay so promise still doesn't stop developers to share credentials on slack or any third-party applications right so uh cedric so this is a again again this is kind of about the the combination between what promise and get guardian can do is you need the tools to be able to uh share best practices so everyone knows what to do because no point in putting in place tools where no one knows what to do and then you need to have something else that will be able to protect it so this is something that get guardian shield gt shield uh what we're getting can do is be able to detect these credentials uh when they see it we have an api so if you want to uh if you want to be able to create a slack bot or something that scans your slack messages you can do this using the gegardian api and we have a free tier and all of that all right i think we've got down to the oh here we are one last question when should we use vaults and not secrets managers that do not dynamically uh change the secret keys so yeah so firstly i think it's important to kind of say that not all secrets can be dynamically changed what you need is you need a service so aws is a perfect example of that where you can have a let's call it a master key that can create other access tokens so first of all we can't always do this so we're not uh and i think like when should we use a service that does this and when should we not it's a very like it's a very challenging question if you set up a sequence manager correctly um you know like uh and we do all this then you're already taking a huge step into kind of managing your your credentials uh for that so is it like vital that we use dynamic secrets it's better but it's you know if we're if we're moving from storing them in a env file in a private git repository and we get to secrets manager then we're already taking a good step along the way and we can already implement really good practices uh for that uh so i think that's a yeah so i mean a kind of a political answer in a way i guess the uh i guess there uh for that so that's i guess that's what we can do now uh i think it's important to note that promise has a 30-day free trial is that correct yes yes to check out especially uh to try and see if you can share these best practices throughout it's certainly going to speed up that education process when you're using it and if you're going to invest the time in just setting up these complicated sequence management systems uh not all of them aren't all of them have to be but important to be able to be able to share the best practices of how to actually use them uh so make sure that you're signing up for the promised 30-day free trial to check out from there so there is uh i have created a keep learning page and a takeaway sheet so uh zead my my my man in the uh chat if you could share the link to the uh to the to the takeaway sheet or the takeaway page that would be great so then everyone can check that out uh and be able to kind of continue on if you're interested to learn more about promise if you're interested to know more about secrets inside git or what guardian does or how you can set up a pre-commit hook i kind of compiled a curated learning list if you will uh in there that you may be interested to check out so he has posted that in the chat for everyone that's interested all right it is that time it is time to announce you know of the swaz bag so i think that uh we should have uh a solution to that let me open up my analytics page and find out for one one minute about where i'm building the extents i'm doing the the suspense so the winner of the sway bag is rahul luther i'll post this in the uh the chat here of the winner so congratulations uh if you could send me a a message uh to my email address uh it is this is congratulations jackson at gegardian.com um and i'll message you directly and we can organize where that's essential so congratulations rahul uh uh i hope hope you enjoy your prize there so we have another webinar planned uh already so this one is going to be on the 8th of december november can be a bit of a busy time for holidays so and this is going to be about maintaining code security through code quality and we're going to be doing this with pony code so we're going to be an awesome chat you can already register for that now uh so they'll be great if you guys can do that and add that to your calendar and other than that i want to thank you cedric for for being here i just realized i'm not sharing my screen so hang on i'll put the evidence yeah that's the question i don't know if you saw uh no no no let's do it last question from vance should you sell to management the implementation of a secrets management solution first versus selling a secret detection solution first i think i might well i i really uh interesting question i think what what vincent's saying is that which is what should come first should you manage your secrets or should you detect them and i think that you should manage secrets uh first get together uh a really good sequence management system uh together and have a good way of best practices and then then you need to layer on top of that uh sequence detection but i mean it's it's very important to make sure that you have that all set up uh as well because the whole point is to be able to try and discover where and when secrets have leaked but then we need a way to be able to prevent this in the future and without a sequence management system then we're not going to be able to do that so yeah i mean interesting point what what should you do first i mean the first thing to do is to always set up your uh your sequence management system but i mean if you're a small team setting up sequence detection it takes about five minutes uh it's very simple to kind of put that measure in place so i wouldn't categorize it as uh if you know what first and i think that i mean particularly guardian we have uh we have uh free tiers for small teams under 25 developers so if you fit into that then you can get our full business plan for free and it's very easy to set up so i mean not to turn into a salesman but yeah but definitely i mean of course set up your sequence management system first and have best practices in place so yeah well uh anyway guys uh that concludes the the webinar so thank you so much for tuning in uh congratulations rahul and i'll send you a message directly and uh get that swag bag delivered to you thanks again cedric and have a great night everyone thank you everyone i thank you again mackenzie and for the invitation see you soon