Marcin Wyszynski: [00:00:00] I'll sound very cynical. What people are saying and what people are doing are two different things. I think frequently what I see about security processes is that they're written for auditors. If the process makes it harder to get the job done, the process will not be found, period.

Ashish Rajan: So how does this gonna apply to your audit logging

Marcin Wyszynski: An S3 bucket change?

Why? Yep. There was an API call made from this and this, right? That's what in cloud Trip. Thank you, captain. Now. You could also be a North Korean hacker that got those static credentials. I think what hurts us most is what we don't see.

Ashish Rajan: If you work for a startup or a scale up. Security probably is not always available, but sometimes it's harder to translate why security is important to a team of smart engineers like your devs or platform team.

I had the pleasure of talking to Martin from Spacelift. We spoke about his transition from being a Google SRE, what he learned over there, and later on, how it led to him identifying the problem in the infrastructure as code space and why he [00:01:00] decided to spend a lot of time in that infrastructure as code space to help improve that and bridge the gap that is existing with security blind spots in a lot of startups and scale ups these days. So if you already work in a startup or scale up or trying to solve the problem in a startup that you're probably looking to be part of, I would definitely recommend this episode. But if you know someone who's probably doing the same as well, definitely share the episode with them.

As always, if you have been listening or watching an episode of Cloud Security Podcast for a second or third. If I can ask you to take a few seconds to hit the subscriber follow button, either on Apple, Spotify or on YouTube or LinkedIn, if that's where you're watching or listening to this episode. Thank you so much for all these support and I will let you enjoy this episode with Martin and I'll talk to you soon.

Peace. Hello and welcome to episode of Cloud Security Podcast. I've got Marc in here. Hey man, thanks so much for coming for the show.

Marcin Wyszynski: Hey, thanks for having me. How are you?

Ashish Rajan: Good, and I am well, I was, let's just say infrastructure as code has not been spoken about for some time on cloud security podcast, so I'm very [00:02:00] excited about this.

Maybe to start off with, could you tell us a bit about your professional background?

Marcin Wyszynski: My name is Marcin Wyszynski. I am currently in charge of product at a company called Spacelift. We do automation for infrastructure as code. I started my proper engineering career at Google as an SRE.

I did that for seven years. I spent then a year at Facebook as a production engineer. And then after a short stint at a failed startup for static code analysis where I was a CTO, we I went to consulting and I was consulting for the cloud, but this time, not for the cloud that I was building myself as in Google or Facebook, but the public cloud.

Ashish Rajan: Oh, it's

Marcin Wyszynski: part of that there is a lot of itches and I scratched a couple of them. And one particular thing that I scratched turned out to be pretty successful, which is the multiplayer mode for infrastructure as code, particularly back then it was Terraform. I built it internally as a tool for some of my clients when I was doing consulting.

Yeah. And it turned out to be pretty [00:03:00] successful, so I was like, okay, maybe I turned into a product and now we employ over a hundred people and just raised a series C maybe wasn't such a bad idea.

Ashish Rajan: Yeah. Awesome. Thank you for that introduction and I obviously, clearly you've been in the space for some time.

I'm curious, how has the DevOps industry transitioned today as it, as you stand in 2025?

Marcin Wyszynski: Interestingly it has and hasn't to, to some extent. I think the tooling that we are currently using, the core tooling is like Terraform and CloudFormation. Like CloudFormation has been since there, since 2011. Now, obviously I'm an infrastructure as code person, so you'll probably not hear me talking much about like service meshes, istio and open telemetry and stuff like that.

I am aware of that, but my thing is infrastructure as code. Yeah. Terraform has been around since 2014, 2015, still there. And if you see like how people use Terraform now, even though there's plenty [00:04:00] of new features. The gist of using Terraform, the gist of using CloudFormation has not really changed much.

So I think we've been working with the same, within the same paradigm. We have just been building more tooling and more processes around it and that. Was finding its way to commercial tools like Spacelift. It was finding its way to open source tools like Atlantis Terra Grant, et cetera.

There's a whole long tail of Terraform automation, CloudFormation, automation. Tooling. So even though, the tooling is getting better and better, these are generally like incremental changes. I've seen massive progress, massive change of paradigm in some other areas of, how the infrastructure or how the applications are being deployed.

But the infrastructure, the way we've been doing infrastructure 10 years ago hasn't changed all that much, and it's. It's not the bad thing actually, [00:05:00] because the skills that people acquired are transferable between jobs. They're transferable between assignments, and it is a kind of a solved problem as opposed to, extremely volatile areas like.

If you've ever done frontend development or ever heard jokes about, oh, what is the new framework for JavaScript for today? Yeah. You don't get that much. I think there, there was a bit of that in the Kubernetes world, right? And a couple of years back there was this whole kubernetes, it's let the thousand flowers bloom.

Let everyone have their own way of doing things in Kubernetes. And now when you go to conferences, of course Kubernetes is a big thing, but then you start hearing the same names over and over again. You don't, you no longer have this flurry of completely new technologies coming up and dying because nobody likes them.

You have a more and more stable ecosystem. And I think the stability of the ecosystem and in infrastructure as code has been there. There's been a bit of drama around Terraform changing its license to BSL. [00:06:00] Then open tofu came came up. We were sponsoring open with as Spacelift.

There was a bit of a, oh my gosh. Okay, what does that mean? What does the license mean? What does open tofu mean? Will the community fracture? And I was like, no, it's actually, it's fine. It's compatible. The license is fine. We had a, at least third of the community switching to open tofu.

Yeah. They're quiet about it and people are quiet. Especially DevOps people are quiet when things are working. I think it is an, there's an interesting cultural affinity between DevOps as a sort of and culture within engineering and the culture of my, my people like I'm Polish, I'm Slavic.

We generally don't share our happiness with others, but just if Polish people don't say anything, the Polish smiles like. This is me smiling, devOps people are the same. Oh, things are good.

Ashish Rajan: Yeah,

Marcin Wyszynski: we are quiet.

Ashish Rajan: I'm glad you called out the transition as well, because. Even infrastructure as code, and obviously [00:07:00] depending on which pocket of the size of company you talk to, some people are all in on Kubernetes, some people are all in on Terraform or some people are all in on Cloud native.

There are obviously all these different kind of pockets to what you're calling out. In terms of I guess some of the common components and where does security fit into it? 'cause are we already in that direction? Where we are moving towards a platform based? Or are we still with to what you started out by saying, are there still like just pockets or different kinds of tools?

Just Jenkins on one side. There is, I don't know, like some Atlassian tool on the other side. Is that still like the case or are you finding that a lot of conversation you have today is transitioning more to a platform even at smaller size companies?

Marcin Wyszynski: I'll sound very cynical.

What people are saying and what people are doing are two different things. What are they saying and what they're actually doing?

I, I used to be a Google, SRE and oh, and there is an SRE book Google SRE book.

Ashish Rajan: Yeah.

Marcin Wyszynski: You think Google SRE behaved like in the book? It is like [00:08:00] aspirational.

No, they're actually, they're telling one thing and then in reality it's slightly different.

I think that we gotta have a nice conversation around DevOps and security around what people are saying, what people are doing and how that interplays. But I think it's you have pockets of. Of everything and the future's already here, but it's not distributed equally, and it might not actually even be one future.

I think some of us are thinking of almost like a game like progression from one technology to the other technology, and it's very linear. The reality is a bit messy. Like sometimes one technology is replaced by, not by one better technology, it's replaced by five different technologies that are better at something else.

Or yeah. Or it's the reality does not always standardize on one thing. It generally, progress sometimes means more solutions better tied to different problems, right? And I think you do see some standardizations, certain areas like Terraform is [00:09:00] definitely one of the standards, right?

This is how you do infrastructures code these days. Terraform are open tofu. It's the same thing, right? The ecosystem, right? The providers, the language in which you do it, the. The paradigm in which you first plan and then see the plan, then you apply from a plan. It's you get some form of predictability, some form materialization of changes that hasn't really changed.

And this, I think is pretty much the standard now. Anyone who's trying to introduce a slightly different way of doing things is going to come up against probably a deeply ingrained way of how people understand. So for example, cross plane, like they don't have this idea to of planning in cross plane.

And in the beginning, to me it was like, surely you must be joking, right? Yeah. I was then brainwashed by CLA cross plane people at some of the conferences. They explained to me that, the plan was always bullshit and it's, it's about [00:10:00] eventual consistency. And when they were talking to me, I was like I see your point.

And then I went back home and I'm like. Nah, you must be joking. So I'm like going between, what I'm saying is you have very certain expectations in infrastructure as code world in this very rigid DevOps world.

Ashish Rajan: Yep.

Marcin Wyszynski: And if you're trying to change the paradigm and you're trying to say, oh, you don't need this at all, then people go no.

You can tell people that you don't always need this, right? You're not gonna get this. But as a trader, you're gonna get that. You're gonna get a speech, you're gonna get what cross plane gives you is the sort of free activity. Like some, something happened, changed in your opportunities in your cloud and cross plane knows about it immediately without you having to run it.

So you get like this. Something for something, right? There's a trade off. But if you're trying to tell people that, ah, you are not really needing this at all. It's sour grapes, that's bullshit. You probably need it. If not for technical then for psychological reasons [00:11:00] sometimes, right? Or for CYA reasons.

Every now and then. Yes. I looked at the plan. The plan said, I'll be fine. It's here, boss. See, the plan was good. Yes, I broke production later, but the plan was good. Boss? Yeah. In a sense, yes. There's a lot of that in both security and DevOps. If you follow the procedure, you're not gonna be fired if you don't follow the procedure.

If you fix the problem, you're genius. If you don't, you're fired. It's, yeah. Procedures are often are often let me say insurance policies for your jobs job safety.

Ashish Rajan: Is that because there's not many security people or is that because we can probably do a better job? Or where is the gap coming from? What do you want versus what do you actually have?

Marcin Wyszynski: I think there is very interesting trade off between the complexity of a process or you might have a very complex, very beautiful process, right? But what tags does it put on a human involved?

And this is frequently [00:12:00] why DevOps and security people are at odds with one another. 'Cause in my view, security is very frequently about, about processes, right? We define the right process. And we expect people to follow this process. Yep. But then people have a job to do, and sometimes a job is quite stressful.

If your production is database is down at 3:00 AM on a Friday, the last thing you want to think about is. Have I followed all the required security rituals to get my temporary credentials to scale the database? I probably get you follow the path of least resistance.

Ashish Rajan: Yep. Yeah. And I think

Marcin Wyszynski: if the process is the path of least resistance, if it's designed to, to be actually usable by humans in a situation of need, then.

Then it'll be followed. But the reality is that sometimes, like I think frequently what I see about [00:13:00] security processes is that it's it. They're written for auditors. They're written for, it looks beautiful on paper. I put it in a, I put it in a policy. I showed it to auditors, and auditors are like, oh my God, this is so good.

Great. You need six eyes to get something done. It's great. You maybe need someone with this role and this role, and then something happens in the middle of the night. So what do you do? You can either follow the process.

Ashish Rajan: Yeah.

Marcin Wyszynski: So that's one option. The second option is you don't follow the process.

You fix the problem and forget about it. And the third option that I've seen quite a quite a bit is. You fix the problem and then you try to make it look like you followed the process, so you leave a paper trail. But way after you you've reached your destination. And I've seen that being done a lot at very big and serious organizations.

Why? Because if the process makes [00:14:00] it harder to get the job done, the process will not be followed.

Ashish Rajan: Period. Do you find that? Is that why? Audit often becomes a friction point for a lot of DevOps people then because, and maybe to your point, there's a shortcoming from a security perspective as well. Maybe teams at that point in time.

In time, if they lead with policy document first versus what are you finding? Is that why it's a friction point?

Marcin Wyszynski: Yeah, I think so. I think so because audit, I think look I'm an engineering leader. I had security, like I was in charge of security and I understand the value of audit, right? We got plenty of value from audits.

But I think there is a certain tendency to make audit ceremonial. It's it's like a school play. Kids don't enjoy it, parents don't enjoy it. Teachers don't enjoy it. But everyone still is doing it, right?

Ashish Rajan: Yeah.

Marcin Wyszynski: Because it's a ceremony, you all need to do it, right? Why? Because every year or so, we have a SOC two renewal.

We have an ISO [00:15:00] renewal, we have this, and that. And so either you have two parallel realities where you know there's a parallel reality for auditors and the job gets done completely differently, and then you try to make. Make the real thing look like. If it followed the process, and I've seen it over and over again for like really large organizations, or if you have good communication between the security team, the auditor, and you have good trust with DevOps people, you can use it as an opportunity to figure out, okay, can we use audit as a teaching moment?

Can we have a learning experience? Can we learn something? And improve our processes. Now, I think in order for that to be realistic it can't be, like, the scope can't be huge. If you're in a really bad place and you're trying to now revamp all that you have, all that you're doing. To get [00:16:00] to the auditors to be happy.

Then all you're doing is you're playing smoke and mirrors. You're trying to make things look like they follow the process. You need to be in a relatively good place to be able to learn from audit, right? Because then the list of action items from the audit has to be reasonably small, reasonably high impact in order for them to be followed.

But what a lot of people do is like. They say we need the audit because the business wants an audit, right? Yeah. Okay. Screw it. Like we treat it as something that needs to happen. We do it, we forget about it until next year. Forget about learning. It's all ceremonial. It's all about make believe and then of course there's gonna be a lot of friction, right?

If you are not ready to onboard the learnings from the audit. If there, if the gap between reality and. And the declarations is so huge then what are we even talking about? I think you need to be in a relatively good place to even use [00:17:00] that.

Ashish Rajan: How do you, how does one achieve that?

'cause finding a balance between, say, a comfortable risk posture versus the DevOps need to hit delivery objectives. That's a, and especially in a startup or a small to medium-sized financial shoots, it's how do you balance that priority as a, and obviously you come from engineering leadership background.

How are you managing that?

Marcin Wyszynski: I'm also a practitioner, right? Yeah. And I've spent a lot of time building and automating processes. I'd say automation to a large extent. You will, as a human, you only have as much capacity to do things and to follow a, an intricate set of procedures, especially if you have multiple things going on at the same time.

And you always have multiple things going on at the same time, especially during the moments of crisis and ops is very frequently about juggling priorities. As humans, we're not wired to do this like we're we, some of my US might say, oh, we're good at [00:18:00] multitasking. The reality is that we're not, all the experiments are showing that we're absolutely not good at multitasking.

So if you can pass some of that distractions, some of that coordination requirement to machine, write a slack bar, use some tooling like incident IO or Datadog automation or Spacelift, or we're also building something for day two operations called flows. Maybe you use some low code stuff like NA 10 or for security.

There is a nice tooling called torque or tines if you are able to utilize that, take as much from the poor human as possible. Then I believe you might be getting a better chance for people to follow the process, stay sane, and have a good relationship between the two. Just don't let us do don't require us to pay so much overhead or so much security tax.[00:19:00]

Ashish Rajan: To your point, automation on standards especially, which are repeatable, definitely helps you find that balance of, oh, I, I guess it's a fair point no matter at a scale up stage or a small status page, that you have to be flexible as well. So there'll be a lot of things happening dynamically.

There was a word that we had spoken about called infra archeology. What is that?

Marcin Wyszynski: Yes. In, for archeology is when you need to understand why certain things exist. And it might be, it might feel like it might feel like, of course we know why it exists, but in reality, different people would spin up different things on the clouds at various stages for various reasons, and they might even follow the procedures they might follow.

Okay we'll follow, like we're spinning up using Terraform. Oh, but it was Terraform from your laptop and the code is there. But actually what I deployed was very different because I actually deployed it locally and the code was not checked in like ever. So [00:20:00] no, actually we don't know what's running in production, but what we're what we don't know that is running production might actually be processing production workloads and then understanding how things go to, to where they are.

Sometimes it's a challenge. Like I still remember at Google. At Google we had this almost like a law that said if it's not checked in, it's not running in production.

Ashish Rajan: Wait. So if it's not checked in, it's not going to production.

Marcin Wyszynski: It has to be checked in to version control to be running in production.

But there was nothing enforcing it. It was so you could choose to, not chicken. Nobody did. Okay. May maybe some people did that. But the, you had a cherry pick. You had a heart fix. You had this, you had that. What was running in production? That's a good question. It's a question for an archeologist.

Sometimes it was so bad to a point where you didn't know what the service was for. Yeah. You saw some queries on the service. Nobody was owning that service. There's no metadata. So we did we turned it off and [00:21:00] saw whose pager was going off. And then from there it was like, ah, that's what it does. Right?

And then, but honestly yes, it can get very bad in, in, in certain areas. So for example, in Spacelift, we actually enforce it. You will not deploy anything. That is not checked into product to, to get no point. Like you, you can't circumvent it. And every now and then, a customer will ask us, yeah, but can you please do it?

There are valid use cases. And I'm like, yes, there are valid use cases. No, we don't serve those use cases.

Ashish Rajan: Those are not the use cases that we want to cater for.

Marcin Wyszynski: Exactly. Like for one valid use case, where this is used, there'll be 99 invalid use cases where it'll be used, and then you'll blame us for making a mess out of your infra and then having to do archeology without any written [00:22:00] evidence of any kind.

So sorry, but no.

Ashish Rajan: So how does this kinda apply to some of the other broader security components, like your audit, logging? 'cause I think generally speaking, I imagine most people at that scale of a company are already logging or at least trying to not log too much as well. 'cause there's a cost associated with it as well.

But, and you've been advocating for logging context. Can you share some context around it and why is it not a common practice? Because I would've thought context makes sense to these days.

Marcin Wyszynski: Context would generally mean that it's, it logging what happens is nice, right? That's a starter.

But I think you also need to understand why.

Ashish Rajan: Okay.

Marcin Wyszynski: Otherwise, you get a flawed of. Things that generally look reasonable, but if you try to back trace them into what was the intent of making a change an S3 bucket change. Why? Yeah, because there was a, there was an API call made from this and this role.

That's what in CloudTrail. Thank you Captain. Obvious, sure. [00:23:00] I pinpoint a that to a role and a timestamp. Where do I go from here? Do I hire a private detective?

Ashish Rajan: Yeah.

Marcin Wyszynski: Or am I able to look up in my, in whatever was calling that, that API call to get more information? So for example, if we're assuming that role is Spacelift, then in the assumption you would see The run ID in the run id, you'd see the.

Going to the run, you'd see which version of code it was executed from. You go to the version of code, you see a pull request being open. You look at the pull request, you can go to Jira and see. What even led to that pull request. Then you see who approved it, who reviewed the pull request, who approved the job, et cetera, et cetera, et cetera.

And you don't necessarily need to log the full context within a particular operation, but you need to be able to back, back, trace easily the full context, [00:24:00] and you need to retain the context that is required to explain any action that was taken in your infrastructure. Without having to do stochastic correlations oh, Johnny was in our, addressing something in production as 3:00 AM and this seems to be a related call, Johnny was maybe using shared credentials and nobody knows whether that was John or not because it.

They just use the same API key and secret or AWS key and secret that everyone else is using. And then you have almost certainty that it's Johnny, but it could also be a North Korean hacker that got those static credentials.

Ashish Rajan: Yeah.

Marcin Wyszynski: That info exfiltrate the content of your S3 bracket.

Ashish Rajan: Because to your point, it sounds like at that scale when you may or may not have a huge security team to go with.

It, what's a good place for platform engineers to start doing this? Because I guess sometimes they may not even have the right guidance [00:25:00] for security, but sometimes there's just too much noise from all the logs that they may have collected as well. How does, or what's a good place for someone to start especially a platform engineer who may not have the security support around them?

Marcin Wyszynski: I think you need to learn first. Some people, like as a tool salesperson, like I, I have a, I have a job. As a co-founder of Spacelift, my main role is a salesperson for Spacelift. I do lead the product, but realistically I sell Spacelift. I explain why people should be using it.

You'd expect me to say I just install Spacelift and everything will be right, and I'm here to disappoint you. No, it'll not. You need to understand what you're doing. There's no way around it. If you if in 2025 you can. Think that you can only get one specialization being DevOps and not understand shit about security.

You're completely wrong. You need to learn the security practices. You need to understand at least very basic concepts of static credentials are [00:26:00] bad. See, you'd be surprised to see how poor the knowledge of that is and how. How people just don't necessarily understand the risks associated with reusing credentials, for example, and using vendors that don't even allow you to scope credentials.

One thing that was shocking to me is, I'm used to a IAM in AWS, which is, say what you will, but it's a very granular system. It might be difficult to explain, difficult to use, but it gives you a lot of control and like with proper understanding and proper tooling.

And AWS gives you quite a bit of that tooling. You can get it to a point where it, you have a robust security posture and then you have CloudFlare in which you can generate. A key that would give you access to one bucket, but it's all of the bucket. Read and write. CloudFlare, you're catering to DevOps audience.

You are catering to security audience. You are the security [00:27:00] company like. Why? Please tell me why. 'cause I don't understand,

Ashish Rajan: wait, is that where the policy or code comes in? 'cause there's a lot of people in DevOps pipeline can use a policy or code as well? Or is that where the role is?

'cause people may not even know that, to your point, identity. Some people look at that as there's too complex. I don't wanna deal with it, but. Sometimes be as simple as, is that Ashish supposed to have access to this? Is it supposed to be authenticated and have that as a policy code, does that play a role here?

Marcin Wyszynski: I think policy code is a part of the solution. Policy code can generally prevent you from doing things that are that are incorrect or problematic. But I think there is. And don't get me wrong, policy is code is one very important tool in your toolbox, but again, you can't do it right without understanding what you're doing.

It's only like any tool is only ever going to help you if you understand what you're doing, treat it as a force multiplier. Yeah. And not like a replacement for your understanding. Policy as [00:28:00] code is good, but policy as code needs to come with a certain level of understanding of either you or someone in your organization who's building the platform for you.

And give is giving you the safe experience they need to understand what they're doing. And even like even if you have policy as code, it would, you probably also need to pay attention to what vendors are using and what are the security capabilities of different vendors. We're now building a tool.

To do day two automation, low-code, no-code. Day two automation for DevOps. And we are integrating with with very like various vendors, some of them dedicated security vendors. And it's like I'm looking at their APIs and looking at the way they do credentials and I'm like, holy mother of God.

There are vendors that give you one API key per. Per entire account, and you can't regenerate it. Yeah. And everyone is using the same API, when it leaks. How will you know? How will you even know [00:29:00] when it's being misused? You, you never will, I'm not gonna be calling names, but like okay, I, I got the security vendor, the security vendors is able to get to my AWS account and they give you an API key that can do everything. In your AWS

Ashish Rajan: yeah. 'cause to your point. So the things doesn't need to be that complicated as well. Just a simple act of sharing passwords.

A lot of people would not even do that with family. They leave it all, anyone else. So one would think so, because where I'm coming from is what's the smallest thing people can walk away with? 'cause I guess sometimes people just are so overwhelmed by. The amount of things they would have to do.

And coming from an engineering background, you probably know this day-to-day things is quite expensive. Quite intense. Yeah. Mind blowing. And your, what's the, what are the small wins that people can include? Like I imagine a lot of people who are listening to this probably come from security background, but they're trying to find ways to reach their infra people for.

What are some of the small wins that they can tell them about, that they can do in their environments?

Marcin Wyszynski: Yeah it's a good question. I'll you [00:30:00] asked me about security blind spots. Yeah. I think I, we can we can connect the two. Sure. I think both security and DevOps, people are very good at understanding what they see, or, there is, we over architect certain bets to a point where they're like foolproof.

And they're beautiful. Maybe they're difficult to use sometimes. Maybe sometimes they're easy to use, but we optimize where it's possible to optimize. Yeah, and then, we locked our AWS account so much, and then some external vendor just needs. Access and the only way they can get access is you give them an admin permission and they give you, if you want to interact with them programmatically, there's just one API key that you can use.

Oh. So now all of my work that I've done, like days and days of work of security architecture. And then you leave the backdoor completely open because you have this vendor that maybe does like magic links for [00:31:00] authentication. Yeah. And they give you it, it's got like keys to the kingdom.

Well done. I think what hurts us most is what we don't see. If there's one thing that, that you might do is think about what you don't see and I would, I know it's difficult because we all focus and we all over optimize, over engineer what is easy to see. Yeah. Yeah. And then it close our eyes to what is not like the business.

Sometimes you reuses the same credentials for everything. They put it in Zapier and then they share the same Zapier account with everyone because it's cheaper and it's easier this way.

Ashish Rajan: Yeah.

Marcin Wyszynski: He introduced Beau, beautiful password managers secrets Manager this, and that.

He introduced Vault, but it's too difficult, so people are just passing each other secrets over Slack or even, oh, let's make it secure. Let's copy that to to an external website and I'll share you the link to that website because then it's more secure.

Ashish Rajan: So do you reckon, because [00:32:00] sometimes the policies get in the way of optimizing to, to what you're saying as well.

Yeah. And that's where, but because I almost feel like there needs to be some hope here, right? What are some of the things that is more understandable by infra teams in say that at that scale of companies to

Marcin Wyszynski: don't over complicate. Don't like keep things simple and keep the processes as simple as possible because when there's complexity, there's gonna be workarounds.

When there are workarounds, there are things that are. We're missing. We designed this beautiful process and we thought, we think that, ah, yeah, we must be secure. But then everyone is working around our fence. Our fence is beautiful. It's, it's concrete. It's got barb wire and it's maybe under extra protection.

There, there are guards around it, and there's like a massive, back door. Yeah. Because people needs to actually get. There without hassle. And they figure out how to do it and then they leave the back doors open for everyone [00:33:00] else. And this is what hurts us.

Ashish Rajan: Do you find that maybe AI can help with this, or is AI impacting this infra as code space at all at the moment?

Marcin Wyszynski: I think it can help and it can hurt. AI is a force multipliers as all tools. AI is a force multiplier. And I think, again, if you're not understanding what AI does, it'll not save you. You still need some basic understanding. AI was, it's only as good as the user of ai. It can give you some hints.

It can it can validate certain assumptions. Yeah. But then again, it's I sometimes give this example of my, me and my future wife going to on our first trip together to Portugal and she bought a Portuguese phrasebook. As a way of getting prepared,

Ashish Rajan: right?

Marcin Wyszynski: The first time we used a foot Portuguese Facebook, we approached a a person on the street we read in perfect Portuguese or so, we hope a question. They understand and they answer and we don't understand a thing because we don't speak Portuguese.

Ashish Rajan: Yeah. [00:34:00]

Marcin Wyszynski: Thank you. Portuguese, phrasebook, right? Yeah. And I feel like the tooling that that we are using and all sorts of like crutches, all sorts of helpers, if we don't understand.

The answer, we it's the Portuguese

Ashish Rajan: Fair, fair. So if people were to start today, and I'm thinking more for people who are listening to you talk about this, where, hey, there's a gap, there's security blind spots. At that scale, what's a good place to start? Sos chipping away in solving that problem, or what are different stages of maturity?

Marcin Wyszynski: I'd start by understanding the concept I, what I, what gave me a lot of understanding back when I was starting with my security or Dev SecOps is understanding how and why tools like Vault were designed. I reading the concept behind HashiCorp Vault. Yeah, it gave me a great understanding of the concepts like credentials, leasing, right?

The role assumptions like OIDC credential. [00:35:00] There's a lot of tooling out there. But you need to understand that they're there. So for example, one big thing is federated identity. We use it everywhere at Spacelift, right? Yeah. So that you don't pass static credentials. A lot of people don't do this.

Why? Because they don't know how it works. They're missing the concept. And we know it because we have federated identity ourselves as Spacelift. And this is a constant thread with support. Support is asking, like support is being asked. Like, how do I do the static potentials here? How do I do that?

And the support goes have you heard about OYDC and white proliferation? No, I haven't. Oh, this is good. This is good. We should be using it.

Ashish Rajan: Yes, you should

Marcin Wyszynski: be using it. Yes. You need to know that something exists to even be able to use it. So go and read. Manual. And the tooling like vault or in physical the basic concept are applicable to DevOps people.

Yes. Go read the manuals of [00:36:00] security tools. Understand what's out there. Yes, please.

Ashish Rajan: That sounds like a fair deal. Just is, at least to know where to start is a good place to maybe that was also the final technical question I had. I've got three fun questions as well.

Marcin Wyszynski: First

Ashish Rajan: one being, what do you spend time on when you are not trying to solve the infrastructure as code problems of the world?

Marcin Wyszynski: Different things. I like running. I like cycling. Oh

Ashish Rajan: yeah.

Marcin Wyszynski: And I do scale models.

Ashish Rajan: Wow. Quite an active person, man. But at the same time, you have art as well.

Marcin Wyszynski: Yeah painting figures and painting scale models,

Ashish Rajan: that's, oh, wow. Yeah. There you go. That's why. So you're basically on one side you are like quite active, but also on the other side you're quite quite a creative person as well.

Marcin Wyszynski: So I, I think I'm not a very good engineer, I'd say, and everyone who's been working with me as an engineer they say ah he gets by, but he's not. He's not a superstar. But I think there's a connection between, not being, I think sometimes a superpower. A superpower and like you're, you are not, you are seeing things from perspective [00:37:00] of regular uses, from okay, yes, your solution is clever, but will a regular user like myself be able to use it?

And if the answer is I can't use it, then there's a good chance that. That most people will not be able to use it, not because they're not smarter than me, because probably most of them are, is that they don't have the time to even understand. Yeah. The thing that is in shortest supply in, in the tech world, but also in, in general, I think is the tension.

It's the, it is the currency that is always in short supply. So if you're making something difficult, your product, if you're making your process difficult, then you'll fail. You have to make it easy.

Ashish Rajan: Yeah.

Marcin Wyszynski: And the way you make it easy is you make it understandable by dumb people like me. And I said, that's a superpower.

Ashish Rajan: Yeah. To what you said. I think it's the same thing Apple did with their product. It's almost like you don't, the. There's not even a need for a manual. I don't think they have a manual. I've never seen a manual from Apple, I think. But it's just supposed to work.

Marcin Wyszynski: Yeah. And yes, it does. And I frequently joke to my wife's I'm an engineer.

I'm not gonna read a [00:38:00] manual. Yes, this is a washing machine. I'm sure it works. I'll figure it out. Thank you. I'm not reading the manual.

Ashish Rajan: Yeah. I'm pretty sure that, and to your point, if it gets to the point where it's too complex, it doesn't really make sense as well at that point in time, like why would you spend your attention already your attention on that?

That leads me to my second question then. What is your what's the proud moment that, what's your proudest moment that you have not shared on social media?

Marcin Wyszynski: Proudest moment that I've not shared on social media. That's a difficult one. There would be personal moments like, my kids achieving things, but it's not something that I discussed professionally.

I think I get a lot of pride from people. It's complaining about Spacelift. And I'll explain why, right? I used to be in I used to be building a static analysis tool called Code Beat. It's still around, but it's not been updated and it was not a major sales success,

Ashish Rajan: right?

Marcin Wyszynski: But even [00:39:00] when we saw the unit, we never heard back. It was just there. With Spacelift, it was pretty shocking. The moment someone starts using Spacelift, they have a laundry list of things that they don't like or they like, but generally people much prefer discussing things that they don't like. It's oh yeah, it's good, but how about this and that.

Why I like it is that it shows that people care so deeply about what you're doing, and they care so deeply because you're, you are solving their problem. And they're hoping that you might solve more of their problems, and they're sharing the laundry list of their problems with you. They're being vulnerable.

They're showing you, okay, I'm struggling with this. You are, we believe that you could be helping with this. I didn't see that with with my previous tools and I don't really see that much with most products. The successful products are the ones that people are complaining about.

Ashish Rajan: That's a good, that's a great insight. I didn't, it probably the [00:40:00] first person tell me the complaints are good in that context, of

Marcin Wyszynski: course. Like, how else would you grow? How else would you understand where you're falling short. Yeah. It's the only way you get, like if everyone's telling you that you're brilliant.

Yeah. It's like, how do you grow, the Chad GPT has this thing like when. It always tells you're brilliant, right? It is

Ashish Rajan: yeah, which is fair. It's like you're always right much. It's so good. Can't believe I did not know this before he told me this. Mirror. Mirror, that's a great information

Marcin Wyszynski: is the first of the, all right, it's, of course you are.

Of course you're the user.

Ashish Rajan: Yeah, man. Wait and then maybe that's a. That's a good thing. 'cause it's a good segue into my final question as well, because final question is about, which I'm not great at and I not, don't get enough feedback on what's your favorite cuisine or restaurant that you can share with us.

Marcin Wyszynski: I'm a foodie, so Oh my god, my favorite restaurant. It's gonna be a cliche. I'd say Gordon Ramsey in London. And Chelsea. Yeah.

Ashish Rajan: Fair. Oh,

Marcin Wyszynski: [00:41:00] it's a good, it's a good

Ashish Rajan: restaurant.

Marcin Wyszynski: Yeah. By all objective means. Yeah. Yeah. It's

Ashish Rajan: supposed to be at that price point.

Marcin Wyszynski: Last Saturday I was in a really nice restaurant in London.

It's west African Cuisine. It's a Michelin star restaurant with West African cuisine. Unusual. And this was like about London that you get all, wait, is that

Ashish Rajan: a cocoa?

Marcin Wyszynski: A cocoa, yeah, cocoa.

Ashish Rajan: Oh my God. Yeah. That is great food, man. I love that. Yeah. I've been, actually, I went there for my birthday, so that was really good.

Great food as well. So man you and I should hang out for food places. Clearly you're foodie as well. Like next time you're in London, definitely let me know.

Marcin Wyszynski: There is another one that is good in London. I'm not sure if you've tried ICOI.

Ashish Rajan: No, I haven't. They

Marcin Wyszynski: used to like they used to be more like African centric and now they're calling it modern cuisine, so they lost their African edge.

Ooh. It's also a either one or two Michelin star Icoi.

Ashish Rajan: I, no I just found it looks amazing as well. I'll, I look forward to trying this out with you when you're visiting London next time, then

Marcin Wyszynski: I'll let you know. [00:42:00]

Ashish Rajan: Yeah. Perfect. That was all the questions I had, man. Where can people find you, connect with you and learn more about Spacelift as well?

Marcin Wyszynski: Spacelift.io is the best place to start.

Ashish Rajan: And where can people find you and connect with you? What's your social span?

Marcin Wyszynski: Pretty active on LinkedIn, so you can find me on Macin

Ashish Rajan: I will put you a link there, Martin. But dude, thank you so much for this information and I'm so glad we at least had this conversation.

'cause I think at least that. It's really interesting to talk about big companies doing such a big, and to your point about you came from a Google background, so you're probably seeing the complexity there as well. But the complexity sometimes is a simple problem to solve. It just that there's a lost, gets lost in translation, for lack of a.

That's what I'm taking away from this conversation.

Marcin Wyszynski: Oh, yeah. And then people are trying to cut through complexity and then there are things that you don't know because they did it as a side effect and these things come to bite you.

Ashish Rajan: Yeah. Yeah. Yeah, dude. No, thanks so much for this man. I look forward to more conversation.

But that's all the time we had for this episode, and thanks everyone for tuning in as well. Thank you [00:43:00] so much. Thank you so much for listening and watching this episode of Cloud Security Podcast. If you've been enjoying content like this, you can find more episodes like these on www.cloud security podcast or tv.

We are also publishing these episodes on social media as well, so you can definitely find these episodes there. Oh, by the way, just in case there was interest in learning about ai. Cybersecurity. We also have a system podcast called AI Cybersecurity Podcast, which may be of interest as well. I'll leave the links in description for you to check them out, and also for our weekly newsletter where we do in-depth analysis of different topics within cloud security, ranging from identity endpoint all the way up to what is the CNAPP or whatever, a new acronym that comes out tomorrow.

Thank you so much for supporting, listening and watching. I'll see you next.

‍