The following is a transcript of the “How to Assess Your Dev Team's Secure Coding Skills” panel - it has been minimally edited for clarity.
Gaby: What we have for you today is the topic of secure code training.
How can we assess that our dev team actually understands secure coding? Do we have the right people to even figure this out on our team? And what can we do to improve coding skills? How do we make this sort of a learning process so that we know that over the time we're getting better and better and better.
This is an important topic because dev teams are getting hacked and one of the worst things that can happen is if somebody adds a line of code and you compile it and now it's digitally signed and goes out. Your product goes out to all your customers with a backdoor. We really don't want that.
There’s a lot of risks around this that we want to address. We have a great team - We have Itzik, who is Wizer's CTO and R&D manager. And we have Robbe one of the best hackers that I know. He’s also responsible for our videos and some of our CTFs.
Let’s get started. I'll start with you, Itzik.
The Levels For Assessing Your Dev Team’s Secure Coding
Gaby: As an R&D team manager and a CTO, you've done this for many, many years, right? For like over 20 now. So how do we even start with assessing if our dev team even understands the risks; like how much do they know? Because when, when we hire people, very often we check their skills, around logic around frameworks. This is what I've seen in a lot of the interviews. Many times we don't have the skills even to ask them questions around security.
So when we hire them, we don't necessarily understand if they're good or bad at understanding the vulnerabilities and writing secure code. So what do you suggest and how do we assess our team?
Itzik: I think it's a great question and there's no one good answer, but I'll tell you what I think and where I'm coming from, how it works.
So first of all, I see there are three levels of knowledge, right? The first level is kind of like when you look at least the OWASP Top 10. Every couple of years, they come up with a definition of the most important ones per likelihood of happening and risk and so forth. So they have the top 10.
If you look at the top 10, the first level is understanding what those are. Like if you look at injection type series of vulnerabilities - there are SQL injections, NodeSQL injection, code injection, et cetera, et cetera, et cetera,- a lot of types of injections.
If you can tell me that they exist, that's the first level.
Gaby: That’s my level. You can ask me about OWASP 10 and I know to tell you what each topic is about. I know what SQL injection is, I know what XSS is, but it asked me to find it in the code?
Itzik: Exactly. So that's the second level. You're right on the spot here, because the second level is being able to spot it. Now that’s starting to get significant. If you know how to spot it, at least you know that there's a problem. Now you have to figure out what to do with that problem.
It’s not necessarily easy and straightforward, but that's at least a progress because you can say ‘here is a problem and I know it's risky.’ Now I have to figure it out. The third level is putting it into practice, meaning that you can spot it and you can also come up with a mitigation that actually works.
You also understand the risk broadly. So that's kind of more lik making it a second nature to think about it as you write code - that's the third level. That's the Holy Grail and where we want to go. We want to be able to be able to know who are developers who know that vulnerabilities exist, can spot them, and can also mitigate them. It becomes almost a second nature for them to spot and remediate.
So you asked about how do I assess, right?
Level 1 Secure Coding Assessment
To assess the first level, you can start with a quiz. It's very high level, and you can start with very simple quizzes like, ‘what is this? What is that? What is this?’ Simple. You can do that at an entry level for any developer that you hire or for your existing developers.
Level 2 Secure Coding Assessment
If you want to get into the second and third level, you have to put code in their in front of them and they have to spot the issues. They have to tell you, ‘Hey, there's an SQL injection here. Hey, there's a potential OS command injection here and et cetera, et cetera.’
They can look at the code and spot it. So that's second level.
Level 3 Secure Coding Assessment
If you want them to actually show you that they're capable of solving it, mitigating it then you need to actually put it into practice. There are multiple ways to do it, but mostly games are a good way. Like, here's a code, fix it; make it not be vulnerable.
You spotted it, great, but now make it work. So that's kind of like the way I think about it.
Robbe: At this moment, I think a lot of developers are still in that first phase where they have heard of things. They've probably seen it maybe through the years a couple of times, but they don't fully understand what it is.
And I think that this first level that we talk about is a kind of level where every CTO kind of has to be, they just need to have an overall understanding of globally what some risks may be and what are not. Then developers are preferably already at that second level that they can already it in their codes and make sure that they don't code vulnerably.
Then on the third level, right now we have hackers that know all the tiny details about everything, but the goal is to get those developers from that first or second level and get them as close to a hacker as possible.
To give you an example from the real world, I work as a penetration tester. So every week I see a new application and I hack into it. A couple of weeks ago, I found an XSS in a company and I reported it. A day later, the developer comes back to me and says he fixed the XSS.
And after 10 minutes of looking, I found a bypass for their XSS fix. So they fixed it in a very simple way that kind of fixed the first payload, but it was not a complete fix at all. It clearly showed that this developer had no real understanding of what the actual vulnerability was. They just blocked my payload from executing.
So, I sent it back. The developer comes back the next day, ‘Hey, I fixed that again.’ I found another bypass and this went on for like four iterations until I sat down with him on a call and told him, ‘look, the root issue is here. And this is what you need to understand. You can't just go blocking payloads and fixing that.’
It was very clear that this developer was somewhere between level one and two, where he should have really been between level two and three.
Gaby: I think that's such a great example because I've seen this story happen over and over again, almost on every pen test where a lot of developers just don't understand the root cause.
It’s only when you understand the root cause of where this is coming from that you can nip it in the bud. Because if you're just looking at the payload and you're saying to them, ‘Oh, there's an issue here that they fixed that, but then you use other characters and other mechanisms to continuously bypass it.
Now that I think about it, it's very similar to how application firewalls work, right? They don't fix the problem - by the way, I'm not saying don't use application firewalls - what I'm saying in reality is this type of approach is only addressing the symptom.
They're not addressing the code issue. So you come up with a rule, somebody bypassed the firewall, you fix it, and then they bypass again and again and again. A lot of hackers that I talk to actually enjoy this kind of cat and mouse game because it makes their payload look cooler, right?
It makes it look very, very sophisticated, but they always find a way to bypass those firewalls. So this goes back to really putting into practice what you've learned. So Itzik, why don't you show a few examples of the level one, level two and level three in terms of a quiz versus an exercise.
Level one, I think, is the easiest. There's really no need to even talk about, like, ask me what is XSS and I'll probably tell you at a high level SQL injection. I think level two requires some training, right?
Assessing Level 2 Secure Coding Knowledge: Going Deeper
Itzik: Right. So level two is that it’s not enough to spot one because you have different ways and there's some chaff sometimes and it's hard to find those vulnerabilities.
They don't stand out and you don't just spot them. But if you know how to look at code and you have the practice, that's more about practice. Right? You look at code, and when you look at an SQL injection, for example, you look at a string that is building a query that runs in the in the database, - you look at the way that the query is built, it's not parameterized.
Then you see that there's a variable that comes from the input. And even if there are some attempts to even sanitize the input it's not necessarily full. So, you know, again, the root cause is don't use that method, use an ORM, use a parameterized query, use a safe stored procedure. There are ways to handle it.
But if you handle the symptom, if you try to sanitize it, it's too hard and it's too problematic to do. There are so many characters and so many bypasses and the syntax is so tricky that 99% of the time there's a way to bypass it and figure out a way to overcome it.
Gaby: Let’s show this within Wizer because I want to make this also practical today for people. What we're going to do now is go into Wizer’s platform and to show you how you can assess your team even before we train them.
We just want to show you the levels of understanding. So let's start level two. Let's just show them the type of questions that if you want to quickly assess your team, you can either have them go through training or just have them do the quiz and just show them the type of questions.
Itzik: Yes. As a quiz, go through the XSS topic. There are questions. What is XSS, how to exploit it and et cetera. Those require listening.
If you're not listening to the topics and you don't understand what they're saying, you won't be able to solve it. Or you won't be able to answer the quiz correctly.
For example, prototype pollution: even if you know it by name, you have to understand what it is and to actually be able to answer questions that are a little deeper than just understanding what it is at a high level. Every topic has those quizzes.
We'll take you through being able to understand it deeply.
Then there's the game itself, right?
Gaby: I know what prototype pollution is, right? Because I've done these courses as well and you guys have taught me about all of those things.
So I actually know how to talk about it. Now I'm knowledgeable, but again, there is no way in the world that I will be able to spot them in the CTFs.
I'm able to do the simple CTFs, maybe, but we'll talk about the CTFs in a second. That's the game that you talked about.
So again, if I didn't get training, I wouldn't be able to understand this. And I think you have two ways. You can either have your team just do the quiz without doing the learning and see where they are to get a better understanding if they know deep dive into XSS, deep dive into IDORS, if they understand the concepts. The results of this test will sort of let you know, first of all, where your team stands in terms of secure coding.
I would advise to probably have them do the course and then do the quiz. I think it's a better use of their time, but you can go either way. Now let's talk about. How do you actually assess level 2 and level 3.
Itzik: Once you've done the courses you can go to the games. So the game here is capture the flags, CTFs. And when start, the games are actually built on a piece of code. So you're looking at a piece of code, you can copy it, you can actually deploy it locally and so forth.
You can see the complexity here. It's easy. And you know, every CTF that exists has different complexity. This is hard. This is easy and so forth. Okay, so you can go one by one and look at the code. Every piece of code has typically one vulnerability we’re focusing on. What you want to do is first we said level two is spot the vulnerability, right?
So specifically. Let's take this one for example, it’s ranked as ‘easy’. I need to change a message of some sort. So if I scroll down and I start to look at the code here, that's an API endpoint. Looks fine, but here is HTML. Let's take a look at that.
So I see a nonce here, which is the CSP and so forth. It's kind of protected, but I still see a situation where in the code I have placed here document right of an argument that is getting from the query the name. Here’s where I should stop and say there must be an XSS here.
Now, how do I exploit it? I don't know. How do I mitigate it? How do I fix it? Maybe I have an idea. But the best way to make it second nature is to actually think a little bit like a hacker. What would a hacker do? How would they exploit it? And there are multiple ways, right?
So we tackled the second level, which is, okay, I can find a vulnerability. Now I don't want to spoil this one [particular CTF] because it's pretty new. So I'm going to go to one that is older. This particular one is a command injection vulnerability. You can see that it's a retired CTF.
There's also a write up here, which is great because you can read through what the code looks and understand the code and get some impressions on what was wrong and takeaways. But if I want to solve it again, I need to first spot the issue, right?
So as I said, it's a command injection. I can see that there is something that looks suspicious - which is an alternative for eval, which is a function constructor, which I can enclose some text and make it code. And that's really, really dangerous, right? So, maybe the developer thought, ‘oh, if I don't use eval, here when I use string function, that could be a little safer because it's running in a sandbox, it's not running in the app.
It's running within a function.’ Maybe in this case, it's not solving the problem. It's not really a solution for anything. Especially since the developer forgot and not forgot, but actually used required here because they wanted to achieve something. So let me share with you what they wanted to achieve and how do I solve it?
First of all, identifying the problem, I look at this line. I see this is probably vulnerable to a command injection. How? Let's figure it out. I have to think like a hacker.
Gaby: But before that even, if you stop for a second before that, going back to what Robbe said at the beginning. The previous code could have been eval, and then somebody would have spotted it, or a pen tester would have said “idiotic. What are you doing? Never use eval because they know never use eval.”
So they said, okay, what do I do? Oh, let's use this because it runs in the sandbox. This is safer. So they came up with a solution that they thought was good. But again, they didn't understand the root cause of the problem and the solution doesn't solve the problem.
Itzik: Exactly, exactly, exactly. They also left a door here. That's why it's kind of like a medium level challenge. It's not very hard. But in order to tackle it, since this is an endpoint, right? I can use Postman and I understand that I can use the first argument require and use Math.js to actually use square root of something. That's an intended behavior of that API. When I run that I should get the square root of 2000. Okay. That was the intended behavior. The calculated was supposed to be a little more sophisticated, JS methods.
But that is opening a can of worms, because once I have the argument zero, is there require I can potentially require other libraries. I will not be able to require libraries that weren't imported. So I won't be able to import any library, but FS is part of Node. js and hence it is something that I can require.
And why do I mention FS? Because I thought if I have FS, I can read files. And I can do dangerous things like reading the PASSWD file, okay? So I'm requiring FS. And then I'm using a method here, readFileSync, to actually read the PASSWD. And that's the purpose, or that's the goal of the challenge, read the content of OS PASSWD.
So if I go to Postman, I hit send, here you go. I've exposed the content of the file of PASSWD right here in the console. So what we've done with the Wizer game is, if you post that same post here, what Wizer would do for you, it will go check. And if you actually expose pass WD, you won the game.
There could be multiple ways to do it, but that goes to the third level. The third level here is I was able to spot the issue, but because I actually understand deeply how it works I can actually exploit it. If I understand how to exploit it, I'm so much closer to a solution because I know now what I shouldn't do.
What I shouldn't be doing is if I hit hack here, boom, I was able to solve it. I'm now going to claim my spot. In this case, since it's retired, I'm not going to get a spot on the leaderboard just because it's retired. So I don't get the points, but I was able to play it. Does it make sense?
Gaby: I think it does. First of all, we've deployed this a while ago. And what I found was very surprising is we started with thinking about complex scenarios. And when we did the public events we had hackers join and they were able to solve those complex scenarios and we imported those scenarios to the Wizer For Developers.
Almost no one was able to solve it. So we started lowering the level and dropped it from three peppers to two peppers. Even then, still hardly any developers were able to solve this. So we had to really push down the level significantly so developers would be able to solve even the simplest scenarios.
This comes to show how big the gap is between what Developers know about secure coding versus what hackers know about secure coding.
A great way to assess your team are via two main paths. One is a quiz, which I think you should do regardless, even if you come up with the Google Doc, like you should assess your team's knowledge.
Yesterday, you can't not know how good your dev team was at spotting insecure coding in general. It's a very important thing to know about in order to be able to improve, right? We're talking about progress in order to improve. We need to know where we stand right now. So that's creating a baseline.
Using Capture The Flags To Measure Secure Coding Progress
The other one option is to do something like these CTFs. And by the way, I haven't mentioned it, but those CTFs are freely available if you log into the Wizer platform. Have your team go in and at least solve one CTF out of the six that are available, you'll be able to know how good your team is at actually spotting and understanding how to mitigate insecure code.
That's with regards to the CTF platform. There are different platforms out there. Wizer is one of them. We've done it specifically for developers.
However, I've seen companies work with other CTF platforms. There's Hack the Box and others, which are a little bit more geared to hackers.
They're more around the entire box and the scenarios are more complicated. As you can see, the scenarios here are very short, very focused on the single vulnerability. And we cover the entire OWASP 10 which allows your team to practice what they've learned as well. So going back, what's your suggestion around doing this over the year?
Itzik: It's a great kind of challenge for an R&D manager to think about that. The best thing you can do is first of all, continuously assess, because things change OWASP 10, every couple of years, updates - there are new vulnerabilities, new libraries.
So you always have to be ready on the trigger with your abilities, abilities of your team. You need to assess and know where you stand. So continuously do that.
Actually go through the courses. And there are a lot of platforms out there, Wizer included, that you have the first level covering OWASP10 at a deep dive.
And then there's a lot of other topics that are either under OWASP10 or, you know, additional things that you need to think about that borders it - DevOps and developers like Terraform and AI and all sorts of topics that are more advanced. You probably want to cover because things are going to become more and more in those areas.
Continuously Assess Your Developer Team's Skill Progression in Secure Coding
First of all, continuously assess, continuously train your team, try to train in portions and not everything together because people don't remember. If you do the course at the beginning of the year, chances are by the end of the year people remember only part of it and vaguely at that, right? So if you always think about it - and that's the approach we've taken with Wizer with those CTFs we update every two weeks.
In terms of topics, our recommendations are doing it monthly. It doesn't always work for folks. Some people want to do it quarterly, half a year, a year. It's not a problem, but always think about it as a continuous process. And it's not something that you start and end and that's it, you're done.
You're not compliant, like to be compliant, you have to continuously work and do that. For example, how do you continuously do CTFs? You have to assign time for it. As a manager, as a C level, you have to dedicate time and say, ‘this is important enough that I will think about it as we plan our time availability and building the product and so forth.
And I'm going to take some points off the developers table and be able to allocate time for you to learn. So once the C level has bought in and you allocate a time, you’re showing how important it is to your team. Then you can plan for events. That's one way to do that, right?
Every quarter, every half a year, you decide what the event is. Like in Wizer, there's always six available CTFs at any point in time. So put a pin in the calendar, say June 15, we're going to do an event. Get ready. And allocate time.
Full day, half a day, whatever you choose. And let's solve, make sure that people at least solve, you know, a simple one or two, right? So they work together. It's also fun and it's very educational and people research and people actually play with it and they collaborate and so forth.
And they solve those CTF challenges. And then at the end, you can produce a report. You say, okay, in June, we played this game. We had six challenges and only 10 percent were able to solve anything. Right? Now we’re doing it six months later after some training and so forth and people over the year, through the year solved two or three on average. Great. Now we're seeing actually more activity and we're seeing like 20%, maybe 30% and we can begin to see a trend. So always be measuring it and always make sure that you initiate and allocate time, initiate gains and allocate time for your developers to go through it because it won't happen without any attention.
Some people will be engaged and like the topic of secure coding and some people will find it hard to engage. So you need to allocate time and to make sure that people do it.
Changing The Mindset Around Secure Code Training
Robbe: And on that note, I do a lot of pen tests and I have to bring bad news to a lot of developers and say, well, it was not a good result.
You have two types of developers. There's a type that really takes it personally, but there's also the type that thanks me and says, ‘thank you for highlighting these issues because now I can go to my manager and show them, look, we do not have enough time to train ourselves to write secure code. This pentest report clearly shows that we need more time.’
And I think that mindset of using what was found and asking for more time to actually train yourself is such a great mindset. If an R& D manager can already give that time without requiring a bad report beforehand, that's obviously a double bonus.
So yeah, great stuff.
Itzik: One more point where I think it is important to change the mindset is that finding bugs is good. Finding bugs is not bad. Finding vulnerabilities is good because you found them and not attackers, right? Everything you find is good. You should give a high five when you find it.
Don’t be insulted and take it and offensively because you found something and you spared a vulnerability from your system. Be happy about it. The approach should be you found things. That's good. That's not bad. Let's not make it a bad scenario
Gaby: What I'm hearing here, which I like is one, you need to get the buy in from the C level. It’s hard.
And unfortunately, some managers are not even aware of the risks themselves. So that's a problem. It's hard for them to push their team to write secure code if they themselves are not aware of all those risks and they're being pushed to deliver a product. So if you're in the security team you also have to sell it to the R&D manager and get their buy-in before you do this. Second thing is to allocate time, right?
Not just tell them do it over the weekends, right? You have to allocate time whether it's points from the sprint or whether it's an event that you do once a quarter and you allocate like three hours and then you know people go and do. The third thing is the report because as a result of that event, you will also see where the weaknesses are.
Maybe everybody knows about XSS right now. Maybe we need to focus on IDORS. Maybe we need to focus on other things. And we'll be able to clearly see that in the report of what people were able to solve and not able to solve. And lastly, which, you know, thank Robbe for saying this, because I think this is very important.
This is a career opportunity. So if you flip it, you and talk to people about how important this is for their own career, and hopefully hiring managers will also look for those skills in the future, and you can basically show that you are very good and you've solved x-amount of CTFs, and this will give you an advantage over other candidates because it shows out of the box thinking and it showed that you took the extra step.
It shows passion, to be honest, to coding. That's how I see this. So let's move to the, to another topic around this. So you're, like I said, you're the guy responsible for doing the videos and people love them, you know, like they're short, they're to the point. You're also on social media.
So you really have a good understanding of, of content in general, what's the secret sauce, you know, how do you what's your approach to creating content? that people will actually want to watch.
Robbe: Yeah, that's, that's a great question. I think what I try to do is I might try to make everything real. All the videos that we make, all the recommendations we make, all the vulnerabilities we cover, they come, they originate from real scenarios that actually happens and this makes security much more tangible.
And definitely for developers, they can actually see codes that, that They could relate to, they could say, Oh, I could write something like that, but I'm seeing here on the screen is vulnerable. I think that's step one is trying to make everything as real as possible. Which is very important outside of that.
Obviously the content also has to be nice to watch. That's why we try to put a storyline in it and we try to make sure that, that you kind of have this thread that you follow and you start from an example where, Oh, you're the developer of this website. You get a message saying something goes wrong.
You have to go investigate. So you investigate your code and you find this vulnerability. And through finding it, you learn more about the vulnerability. And then eventually you progress from learning about the vulnerability to fixing the vulnerability. And that's kind of the idea that the videos are short and sweet.
So there's always two videos of about five minutes each. You just have to take a little bit of time out of your day, go through this story which guides you fully through a vulnerability. And if you do something like that every month, then security will always be in the back of your mind.
And then there's also the hacker mindset, the idea that we're portraying here is that you need to start to think like a hacker. If you think like a hacker once a year for two full days, then you're going to forget most of it. So if you do it a little bit, it's like one hour every month.
Then every month a new vulnerability is going to be in the back of your mind. So with the content, we really focus down on a single vulnerability. Besides that, I also make a lot of content specifically for hackers. Hackers are a really fun audience, but I also noticed that a lot of developers are in between there because developers are very passionate people, most of the time they love codes.
They love the bits and the bytes. They love to understand how things work so they can build stuff. The perspective of an attacker - breaking down things to understand how they work versus a developer, building things to understand how they work - I get a lot of comments from developers saying, wow, that just give me a whole new perspective into the way that I can look at my own code or I can look at the world around me.
And then that's kind of also something I really like to portray.
Gaby: What I love about your videos isit's a story, right? It follows a storyline and it doesn't jump in with SQL injection is a very big problem. It basically leaves you in a mystery, like, how did the heck did that happen?
So you're going in as an IT manager, for instance. I got an alert from someone that they were able to hack us but I don't know how it happened yet. You leave that answer towards themiddle of the video where people get a chance to try to figure out themselves how it happened.
And I think it's really fun, you know, because when you do show this, that's where the aha moment comes. 'Oh, that's what happened.' So I love that storyline.
And then on the second video, yes, it's more technical goes in deep into how you mitigate it. And by the way, even if you do it like this, it's not enough because there's other options.
So you're showing that process that you talked about, how you came back four times and showed how you can bypass it again and again and again, and again. I like how you bring that real life experience that you mentioned earlier into the videos. I've learned so much from them.
In terms of, in terms of using Wizer's security awareness training platform you can sign up for free and easily get started using it. I think it's also something we haven't really talked about, but it's a great platform.
It's a great way for hiring managers to test the skills of developers before hiring them because I haven't seen a lot of hiring managers doing security tests for candidates - having a candidate, for example, solve one CTF out of the six, whichever they want - will go a long way in assessing their secure coding skills prior to hiring.
And even if, for example, you see that there is a huge gap, you know that at least, and you can have them go through training, so it's not a deal breaker for them to get hired, but at least they understand as well that there is a gap that they need to fill.
It's a great tool, both for assessing before, assessing during, and assessing as you go. You always have to be constantly improving, and just watching videos is not enough. It's great, but not enough. So, watching videos is a way to learn, but then you put into practice by playing those CTFs and doing those events.
And that's a cycle that you keep on doing. And people, there's a lot to learn.
Robbe: Don't underestimate how much there is to learn, because I really would invite you all to go look at the six current challenges that are up and running right now.
Try and give it a shot. Some of them may surprise you. Definitely go and look at them.
Gaby: There are so many things beyond the OWASP Top 10. So thinking that you're covered by the OWASP10 alone is not enough. Even the OWASP10 started to groupa lot of things because they're just too much.
I think SQL injection became injection because there's tons of stuff - even they found it, you know, overwhelming and they grouped a lot of things together into single categories - even that's not enough. So it's always continuous learning. And regardless to that, a lot of regulations like PCI and others are mandating this today, which I think is a good practice for everyone.
So that's it. Any last thoughts before we conclude this webinar?
Itzik: I have one last thought. We have an event coming up a CTF event on May 5th. Which is a 6-hour CTF Blitz. We've done one in February and invite anyone who wants to join for this next round.
There's a link - https://www.wizer-training.com/ctf-challenge - to join. It's a free sign up. We just love people joining hackers and developers alike.It's a great way to mingle between the two mindsets and think together about solutions and vulnerabilities.
It's a great event to join.
Robbe: Exactly. And how this works is, so there will be six hours and six challenges just like the ones you just saw on the screen earlier here. The challenges will release at the same time, so everybody gets the same amount of time. You can see how quick people solve them.
Participants will be also talking in discord. We also have a prize pool. It's an amazing opportunity to meet new people as well solve some challenges and just have a fun Sunday afternoon. That's the whole idea.
Gaby: This is such a great opportunity to invite your team and to assess them, so you can even make it mandatory. Again, it doesn't cost anything, and there are prizes for them. What you will get out of this is a good assessment for your team.
You can tell them just go in and solve one at least, you know, they don't have to stay for the whole six hours, but get to a point where your dev team, this will be like the first baseline that you can achieve next month to get a good understanding of how good your team is.
With when it comes to secure coding, have them join any time within those six hours. Solve one CTF, show me that you solved it, and then see how many people were able to solve at least one from your team. And that will give you the baseline of where you are right now.
Robbe: And another benefit of this can be a team building. For me personally, it's one of the favorite things that I do with my colleagues is we just spend some time hacking together.
That can be a team building for everybody, bring the team closer together, get those cross skills going. Everybody has their own ideas and if you bring them together, you really get that team element that is also very important as a development team.
Gaby: Thank you very much for your time.
Thank you for the audience. And see you next time. Bye.
Connect with Panelists
Itzik Spitzen 
CTO / R&D, Wizer Training
Robbe van Roey Sr. Pentester, Toreon | Content Creator, Wizer
