Simon Wijckmans, Founder and CEO of cside.dev, Revolutionizing Client-Side Security

0:00 Jon McLachlan

Hello, everyone, and welcome to another episode of the Security Podcast of Silicon Valley. I am one of the hosts, Jon McLachlan. I am joined today with Sasha Sinkevich, and we have an amazing guest, Simon Wijckmans.

0:12 Simon Wijckmans

Excellent pronunciation. Thank you. Thanks for having me.

0:15 Jon McLachlan

Thanks so much for joining. Yeah, welcome. Welcome to the show. You are the founder and CEO of c/side.

0:22 Simon Wijckmans

Yes, a security startup.

0:25 Jon McLachlan

c/side, everything from the ocean to client-side security. I love it. It sounds beautiful. Previously, you were at Hydra, you were a product lead there, you were at Vercel, you were a senior product lead there, you were at Cloudflare before that, and founder even in your recent history too, [Joe the Fish].

0:45 Simon Wijckmans

[I think] that's side projects. Little side projects.

0:47 Jon McLachlan

We love side projects. I think all great engineers have little side projects going on all the time.

0:52 Simon Wijckmans

Yep, exactly. It was during COVID. There was very little else to do. Participated in some Mozilla incubator program, made a little thing, got a little traction, went back to work after.

1:02 Jon McLachlan

Do you brand yourself as a security person?

1:05 Simon Wijckmans

Interestingly, yes. Even though I've done many different things, I would say, in my career, I think I live at, like, kind of the intersection point between good developer experience and security done more modernly, I would say that. Security industry has a tendency to do the same things over and over again, even though they don't necessarily work anymore. And that is because a lot of these large companies are fully enterprise focused. I personally don't find web security to be an enterprise problem only anymore. We got to make it accessible to people. Therefore, the experience of Cloudflare and Vercel, bringing that together to build a more accessible security product that people can actually use and just swipe a credit card. That's what I like doing.

1:48 Sasha Sinkevich

What is the main pain point that c/side is positioned to solve?

1:53 Simon Wijckmans

There's an [attack vector] that we've known about for a while, and that is client-side security. Basically, in 2010, when JavaScript started getting actually built into browsers, there was a sudden surge of people using JavaScript to do malicious things client-side. Before that, we already had that happen for pretty much more than a decade. Like, you had the Flash players and the Java players and whatever [essential mod] you had to download for your browser to support dynamic things. Client-side, they suffered from a similar problem. The problem space got rebranded a couple of times. So all of a sudden, it was called the Magecart attack, because Magento had some pretty severe security problems that allowed people to inject code under bad circumstances. And for a long time, client-side security was called Magecart security. The more umbrella term of XSS, cross-site scripting, was also a way of referring to it. But the logic here is quite simple. Client-side security will only continue to become a bigger problem as we protect our infrastructure better, as we protect our open source dependencies that we use better, if we get a deeper understanding of the code we write. If we then have a thing that allows you to bypass all of that to go direct to the client, direct to the browser of the user, and execute things there, that obviously becomes an interesting attack [vector] to bad actors. So that's essentially what we're trying to solve here. We want to solve client-side security, and also just do better web security using client-side intel, starting with third-party JavaScript. So these weird scripts you got to add, like anything from tools like Intercom all the way to maybe jQuery being implemented using some CDN that you found online somewhere your junior engineer implemented at some point. And then recently, there's been a big surge of these types of attacks, and it's sad to see polyfill.io, half a million people's websites being impacted. That was a severe wake-up call.

3:44 Sasha Sinkevich

Yeah. The adoption, the adoption of client-side technology usually depends on how seamless that integration is. How do you guys approach the integration of the c/side technology into the browser?

3:57 Simon Wijckmans

Yeah, I mean, I took some mental time to iterate through the best ways of doing this. There were a couple of opportunities that showed up in the market that allowed us to do a difficult thing that is actually the most user-friendly way. So the way that it works is you basically add c/side as one of your first scripts to load on your website. And what it does is it rewrites all of these other scripts that you use and puts [proxy.cside.dev] slash in front of it. Instead of going to googletagmanager slash gobbledygook, it's going to [proxy.cside.dev] slash googletagmanager.com slash gobbledygook. That is a bit of a pain, because now, as a security company, you're running a proxy. You got to maintain that. You got to keep it up and running. And you could make things slower if you don't do it well. And we did the hard thing of actually implementing this as well as we could, to make scripts a little bit faster. The great thing is that as a developer, you don't actually have to change that much about how you do your job, how you interact with scripts. You can just add our script as one of the first ones to load, and magically, if one of your scripts loads another script, that other script will also be monitored, and we'll keep an eye on all of the things that it does. So that's the angle we've taken. It's definitely been more painful. There's other approaches other vendors do, but they all have their own pros and cons, and so we decided that this was the angle we wanted to take.

5:09 Jon McLachlan

Nice. What's an example of one of the attacks that this will catch?

5:14 Simon Wijckmans

[unclear]. Well, I think a very recent example is that polyfill.io incident that happened. So, taking a step back, Polyfill was a popularly used package that people implement on their website to continue to support [older] browsers. So if you had a business that had to also support that very small percentage of people that still use Internet Explorer, then there was an easy hack. You just implemented Polyfill. Polyfill.io was a domain name bought by another person that wasn't really a maintainer of the polyfill package. And that got implemented on half a million people's websites, all the way from large brands like The Verge and The Guardian and Hulu and you name it, massive websites, all the way to very small, little, like, e-commerce stores, WordPress sites, et cetera. And it's still online for, like, more than four hundred thousand websites, which is pretty shocking. But what happened was that in February, that domain was sold to a Chinese company. Initially, they didn't do anything bad with it. But then, on the 25th of June, you started noticing that a small amount of traffic got a different package, where the JavaScript was calling another JavaScript behind the domain name of [googie-anaiytics]. So it's not Google Analytics, the L was [a Y]. But as long as it looks similar to the legitimate domain name, it's supposed to mask. Good old typos. Yeah, so that was a good old [typosquatted] domain, and what it did is it redirected a small percentage of people that got that package, of users, to adult content websites and casinos. Only once. So if you try to go to the website again, you would not have the same thing happen, making it harder to raise the alarm bells. But the main thing that happened there was that change happened quite suddenly, only impacted people with a specific user agent, and then the change meant that a bad domain name was added to the script that was obviously [typosquatted] and actually was already known to be a bad domain. That's exactly the type of attack that we go after and that we're able to spot. Just in general, client-side security, there's a lot of things that you can do there. We're building detection capabilities for all of those. But we look at things in a historical basis. So things happen on a Monday versus on a Wednesday, and on Wednesday, the script behaves very differently. That is something that basically makes us do some more digging.

7:22 Jon McLachlan

Interesting. So it almost smells like very AI-esque.

7:25 Simon Wijckmans

Yes. Yeah, so we have access to the full code. Most of our competitors don't really. Yeah, we do. And of course, LLMs are pretty decent at reading JavaScript, relaying what it does, and maybe, if you compare it to the previous state of it, how it is different and what it has changed and what that functionally means. So yes, we do use a bunch of AI. And of course, I mean, this is a space that's rapidly evolving. I expect that there's going to be way more powerful things we can do over time with that.

7:54 Jon McLachlan

So this is like the dynamic version of client-side security. It's like you're in the browser, you're right there where the code is running. You're right there. You have a proxy that you set up so that all the other scripts go through your proxy. So you get a little bit of static analysis there on what's happening in terms of the JavaScript. But it seems like you're in a very powerful position to do a lot of stuff, a lot of good, in terms of client-side security, where other solutions might actually fall a little bit short. If you're analyzing, like, static code at build time, you would miss things like that attack that you just mentioned, that hijack only a small percentage, only sometimes, because it's dynamic, because that script sounds like it was changing. Only sometimes it would download the malicious version of whatever package was redirecting traffic to casinos and whatever.

8:48 Simon Wijckmans

So that's the real pain point of this dynamic style of attack. A bad actor could easily say that 1%, that 1% of users in a specific geography at a specific time of the day gets the bad code. And the bad code could be hidden. It could be listening to user credentials, and you wouldn't even know. This type of attack that happened now with Polyfill was a very obvious one. You know when you get redirected to an adult content site or to a casino. So we got away quiet on this one, I would say. The attacker could have pulled off a way worse attack. But yeah, there's definitely a problem there. And it's part of your supply chain, but it's part of the supply chain that people have forgotten about somehow. So we need to protect that.

9:26 Jon McLachlan

Dynamic languages have dynamic supply chains. Surprise, surprise.

9:30 Simon Wijckmans

Yeah, especially when fetched client-side. I mean, this is the part when I speak to engineers. I tend to ask them, do you actually know what's happening in the browser of your user? And the response to that is usually a little silence and then a, well, no. So that's, the more we know, the better. And the more we understand what the user is getting, the better.

9:51 Jon McLachlan

Yeah. Let's fast forward into the future a little bit. I'll let you decide how far into the future we want to time travel. But when you look at success, and you see success for cside.dev, and it's just this amazing, successful, your entire vision has been realized and you're on the right path, what does that look like from your point of view?

10:11 Simon Wijckmans

Yeah. So as I mentioned, kind of what I would like to do is make web security more accessible to people. And I've been fortunate enough to have worked for, in my opinion, the most successful company in this space altogether, Cloudflare. I have [insane] levels of respect and love for the entire team at Cloudflare. If you have a couple of hundred dollars to spend on web security, there really isn't another good solution aside from Cloudflare. I would love to be in a position where we basically build web security to take into account more, deeper client-side behaviors, so we can protect web applications better against zero-day attacks, that we're no longer relying on threat feeds and glorified threat feeds and things like the NVD that had a massive backlog, right? And then we can actually look at how behaviors changed and the behaviors that lead to an attack, and try and prevent bad things from happening. And so what success means for me there is that we make the web, like, for a good chunk of websites, a lot safer, and so that you, as a user, do not have to worry about where am I putting my credit cards and what about my login credentials, and we just build better web security.

11:20 Sasha Sinkevich

Based on what I hear so far, it sounds like c/side is taking supply chain posture management into the real-time space, whereas existing tools, it gives you a snapshot of where your software was in the past in your development pipeline, whereas c/side is continuously scanning your patterns in the browser. This is the actual, real, live logic that is being executed, and these are the things that you should be concerned about. And I imagine, as time goes by, you'll be adding a lot more analytics on the traffic and on the patterns on third-party libraries that the client is using. And you probably are getting close to the position where you can identify libraries that are loaded but are not used. In general.

12:08 Simon Wijckmans

Yes. So all of the above, everything you mentioned, is technically capable. And I mean, as I explained, that the way that we work is we are ourselves a script. We have an npm package. We can do great things with that. And so the sky is the limit with that. I don't want to talk too much about future products yet, but c/side is, c/side stands for client-side. Attack starts from a client. Every attack involves a client. And we want to use as much information as we can to prevent attacks from being successful, using client-side intel in combination with whatever else we can get our hands on. I think people would be surprised to learn that large security companies tend to oversell how they use data. And then, in reality, the good data is not actually being used to protect web apps. This is an unfortunate truth about web security. There's a lot of data that can be used for better security that isn't actively being used. And yeah, we basically want to [ace] that space.

13:03 Sasha Sinkevich

And it's actually a very interesting space, because once you move security, it's the edge security, right? We're talking about security on a client, which is moving further out of the infrastructure and logic that runs and executes the logic itself. There are a lot of interesting products that I'm sure could be built on top of the technology that you guys are building right now.

13:30 Simon Wijckmans

Correct.

13:31 Sasha Sinkevich

Would probably be very interesting for...

13:33 Jon McLachlan

Are you asking him for his secrets? Like, all [unclear].

13:37 Sasha Sinkevich

No, absolutely not.

13:38 Jon McLachlan

Sounds like he doesn't want to give out any of the secrets.

13:41 Sasha Sinkevich

Simon mentioned pretty clearly, and this is not the purpose of disclosing, but there are a lot of interesting developments in the space. There are a lot of legacy DLP solutions that rely on ACLs and on what your client is supposed to do, but you cannot really control the way data flows when it lands on a client, in your browser.

13:59 Simon Wijckmans

Exactly. I mean, and this is the thing. Once you get what we do, there's a lot of obvious next steps that we can take and that we will take. Yeah, I mean, it's prioritizing, and DLP of sensitive data is definitely a very important one for many people. Lawsuits, and also just the fact that compliance kicks in, right? PCI DSS v4 requires you to monitor third-party JavaScript on payment portals. That has an interesting side effect. If you have cyber insurance, most of the time your cyber insurer will ask you in a questionnaire whether you are PCI DSS compliant. And if you say yes to that, and then some incident happens and they find out you're actually not, or you haven't done self-assessments, et cetera, the result could be that they're not insuring you anymore. So these types of situations became worse and worse as they happened, because now people that normally have to actually put the money down to help you, they're covering themselves. And so DLP is the, I would say, the legacy problem there. As soon as there's a data loss incident, cyber insurers will go above and beyond to try and find out, was the data lost in a way that was preventable, and if so, they probably should have done, but they didn't, and therefore, we're not going to cover you. Those kinds of scenarios are unfortunately common. I mean, and then to come back to the infrastructure element that you mentioned, where we put our security hasn't fundamentally changed much. Back in the day, we used to put a box in front of our infrastructure, as close to the router as we could, like, as close to a modem as we could, so that the point of entry would be secure, but you'd basically be inside of the barracks at that point. But we've moved on to more virtualized versions of that, living on the edge, often at the DNS level, proxying traffic. But it's still basically a box in front of the infrastructure looking at network packets. The way I'm thinking about security going forward is we should use more data in regards to what happens before a bad request was made. And that essentially moves things further towards the client. Not necessarily happening on the client. Like, we do not rely on the client as our sole place of detections, because if you put a list of bad behaviors in a browser, bad actors are going to know about it and going to try and avoid it. But the reality is that there's some things we can do there that are more hybrid, that allow us to just touch more bases.

16:08 Sasha Sinkevich

As you guys discover these anti-patterns that might be a first sign of malicious logic being executed in a browser, do you have a publicly available resource that can then provide this information across people who are interested in consuming the information that you have discovered?

16:30 Simon Wijckmans

We currently don't do that yet. We will, in the next week, actually, and this is a little teaser, so by the time this goes live, it'll likely be online, have a website where you can type in a weird domain name and it'll tell you what it does, because a lot of these third-party scripts come from domain names that if you Google them, you can't actually find out what they are. So that's a little feature that we're doing. We don't necessarily talk about the depth of the script. We talk about who owns the domain and what that tool is used for, et cetera. We do have a bunch of data that in the future we could potentially expose. The thing I would not want to do is give people a threat feed, basically, because threat feeds are not the way to do things. I do not like threat feeds. When polyfill.io happened, it took over thirty hours for a single threat feed to do anything with it. Some of which, like, literally Namecheap was faster to block than they were added to a threat feed.

17:18 Sasha Sinkevich

Yeah, there's already a lot of noise in the security space. And the point is not to create more noise, but rather gather additional context and do the overlay of information, and then provide explicit threat that is applicable in that specific environment. This is what you guys are doing as well.

17:36 Simon Wijckmans

I mean, I basically want to fight a false sense of security. If something is on my threat feed and it's bad, then it's bad. If it's not on a threat feed, some people think it's good. That is not true. It's not because it's not on the threat feed, it's not because the threat feed says we don't know about it, that it is good. Unfortunately, that's how security has taught us to [look at] things. If it's not on a threat feed, then sure, it is fine. That's not how things work. I don't want to push that agenda, because it creates a massive false sense of security. I don't feel like I want to contribute to that. But on the other side, it is useful for us to share data as much as we can. But the sad thing is that bad actors also check threat feeds. So as soon as you put something on a public threat feed, you can count the minutes or hours before it is taken down and they've moved on to a different thing that is not on a threat feed. I don't like exposing all of the data. I do like a good cat and mouse game. I don't have a problem with that. That's kind of something that I weirdly enjoy, a cat and mouse of security. But the reality is, as soon as you make it obvious that you know something, they will do everything they can to avoid being detected again.

18:38 Jon McLachlan

But are you the cat or the mouse? Or it depends on the day?

18:41 Simon Wijckmans

It depends on the day. I mean, it's funny. I saw this when dealing with bot detection, right? If you build a bot detection tool and you give customers an API or a [block page] that they then use to make it super obvious that you've been detected, then guess what? The whole bot community is immediately on the lookout for a way to bypass your latest detection capabilities. The best security vendors out there for bot detection, they're a little smarter. They tell people, here's an API, but don't make it obvious, because if you make it obvious, we're just going to end up chasing the whole community of botters out there. You just don't want to deal with that. So, in my opinion, you got to be a little stealthy about how you detected something, whether you detected it and when you detected it, in order to be successful. Because if you just put it all out there, yeah, I mean, bad actors are smart engineers. So I just really don't want to, like, yeah, be chasing attackers. There's sometimes many hundreds of them working together on something. We're a small seed stage company, so yeah.

19:43 Jon McLachlan

Okay, so you're the cat. You're the cat.

19:45 Simon Wijckmans

I would like to think so, most of the time.

19:47 Sasha Sinkevich

It sounds like, yeah, more often than not. So how big is the team?

19:52 Simon Wijckmans

So currently, there's five of us full time and a bunch more contractors, six of those. But we're growing the team massively. So we've got six roles open right now, principal and senior engineers, but also business operations manager, because I am a solo founder. So getting an extra person on board to help me keeping that business going is definitely going to be welcome. And even an account executive role that I'm looking to hire for, starting sometime in September.

20:14 Sasha Sinkevich

All right. Yeah. So, typical, typical customer?

20:18 Simon Wijckmans

Yeah, it's funny, because it is quite a broad spectrum. We've worked with all types of companies, from consumer brands to e-commerce platforms themselves, to online accountancy services, to crypto exchanges. Basically, everybody has this issue if you use third-party JavaScript. Some people are more familiar with the problem than others. Some people are more aware of the problem and really need to fix it because of their compliance requirements. But yeah, in general, when I talk to people about this, I mean, I don't want to sound cocky here, but we do tend to create a bit of an urge, because we explain people the risks that they're under. They sometimes, I would say most of the time, have done some research into supply chain security, and then they're like, oopsies, there's an area of supply chain security that we haven't quite covered yet, and it is client-side. So very broad, I would say.

21:11 Jon McLachlan

Do, do you find, like, that PCI DSS compliance requirement gets you a lot of traction or initial conversations or interest, or?

21:20 Simon Wijckmans

It's a similar situation to GDPR, I would say. So three to six months before GDPR compliance kicked in, a small percentage of people actively cared about it and were doing what they had to do. And then the twelve months after, there was a sudden crackdown by some company, like, by some regulators around the world to go after companies that weren't compliant. And nobody wants to be the story. And so at that point, a bunch more people care about it. I do not think that c/side as a company, the success of our business, is going to rely on PCI DSS. PCI DSS is one compliance element that is pushing people into the direction of securing this. It's not going to be the only one. I expect there's going to be more of these, and just in general, I think we need to be a little self-regulating at times, and understand that if we use random third-party domain names, that we should keep an eye on them, that we can't just have them render whatever they want in a browser of a user. So PCI DSS, for me, is a hook to talk to people that are more, like, compliance checkbox driven, that look at things as, yeah, I've got 20 projects to do this year, PCI DSS is one of them. It's an easier conversation starter with them. I tend to work most with actual engineers right now that understand the technical elements and the risks of this actual thing, and don't necessarily need a compliance reason.

22:35 Sasha Sinkevich

A lot more people are a lot more aware and cautious about security in general and data privacy. Hence, companies that try to grow their user base have to consider that fact. They have to consider that our user base is now more conscious about the security aspects and security controls. Hence, we have to provide all of the additional layers of security to make sure that we can continue building trust with our user base. So the landscape of security is definitely changing. It's no longer just the checkbox for the compliance, but rather you have to have basics covered in order to have the business in the first place.

23:12 Simon Wijckmans

Completely agree. The risk is that, unfortunately, people haven't, I would say, indexed this problem as one of their basics yet. But there's definitely some changes happening there. An attack like Polyfill gets this subject on people's radar. So in a way, I think we got very lucky that attack wasn't worse or impacted people in a more stealthy way, because it acted as a good wake-up call to people without people actually getting harmed. I mean, casino website pops up, close it, and you're fine, right? Your credentials being stolen, going after all of the places where you reused your credentials, [resetting] all of your accounts, that sounds like a bigger pain. Credit card information being stolen sounds more horrible.

23:50 Jon McLachlan

I mean, imagine that attack, but, like, only 1% was being redirected to adult websites, and then another 1% had their information secretly scraped. You don't know what you don't know.

24:02 Simon Wijckmans

Exactly. I mean, and there's been attacks in the past where IoT devices, so user agent of IoT devices, were used as the qualifier for sending a bad script or not. And so all of a sudden, there would be a bunch of crypto mining happening on a fridge, right? Or on your Tesla browser or something like that. This is the sort of stuff we're putting up with. It's not necessarily the most harmful thing either. Yeah, maybe your electricity bill goes up a little bit because your fridge is using more compute. I mean, the reality is you can do a lot of crazy things here. Anything a good web developer can do with a browser, a bad actor can do with a third-party script. So the expectations, I mean, the expectation from my side is that people should be more thoughtful about how they use third-party scripts. And browsers become more capable every day. We add more features to them to do more cool things, for front-end people to build cooler things. Bad actors then obviously have access to better tools as well to work with. So, yeah.

24:58 Jon McLachlan

And I'm so sorry, I apologize for this. The question around the PCI DSS, it was a little bit of a litmus test, almost, to try to see if your go-to-market strategy was more top-down-ish or more bottom-up-ish. From the gist of it, it sounds like you take advantage of both, but you're a little bit more engaged in the bottom-up-ish.

25:22 Simon Wijckmans

Yes. I mean, the bottom-up is where we get the most useful feedback from people, where I get to make our detection capabilities better, where people are very honest about, this is great, this is not great. At this stage of the company, and I mean, we're building c/side to be a company that we can go and talk to anybody, right? At this stage, the most valuable people to us are getting the individual developers to talk about us, that gives us feedback.

25:48 Jon McLachlan

And so, what's the, you mentioned you're a solo founder. That must be incredibly challenging in its own ways, I guess. You do away with certain number of challenges, and then you get a whole other bucket of challenges. Solo founder, but what's your typical day look like?

26:03 Simon Wijckmans

It's funny, 'cause I've not, I mean, in the past I've had projects with other people, but I think the co-founder journey is more challenging in many ways that you cannot control. And so I actually spoke to a very senior, amazing VC that was friends of a friend, and I asked her, I was like, hey, what should I do about this? Should I be going out of my way to find a co-founder, or can I just do this on my own? Like, I homeschooled myself. I've done a lot of things in my life on my own, from my bedroom. And the response was, finding a co-founder that you haven't worked with before, and that might result in, like, in a founder breakup, is a worse thing than just being a solo founder and knowing what you can do, and then surrounding yourself with other people to help you. And then, of course, as soon as you can afford it, get somebody to help you on an operations side, which is a current stage we're in right now. My day-to-day is literally a bunch of everything. I mean, I've got to do everything, from making sure that our compliance is in place, and that we are working towards getting a bunch of good customers, and keeping our engineering going, and product, and our website doesn't work in some areas, and hiring now, all of a sudden. It's literally everything. But I'm lucky to have the team that I have, and some of them are ex-colleagues of mine, some of them are people that I know from, like, my broader network. I knew very well who I was hiring and what that would give me as extra work or less work. And so far, people have really been great.

27:26 Jon McLachlan

Is your brother in tech too?

27:28 Simon Wijckmans

My brother is not.

27:29 Jon McLachlan

Your brother's not in tech. Okay. All right. So it wouldn't make any sense to invite him to work at c/side.

27:35 Simon Wijckmans

No, he's got an amazing job. He works at Nike. He does a bunch of sports things in his life, and he works at a sports brand. So it's, I would say, he found the job for him. So it's perfect.

27:46 Sasha Sinkevich

It's actually an interesting subject, because in a lot of security-related discussions or engineering-related discussions, what I've noticed is, often, when you bring someone outside, without the bubble mentality of tech and security, into the discussion, can often bring up interesting points that a group as a whole has not considered in the past.

28:11 Simon Wijckmans

Yeah, definitely. I mean, I think that's a general thing in life. If you [bring] people that are not necessarily as familiar with the subject as the specialists, they will ask very simple questions that we do not ask ourselves enough. I mean, and that's the thing about, I mean, we made a very basic video to explain, in what they call in Dutch [Jip-en-Janneketaal], a basic language, and anybody could understand what this issue is and why we're solving it. My grandparents understood it, my mom understood it, everybody understood it. That's how we should be talking about complex things, so that people actually are becoming more familiar with the security risks out there, and know also how to put pressure on the companies that they buy things from to do the right things. The fact is that the general public knew how security works nowadays. On some areas, they would be really excited and feel very safe, but in other areas, they would feel a little scared. I mean, explaining the thing again of threat feeds, the fact that there's literally companies out there that are spending their whole days on Twitter looking for people to complain about things, to then add it to a list of naughty things that should be blocked. The fact that that is still an industry, and that we heavily rely on that as security companies, that's quite shocking to the general public. Personally, I think we shouldn't be doing that anymore. We should be way more, like, on board and hands-on.

29:26 Jon McLachlan

The security companies plus Santa Claus at the North Pole, both with naughty lists.

29:31 Simon Wijckmans

There you go. I mean, block lists and things like that. I just call it a naughty list. People get what that means.

29:36 Jon McLachlan

I like dumbing it down and using simple language to describe complex topics. It's more inclusive. Can speak to more folks that way.

29:45 Simon Wijckmans

I mean, even my baby niece gets what I do as a result. So that makes it more fun.

29:49 Jon McLachlan

Absolutely. And if she understands what you're up to, maybe the world can be a little bit safer in the future.

29:55 Simon Wijckmans

Exactly.

29:56 Jon McLachlan

What's the best day that you've had so far at c/side? The best day. The absolute best. On top of the world. Maybe you closed a round. Maybe you hired someone that you just really needed and they played hard to get.

30:11 Simon Wijckmans

There's been some incredible highs for building this company. Actually, there haven't been that many very deep lows, but I'm sure at some point that will happen, and I think we'll all work together and make it a good day anyway. I mean, being able to hire the first few people that I looked up to in my career and I had as amazing colleagues, I was obviously high. We did a nice off-site with the team a few months ago, seeing everybody come together and just, yeah, being...

30:39 Jon McLachlan

[You have a remote-first]?

30:40 Simon Wijckmans

Yes, we're fully remote. I mean, there's a lot of chatter about whether that is the right thing to do or not in the entire industry. My perspective is that if people have worked for ten years and they had a good career so far, then likely they're going to want to move somewhere that they have space or whatever that they need, right? If some of them get kids, or some of them just want to move back to their home country and buy a nice flat, and they can, right? So meet people where their life makes sense for them. That's more my attitude. But a moment I was very happy was when the whole team came together. They got along very well. There was a really great chemistry. Even though those people never saw each other before, it was like they've known each other for a long time. That was a big high for me. I remember the first engineering kickoff we had, where I brought everybody into an actual, like, Zoom call, and we spoke about what we were going to work on. Remember, that was basically the best one I've had in my whole career. And then afterwards, I realized why that was. It was because I brought my favorite people that I worked with before together, and basically built that super team. And yeah, it worked out. So those were all moments that I was very excited. I mean, I, more recently, we haven't announced this publicly yet, but we [closed another round].

31:49 Jon McLachlan

Don't worry, we won't tell anyone.

31:50 Simon Wijckmans

I won't say anything I'm not allowed to say yet. There will be a big announcement in September. But bringing people together that I've looked up to so much in my life, that have really shaped the entire industry, that have invested in people that created new categories, it's been an experience like I couldn't have imagined. I'm a 26-year-old born in Belgium. When I looked out of my window, I saw fields with sheep and cows. The fact that a couple of years later, I'm here, building this company with some of the best people in the world, it's pretty exciting.

32:24 Jon McLachlan

So, yeah, that's amazing. I really feel the passion and the love and the care about the people that you work with. And so that's spectacular to see and to hear, but also to feel.

32:36 Simon Wijckmans

Thank you. I don't know what to say.

32:38 Jon McLachlan

Nothing to say. Of course, the next question after the best day is, what was the most challenging moment that you've had? And then, how did you find the strength, or navigate that complex, challenging moment, and come out on top?

32:53 Simon Wijckmans

I mean, put things in context here. So we've had a long wait list of people that wanted to use our product. We've got enterprises that want to use our product. We've been very thoughtful about who we let on when, to make sure that we don't make a major website go down, and that if we have a bad day, that it's not the worst day.

33:10 Sasha Sinkevich

Right.

33:11 Simon Wijckmans

So as a result, we haven't had incredibly bad days yet. I would say one of the worst days for me personally was that Polyfill day, which ended up being, in retrospect, a rather positive day, because it got people to talk about the risk. But that was literally the one day that I was going to take off to, yeah, take a break and relax, and literally Murphy's law, something that very rarely happens, just then. So that, for me personally, was tough. Like, we haven't had major setbacks aside from that. We will at some point. We are building a proxy service that proxies a bunch of, I would say most DoS or DDoS detection algorithms would flag us all the time because of the high level of concurrency that we got to deal with. I expect at some point there will be a really bad day. But we're doing everything we can to prevent that, going to extreme lengths. And the fact that the team has also gotten the experiences from their previous jobs to prevent that gives me some level of confidence that if we have a bad day, we'll be, like, we'll be set up to recover from it fast. I think we've been incredibly lucky. Not confident it remains that way, but we'll see.

34:15 Jon McLachlan

That's great. I mean, if you want to, I guess part of your marketing strategy, if you want to get more people to talk about these bad things to happen, you could just take more days off, and then more bad things will happen.

34:26 Simon Wijckmans

Yeah, I'm very bad at taking days off. I enjoy my work too much. But yeah, apparently if I take a day off, that's, yeah.

34:33 Jon McLachlan

I mean, I think there's also something to be said about, like, mental health and prioritizing that and making sure that burnout is a thing that doesn't happen. But at the same time, you balance that with, okay, you're building something. This is, you're bringing something new into the world. You want to give it the best shot that it possibly can, and you're dedicated to it. I mean, and not only that, but now there's, like, when there's investors, like, there's other people's money on the line. And now with employees or contractors out, also other people's livelihoods in the hook too, to build a business. No pressure.

35:08 Simon Wijckmans

The biggest moment of relief I've had was when that new round, we got to an agreement on that one. Terms were signed. I got the right people on board that I also back-channeled heavily to make sure that they would not put us all in prison for failing, right? Because that is, I mean, it's important to know who you were working with there and how they responded to other companies that didn't quite work out, right? The fact that I could look at the bank account and be like, okay, we've got years of runway. The people that I hired to join are going to be fine for the next few years. That was a moment that I had, like, a massive feeling of relief. I've personally gone through burnout stages in my career. I know what it feels like. I personally found that, for me, it's often not necessarily the amount of work, but the level of friction that you have to put up with in executing the tasks you got to do and the things that you care about. To give you a simple, like, explanation there, it's if you're in security and you're trying to build a thing that protects people, if then the whole organization turns against it, because for them it's not a priority, when your job is to prevent bad things from happening, that's incredibly exhausting on a personal level. Like, you just really don't feel like the organization understands your role. You feel disappointed, because you know that your job is going to be that when this inevitably bad thing happens, you're going to be the one on the call explaining to people, oops, sorry. Yeah. Those types of situations I'm very familiar with, and they create, like, immense harm to people. So burnout, massive problem. Creating a low-friction environment for people to do their best work, making sure people are personally invested in what they're doing, and that people respect each other on that basis and know that everybody's there with the best possible intentions, I think that helps a lot. But yeah, the founder burnout is [only] a thing. Just make sure that you surround yourself by the best possible people. Get investors that understand it. And one of my investors called me when I was going through our last round, and explained to him that I was tired, that it was a very intense two-week period of talking to everybody, going from meeting to meeting. He says, don't worry about it. Everybody gets sick when they go through this. So just know that this [isn't normal]. You're doing it right. And it worked out. And yeah, if it hadn't worked out, then this is the kind of job we're doing, right? Like, we try to build something new. Not everybody gets it. That's okay. And in the end, it makes you a better entrepreneur, better founder, better leader.

37:39 Sasha Sinkevich

I think you hit on a very important point, which is friction always distances actions. And it sounds, the product that you guys are building is removing a lot of friction, which is present today in the client-side security. Hence, c/side is an excellent name, I have to say.

38:00 Simon Wijckmans

I didn't even come up with it, but yes. I was calling the company Client Side Development Inc. as a legal name, and then someone told me, hey, Simon, you should consider calling it c/side. I said, c/side? Yeah, like the letter C, slash, side. I'm like, that's actually really cool. And then there we go. But yeah, I mean, to come back to the burnout point, I don't think necessarily this has been a cause of burnout documented anywhere yet, but the reality is that client-side security is an unowned area at many companies. And usually that means it's going to come down to the front-end engineer that actually put the code there, even though they weren't the one that requested it. So the marketing team is trying out fifteen different tools, and they all give them to a developer over Slack, Discord or Linear or whatever, and the front-end developer then implements it, and oh, one goes wrong, and it becomes their problem. And that's because of the lack of governance and the lack of process and the lack of ownership of who does that. Ideally, c/side is one of those tools that a developer just goes, I don't want to be liable for any of this stuff. I don't want this to be my problem. I'm just going to go to my boss, swipe the credit card, it's cheap enough, and we're going to just use c/side, and this is a problem that is not necessarily mine anymore. There's now a tool that will deal with this problem for me. Yeah, if that makes an engineer's day better, that would be a great [win] for me.

39:17 Sasha Sinkevich

There is another interesting technical aspect of this. You mentioned Google Analytics, and there are a lot of other tools. It just loads the script, but you don't really have the version control of that script. And each time you load a browser, you don't really know what changes have been made since the five seconds ago. And I'm sure it's an interesting problem statement in itself, and you guys are positioning yourself to take a step at this problem. And a lot of frameworks and regulation compliances speak specifically around the dynamically loaded JavaScripts in a browser. So that in itself is an interesting friction and problem point that could be addressed with something like c/side. If you had an abundance of time, say you were not running c/side today, in a fake, make-believe world, what other security domain do you think is ready for innovation?

40:16 Simon Wijckmans

I love this question, because there's just so much we can talk about there. I find that my mind naturally goes to the risks of our own physical security as work-from-home employees. 'Cause, I mean, I'm going to take another trip down memory lane. One of my previous employers used to rent office space [unclear], et cetera, and they had very tight physical security guidelines. Yet I was surrounded by Hikvision cameras, because of those co-working spaces using Hikvision as their camera vendor. Just a bit of a problem, right? There's been a few companies that have done great work at revolutionizing the space, companies like [Verkada]. But I still think that it's not a problem solved, and that it's not accessible enough to people. Making sure that the tools that you have in your house are listening in on you, making sure that where you go to work in the morning isn't being counted, monitored, et cetera. Making sure that those tools are not incredibly prone to attacking, and that people can't just SSH their way into the box and do bad things. That I see as an interesting problem. And you'd be surprised how massively behind that entire industry is. Most CCTV DVR boxes you'll find anywhere in the world will run the firmware that they were once shipped with in the beginning, some of which are just literally publicly known to be open to anybody to do bad things with. That I find an interesting space. I'm not saying that is a high priority problem, but it's definitely something that we should be more aware of, that whatever we put in our house, in our apartments, in our buildings, in our offices, as IoT, which includes security systems, themselves can be security problems. Other areas that I find interesting, there is this whole movement towards putting more things in clients, making web applications accessible offline. That is in the realm of c/side, right? And I find that a really interesting space, because we're just storing more sensitive stuff in browsers and basically making them like native apps that work offline. That I find a particularly interesting space as well. Yeah, that's just, honestly, Google companies that IPO'd ten years ago, look at their product, go build a better version. It's really not that difficult, because at the end of the day, a lot of these security companies have lost their employees that really pushed the company to innovate, and they just haven't innovated. So you can actually just build better versions of their stuff and build a good business around it.

42:45 Sasha Sinkevich

In other words, there's a lot to innovate on, enough to go around for quite some time.

42:49 Jon McLachlan

Okay, so, Simon, if you could go back in time, meet your younger self, two questions for you. Would you? And if you would, what would you tell your younger self?

43:02 Simon Wijckmans

I homeschooled myself since I was 14.

43:06 Jon McLachlan

Yes, you mentioned that. You've homeschooled yourself. So I was actually, I was homeschooled for a bit as well. Not by myself.

43:13 Simon Wijckmans

It was an interesting time, 'cause I was going through, I mean, the traditional public education system in Belgium, which at a certain point didn't allow me to bring a computer to school. It was even so bad that the government defunded, like, computer infrastructure in schools altogether. So yeah, it was...

43:30 Jon McLachlan

So you homeschooled yourself so you could gain access to computers.

43:35 Simon Wijckmans

Big chunk of that, yes. Also the fact that I just really didn't find the average person my age at that point to be that particularly interesting. And there were just really great people that I could spend more time with outside of school. I mean, I grew up in Belgium, very random place. There wasn't really a system for that. We figured out a hacky third-door approach to do it. That's the sort of thing I did. But that put a lot of strain on me personally, because I was a weird one. I was doing something that people didn't quite understand. But I had to go back to younger Simon, I would just tell him, trust the process. 'Cause everything I've done, the most painful jobs I've had to do, the most stressful times, including some really bad experiences at work, they all led me to become a better version of myself. When I was at Microsoft, I relocated from Belgium to Dublin, living on my own when I was 18, in a very different environment, going to the office very early in the morning, leaving very late in the evening. It was a weird time in my life, because I wasn't really enjoying that specific job I was doing at the time, but it taught me so much. So trust the process. And that's also what I try to tell people now, is, like, 18, 19-year-olds talk to me and ask me stuff, or build your own startups. I tend to tell people that if you really feel very deeply about a problem you're going after, it's probably not a bad thing to go work in that industry for two years, so you get the inside scoop of that space. So trust the process. Everything I've done in my career, in my life, has to an extent helped me with what I'm doing today. And if I had spent two more years working somewhere and learning about more things, I probably would be an even better version of myself. There's that golden moment that you feel like you're close enough, you can go do something. I felt that way a year ago. But yeah, I mean, trust the process.

45:21 Jon McLachlan

That's when you started c/side, a year ago.

45:25 Simon Wijckmans

2nd of January. But basically, this time last year, I started speaking to a VC or friend that knew somebody, and just high level started to network about it. But, like, a year ago today, I felt, okay, Simon, you've got this experience now. You've done these things. You should now start thinking about whether you want to go work somewhere again and maybe get a more senior level job, or put this to work to start your own thing. At that time, I decided, let's go get a more senior level job at a very early-stage startup and try and make that more successful. And then six months later, I realized that actually I would love to just go do something myself now. The investment space was also getting better, so investors were actually looking to invest in people again. Pre-seed funding. That wasn't quite the case, I would say, this time last year in the summer. So yeah, it was also timing of the market, I would say.

46:15 Sasha Sinkevich

If you could speak directly to the listeners of the show, is there anything that you would ask them? If there is anything that our listeners could potentially help with?

46:26 Simon Wijckmans

This is going to sound ridiculous, but it's true. Sign up to c/side and tell me what you think. I would love to hear people's perspective on how we're doing things, what could be better. c/side isn't really open source, but I would love a culture of feedback similar to the open source community, where people can tell us, c/side would be [10x] better for me if it did X, Y or Z better, or, I tried this and it didn't do what it needed to do for me, because I expected it to do something else. I'm just very receptive to feedback. So the smart listeners of this podcast, their feedback would be very much appreciated.

47:03 Jon McLachlan

We will put a link to the call to action in the description, so look for that in the description. We'll also put a link to your LinkedIn so that people can funnel all of the great feedback that they'll have. And really, it sounds like simple onboarding. You just have to include your JavaScript package in the page that's going to be loaded. You're pretty much done with the integration, right?

47:26 Simon Wijckmans

That's a high-level version. Something like that.

47:29 Jon McLachlan

Exactly. I'm totally butchering it.

47:30 Simon Wijckmans

But no, but you're right. Add our thing and let the magic work. That's the idea.

47:36 Jon McLachlan

Perfect. Perfect. I love the simplicity. I love the simplicity. Thank you so much for coming on to the show. It's been an absolute pleasure to have just a super warm, open, authentic, friendly discussion. Thanks for sharing vulnerable moments with us. Would you like to leave our listeners with any words of wisdom?

47:52 Simon Wijckmans

Well, firstly, thanks so much for having me again. It's been great to talk to both of you. I mean, I think a big hurdle that I had to jump, basically in December last year, you can always continue to look to learn more and more, but sometimes biting the bullet on a problem you faced is worth just starting your own company around. So my little word of wisdom to people is, don't be too harsh on yourself. That's other people's jobs. And go try and build an actual company yourself. Go build a better product. Go make a better internet. Use your skills. Go do a thing.

48:24 Jon McLachlan

Use your skills. Go do a thing. That's great advice. It's great advice, actually. Don't worry about it. Don't take things too seriously. Use your skills, go do a thing.

48:33 Sasha Sinkevich

Simon, thank you so much for your time, for your insights, for sharing with us your journey. We are super excited for the future, for you and for the company.

48:45 Simon Wijckmans

Thank you very much for having me.

48:47 Jon McLachlan

It's been an absolute pleasure. And thank you to all of our listeners for tuning in to another episode of the Security Podcast in Silicon Valley. I'm one of your hosts, Jon McLachlan, and I'm joined today with the other host, Sasha Sinkevich, Simon Wijckmans, the founder and CEO of c/side. This is a YSecurity production, and stay tuned for another episode. Take care, everyone. Thank you.