Jeroen Willemsen: OWASP WrongSecrets: How We Keep on Growing Our Open Source Project

In this talk, Yon Williamson discusses the OAS Wrong Secrets project, which aims to educate developers on the importance of secure secret management. He explains how the project serves as a hackable application that illustrates common mistakes in storing secrets. Yon shares his journey in open-source development, emphasizing the challenges of maintaining such projects and the need for community involvement. He highlights critical lessons learned, including the value of consistent coding practices, automation, and fostering collaboration among contributors. Ultimately, he encourages developers to embrace open-source culture and understand that building and improving projects can be a rewarding experience.

[Music] hello everyone and welcome to the security World stage here at cyber wise con uh this next speaker I'm going to say I'm uh I have some Insider Insider knowledge to the to the next talk I've had the privilege of uh talking to uh euron villman before and some of the amazing work that he's been doing with the oos foundation and in particular on his project wrong

Secrets uh but I will not dive too much into this instead uh I want to hand it over to the and himself yon villman who's going to be taking us through uh the OS wrong Secrets project and how they've managed to keep this project going and some of the great insights that you can use it for to help uh your developers understand some of the security risks

around secrets so you're wrong I'm going to hand it over to you oh I almost forgot before I do please make sure everyone that you participate ask questions in the chat panel or in the Q&A panel um this is is now your opportunity to be able to talk directly to people like yon so yon welcome and I'm going to uh shut up and you thank you so

much for the one welome McKenzie really awesome to see you again um so hello everybody Welcome to my talk uh all wrong Secrets how we keep on growing our open source project if you're wanting to build out an open source project yourself you've been wondering like how do I do it what should I do um what should be my idea well this might be a talk just

for you to get at least my perspective on my journey that have a from sequence um let's go let's see if all the nuts and bells work y there we are so about me I'm Yun Williamson uh I am a project leader of all secrets I'm a principal security architect at a large technology firm next to this um yeah if you want to know more about me

feel free to scan that QR go to all my link.com SL Community where you can find my GitHub my blogs and all the other stuff all right so um if you're already in an open source project um you might you might well these two pictures might actually talk to you one might be the first one where you see the guy pushing up the hill you might just

feel just like that that you're the only one contributing right now and you're trying to make something out of your library or your tool or your ation it's so much work the other thing might as well that um while you've been working on it you might just feel bored right now as in why do I have to do this why do I have to write the test

I don't like this one bit if that's where you're currently at with your project stay tuned because it might have something for you and don't worry many people in open source feel this often even if you're in a large team it might still feel like you're pushing up that hill with the big boulder um and even if you have a successful project or whatever you might think

of successful but successful to your own standards you might still feel bored about the project that's not a that's not a bad thing that's a completely normal natural thing to feel so for me I first worked on a very large project like the OS mobile security testing guide and I did a lot of stuff over there but at some point there was just so much involvement of

different things that I felt like uh I had to keep on pushing that Boulder and when I stopped doing that I realized as a very busy PSA that I needed something else to do I needed something outside of my work to solve puzzles to help others but not to feel the pressure to do stuff timely like in might you know any security day-to-day job so I wanted

to have a hobby to keep my sanity besides all the hacking advice and architecting that's the hobby you're currently looking at well in a minute that is this o BR secrets so what is O spr Secrets let me quickly try to summarize that so overr Secrets is a hackable application that gives you um insights on how to not store your secrets we currently have 46 47 up

coming challenges where in each challenge we try to show you one way how you could make a mistake with how you to store the secret you might think of yourself what 4 challenges that's a lot how many mistakes can you make well we got many more that we would like to build out and all of them I've seen in real life while either being an internal employee

somewhere or being a security consultant and therefore being security consultant have been great because I've seen so many companies with so many employees having their own ideas of how to store secrets that we have this great data set to work on and luckily we also have many people that contributed with ideas that they found in the wild even with articles uh where companies got compromised with their

um wrongly stored credentials or compromised credentials um because of the way how they got stored so to the left you see the logo to the right you see the entrance page and the bottom you see the contribution history there's this funny l in the beginning and then there's this empty space and then there's lots of contributions we'll talk about that in a moment so what is wrong

Secrets wrong Secrets basically has the following architecture it has an appco with some config on top which all runs inside a Docker container next to that Ducker container we got a bunch of other things in there you can see go C++ rust and soon.net as well uh which are just all sorts of binaries we packed inside the container so we build those out ourselves um and we

try to hit Secrets inside and then we have challenges in which you can learn how to reverse engineer the binary because for some reason there's plenty of people in this world that believe that if we cannot read it just in our text editor it's safe whereas there's so many decompilers that will allow you to uh actually see the inside of applications and understand its logic as well

as find the symbols that are used to represent the secret and convert it to a human readable secret um that we figured it would be great to have those in so that Ducker container then I it can run on Heroku which you can currently see for instance let me quickly share another screen let me oh share screen here it is so here for instance you can see

wrong Secrets running on Heroku so this is a Docker containing running on top of Yoku where we also have those binary challenges I talked about earlier so for instance over here we have web three oh here we are here's a bunch of binary challenges and after that we got inspired because we found other mistakes as well to write more of these binary back yeah so here we

are so all of this can run on a kubernetes cluster and then we can also provision Vault because Vault has a great open source variant for which we're very grateful if anybody from highi Corp ever watches this thank you so much for highi Corp fold open source we really appreciate your effort there um and this is a great SE management solution but you can also configure it

completely wrong and that's not necessarily um a bug it's uh how you are going to use it basically uh if you use it the way that they describe to do it in in their read me and documentation you'll be fine luckily we found many people to not do any rtfm at all and just blindly start using Vault and then do lots of funny stuff in there so

for therefore we also have a bunch of Vault challenges all that can really this and you can r on Mini Cube we also Pro provide terraform code for you to have AWS and G P or Azure covered so you can have a full experience in the cloud um next to that we also have wrong secret CTF party which is a fork from OS multiuser where you can

actually host your fully automated um uh CTF together so then everybody can compet to each other and you also have ctfd hosted inside the platform so you can keep your score over there it's a wonderful game all right so how do we get there we get there of course by first finding uh a reason to start why do you want to um why do you want to

have an open source project is it just do you just want to experiment with something because that can really be a great basis if you want to play with some check feel free to create a GitHub repo or a git lab repo share it with the world while you're committing your code if it's all messy it doesn't matter it could be a great start of an idea

for yourself that you would like to share with others easily it could also be your journey to learn something um so for instance some of the tech inside our project are really there because I wanted to learn about the technology and if you look at my commit history I'm sure you'll see where that was um but what about proof of Concepts some of the best open source

libraries all started as a proof of concept because you had a brilliant idea and you wanted to just create a proof of concept and see what happened or do you want to create something to teach um so for me the very early start of wrong Secrets wasn't necessarily about me being bored as BSA it was me wanting to uh speak at all day devops um but I

didn't know what type of topic and then a colleague of mine told me like hey we got this secret automation provisioning pipeline which might be a great topic to talk about um and we figured yeah that's actually a great idea um but then I only needed some examples to show why it's better to automate this than to let people make something by hand and that's where the

first seven challenges of over secret wrong Secrets came from wasn't as pretty as today it was B ugly like just plain H text on HTML page but it worked so one year later I wanted to pick up open source work again like I told earlier because I got bored I got over mess and over stimulated at work so I needed something else something creative and that's where

I figured okay let's let's pick this project up again um so yeah why not use this to teach people stuff and at the same time you know experiment with various Technologies I haven't been playing around a lot with so as you see um till now we really spoke about this from my own perspective what do I like what would I want to do with it and that's

really what i' would like to invite you to do if you're stuck in an open source project or if you're uh really wanting to jump into something just go for it try it out if it feels good continue if it doesn't feel good stop it's that simple no it's open source nobody expects you to do anything um and when you start try to get feedback very often

for instance share this with friends try to find um what their opinion about uh your idea about your concept or about your first proof of concept when I shared mine with ban and Madu aula uh and n and all of them really helped me out greatly because they love the idea I also shared this with my non-technical friends and there is even a challenge which we always

doubt the the case challenge which is about having a shorter password on your password manager because even you know non-technical folks might actually be very interested in what you do as your friends or whatever and actually might give you the best feedback ever to make it usable for other people and the only thing you have to do is share about it talk about it be be transparent

about it and if that works um and you got something working share it with more people just send it over to the people where you think like they'll be pretty um either pretty happy about it or they'll be very or or send it to people that might have a lot of criticism or feedback or however you want to call that because you know that they have very

high standards of what they think is good that doesn't mean if they're against it you should stop it just gives you another perspective of your idea which can be all great all um and once you did that try to work together at a solution don't be that guy that push the boulder by themselves try to find people that really are interested ask them to help you you

don't need to be single hero and if you're an open source for the money I'm sure you can but at the same time I can really tell from experience it's very given by itself if you could just have a good time with friends while working out some on something um and then when you work together at that it's very important to understand that um uh uh there's

all sorts of feedback of course people can shout in your face um this is not nice I don't like this idea at all well it's your hobby time not theirs they're not paying you don't worry about it let it go if everybody feels it's a bad idea and you've lost your motivation for free to stop but don't let it get to you doesn't it's not required um

and then of course you can also have other types of feedback like hey um I don't like uh the black color of the background can we have a white one because I I don't like dark screens that much again it's your project whatever you feel good about just do what you like to do um but then of course um it's always good to to to listen to

them in terms at least to see like hey does uh do the people you want to work together have a point for instance um when I worked with Nars you saw me um making a bit of a mess of my spring boot controller it was like that's the old way of doing this have you looked at this new type of rest controller you have far less codent

try it out if you don't like it I'm happy to help you on your old one but maybe you like this instead and it was really my 160 lines account just became 12 and I was like wait I need to do this more often I love this um and and even better um try to also stimulate people around you to to have that same productive way of

working with you Food For Thought can be great help but even better can be asking volunteers to just give PRS so that's what we asked in our friends and volunteers and they all come up with either very well educated issues or they come up with a very nice PR which basically either solves a problem implements a very nice Improvement or other stuff um in all cases it's

very important that you even during those PRS um ask their feedback on what they want this why they think it's a good idea why and also check in if you think it's a good idea you can also do this the opposite way around if you feel like hey I need to update my library or my project file an issue for yourself if people really think it's valuable

they love to work on it if they don't think it's valuable or if they think it's tough they might just you know step back a bit uh but you can also ask your friends and uh go contributors what do you think about this issue or you think about Mak your a new PR so together you build something where everybody feels of and all in all most important

thing is focus on something that can be finished whether you file an issue or whether you create a PR make sure it's really something that has a beginning and an end not a 160 file change PR but something that takes a consistent amount of work uh and brings to the next level um and always go back and test yourself is this good is this idea good enough

to invest your time in do you like the idea do you like to work at it maybe I should have capitalized work as well because you're going to be the first one if you like this to work on it because somebody's got to do the work does it give purpose does it bring value for others did other people like your idea um and then you can spend

your time on anything you can try to recruit people to build out J in here you can hire people you can do stuff you can build test or you can try to be a coordinator but to be fair if you build your PCC first your MVP later and you want to make progress make sure you are building a lot don't let other people do the building themselves

because they'll you'll be disconnected in no time try to understand what you really need and try to see how you can build it anybody can build software really anybody the moment you can read and write you can start learning how to build software or with no code solution you don't even need to understand code you can just go for it just go for it but make sure

you build them L I think that's very important um in compose and reuse don't reinvent the wheel yourself remember that spring boot rest controller example I gave I use a lot of Frameworks in my software I use a lot lot of third party components why because they already did the job for me I want to maintain as less as possible while making sure it works um so

make sure that for your idea you find suitable building blocks and tools if you feel like yeah but my idea is so new there's no component ever done this before try to think of how do you materialize your idea and in that materialization you all share the same thing because you're going to execute it at some device where already people have wrot software for never forget about

that no matter how special you are or how special your idea is it's never too special not to have any third party stuff unless you're doing an open source project like building your own GPU I'm sure even then you'll find libraries you use and try to scale up with automation stop correcting yourself have LS inside uh as many as you can for the languages you're using for

the Frameworks you're using and stuff like that use something like pre-commit so here you see a beautiful uh PR from lus again thank you so much for this sir you're really were a great help to our project where he found a way to reduce the code per tremendously however there was some stting stuff that wasn't very well in his cat yet so with promit CI light the

linters were applied automatically and the pre-commit hooks were fired and the corrections were done automatically and then just committed to get inside the same PR that way I didn't have to bother Nana with I'm so sorry I can't accept your PR because there's some mismatching format in there's too spaces in the too much we don't want to waste time with our volunteers doing that it gets fixed

is for you so make sure you automate stuff have as many test as you can because people will try to help you out refector stuff so make sure you have unit tests and lots of them make sure it's also easy to change your code in such a way that the overall public testable surface won't change that easily so your test can be stable also make sure you

have integration tests because integration tests can help you to see if somebody Vector um component a whether component B would still work don't forget to have stuff like endtoend tests this can be very very valuable because overall that will really be a chall over time to um to make sure that everything really works so we're using Cyprus and it's been very helpful to see whether the application

still does its job after uh you committed uh another change and make sure you run all these checks on all the BRS have stuff like Security checks so we have for instance um uh we run jaap uh uh desk scanner every uh on every PR we run various other checks we run all these linters and we do all these different types of tests the whole time whenever

you do whenever you're done with something so on our PR for instance we test if we can build out a container based on your NE code change we test if that container will will work well on our kubernetes platform uh um and we do all sorts of other tests this really helps us to make sure that whenever you create a new challenge or when you um uh

uh refactored as part of our implementation that every thing will still work um and we also for instance automated dependency management so we have dependencies for applications for GI up actions for Ducker container for terraform for our unit tests our cyp end to end tests but also in our precom books we also have dependency if you can manage all of these through dependabot you don't have to

uh run after them yourself it can easily be fixed by uh Dependable or if you're on gitlab use renovate just use anything to automate this away the nice side effect about this is is that this is automatically becoming a heartbeat for your for your application because depends will file new PRS for instance here you can see that we do a daily check on to get the actions

because we have some more sensitive actions um and we do monthly checks uh on most of the other dependencies that means your project will at least get new PRS every month so at worst we only have contributions on a monthly basis but still the application won't die as in it won't look like an abandoned system all together because all you didn't have to do if you did

all the other stuff correctly like the test the linting ETC is make sure that your application remains compatible with those new dependencies and then just um change the application where required merge the PRS and you're done so that's automation that's all on the provisioning side of things now the negative part where are my users when I started this out there were no users nobody cared I mean

sure I was fun uh as in all the develops um and and some people watch the talk but it's not like they're going to wait for me to create an application or something because the internet is full of ideas it just continues all the whole time so when I picked this up again nobody knew about my idea I had to you know uh uh talk to people

and it's fine I mean uh you can start with your idea without anybody knowing about it or wanting to push it forward it's not a bad thing it's okay um and no one might initially care about your idea either so when I talked about wrong Secrets the first feedback I got wait can't we first have a Secrets management cheat she in no but actually shows what we

have to do or can you write a block on better practices because we don't care about the bad ones um which is fine uh right but one doesn't go without the other it's fine to still have bad uh ideas next to the other one so in the beginning you might not have any users don't let this get to you it's not a problem just have fun building

out what you want to build out and if your idea is good the users will come eventually and people will like it in fact well I hardly saw any consumption I then read on Twitter that a bunch of people were very happy with the project I was like wait what people actually are excited about this that's so nice um but I never knew until you know um

until those people started mentioning it and we saw it Al in good the traffic of course after a while but it just takes a while so again enjoy the ride even without the users you don't need to create something necessary has value for others make sure you first build something out you like that should be your starting point I know I've said like this is like the

third time I'm saying it but if you like what you do please continue doing it it doesn't matter what other people say about it if you don't feel right about it but somebody else says like you should do it but you don't see users and you don't feel good about it you're not paid to do it don't feel bad stopping and we'll talk about that in a

moment as well um one very important thing though even without users consistency is King you need to make sure that your code is a bit consistent you need to make sure that the way it works is a bit consistent because if you abandon your project for a while and come back to it it should be something that speaks to you not something that makes you spend a

night of your spare time that's already a very little spare time you could have spent with maybe family computer games friends or whatnot uh or even other beautiful things uh trying to find out what was I writing back then again because that's horrible you don't want to spend your free time on your own debth that's that's totally useless so make sure you you're consistent um in your

code but also in in the product itself make sure you have something just works that you don't need to do 12 different steps just make it work if you look at my community giup account you'll find a few um small PCS to see how I can something can make something work work and they all share some stupid script called automate Dosh if you call that automate Dosh

my PC just works you don't have to do anything else so I just stops at automation the moment I have the automat H working so go then just works I do the same my work if I have to show something is insecure I want to create a payload I'm done when my automated works at my col's computer without any preparations that means it works for open source

projects that you want to continue you make sure so you have something that is updated nobody wants to look at cityy old code that doesn't work on their computer nobody really cares for it either unless it really solves a problem nobody else can ever solve which there seven billion people on the planet will never be the will never really be the uh the idea so make sure

you have something that's just updated and that's hey remember what we just talked about exactly make sure you have something that feels usable that you understand how to use it it's not hard to use it and you can just in and make sure that you also understand that you're consistent in your development itself because an open- Source Library it's not about is the productize jar file uploaded

to Maven or is the create uh finalized uh uploaded to the registry we product we care for now everybody looks at your code everybody looks at your GitHub so make sure that your development setup is actually something consistent enough to work with and it might sound D but if you spend time on that to make this consistent your development your your updates uh and all the other

stuff around it you'll actually enjoy working on your project a lot more after because you don't have all the extra work yourself anymore either and then of course when you have something try to promote your work find relevant communities for whatever you're trying to build out use social media I have to be honest I haven't done anything on Tik Tok so if you watch this and you

want do a Tik Tok video on wrong sequence let me know I'm happy to uh to check out your work after that also try to use other platforms super mer contact like Dev 2 or some other blogging uh like medium or whatever try to be on existing vogs and podcasts um so you at least can you know make yourself hear a bit about the project and if

the author of the podcast or the vog really thinks it's a good idea what you're working on they'll definitely let you win if they don't that's also something feedback from the community automatically to your idea it might very well be that people are not really excited about it and maybe you should just keep it to yourself then also try to do cfps to conferences that are relevant

to your solution for inst like this one so here we are talking about it um and of course once you did that not all repositories grow the same way in terms of appreciations like GitHub Stars you can see through three different projects that are growing very different l so the yellow one is wrong Secrets the blue one is coraza uh like the firewall rules and the red

one is API security um if you look at these other two projects coraza and uh API security they're very different from wrong Secrets wrong Secrets is a vulnerable app to play around with with coraza you actually get rules that bring a lot of value to organization and API security is like a standardization body of work that's really important if you want to secure your apis so if

you compare your projects to others it might very well be that your project doesn't grow as nice as theirs and that you don't have as many stars as have that shouldn't bother you at all wait what no it shouldn't bother you at all because you are your pro your project is your project it's different from any other project your project is fine the way it is don't

expect the same type of grow curves as other projects it's nice to compare to see how it developed and what happened to make them pick up more stars for like certain media events or certain releases um but be okay if your project doesn't grow in GitHub traffic or start appreciations as some of the others do because you might not be that special but you are unique and

your audience is unique so it's fine if it's growing differently or not at all if it grows very fast remember you just got lucky and congratulations on the fact that you did because that's awesome but it's okay okay if it's not the case as long as you enjoy what you're doing very important is be the maintainer you want others to be so be kind people might have

spent hours on writing an issue text and then um you can say not only you good buy um wasting their whole uh hopes and dreams you could also say yeah I love the idea but that's not applicable with us right now and maybe just try to find a way to contact them directly so what I try to do if I can find them on or for instance

say like uh this might not be a super idea um can we have a chat about it and just talk about it and say like hey if you still want to contribute maybe you like to do this or that or what do you think about this issu Gile something um um uh it it it the issues you might get from others being filed um uh might have

a very weird tone and that might not be very productive for you as a maintainer so always step back because I just wrote these four types of um feedback that I received over time the first one is is the hero or the prover he basically wants to prove how cool he or she or they are um so so they want to point out that something is very

wrong with your project you shouldn't be doing this this is so bigy why un Earth did you do and don't take it personal they're trying trying to prove how well they know something and try to project it on on your project for instance we have many Security Experts talking about the binaries in our project telling us that the binaries are very risky you can't just put binaries

in your project because that's you know supply chain risks and then we kindly explain them look we build our own binaries and WR secret binaries there's the code there's the cross compilation we even manage dependencies over there and scan them so we should be okay but people would like to show oh yet they know something about supply chain security so they'll eventually notice or try to make

note of this if they didn't study it correctly we also found other issues where people basically said like look I love this I love that and can I help you to grow your project can we do this together for instance um but we also saw the envious or the frustrated he just basically say this project sucks um you should have done something completely different this doesn't educate

anybody that's okay if people feel that way about your project don't make yourself feel that way as let it sink in Let It Drop off and move on and then of course we have the helper can I contribute with you can I join you and those are the best in all cases the feedback you get is not necessarily about the project itself it's about the context of

the project or it's about the author of the issue in the context of the project never forget about that and it's fine no matter what they say it's fine just try to be kind yes I I have hard times being kind everybody does take a deep breath and if you fail you have a better day tomorrow don't worry and no you can't satisfy everyone you can't um

get all the PRS in for inst we I got a PR once with seven different big ref factors uh because they thought they wanted to somebody wanted to remove all the Cod smells but it made my project so complicated I couldn't maintain it after it was without Cod smells with so many nice abstract classes and whatever that I felt like I can't do this I'm sorry I

have to decline this but it took me a talk with Ben and n and like a few nights of sleep to decline it because it felt to me like I let down that contributor because she really put an effort in to make that work and it was beautiful code but it was just not helping me to maintain it future um so yeah it's hard to decline that

but please do it because you need to maintain the code after the pr is merged have a code of cont conduct and a contributing guideline that's really helpful when you want to be a good maintainer and make sure you're ready to enforce them because people might be you know not so nice to each other within your project context and that's where you have to step up as

a maintainer and to explain to people that this is not the way how to work on your project whether together or against each other and make sure you're always realize and maintain it doesn't mean you're going to be the mentor of every contributor unless you want to help a person but that's really not up to the contributor to decide there's no depth from you towards a contributor

to become their Mentor or whatsoever if they file a PR or file issue um oh yeah you're not an inade service desk employee there's no SLA you can say no if you don't have the time let it go it's fine and in that sense make sure you have an ordering in your components architect to maintain together so for instance um uh we had something stupid we first

had challenge names in orders like challenge One Challenge two Challenge three challenge four and if I would now challenge eight without challenge seven then the application will break so we had to re architect the whole thing to make sure challenge were loaded in such a way that it doesn't matter how they were named and it doesn't matter which order so we could just configure that um and

and by by fixing that we no longer had to wait for certain contributors to fix their challenge feedback or their PR feedback before we could you know merge the next one then split essential Parts if you can split essential Parts people can contribute to search essential part without you know um uh changing the others giving you far more space to do stuff and please don't make perfect

Solutions because there is none there is no software on this world that's perfect leave room for improvement in an next issue it's fine because it's your open source hobby work right don't overspend time on it and it might ver be that you thought it was brilliant and then somebody fils a PR and doing half the work you did but with such a beautiful elegant solution it's far

easier to maintain but you can only have the space for that if you have an open mind to kill your own darling um and to not you know aim at Perfection and at the same time all of this doesn't make sense if people file PR that touches eight different components or changes everything so ask people as part of your code of conduct or your contributing guidelines to

focus on one item per po request or merch request otherwise your real brain is going to be berserked and and and whatever whoever else tries to contribute will then be on a a running train and that's not very nice to to and try to leverage free Solutions so there's many free Solutions unfortunately not everything is free anymore when I wrote this OCT had an open source Free

Solution is no longer the case but that's inside you your farious deployment methods that have some free credits or an open source solution for instance render has uh render IO and realway have a free or have some Open Source Credit Roku has an open source program where you can subscribe to where you can just deploy a container to it can be very helpful um hashicorp has for

instance hashicorp fall tool where you can uh open source variant which you can just use to do your stuff kubernetes is an open source project so so Docker can be used for open source stuff if you want to work on a web three project stuff like ether scan is also open source to use when you're in want to host something in the cloud AWS Microsoft for Microsoft

Azure and Google for the Google Cloud all have their open source programs where you can apply for free credits these credits really saved us because otherwise we would have huge Cloud builds when wanted to test our online challenges again and now we don't have everything online the whole time we just spin up something online in a cloud run terrot tests against them and then just ship them

down again that way we save a lot of costs but we know it's still working and then there's of course stuff like one password who has an uh open- Source uh uh Vault integration setel uh and also an open source subscription if or a subscription for open source and Jet brains uh provision uses intell as part of their open source program so we could do far more

with far less keystrokes which again helps us to write our uh Java open source program and all of that would never have happen I mean all of this is great stuff right this are great programs and we're very grateful for all these different open source tools that we're able to use next to for instance spring boot uh and tons of java libraries beautiful R libraries and go

libraries um uh but all of that it's just free and you can use it to grow your project faster but of course no project grows as fast uh if there's nobody to help out and I'm very grateful and and and very honored um uh to have such a large group of people contributing to our project it's been great guys if you ever watch part of this thank

you so much I really appreciated um there goes also a second special thanks the first one goes to get Guardian who was our first sponsor so we had something to apply with a before to get our Cloud bills Pig next to the open source credits of course je brains one PS um but what really will helped us out is making this an OS Project because under the

OS Foundation um you automatically get more exposure because you're part of the O organization with your Repository and um there's just people out there that don't know about any of the security projects apart from the OS projects so if you're becoming an OS Project you're automatically increase your visibility and lately I must say that the O project support has been increasing over time which made it again

more useful to do this I also have to share you shouldn't uh try to become an OS Project if you're not here for the long run because o is trying to kill their Dead projects um and clean them off and they don't want to have new projects that will die in a few months as well so make sure you first grow your thing and when you really

think it's good then try to apply if you think it's idea and again it's okay to let go if this is an if you're in some unpaid project Let It Go for a while if your family says Hey stove away the laptop son because we're here and we need your my husband dad or whatever try to step away to me that's often very hard and I'm still

learning that because I'm sort of addicted to make this bigger because I like programming it's like this uh yeah gaming or programming addiction I could say um but try to let go of that if you can all right so Lessons Learned open source development is hard make sure you're motivated make sure you like what you do try to get feedback often compose and reuse and automate don't

do stuff all the all the way yourselves be the maintain that you want others to be that doesn't mean necessarily everybody's Mentor but be a kind maintainer if you can or detect your solution to maintain together in a way that everybody understands it and can work separate from each other and again it's okay to let go after all it's your time all right that was it do

you guys questions thank you uh so much you're I've just seen a note here from Chantel in the in the chat just say that your your insightfulness your expertise and passion truly Inspire us and I have to say every time I hear hear you talk about that it the your your passion for the projects and for open source does ooze out of you and it uh it

certainly it certainly makes us all really want to be part of the project I I can tell you that um I'm gonna kick off the questions uh here this is kind of more in line with just like General open source you talked a lot about being an open source maintainer and the the challenges that that come with that and how to overcome them what about from the

other side of being you know a firsttime open-source contributor as a maintainer yourself you know should people be kind of scared to make contributions or how how could they go about making maybe making their first contributions if they're worried about things like not having the correct linting as you talked about or you know or if they a bit nervous what what what advice would you have to

people wanting to contribute to projects for the first time so it's natural to be nervous I remember my first contribution to an open source project I think it was the ZET sing barcode scanner for Android and I was usely nervous because I was like why why would my Improvement make sense and I even did something stupid like something like public static whatever type of varable naming instead

of the right ordering so so his linter broke and I was like oh I did it wrong oh man oh man but um and that happens and that's okay it's okay to be nervous because your code's going to be at the internet let's start with that that's okay embrace it at the same time knowing that everybody went through this nerves you're not alone on that so feel

free to contact anybody who's in the game whether it's the maintainer or somebody else who contributed before and ask about hey I read the documentation offered like the code of conduct or the contributing guidelines I did a fork I did some tests it seemed to work but I still not I'm not sure if this is okay can you have a look at this um feel free to

ask that I've gotten these questions many times as a maintainer like is this okay and then I got this whole chunk of code even in an email and I'm like oh how am I gonna see whether this is okay I don't know and then I just kind it it looks okay from a conceptual basis or it doesn't look okay because I'm not sure how to use this

um can you file a PR and just file it as a draft PR and we'll just maybe over stack or even over a video call go over your code together and have a look at it um see if we can make it work um the worst thing you can do is say to a maintainer the simple two lines I have an idea but I can't get the

C run and then walk away because Animan what do you need help do you just don't like the IDE did you try to Rue C++ while it's Java I don't know man I don't know what the problem is so I can't help you help me so give a so give contrib uh give fellow contributors or or coordinators or leaders or maintainers the space to help you that

means really make sure it's clear what the problem is and if they ask for clarification respond because it's also their spare time Absolut absolutely um and I also think too you know don't feel bad if if certain maintainers don't have time to maybe work with you as well you know people people are busy and uh that's nothing on you as a contributor sometimes uh but don't be

afraid to start I'm sure everyone appreciates that um I have I have one other question we're we're running our time but it's lunch break so I'm going to take the executive decision we're going to go slightly over uh because I'm the moderator and I have more questions and I can do that so so uh I just want to say uh I Wrong Secrets is a great project

what is the number one mistake you see other companies doing in managing secrets you know what what what is a what is probably you know the the the maybe not number one maybe couple but you know what what are some big issues when it comes to other companies storing Secrets incorrectly which is what OAS ROM Secrets is all about so if I would have a top three

the first one is actually not about the secrets themselves but it's about not educating developers security and whatever on guidelines where to and where to not put stuff most places where it goes wrong is because there's no gu Ence so security doesn't have his their scanners running out and it's part of pipelines or whatever or or or or their own little exercises because it's not on their

radar and Engineering will be like ah I got this variable called API key H fits nicely in this class doesn't it um because there was no guidance not to do this um it's it's up to the person itself so the first rule number one is make exactly clear to everybody this is this is how we store Secrets this is how we store human secrets and this is

how we store machine Secrets it starts with that and then try to enforce them um when that doesn't exist then number two comes in then it's still well good bloody old code um and often it starts with you know just your Java files or your uh uh HPP files or your uh uh your your your C files and stuff like that and eventually you grow and put

it in your config ation file which is still in repository um and so so that would be number two and number three is currently to me will be um uh infrastructure as code State print is terraform involved with secrets and stuff like that um yeah and officially statistically I think we should say darker containers but by now many people have heard about the stupidity you can do

in Docker and that you shouldn't put it stuff in images and we still see it on a daily basis um but very often the bigger secrets that allow you to go outside of that workload to a lots of other things are often in terraform uh state for instance so those would be really my uh well top four in or top five really really interesting well we have

run out a little bit overtime it is time for lunch so you I will let you go but I just want to say thank you so much for coming in here sharing your passion uh with with us all and running us through this and I I really hope that a few people will feel comfortable maybe becoming maintainers or open sourcing the projects after your talk so thank

you so much all right cool