This transcript was generated automatically by AI. If you find any mistakes, please email us.
[00:00:00] Announcer: Hello, everyone. You're listening to Cloud Next, your go to source for cloud innovation and leaders insight brought to you by GlobalDots.
[00:00:14] Ganesh: Imagine a rapidly growing e-commerce company gearing up for the biggest sale of the year. The marketing team has been working overtime, anticipation is building, and everything hinges on success.
[00:00:24] on the seamless performance of their cloud infrastructure. But as the clock ticks closer to the launch, the IT team is caught in a frantic dance, navigating a labyrinth of cloud configurations and security protocols, trying to safeguard against the myriad of threats that loom in the digital [00:00:40] shadows. I'm Ganesh D'Awesome, and today's episode brings us to the heart of cloud security innovation with Stav Sitkinov, co founder and CTO of StreamSecurity, who is trying and succeeding in changing the stressful scenario So many companies face.
[00:00:56] Stav, before we start, what should people know about you?
[00:00:59] Stav: So my name Stav. As you mentioned, I'm 35 years old. Um, I live in Tel Aviv, Israel. Small girl, a wife and a dog. Um, I've been, um, since I can actually remember myself probably like from the age of 10 when I was first introduced to a computer. It's pretty late.
[00:01:18] Uh, I [00:01:20] think, um, Um, But that's where my parents were actually being able to buy me a computer. And since then, I'm in love in tech and infrastructure.
[00:01:29] Ganesh: So a little bit more than in love with tech and infrastructure, because you are now a co founder of your very own company called Stream Security. And it's [00:01:40] a cloud protection platform.
[00:01:42] Roughly speaking, can you share some of your insights on your journey to being a co founder? Um, I know that you started on a slightly different path when you first built this company. So can you walk us through that?
[00:01:53] Stav: Of course. So I think before, before I even came into the [00:02:00] conclusion of that, I want my own company doing something myself, um, I was working in tech for quite a while.
[00:02:07] I think it took a, took me like 10 years to actually feel that I'm ready to do something of my own and take a, you know, that destiny. Um, and I, my career path was a [00:02:20] bit different, I think from traditional founders in this space where usually they're in specific in Israel and everyone is like from 80 to a hundred and they go out of the army and they build a thing.
[00:02:30] I went out of the army and. Came to a pretty large enterprise, which was called Mellanox at the time, now it's NVIDIA. Um, and I went through the ranks from system [00:02:40] automation, um, you know, on prem stuff, virtualization, routers, firewall switches, stuff that most DevOps engineers today don't even know what it is and how do you connect it or manage it.
[00:02:51] Um, but that's where I actually began. Um, then I went to more development. position in chip design group where we [00:03:00] actually were building simulators in code to mimic what will be the behavior of a chip of a router before we actually go and build that because that process costs a lot of money. Um, then I took a break for a year.
[00:03:12] try to bootstrap actually something like a SaaS company myself understood that I don't really understand nothing business [00:03:20] and decided to close that with the team that we work. And I came back to Mellanox and thankfully, um, I had enough friends that I've worked with, which gave me the opportunity to go into the business world, um, where I led.
[00:03:34] And then I [00:03:40] was fortunate to work with amazing sales leaders and learn how, how sales is actually done. Right. So from, let's call it a development position to a salesy position, and then I actually transitioned to a technical marketing engineering role. Um, so I, I think I touched on a lot of the stuff that you as an entrepreneur [00:04:00] or building a company will need at least the understanding of to actually be successful.
[00:04:05] And even like hiring the people so that when you hire someone, you can talk with them and understand he should know much better than me, but I should know the basics. And that's where we started. And the initial idea, as you mentioned, [00:04:20] Um, for what we have built was we will build a technology that will be able to mimic and understand all of the dependencies in the cloud infrastructure in real time against any change.
[00:04:31] And the target persona, the person who we expected to use the product at that time was the DevOps engineer. And as you know, DevOps engineers specifically at smaller [00:04:40] companies, it's a bit different in larger enterprises. You need to touch on any aspect of your. infrastructure, code, CICD, security, FinOps, whatever it is, you'll do it.
[00:04:53] Um, and that's where we understood like, okay, we need to build a technology that will actually understand the cloud. And then on top of [00:05:00] that, give those engineers the ability to understand, okay, What drives costs, what drives security issues, what drives compliance issues, what drives reliability issues, et cetera.
[00:05:10] Um, as we started building the company and growing, we have felt that security is the way to be and on the go to market side, that the truth, [00:05:20] um, security as a market is, is much more mature and specifically on budget. Let's let's tell you the truth. And, and we have seen that the use cases that those.
[00:05:31] People who actually decided to buy the product in a very early stage started to become more and more security oriented. And that's where basically three quarters [00:05:40] ago, mid 2023, we decided to change a bit the go to market and do it a full blown security product while our users at the end are still.
[00:05:49] Mostly spread in between security and DevOps. And that's where we are today, basically.
[00:05:54] Ganesh: So I, I, I resonate with you in, in knowing all of [00:06:00] these old things about VM and converting old physical servers into, into things. It makes, slowly making me feel a little bit old about these things also. And I would say 10 years is not much at all.
[00:06:13] Um, I'm, I'm 17 years now, I would have nowhere near the courage to go into the co founding, but I think [00:06:20] that's something that's in the, seems to be in the DNA of, um, is of the startup in Israel. It's like a, excuse me, it's just part of the programming deep down inside. Um, so the, talking about your, so your company, quite interesting, you mentioned that I hadn't put, I just sort of [00:06:40] thought about it while you were talking, but the.
[00:06:42] The purpose of your, your tool really is to provide a kind of a cloud twin that you can analyze rather than looking at the actual cloud, how much of that was born out of looking at tools to imitate what a router does, like, [00:07:00] sounds like that was your inspiration for, for what built it out and if it wasn't, what was your inspiration?
[00:07:06] Stav: So actually you, you. You've touched on the exact point, and that was part of the thinking of how we can build what we're actually building today. So, um, myself, during the work at the chip design [00:07:20] and those simulations, we were, we needed to mimic parts. Um, of a router, right? And then every part you need to mimic what will be the input and expected output in different configuration states.
[00:07:31] And that's basically the basis of the Cloud Twin. And of course, I have two amazing co founders where one of them has been [00:07:40] building FPGAs. similar processes. And the other one is actually like a software genius who was able to take my concepts and actually build it out. So that was his part. And, and when we decided to build the cloud twin, the idea was like, how do you take basically every large concept in the cloud?
[00:07:59] And [00:08:00] that might be from the smallest parts to the biggest ones, like a routing table, an ACL, an IAM policy, right? Um, transit gateways and such, right? And all of those blocks are blocks that are being networked at the end, right? Same, similar thing that we had on on prem, similar concept. And [00:08:20] then WAFs and the permissions are additional agnostic layers of additional things, right?
[00:08:26] And the challenge in building a cloud twin truly And that's why it actually took us like two years to develop it out of the box, is that You need to process data at the speed of cloud. Now the speed of cloud is [00:08:40] much faster as everyone knows, then the speed of on prem. Somebody pops up a new instance in your Lambda function and you pod in this Kubernetes environment, does some changes and things happen.
[00:08:51] Now for us to be able to do that at scale, we had to build an engine that can calculate the impact of each of those changes, provide you the [00:09:00] output and the actual conclusion of what happens right now at that moment. Um, And I think that the approach we took, um, which at the beginning, I think nobody actually believed us that it's possible to build that was like one of the challenges.
[00:09:16] I think that we were, um, let's call it [00:09:20] naive by thinking that it will be easy. Um, it took us more than we expected. But once we broke multiple, uh, let's call it walls in the way, um, I think we now we have a very strong IP and that's the main differentiator between our tool and current solutions in the market where [00:09:40] we do it in real time against any change while others will scan periodically.
[00:09:45] Usually at scale, it will be like once a day and we'll give you like, those are all of the issues that you have. Good luck. You have no idea what changed, who did it. And then that's bring you to the point where. We believe the biggest challenge is, the challenge is not in detecting all of the [00:10:00] issues, right?
[00:10:00] The challenge is how do you understand who did the changes? How do you remediate them? And by understanding who did the change and what was changed, it is super easy to remediate, right? Because you will just revert the issues that you have done. Now that's the difference, the big difference in between how we Perceive cloud security, cloud operations versus [00:10:20] the tools that we have in current generation.
[00:10:22] It's got like that, that basically took the concept we had in on prem data centers where we like scanned everything once a day and nobody will touch anything, right? This, my server, probably the servers that I've been using in Mellanox are still there in the REC, right? They're in the same place, nobody touched them, the cables are still [00:10:40] there.
[00:10:40] And that's where we perceive the difference in cloud happens. And luckily for us, um, I think that the evolution of AI that happens and that that moves very fast during the past two or three years, um, will actually bring the attack vector and capabilities of threat actors to [00:11:00] move much faster in the cloud.
[00:11:01] We already see some example of that. So enumerations are much faster, et cetera. And I think that in a year or two, you want to see people continue to use tools that are still point in time, uh, scanners due to that.
[00:11:17] Ganesh: I love the idea of the technology, the [00:11:20] cloud twin. It's What, what VMs were to original bare metal machines and then everything got virtualized and then it's like the virtualization on top of the virtualization, it's like Russian dolls or something where it's each layer is just another abstraction and another abstraction.[00:11:40]
[00:11:40] I like to think of it actually. I don't know if you're familiar, you're probably familiar, there's a sort of way, you know, it's a what if query, if you're in, if you're into data and analytics, so if you're looking at, um, information about anything, population or census data, you can say, you know, what, what if [00:12:00] you can feed in these queries, and it's very basic, you know, it's like, Well, if there was 10, 000 more people and then everything goes up in, in cost, the, the ability of your platform to handle these, what if queries, you know, how do you see it going forwards in the future?
[00:12:17] It'd be quite interesting to know, because if you have, you, [00:12:20] you have like programmable data set. It's almost a bit like, um, capturing weather or something, you know, you can look at weather and say, what, what if happens and try and predict outcomes? How do you, how do you see yourself in that?
[00:12:32] Stav: That's, that's a great question.
[00:12:34] So think about it like that, how weather is forecasted today. There are simulators, which run in [00:12:40] huge high performance computing environments to simulate the environment, and then to simulate what will weather will behave in case of a what if scenario, um, but you can do the same in the cloud. If you understand.
[00:12:52] The, what are, what are the dependencies in the cloud? And then if you are able to understand the actual behaviors that happens on this [00:13:00] cloud, you can do what if scenarios on that cloud. Now, if you look specifically at security, um, the, what if scenarios are. What is the possible attack vector into my environment based on the actual posture and the data activities that is happening on top of it, which usually it will be [00:13:20] identities, usually humans or machines, which will manipulate network or identities as well.
[00:13:25] Now that what if scenario is what actually enables us to understand those attack vectors, like, right, so you can basically populate the model and understand, like, if that. Vector is going to happen. What are the [00:13:40] next steps that could be happening? Um, when we started the company actually, um, we had a customer who talked with us about like a what if scenario of scale, right?
[00:13:49] So what will happen when I need to now scale up my entire e-commerce website? to a traffic, which is 10 X than what we have today. Now [00:14:00] they have the scenario, they have the playbook. They know that like they would need to go to the auto scaling groups, make them bigger. Um, I don't know. And whatever they have else to scale.
[00:14:09] But what about the Kafka? Will my Kafka be able to observe that? Um, I think technology wise, this is not something that we're solving today. Um, but technology wise, I think [00:14:20] that's where we will be heading. So think about it. Like if you have. observability companies that actually observe the entire data and all of the dependencies, whether those are like APMs, tracing metrics, et cetera.
[00:14:32] If you take all of them and push them into a model, which understand all of the dependencies, in theory, you can say, what if [00:14:40] my website is going to hit by 100,000 users at once, what will happen? Will my Kafka be, will the the scale of my Kafka be able to hold it? Right? Kafka is something that doesn't autoscale.
[00:14:53] You actually need to manage it. Our infrastructure is still not fully auto scalable unless [00:15:00] you use everything serverless. Um, I'm not familiar with too many companies that have serverless everywhere we can. discuss into that and why, for example, we decided not to use serverless function of vendors. Um, and why we do use managed services, but we try to find like the ones that have [00:15:20] open APIs.
[00:15:20] And I think that's, that's a bit different answer to your question, but I think that the cloud will at the end, find its way into a mesh where in our organization will use serverless, non serverless, et cetera, um, That's what I believe.
[00:15:36] Ganesh: That's a, that's a great answer. So we, we also, we [00:15:40] talked a bit about your initial pivot, which is, um, maybe not so huge actually, because the, the, the, the platform underneath was just, it just went in a slightly different direction, but all of the, all of the difficult bit of building that was, it's still fit for purpose.
[00:15:59] Um, [00:16:00] could you share anything just for any other co founders or, or What you, what were some learnings out of that or what, what possibly good or poor decisions came out of it, you know, deciding to keep features or remove features or, or just, uh, any advice for people who may be finding themselves in a similar situation?
[00:16:18] Stav: I will split [00:16:20] my answer into multiple points. So I think there are the technology points, right? Um, if you, if you need to pivot on the technology layer. At the stage where you already invested like two years, it's going to be super hard unless it's a small change, right? And thankfully on that part, we didn't need to do too [00:16:40] much.
[00:16:40] We had to add stuff on top of what we already had, right? But that was the easiest part, I think. On the product layer, I think that it really depends on how many customers you have at that moment using features that you think you don't need anymore, right? And that's a product decision. [00:17:00] Um, we had to cut features from the go to market approach while still keeping them in the product, right?
[00:17:08] Um, will they be there in the future? Depends. Right? Um, but as you refocus your go to market, the actual use cases and the users [00:17:20] that use the product, the product, they will drive you to the product. You know, to the features that are needed, they're not needed. And you can track that today pretty easily with many different tools that you have.
[00:17:31] Um, I think that thankfully for us, we just reduce the focus of features that were, [00:17:40] let's call it, Outside of the scope of security, um, we still have some of those because we have customers who love those and, and use them, but we do not charge for them, right? So it's not like if a customer will come and tell us we need a feature here, we won't develop it.
[00:17:54] You get it for free, for now. We're not obligated to continue [00:18:00] developing it, etc. Um, And I think that on the go to market approach, our way, well, like we intersected with security in many ways, even in the early days when it was purely DevOps, we still had security use cases. And actually security was most cases paying the budget for DevOps because that, you know, it's easier [00:18:20] for those to find budgets when they go to security, usually there is a budget there.
[00:18:24] And I think the, the challenges in that is how do you take an entire engineering. organization, which is focused on a specific user persona and tell them, okay, guys, everything you, we knew till now. [00:18:40] might be wrong. We need to think about everything again. Um, even like the basic screens, you know, in the system, um, where even like back then they could populate multiple use cases, you want to refocus them on the security first.
[00:18:55] So you need to find those adoptions and on the marketing, et cetera, like, [00:19:00] you know, we had to change everything. So we changed who we outbound to, who we market to the website, et cetera. I think it's a hard decision for a startup to do, especially if you are in love with the technology and the problems at the moment that you, you wanted to solve.
[00:19:17] Um, but business wise, it, it [00:19:20] was very good for us. Once we pivoted, we were able to, um, start approaching 1, 500 and large public, public enterprises, um, on the security use cases. And the entry point was easier than in DevOps. Um, I think that we are on a [00:19:40] successful path right now. And that's that direction.
[00:19:42] Ganesh: I think you're allowed one pivot in business as well.
[00:19:45] And I don't think you can have more than one, but as a tech startup, you have a dream and it turns out actually that your dream was sort of on the right path, but it's a little bit off. You're allowed one, I think more than one, and you start to lose credibility in the [00:20:00] world. Um, Your, your technology generally, and we, we know the landscape is full of technologies like this.
[00:20:09] And so people will be familiar with Orca Security, Lacework, whatever. There's a, there's quite a few that are crammed into this space. We [00:20:20] see what makes you different. Um, I, I'm keen to see. What's, what's this, what's, how difficult is what you've set up and, and just the nuances of difference and why you wouldn't fear someone like Wiz stealing the feature and building it out as part of their next release.
[00:20:38] What are your thoughts on that?
[00:20:39] Stav: [00:20:40] It's, it's not the feature, right? So features are things that you build on top of an engine, um, that, that serves your customers at the end. Right. where usually that's at the engine, nobody sees it, right? It's underneath the hood. It's like taking a Tesla and versus a Dodge Viper.
[00:20:59] Who wins? [00:21:00] You will know after the race, depending on the engine, depending on others, other stuff. Um, so. With regards to like Wizz, Orca, Lacework, Sysdig, all of those are amazing companies, of course. But at the end, they, all of them still took an approach which was brought from vulnerability scanners, right?
[00:21:19] [00:21:20] You'll statically scan the entire environment. If we will look at The progression of those tools over the years, let's call it, there was like the phase one where we scanned configurations on actual assets separately and said, like, that means that's a misconfiguration, that's a CV. Second [00:21:40] phase is what basically Orca and Wiz pioneered, I think, into the market during the past years was like, we'll take all of those configurations.
[00:21:47] We understand the dependencies of them, and we will provide you the risks and the toxic combination that are found between configurations and vulnerabilities, which took the market, I think, a huge advancement with how we can [00:22:00] actually detect, like, what are the stuff that we need to fix, right? And because at a larger organization, the findings, the amount of findings will be huge.
[00:22:09] So you want to reduce those to the actual critical ones, right? The issue with that is that we still have a gap. Right, where the gap is between the [00:22:20] security posture scanners, which do their job greatly and find the issues once a day. And the same where the same is the component that does a real time analysis of changes in my environment, but it has no context.
[00:22:34] And that's the gap that we need to, we came to feel at the end as part of the pivot. Now, [00:22:40] technology wise, there is a huge difference on how you calculate. a separate change and what its entire impact, the impact on the entire infrastructure versus doing a scan and then building out the output of that.
[00:22:54] When you calculate a change, you need to understand the entire dependencies across all [00:23:00] of the components in the infrastructure because you have no idea what will be the impact of the change before you actually get it. So security tools will calculate the security posture. We calculate the entire cloud posture, and then you need to write very fast algorithms and And other parts of IP that we have on how do you understand what is the impact [00:23:20] of that change now that impact if it's on a centralized location of the customer cloud, for example, that you know, let's take a an enterprise running on AWS.
[00:23:30] Usually they will have like a huge AWS control tower architecture, right? Hundreds of accounts, pub and sub connections between all of them. Now what happened [00:23:40] when somebody changes the centralized transit gateway? You have no idea. The blast radius is huge. You will need to calculate a metrics of sources and destination, which is very, very large, right?
[00:23:53] Now, those tools today don't even calculate cross account dependencies. They will tell you like that asset has access to that account. They [00:24:00] have no idea what in the account because of, of the scale of the calculation. We were able to actually do it in real time against the change. Um, so features. are not the thing that I think makes us unique.
[00:24:15] The uniqueness is the engine that allows us to do those impact analyses, [00:24:20] that's the gap. So we don't see, we are not, we are not in a fear that somebody will copy that. Um, I think that if, if, if you want Someone else will do it as well. It will basically show the market that what we're doing is actually like, you know, the next thing in tech.
[00:24:36] So we want someone to come and compete actually with us against [00:24:40] that. That's, that's how you build categories in cyber. Yeah.
[00:24:44] Ganesh: I like the idea that that's, that's a good thing when they start to try and mimic you, cause then, you know, you've picked a good place to go. It's, it seems like, I mean, we, we could talk philosophically about it, but.
[00:24:57] They. The, the cloud [00:25:00] twin in general, I know you, you've now focused on security, but actually there's tons of tons of use cases. If you start really getting into it or exposing that engine for other people to build other tools, it's almost like. The, the purpose of a cloud twin or building a cloud [00:25:20] twin is it's, it's multi purpose and actually your security product is just one.
[00:25:27] And if you expose your APIs, like a FinOps tool could sit and program things on top of it, or, uh, you know, a, a, an other tool and an identity and access management tool could, could look at what a user breach looks like, or, or blah, [00:25:40] blah, blah, blah, blah. Um, We, what, what are your thoughts about that? Like the, the evolution.
[00:25:46] So maybe you build something unique at the moment. Where do you see the evolution of cloud security? Where do you see that going?
[00:25:53] Stav: That's a great question. So I think that first of all, we as a company understood it, um, not so [00:26:00] long ago that security at the end, um, in most customers where they start to scale.
[00:26:07] is an integration play, right? Like any customers that you will go to, which has massive amounts of infrastructure in the cloud, they will have multiple tools, right? Um, they will have something dedicated for OPSEC, they will have [00:26:20] something dedicated for vulnerability scanning, they will have a bunch of other tools around it, like CloudFlare for WAF and DDoS, right?
[00:26:27] Maybe it's the actual WAF of the cloud provider. And then, our thought about is, And this is how we look on what we're doing forward and both our road map is that how we play together [00:26:40] and improve those tools with the information that we got. So, for example, let's say I have a WAF in place, right? It might be cloud third, it might be AWS WAF.
[00:26:50] Now, a vulnerability is found. And that vulnerability finding is not coming from us. We are an integrative play. We integrate with AWS Inspector, Qualys, [00:27:00] Tenable, Snyk, whatever you have there. Now, when that vulnerability is found, um, the fix of that vulnerability can actually be in, in multiple ways, right?
[00:27:12] Beside patching the actual image of the container or the instance, I can go to my WAF and maybe set a policy that will block [00:27:20] that. Maybe my WAF is already blocking that with the ruling and policies that I have. Now most tools today will not understand that because they don't have the posture understanding of the WAF.
[00:27:31] And maybe they Don't look at it at all. We believe that to help basically teams harden the infrastructure, if you play an [00:27:40] integrative playing between the security tooling at hand, for example, if the AWS inspector found a vulnerability, our system understand that that asset is currently covered by a WAF.
[00:27:50] That WAF might be even Cloudflare. Maybe the best way to mitigate that because there is no fix at the moment is to actually go and set some policy on the WAF of Cloudflare and then [00:28:00] tell the customer, listen, you have that CV, but you are protected because that, uh, the traffic coming to that microservice is passing through Cloudflare, which has that policy in place.
[00:28:10] Now, same thing can be done with workload protection, right? Like at the enterprise, you will see a lot of CrowdStrike, Sentinel one, et cetera. Um, and they are amazing tools, but they were [00:28:20] purposely built. to run on compute assets. Um, and they were built in a generic way. They have no understanding of your infrastructure.
[00:28:30] Now, what if a tool like ours is in place and understand the entire infrastructure around that asset, the current issues and risks that it might have in your [00:28:40] infrastructure. Then you can actually communicate via APIs and maybe modify the policies a bit of the worker protection, set different declarations of what is critical and what is not.
[00:28:50] And so that's where I believe cloud security would go to. And that's our thinking, right? There is a different thinking in the world right now. If you look at the big vendors where they do what [00:29:00] they try to basically say, we are the platform, come and get everything from us. I think that at least what we see in the real life is that beside like the 10 percent where we'll actually buy everything from a single vendor, most customers will have multiple vendors covering different issues in their [00:29:20] infrastructure.
[00:29:20] And I think that we, and hopefully us will be basically the layer that aggregates in between them. And that's our way forward.
[00:29:30] Ganesh: I like aggregation seems to be the way. Of everything at the moment and context is king [00:29:40] and I see it happening across quite a few areas. So, um, the, the AppSec pipeline is something that I'm sort of very heavily involved or interested in at the moment.
[00:29:52] And. It's like you said, if you, if you add something to your source code, but then you don't actually use it later on [00:30:00] in the cloud, or even if you have, you know, you've referenced it, but the container is not turned on. That's not a vulnerability. The thing that scans the code will tell you it is a vulnerability.
[00:30:10] So anybody linking together all of these different tech, you know, previous technologies that used to be. Individuals now they're all aggregated. I see that as the, [00:30:20] that is definitely, I see it going that way where the platforms, it's just, just more and more aggregation so that you can have more of this insight.
[00:30:28] I can't imagine what a tool looks like that. manages to plug into all of those different aspects and then suggests you three ways to fix a problem. That would be insane. It would be [00:30:40] so powerful. So the
[00:30:40] Stav: question, if you,
[00:30:41] Ganesh: yeah,
[00:30:42] Stav: no, no, go
[00:30:42] Ganesh: on.
[00:30:44] Stav: So the question is if you want a single tool to do it for you, or you want a tool to orchestrate it between those dependencies and update the other tools, because at the end, even in AppSec, as you mentioned, like there are great.
[00:30:55] Companies right now in AppSec doing those type of like, what is happening in my CICD? What [00:31:00] is scanning? What? How do I clear dependencies in that? Those tools are built for a specific purpose, for a specific end user, which usually the end user should be a developer. writing code, right? Now, I don't think there will be a platform that will take all of that information and will give it in the best way possible to a developer, a [00:31:20] DevOps, an SRE, and a SecOps, and an InfoSec engineer.
[00:31:22] And in, in the enterprises, you have dedicated vulnerabilities management people as well. So I think that actually like the API play, sorry, in between the tools. Where you will add the context that you have mentioned, like, right. I wrote my code, Snyk scanned it. That's amazing. [00:31:40] I got 10 CVs, one critical. Is that package loaded?
[00:31:45] No. There are companies who check if packages are loaded in runtime, right? Oligo is a great example, I think, in Israel that is doing a very good job at that space. But again, Yeah. They didn't scan the code. If Oligo gives me that insight, then let's say, for [00:32:00] example, stream security detects that that asset is actually exposed to the internet and has the possibility to do a privilege escalation to an admin user.
[00:32:08] And I can't fix that right now. And it connects to my code, the developer can easily understand why I should fix that code right now. Right? So I think that the connection will be like, okay, [00:32:20] the finding happened in runtime, somebody connected it, somebody alerted in the tool that scanned that code, that there is a runtime reason to fix that.
[00:32:29] And that's the reason. And the developer will still have an experience with the project. product that he is working at hand. And I think that cyber specifically to succeed, to build [00:32:40] what, what you said, which I think is like the Holy Grail, will be like an integrative play and not a single company play because otherwise, um, for that company to grow, they will need to build the features that they are integrating with.
[00:32:52] I,
[00:32:52] Ganesh: I totally agree. There'll be, uh, eventually it's going to take a lot of collaboration, but eventually some sort [00:33:00] of, I mean, we managed to get a common format for APIs. So we, we, we got there for APIs eventually after people doing loads of stupid things. So it seems like inter product operability or inter product alerts or whatever you want to call that thing, where we'll get there eventually.
[00:33:17] Um,
[00:33:18] Stav: there are, there are multiple [00:33:20] initiatives, by the way, in that area of like, uh, formats to alert between products and such, right? I think it would take a lot of time, but I think the industry is going in that direction, at least in the companies that You know, are still pretty early in the stages, not like the huge enterprises were there.
[00:33:38] They have a different play, [00:33:40] um, where it's like at the end, uh, best of breed or best of sweet. I believe constantly in best of breed, um, but we'll see where the industry will go.
[00:33:50] Ganesh: I look forward to that industry standard. Being released on a Monday and then by, by Wednesday, there'll be a [00:34:00] fork and there'll be two versions, you know, we know, we know how that goes.
[00:34:03] Um, so go back to your company. Um, it'd be really interesting to know, you know, you've built a company from the ground up, lots of problems. Have you found any specific tools or hacks with, um, [00:34:20] managing your team, especially, you know, related to the fact you're building a cyber security company, anything in there that you could share is.
[00:34:27] Yeah. As I say, as a management tool or a, or a, or a piece of software or something you
[00:34:32] Stav: use. Um, so I think that from, from day one, we've used the code scanning security, right? I think [00:34:40] like as you want developers, especially small companies, when you don't have a dedicated security team, right? You need developers to own things, whether it's security to scan the code very early, um, to patch automatically, whatever you can.
[00:34:56] Um, a lot of times it actually breaks You record, it happens, [00:35:00] so a non breaking change is becoming a breaking change because the import of that version actually does not work with a different version that happens in life, but you don't deploy to production, right? So you can have that not working on a developer's PC or demo environment, and then you fix it.
[00:35:17] So I think that's important. One of the [00:35:20] things that I think took us too long to understand, but thankfully we are there right now, is that you want your developers from day one to think about cost, not about performance because performance is something that they think about it by nature. That's software engineer, that's his job.
[00:35:38] Like I need to build [00:35:40] something that is performing, but when you build stuff that are performing by design, many times in the cloud. They become costly. Um, for example, I write a code that needs to handle a lot of data. I have two options. I can save to the DB, write from the DB, save to the DB, and write from the DB.
[00:35:59] Or I [00:36:00] can handle all of that in memory. Now, when I handle all of that in memory, it means that my microservice becomes bigger at peaks. Now, what does that mean? That I'm paying a lot of money to the cloud vendor. Um, and then when you think about costs, um, and the own costs. They understand that the decision they make might impact [00:36:20] performance.
[00:36:21] Um, but actually performance wise, it might become better. So maybe the language that we have chose for that microservice is not handling memory good enough. We need to change it and then it will reduce costs as well. So cost, I think actually forces you to build much better software than thinking of performance because they will at the [00:36:40] end is the same thing.
[00:36:42] But cost is easier to, let's call it feel. And specifically in a startup, when you start to scale and the amount of customers grows, um, when you have like 10 customers running on a multi tenant, it's, it's fun. Then when you get larger customers, everything is, changing, [00:37:00] right? And then, um, your AWS bill or whatever cloud you're using starts grows and you understand like, okay, we are super optimized on the infrastructure layer.
[00:37:09] Like we have carpenter, we have been packing, we have, like all of the data transfer figured out between availability zones and spot instances arise, whatever you want. So you are [00:37:20] optimized. The real cost in cloud is software. It's not the infrastructure, it's not those optimization, like you can get a great tool or a great partner like GlobalDots in this example that will help you optimize that cloud infrastructure cost.
[00:37:35] But the real cost once you get there is your software and usually software in [00:37:40] startups and enterprises as well is not written with the thinking of, okay, like, How do we make sure that that is not using too much money? What are the ways we have to implement that? But it's, it's with the thinking of performance and then those two can collide, um, when you serve a lot of customers on the Microsoft.
[00:37:59] It's [00:38:00] funny
[00:38:00] Ganesh: you're talking about that always reminds me that I have to go back very far in my history to think about these things, but whenever you used to set anything up in the days before SAS, the requirements for that at an individual piece of software would always be. Needs, you know, 24 gig of RAM and [00:38:20] 20 processes or whatever, you know, always, always, always the specifications were just totally through the roof.
[00:38:26] I think it's like, that's the modern version of that is what you've just described basically, you know, the, the, the knowing that you can just use the most. The beefy solutions from the cloud provider when actually you shouldn't be doing that. [00:38:40] Interestingly, code is a huge part of it that people don't think about as well.
[00:38:43] I mean, Python is super popular out there, but it's, I can't remember the statistic. It's like 27 times, uh, more expensive to use than C sharp, something like that. You know, so they, even the. Even the languages and stuff like that that people use. I mean, they don't really matter so much as a [00:39:00] startup, but if you suddenly become enterprise scale, maybe those things are even on the radar.
[00:39:04] Stav: You, you hit, you hit exactly on the point. Like we have a mic, well, I'll be very honest and that's how I came to that. So decision that you make at the beginning. Um, at a startup, you want to run fast, right? So you will write with the easiest possible code and [00:39:20] in areas that you know are, will be problematic to write in different languages.
[00:39:23] So for us, for example, our stack is composed out of three main languages, Golang, where we use for the data pipelines, right? Makes sense. Then 90 percent of our architecture is Python and Java in some algorithmic areas. Now the issue that I [00:39:40] mentioned with the memory, it's something we had with Python, right?
[00:39:43] That we develop fast. Um, But that Python code, specifically when working with memory, is super un unoptimized. Let's go out like that. And you can't solve it with Python. Like, we have the best developers, I think, and with experience in Python, you need to [00:40:00] rewrite it. So now we are paying that debt in rewriting parts of that microservices with Go.
[00:40:06] And that's stuff that you, you need to hit and fix as you grow. But if you have developers who are thinking about costs, um, ahead of time, I think like you will understand like Python, by the way, is [00:40:20] highly performant language. So you can perform very well with it. Um, but you will pay a lot for that, right?
[00:40:25] As you mentioned. And that's exactly the point that I was mentioning.
[00:40:28] Ganesh: That tickles me that that was my example. And that is, that is exactly your pain. Um, uh, we always like to ask people who come on the show, if you could go back in time and give yourself one [00:40:40] piece of professional advice, what would it be?
[00:40:42] And maybe, um, Maybe it's coding in Python, but maybe it's not.
[00:40:47] Stav: So I think it won't be coding in Python because Python is a great language. And you just need to decide where you use that or use other languages. Um, but I think on, [00:41:00] on, on this, this journey as a startup, the balance in between how many unit testing Right.
[00:41:08] This is how many, how much code you write, maybe what is the right methodology around that. So I think we started too late with that. And I, [00:41:20] I would probably my next company or my next journey and would start with actually building a much more robust infrastructure. Of unit testing when and end-to-end testing, um, around that because that's something that takes a long time to catch up with once you are writing a lot of code.[00:41:40]
[00:41:40] So if you are actually having that from day one, um, that can help you a lot in the, in the future, I think. And that's, that's a point that I would say for myself to, to the next, uh, next thing.
[00:41:53] Ganesh: That it's a, that's a good piece of advice. Not, not something that I've heard before either, to be honest. So, um, [00:42:00] that's, that's interesting.
[00:42:02] Um, we we're coming to the close of the episode. It's always interesting to know how you keep on top of things. You know, we live in a very fast paced tech environment. Is there any particular blogs or podcasts or news sources or how do you, how do you stay on top?
[00:42:19] Stav: [00:42:20] Um, if you want to keep up with the technology pace, you need to.
[00:42:24] read and listen to things outside of your scope. So because of the fact that everything is moving fast, as you mentioned, like AI is, is huge, right? I didn't even touch on that, but if you want to keep up with everything going on, and let's [00:42:40] say you want to be the best DevOps engineer in the world, you still need to look around what you're doing.
[00:42:45] Um, because the actual next big change that will impact yourself might not come from the areas that you are thinking about. And that's, that's my suggestion.
[00:42:56] Ganesh: Wise words. And that's a lovely way to close out the [00:43:00] show. Um, Stab has been. Totally great talking to you. Thank you so much for coming on the show.
[00:43:05] We really appreciate it. Um, any final words?
[00:43:08] Stav: Thank you Ganesh for hosting me. It was a pleasure and thank you for giving me the opportunity for my first podcast.
[00:43:13] Ganesh: Pleasure. Loved it. This episode was produced and edited by Daniel Ohana and Tomer [00:43:20] Morvinson. Sound editing and mixed by Bren Russell. I'm Ganesh the Awesome.
[00:43:24] And if you're ready to deep dive and start transforming the way you approach cloud practices and cybersecurity strategies, then the team and myself at Global Dots. I'm at your disposal. We are cloud innovation hunters, and we search the globe looking for the future tech solutions so we can bring them to you.[00:43:40]
[00:43:40] We've been doing it for over 20 years. It's what we do. If I don't say so myself, we do pretty well. So have a word with the experts. Don't be shy and remember that conversations are always for free.
