Neatsun Ziv is the Co-Founder & CEO of OX.Security. He joins the show to discuss software supply chain security, attack techniques, and lessons learned from previous major supply chain attacks. Moreover, he explains the role that DevOps play in software supply chain security. 

Jonathan:

Hello everybody and welcome to another exciting episode of Adventures in DevOps. I'm your host for the day, Jonathan Hall, and here I'm excited to have with me in our virtual studio, Nit-Sun Zeev. Nit-Sun, welcome to the show.

 

Neatsun Ziv:

Hey Jonathan, pleasure being here.

 

Jonathan:

Would you tell us a little bit about who you are, what you do, and what you know about DevOps? Why we should listen to you today.

 

Neatsun Ziv:

Okay. So, I used to work for Checkpoint for 10 years as the Vice President of Cybersecurity. We've encountered a lot of... challenges regarding AppSec. We went abroad and actually asked friends whether they're countering the same issues and it came across the board that everybody is dissatisfied with what they've got today. And we started looking for things to actually how to improve it and especially in today's software supply chain became a big thing and this is what we've been doing for the past two years.

 

Jonathan:

Nice.

 

Neatsun Ziv:

And if you ask me, what is the one thing that I know? that makes it interesting for this discussion is that throughout the years, we created some kind of a rule or internal rule called 3-Promil. It means that about a third of a percentage of the cases that you're going to see will be an anomaly. And this guides us through everything that we do, saying if you deep dive enough in a big enough pile of data, you're going to find unique and interesting cases, and in security, it's key.

 

Jonathan:

Fascinating. So I like talking about security, mainly because there's so much I can learn about security because I'm not a security guru, but it's a fascinating topic. So before we hit record, you were talking about DevSecOps and SecDevOps. You know, we like to add words to DevOps, you know, BizDevOps and, you know, there's just a thousand different things we can add there. Talk to me about your take on sec dev ops, sorry. Talk to me about your take on DevSecOps versus sec dev ops. Is there a difference and what is it?

 

Neatsun Ziv:

So let's start before the distinguishing between the two.

 

Jonathan:

Mm-hmm.

 

Neatsun Ziv:

Let's start with what does it actually mean and what's supposed to mean. So imagine what is actually DevOps is you've got operations, you've got developers, and now you need to somehow connect them. There used to be a part, two different teams reporting to two different sections within the organization. And definitely there was a disconnect, and then DevOps was created. saying we need to take developers, we need to take operation, somebody needs to be in the middle or to own it, and now we've got DevOps. What happens next is saying, OK, now I've got the DevOps running all the pipelines from code to cloud, delivering things fast, maybe even in a continuous delivery method. But now the big challenge becomes, how does security come into that? Now, if you might be recording something that happened. let's say 15 years ago, there was a process. You release the version once every quarter and security would come in two or three weeks before the quarter, do some scans saying, you need to fix those things. In the model world of continuous delivery, there is no such process or a point in time that somebody can actually say, you know what, let's do a security review. You need to do it in a continuous way, just the way that you're releasing software. And here DevSecOps. comes into play. How do you take security practices and connect them to developers? So if you started this long answer by saying developers on one hand, ops on the other hand, now we've got DevOps on one hand and security on the other hand, and now you need to glue them together

 

Jonathan:

Mm-hmm.

 

Neatsun Ziv:

to build a process that works continuously.

 

Jonathan:

Mm-hmm.

 

Neatsun Ziv:

that's DevSecOps. SecDevOps is usually people that started with security and then morphed into saying, we understand that we can't block the business, but we need to integrate to DevOps. So I think it's just the origin of where you started your journey. DevOps-oriented

 

Jonathan:

Okay,

 

Neatsun Ziv:

or security-oriented?

 

Jonathan:

makes sense. All right. And which do you consider yourself to be? Are you more DevOps oriented or more security oriented?

 

Neatsun Ziv:

First of all, we consider ourselves as DevSecOps, which is...

 

Jonathan:

Okay. Well, I have to explain that one. Hahaha.

 

Neatsun Ziv:

Yeah, actually I've got a t-shirt saying DevSecOps.

 

Jonathan:

Okay.

 

Neatsun Ziv:

What we encountered is actually, okay, you wanted this process and you're going to have a lot of small things that you need to do and finding partners that will do it with you is always easier. So this is the DevSecOps. We are definitely on that trend of the... of the calling name DevSecOps

 

Jonathan:

Mm-hmm.

 

Neatsun Ziv:

or DevSecOps.

 

Jonathan:

Thanks. So let's talk about what are some of the security practices that need to be, as you said, glued into DevOps. Because I mean, I can think of a million things from making sure passwords are long enough and they aren't sequential numbers to making sure dependencies don't have CVEs in them. And you know, there's a million other things. What kinds of things... are you talking about, and maybe the answer is everything, but I'll put it in your own words, what thing is you talking about that we need to integrate with DevOps when it comes to security?

 

Neatsun Ziv:

Okay, so I think the answer to your question is actually the reason that we started the current journey,

 

Jonathan:

Okay.

 

Neatsun Ziv:

which is we found ourselves asking the same question saying, okay, what do we need to do? So let's buy a software composition. Let's buy some study code analysis. Just let's run them as part of the pipeline and we should be fine. What happens is that reality is a bit a bit different from that because Just running the tools as part of the pipeline doesn't mean everything gets fixed.

 

Jonathan:

Mm-hmm.

 

Neatsun Ziv:

And when we got to that stage, then you've seen attacks like SolarWinds or CodeCore, when you ask yourself, wow, I'm not even prepared mentally to answer the question of how would I have found it originally?

 

Jonathan:

Right.

 

Neatsun Ziv:

So you're getting to the point saying, okay, what is actually the landscape? Can you just describe for me what exactly are the risks that I'm supposed to handle right now? So we started our journey by actually mapping everything that is in the industry. We created a workgroup with about 20 different companies. All the work is public and open sourced under the name Oscar, the open software supply chain attack reference. It is actually in GitHub and also in the site pipeline-beethofmaterial.dev or pbomb.dev. And it allows you to actually have a map. of everything, all the known attacks, all the techniques that threat actors use over the past five years. And it creates for you some kind of understanding saying, okay, all of these are the risks and I know what attacks they are associated with. So imagine a map that starts from reconnaissance on the left side to the actual impact on the right side. And we're allowing you to see what are the path that you might have in your organization to actually understand. how somebody can actually do this work.

 

Jonathan:

You

 

Neatsun Ziv:

Now that you've got full coverage on everything that you need to know about, you need to understand whether you can deal with them and in what way you can deal with them and how can you automate them. Because the entire movement of DevOps started by saying, let's automate things instead of them being manual. I hope so far it makes sense.

 

Jonathan:

Yep.

 

Neatsun Ziv:

So you mentioned before, how do I do password? How do I do software composition? But there are about 100 different questions that you need to ask yourself. And here becomes a difference between somebody that comes from the DevOps orientation into security versus somebody that came from security to DevOps.

 

Jonathan:

Mm-hmm.

 

Neatsun Ziv:

The security person would ask, what are the risks and how would I mitigate them? While most of the DevOps guys will say, How do I integrate this to the process in the easiest way so it will not disrupt anything in the velocity of releasing code?

 

Jonathan:

Mm-hmm.

 

Neatsun Ziv:

And here's the tweak of how do we actually understand what's the difference between them. So first, number one priority is, of course, releasing in high velocity. Second is, how do I make sure that I prevent issues in a way that does not hurt the developer's productivity?

 

Jonathan:

Right.

 

Neatsun Ziv:

Those are the combination.

 

Jonathan:

How do you convince someone that this is important? And what I mean, let me explain my question a little bit. Because I think we all agree that, in the abstract, that security is an important concern. But there's always business concerns that come into play, especially if you're a brand new startup, especially, I've worked on a number of startups, even financial-related startups, where the mentality was, yes, security's important, but not until we have revenue.

 

Neatsun Ziv:

Mm-hmm.

 

Jonathan:

And you know, I understand the mentality, but it can it might be dangerous How do you how do you convince people that they need to put the time in? To invest in into security and their in their DevOps work

 

Neatsun Ziv:

So I'll tell you how we do it as a company and then I'll give a general recommendation.

 

Jonathan:

Mm-hmm.

 

Neatsun Ziv:

First of all, as a company, we're selling to companies that already have AppSec guys on board. So we don't need to convince them this is the job. They've

 

Jonathan:

Mm-hmm.

 

Neatsun Ziv:

been doing this for a long time. They are professional. So for them, it's about understanding the full map and being able to automate the entire software supply chain security process.

 

Jonathan:

Okay.

 

Neatsun Ziv:

So we don't need to convince them at all.

 

Jonathan:

Mm-hmm.

 

Neatsun Ziv:

They already tried a lot of product out there. Most of the products, even those that are relatively young, let's say five years old, they're not really equipped to deal with the modern world. older assumptions and the new age of DevSecOps are looking on those products and you see them saying you know what we've paid for this service last year, we couldn't get the value and we need to find better alternatives. So most of them are already in the look out for younger and more innovative approaches.

 

Jonathan:

Mm-hmm.

 

Neatsun Ziv:

We can't rely on technology that is designed 10 years ago or 8 years ago to solve today's problem. We've seen this in the cloud where the older cloud security companies simply yielded to new security companies because they came with the right approach versus older ones.

 

Jonathan:

Mm-hmm.

 

Neatsun Ziv:

So the older companies are kind of being replaced and everybody's looking to replace them.

 

Jonathan:

Mm-hmm.

 

Neatsun Ziv:

I think it's a movement that everybody can kind of agree on in the first place. The second part of the equation is that the security concerns comes usually after some kind of an attack. Now

 

Jonathan:

Yeah.

 

Neatsun Ziv:

over the past year we had like 25 big issues. that got to be a big concern for everybody, starting with known CVEs in open sources that everybody had to jump in and change them overnight, through CI, CI... systems that were broken into and all the credentials were potentially exposed, causing everybody with a certain vendor to just go in overnight and resetting all the passwords to previous events that are saying, okay, if you're using this software or this package, then we understand that you got breached. So I think that every two weeks right now, we've got some kind of an article that rattles a segment in the industry. or helping people at the time. So what we've done to do that is we have an open source as well,

 

Jonathan:

Mm-hmm.

 

Neatsun Ziv:

which is completely free called Megalinter. That helps people to identify things if they don't want to get to an investment or a long project, they need something ad hoc. I think it's trending really nice. I think it already passed the thousand stars stars in less than a year. So shout out to Nicolas that is maintaining this. And I think that we were trying to find ways to be productive in those areas, understanding that people just need a quick fix versus thinking strategy at the time of need.

 

Jonathan:

Pardon me, I'm looking at your website right now here. I'm looking at a Megalintr actually. I'll have to check that out in greater detail after the show. Cool. I had a question and I forgot what it was now.

 

Neatsun Ziv:

If you want, I can give you a few questions that we

 

Jonathan:

Yeah, that would be

 

Neatsun Ziv:

get.

 

Jonathan:

great. I'll think of my question again as we're talking, and it'll come up later.

 

Neatsun Ziv:

Okay, so we're getting two questions from DevOps. One is about privacy of data.

 

Jonathan:

Mm-hmm.

 

Neatsun Ziv:

And... That's something that really people care about saying, okay, are you just a SaaS thing, or can you also run on our cloud? Because we do have something special

 

Jonathan:

Right. Okay.

 

Neatsun Ziv:

and so on. That's number one concern that we are getting quite a lot. And the second is, how do you actually integrate to the systems, or how do we know that what you're actually saying is true? Because a lot of things that we find ourselves working with DevOps is, they find themselves, back to them in findings and saying guys you have your false positive and you've got to hear this and they find themselves needing to help developers while they're not really equipped to do security so how can you actually shift it to the developers what is required over there so that would be a second question I probably ask a third question about how does LLM or large language

 

Jonathan:

Oh yeah. Mm-hmm.

 

Neatsun Ziv:

And I'll probably ask things like, yeah, we can start with this and I'll have a few more questions about how they actually do passwords and how do you do the right software composition and we can continue from there.

 

Jonathan:

What was your first question that you just told me?

 

Neatsun Ziv:

privacy in

 

Jonathan:

Yeah,

 

Neatsun Ziv:

on-prem

 

Jonathan:

data

 

Neatsun Ziv:

versus

 

Jonathan:

privacy.

 

Neatsun Ziv:

in service.

 

Jonathan:

All right, whoever's editing this, you can edit out that brief conversation. We'll jump back in here with my questions. I can imagine that you have customers, clients who are dealing with a lot of sensitive data. How do you handle that? What's your answer if they're concerned about giving your technology access to their data? What's the answer there?

 

Neatsun Ziv:

So we see two different kinds of companies. I'll probably say that more traditional companies, they're saying, look, we need everything running on-prem or on our cloud or on VPC, and we need to own this.

 

Jonathan:

Mm-hmm.

 

Neatsun Ziv:

And when you ask them, why do you need to own this, what they're saying is, look, we do have a lot of passwords embedded in our code. And since we do have that, we cannot have the password to our payment service or a super, super something that is internal to us. Even if we wrote the password by mistake, we can't move it outside of the organization. So in that sense, we're saying that's not a problem. You can run our service as part of your cloud. And we are doing it constantly. I think most of our larger customers actually prefer it to be on-prem. They all say that they will move to the cloud at one point to be a public cloud. But realistically speaking, they're saying it will take us a few good years.

 

Jonathan:

Yeah.

 

Neatsun Ziv:

We're running on a private cloud. Even if it's one of the public clouds, everything needs to run as part of their VPC. their controls

 

Jonathan:

Mm-hmm.

 

Neatsun Ziv:

and we're fine with that.

 

Jonathan:

Right. Okay.

 

Neatsun Ziv:

And the other one is saying we don't want the maintenance. We want everything as a service and not as

 

Jonathan:

Hmm.

 

Neatsun Ziv:

on our cloud. Those, by the way, are the deployments that usually start and end within the same day.

 

Jonathan:

Hmm.

 

Neatsun Ziv:

So people get the value, understand how they actually get into Drive Developer, how do they create automation, and it's the easiest ramping up possible.

 

Jonathan:

Nice. One big part of DevOps is the idea of integration, that kind of the idea that Devs can own the process, right? You build it, you deploy it is sort of the mantra that a lot of DevOps people use. How can we apply that to security? Because security is such a big complicated thing. I can't imagine trying to expect every developer to learn all the nuances of security. So how do you accomplish this? Obviously, your tools do some of that for you, but how do you get the developers to understand this and to integrate with the security aspects here?

 

Neatsun Ziv:

I think it's a great question and I'll maybe broaden it for a second.

 

Jonathan:

Okay?

 

Neatsun Ziv:

Developers right now are expected to understand performance, understand security, understand architecture, understand cloud, understand different coding languages. The expectations are accumulating on a daily basis. So security is just one silo that they need to master and obviously there is no way to master it without spending a lot of time. So the easiest question is that there is no way to expect developers to do all the work without the proper guidance. The way to get the proper guidance is by a concept of a sherpa. Somebody that knows the ropes and actually tells you, okay, here are the things that you need to understand. Here are the things that you should do. Here's the next step because when you're doing a walk with a sherpa, it's usually a place that you hadn't been in yet. And

 

Jonathan:

Right.

 

Neatsun Ziv:

you need somebody to say, you know what, I'm gonna send this as your first time in this scenario. This is where you should place your food. This is where you should do this. These are the ropes that we already prepared for you and help you with the journey. I think the expectations from developers right now is for every tool to do this for them, whether it's performance, bugs, tracing, security, the tool needs to be there for them. not

 

Jonathan:

Mm-hmm.

 

Neatsun Ziv:

the other way around. I mean,

 

Jonathan:

Right.

 

Neatsun Ziv:

we're not expecting the developers to be available to fix issues from the tools, but the other way around for the tools to be able to guide developers in this journey, saying, why is this important? And in order for developers to interact with that, they need to create trust. And it is my experience that if you're just saying something like, you've got here an issue and you should fix it. without giving a broader context, it is usually getting a lot of negative feedback. One of the things that I think can really improve that is a combination of understanding the broader context of an issue. So let's say that you've changed a piece of code or even a simpler case, you just imported right now as part of your code, a new package, but this package is already known to be vulnerable. Now, the developers... They might have just copy pasted it from, let's say, Stack Overflow, because they've seen

 

Jonathan:

Mm-hmm.

 

Neatsun Ziv:

an example that is doing just that. But this example is three years old and they just brought in a wrong package. Nobody would say, you know what, that's a big no-no. You need to do update search and so on. You just take the code, edit, and then write your business logic on top of it. At that stage, somebody might come in and say, you know what, you just imported the new, that was fine, now we know it is vulnerable. Please note that your code is actually later on being pushed to the cloud, and the code that you're generating right now, this API touches the new vulnerable code, and it is internet exposed, and there is an exploit available on GitHub. Let's change the version number from here to here. It should work perfectly fine. And if somebody intervenes in the right time with that message, It is super easy for developers to say, you know what, let me just upgrade from version 3 to 4. Easy fix, if you guide them to do that. On the other hand, if you're just going to tell them, guys, you've got a problem with what you did right now, then you say, yeah, but velocity comes first.

 

Jonathan:

Mm-hmm.

 

Neatsun Ziv:

I don't have time to even understand what you want from me. So let's

 

Jonathan:

Mm-hmm.

 

Neatsun Ziv:

just move on. I'm going to insert it and I'm going to fix it later. And later means, probably not going to happen.

 

Jonathan:

Oh, they never go.

 

Neatsun Ziv:

Totally heard. Heard it's an effort.

 

Jonathan:

Yeah. How do you balance the security concerns with the sort of fatigue that can happen, especially, you know, maybe you have a legacy project and you're trying to get it up to speed and you just have hundreds or thousands of security vulnerabilities. How do you cope with that? Do you start with the highest priority ones first? What approaches can people take if they're starting this journey?

 

Neatsun Ziv:

So part of the process in security, it's always about having a lot of issues and understanding what you need to prioritize. Now think about it as a metric saying what's probable and what is the impact.

 

Jonathan:

Mm-hmm.

 

Neatsun Ziv:

So on this metrics you might find yourself things that are low probability and low impact, probably you'll get to them last. If you've got high probability, high impact, those category will go first. Another question is how do you distinguish between all the issues?

 

Jonathan:

Mm-hmm.

 

Neatsun Ziv:

So across the software supply chain, you might find yourself dealing with security controls on the code, on the posture of the systems, on the container level, on the cloud level, on the artifact level. You're going to find yourself dealing with a lot of things throughout the ecosystem. And now you want to actually say, how do I normalize this? So let's take a simple playbook and say, I've got a password in code. So what would be the next question that you would like to ask yourself? Something like probably, is it part of a public repository or a private repository?

 

Jonathan:

Mm-hmm.

 

Neatsun Ziv:

If it is a public repository, oh, that's really bad. But then you ask yourself, wait, is this password actually active or did it already revoke it?

 

Jonathan:

Mm-hmm.

 

Neatsun Ziv:

If you revoked it and it's public, then you don't really care because nobody can do anything besides just. saying you've got poor hygiene in your code, but it's not really exploitable.

 

Jonathan:

Mm-hmm.

 

Neatsun Ziv:

If it is, um, with a password that is not revoked, it's active and it's public. Yeah, well, this is bad. And then you ask yourself, okay, what is this code? Is it something that should have been internal or is it just a POC code doing something that

 

Jonathan:

Mm-hmm.

 

Neatsun Ziv:

is not important to organization? So if you start mapping the next question constantly, you get to the place that you know what is the right playbook. Now

 

Jonathan:

Mm-hmm.

 

Neatsun Ziv:

imagine that for every case there is a playbook, meaning larger teams that are already very experienced with it, they wrote the playbook, they know how to play it, and now all you have to do is automate as much as you can from that playbook, saying, oh, I understand that you've got right now a software composition issue, it is internet exposed. Through an API that already we see a lot of traffic in the AWS gateway API gateway And the damages are remote code execution and so and say okay. This is really bad. This needs to go first

 

Jonathan:

Mm-hmm.

 

Neatsun Ziv:

So this is how you think about the prioritization I probably say that most playbooks that we've seen in mature companies Might have 16 questions per item And part of the challenge is how do you get the information? Meaning, I'm asking you whether the password is active, you need to figure out, wait, what password is it for? What service is it?

 

Jonathan:

Mm-hmm.

 

Neatsun Ziv:

Oh, it's the that service or that service, then I'll need to log in and I need to understand how to do that. So a lot of things is just about making things easy. If

 

Jonathan:

Mm-hmm.

 

Neatsun Ziv:

there's a password and I can connect and check whether it's active, easy.

 

Jonathan:

Mm-hmm.

 

Neatsun Ziv:

By the way, this is, when people see their system for the first time, and they see the evidence saying this password is active, it's exposed to the internet and such and such. The immediate reaction is no, you've got a false positive.

 

Jonathan:

Mm-hmm.

 

Neatsun Ziv:

And then when you go and actually show them guys, have a look here, I can actually open an SSH and connect your system with this token, for example. That's when they actually understand that they might have already been breached and they had no idea that the exposure was even there.

 

Jonathan:

Right. Thanks. We've been hearing a ton in the last few months about chat GPT and generative AI. Are you able to take advantage of this in the work you do and if so, how?

 

Neatsun Ziv:

Yes, so first of all we released what we call OxGPT, which is our interpretation

 

Jonathan:

Good name.

 

Neatsun Ziv:

of large language model.

 

Jonathan:

Mm-hmm.

 

Neatsun Ziv:

And what we've done over there is understanding that each developer needs different guidance. And imagine that if you know what a developer might need in order to be productive in fixing security issues. then I can tailor a message directly for one person. saying you need more information, less information, guidance, just point me out and I'll do the rest and each one with his own seniority. So what we're trying to do with this is actually engineer the prompt in the right way. We figured out that there are about 30 different parameters that control the equation and now you can actually say okay this is the developer that likes just short and to the point, show me the solution, I'll get it done versus somebody that says you know what, I'm here. in this organization for two months. I don't really understand the ropes yet. I'm a bit concerned that what I'm going to do is going to maybe do damages that I can't really understand right now and maybe I should have also guidance. So if you don't mind, show me how am I supposed to do this and how am I supposed to communicate this to my manager as well. And if you guide them through the process of actually what does it mean in a simple language and in language that you see in previous tickets, it creates a lot of ability for the developers to do self-empowerment and actually get to the point they are able to solve the issues themselves.

 

Jonathan:

Nice. Really

 

Neatsun Ziv:

Super

 

Jonathan:

cool.

 

Neatsun Ziv:

interesting technology.

 

Jonathan:

I hope this question isn't a taboo question. I'm curious, we're all geeks here listening to this show, we're all nerds. Would you be willing to lift up the hood a little bit of the technology you use and tell us to whatever detail you're willing to share on a public show, what your technology looks like? What language or languages do you use? Do you deploy to Kubernetes or to EC2? How does your system work?

 

Neatsun Ziv:

Sure, so first of all, everything that we do is product-led so you can actually see it. We're great believers in open source, so you can actually see how we do things. So we're running Kubernetes. We are running on multi-cloud. In some customers, we are actually running on bare metal in their own deployment

 

Jonathan:

Mm-hmm.

 

Neatsun Ziv:

on OpenShift. The entire system is isolated and works as a sandbox concept. So part of my previous role was also to be in charge on the sandbox. And if you know how sandboxes actually work, is you take a virtual machine or a container, you load it with the data that you want and the code that you want to detonate within the sandbox, you isolate it from every communication abilities to the outside world, and you detonate it. So you cause an execution or a scan, whatever it is, and you're just looking for the residues. Now for us, it is super important to constantly isolate things to make sure that we have full control on all the ingredients, I think gets compromised. For example, if you might bring in a code that have access to the internet in order to pull new packages, then what I'm simulating might be different from what you're running in your code. So we need to be really... precise on how to do this. In order to do this, we've built everything on sandbox concepts. In terms of coding languages, so a lot of here is written Node.js, Python, I think that there are some Go in most cases. So for us it is really straightforward, all new stack, we've got great experts for each one of the components and ingredients. We've got great partners that are actually working with us on each one of the technology aspects, whether it's storage or compute or even GPUs, and how do you do parallel computing in order to do things really, really fast and deliver answers fast.

 

Jonathan:

Mm-hmm.

 

Neatsun Ziv:

So very, very diverse technology stack.

 

Jonathan:

It's really cool.

 

Neatsun Ziv:

Yeah, it is.

 

Jonathan:

Thanks.

 

Neatsun Ziv:

It's really nice to see modern development versus, I would say, developments that started five years ago.

 

Jonathan:

Mm-hmm.

 

Neatsun Ziv:

The barriers that older companies had in this field, you can see them now starting to feel the pain of older infrastructure. I think it's part of the challenge that you need to be able to constantly renovate your infrastructure. And if you're doing it too late, then you're already in a place that you feel the pain of all the infrastructure. So it's constantly about making sure that you've got the right infrastructure and make sure that you're able to run fast.

 

Jonathan:

Nice. Um, what else should we talk about?

 

Neatsun Ziv:

Um...

 

Jonathan:

I want to take some time to talk about Ox specifically and the services you offer, but we can save that to the end if you want.

 

Neatsun Ziv:

No, we can talk about it. I don't think that we've got any open topics right now. I think that if I've got questions about what would interest DevOps is whether they can use the system if there is no AppSec

 

Jonathan:

Mmm.

 

Neatsun Ziv:

in place. And then you can ask questions about Asks. Feel free to ask any questions you would like.

 

Jonathan:

Yeah, all right. All right, so whoever's editing, you can cut back in now. So how do people, let's talk about Aux a little bit. Aux Security, your company and the services they offer. Just really easy off the bat first. How does a team integrate into Aux? How does it integrate into their workflow? I assume webhooks or something with their CI pipeline. Just paint that picture for me a little bit.

 

Neatsun Ziv:

Yeah, sure. So you've got four major systems that control the build process. That is your software control system, or so CSM, GitHub, GitLab, and others.

 

Jonathan:

Mm-hmm.

 

Neatsun Ziv:

You've got the CI-CD that builds the code and creates the artifact. You've got the artifact registry, and then you've got the production where you actually run the code. Those are the major four steps across the line. Now, in order for us to integrate, we're asking for integration. to those items, you can start with one, usually the source control manager, and then it gets you the entry point. But the more data that you're allowing us to access, the more accurate the actual results will be.

 

Jonathan:

Mm-hmm.

 

Neatsun Ziv:

And then you're moving to the second stage, or the peripheral stage, saying I need to do integration to the ticketing system in order to talk with the developers. So you might have Jira in one place, or you might have... another system in another place and for us it's about just integrating back to the developers And allowing them to work whether it's using apps That are in the source control or things that are part of ticket management that are completely separated So the integration super easy just API's no agent and no Anything that can interrupt production or slow down just APIs.

 

Jonathan:

Alright. And let's talk about. What's the onboarding process like? So that's how the integration works. What's the onboarding process like? Let's say my company's decided that we're gonna sign up with OX Security. Yeah, what's that process look like?

 

Neatsun Ziv:

So you go to our site, ox.security, you press try now. It is ungated, so you can actually go and play yourself. As part of the wizard, you can play with demo data. Or you say, no, I want to experiment with my own data. Demo data, everything is pre-populated for you. You can browse. demo organization, a few tens of repositories, you can find different issues. If you want to connect to your own organization, just say I want to start with GitHub, GitLab, CircleCI, whatever you've got right now, a list of plugins, you start with them, you connect it, and within minutes you already start to see the results. Really, really easy onboarding, because everything is just API-based.

 

Jonathan:

Mm-hmm. And so that's aux.security is the website, right?

 

Neatsun Ziv:

Yes, exactly. Ox.Security is the website.

 

Jonathan:

I didn't even realize that was a TLD, but that's nice and easy to remember. There's too many TLDs to keep track of these days,

 

Neatsun Ziv:

Yes.

 

Jonathan:

aren't

 

Neatsun Ziv:

Yeah,

 

Jonathan:

there?

 

Neatsun Ziv:

Oxford Security.

 

Jonathan:

There it is. There it is. Nice. What else would you like to tell listeners about Aux security? What do people normally ask? What should they know?

 

Neatsun Ziv:

I think that the thing that everybody asks us when they hear what we're doing is, well, how can we try this? And the simple answer is, once again, go to the website. You can actually play with it by yourself. You don't need any guidance. It is self-service, unnegated, and we're always happy to hear feedback from people. Inside a product, there's a way to leave us feedback. We're always happy to hear feedback about, wow, you're missing this, you should do this. I've got a special case like this. And it always drives interesting conversation about why would you do that? how have we missed

 

Jonathan:

Hehehe.

 

Neatsun Ziv:

such an important use case.

 

Jonathan:

Mm-hmm.

 

Neatsun Ziv:

We've seen cases that we've learned from a lot and we've seen cases that when we are in a conversation saying look we've been working with a lot of customers I must say that this is kind of off the charts what you're doing just an indication for you where you are located versus everybody else. I think there are other solutions like this and this or so we're trying also to give some statistics about what we see in the industry, what are the recommendations we see in other places. And sometimes, by the way, we ask companies if we can connect them to each other because somebody is right now facing a challenge saying, I want to replace my CI-CD. And I'm really thinking between this and this. I'm saying, you know what? There's another company that we've been working with. They've done this journey about four months ago. Let me connect you guys. You can have this chat between yourself.

 

Jonathan:

Yeah, nice.

 

Neatsun Ziv:

We're doing a lot of those connections, just references, unrelated to us, just about other tools, technologies, tech. And people actually show up to... We are organizing once a month a dinner, and people just show up to discuss unrelated things. We're always happy to be part of those conversations. This is where we learn and evolve as well.

 

Jonathan:

Really cool. And how can people, other than Ox.Security, how can people reach out maybe to you, get in contact with you? Are you on social media or is the website the best place?

 

Neatsun Ziv:

So the easiest way to get me is through LinkedIn. My handle is Neatsun, neat like cool and sun, the thing that lights the sky, last name Ziv, feel free. I know that I'm going to get bombarded with SDRs approaching me

 

Jonathan:

Hehehe

 

Neatsun Ziv:

and I actually rise up to the challenge saying the best one that gets my attention with a very unique way to approach me, $100 for the winner in that contest.

 

Jonathan:

Ha ha ha. Nice. Cool.

 

Neatsun Ziv:

I actually really like to see the creativity of people and I'm always amazed. Somebody just sent me, it's a company that is doing SEO improvement and

 

Jonathan:

Hmm.

 

Neatsun Ziv:

they created a very nice movie on our website saying, how can we do your website better? That's a big investment. I really appreciate it and I contacted them back.

 

Jonathan:

Nice, cool. Anything else you think that our listeners ought to hear before we move on to picks?

 

Neatsun Ziv:

No, thank you very much. It's a great show and really thank you for having me here.

 

Jonathan:

Great, thanks for coming on. It's been a lot of fun. So this is the part of the show where we do picks if you have one. So I'm gonna start with a pick. I just started reading Dave Farley's new book, Modern Software Engineering. So that's gonna be my pick. I've read his older book, Continuous Delivery, which is kind of a classic now. This one just came out, I think at the end of last year. So. I've enjoyed his YouTube channel, Continuous Delivery, and I'm enjoying the book. So it's a really nice book, sort of trying to, shall I say, rescue the term engineering. It's kind of gotten a bad reputation as being bloated and overloaded and so on. And he's trying to rescue that term and say, actually, what we're doing, if we're doing software development correctly, is engineering in the truest sense. and here's how to do it better. So that's my recommendation, that's my pick for the week.

 

Neatsun Ziv:

May I join as well to the peak as well?

 

Jonathan:

Yeah, absolutely.

 

Neatsun Ziv:

So I would take on the same category, the Phoenix Project.

 

Jonathan:

Uh-huh.

 

Neatsun Ziv:

I'm sure that you heard about this book a lot and maybe others have already referenced it. I think it's a book that actually explains really well why does the DevOps movement is really changing the world. I read it a few good years back and it changed my perspective. There wasn't anything novel at that book, but... It just took the concept and embedded it into real characters that you can actually relate from day to day and say, I get it now, I get it from a deeper place.

 

Jonathan:

Mm-hmm. Good. I like that book. That's another, that's a good one. I read it many years ago, but yes, it's a good book

 

Neatsun Ziv:

Yeah,

 

Jonathan:

too. So.

 

Neatsun Ziv:

it's like eight, ten years ago.

 

Jonathan:

Yeah. Great. Two great picks. Thanks, Neat Sun, for coming on. It was a pleasure chatting. We'll hopefully stay in touch and chat again sometime soon. All

 

Neatsun Ziv:

Thank

 

Jonathan:

right.

 

Neatsun Ziv:

you very

 

Jonathan:

Until

 

Neatsun Ziv:

much.

 

Jonathan:

next week. Cheers.

 

Neatsun Ziv:

Alright.