James Berthoty (00:00)
Hello everyone, welcome back to SecOps Confidential. Today I'm super excited to be joined by Srijan from Fuze. And part of why I'm so excited is Srijan, you are in the illustrious ⁓ CTO product leader category that every security person wants to go and engage with, but always has some roadblocks along the way. So thank you for being here. And yeah, go ahead and tell the people a little bit about yourself.
Srijan R Shetty (00:24)
Thanks James for having me over here. So yeah, I am the co-founder and CTO of Fuze. Fuze is a digital assets or a stablecoin infrastructure company. We are based out of Dubai and UAE. We've built out this entire ecosystem for any bank, any fintech in the region to be able to use our regulated license infrastructure to launch crypto product. The core idea was banks and fintechs would probably not be hands on with crypto and Web3.
We will help them launch these products because we believe this is the future of finance. Fortunately, in the last two, three years that has played out really well.
James Berthoty (00:59)
Yeah, and that's honestly a part of my background, even as being at a company called Very Good Security, which like doing payment infrastructure around like credit card processing. So I have a little bit of familiarity with the challenge of building a scalable backbone infrastructure for like other people to use to build their products. And I think what I'm the most curious of from a security perspective is just, I mean, when you start that company from day one, you know there's going to be a lot of regulatory. Security requirements, international trade requirements. Like how did you guys even start to like build a framework for how you were gonna think about that?
Srijan R Shetty (01:36)
So one good thing about being in UAE is that our regulator, Vara, is one of the most progressive regulators that we have spoken to. And that is a team that actually plays across all of UAE. You have the central bank, you have Vara. You can have a dialogue with them to figure out how to build these things out. So when we started out, they have a very good framework of what they expect the security program for a digital assets company to be. The other thing that really helps is I'm a paranoid person. I've always been a paranoid person. So security kind of becomes the default, wherein you assume everything that can go wrong with the system before you actually start planning it out. So at the get go, because we started in 2022, so we are mostly a modern company that allowed to have a few bedrock principles and foundations, which most companies cannot afford to have. So we started with Zero Trust Network on tail scale. We started with making sure that entire infrastructure is built on this principle of least privilege, role-based access control. So if your code itself starts from that point, it becomes much more easier versus having a legacy code base and trying to morph it into the newer tech stack. Back then, AI was not that popular. I'm really happy now that AI becomes a very important foundation for making the security program much better in Teams.
James Berthoty (02:58)
So let's ⁓ explore that a little bit more. Because I think most CISOs perspective is ⁓ fear of AI because it's doing all sorts of stuff and we don't know and we don't have visibility and so it's a scary thing. Why do you see it ⁓ as an enabler for what you guys are doing?
Srijan R Shetty (03:15)
So the one thing that I need to differentiate for the space that we are in crypto and digital assets, it's out in the open. All blockchain development happens in the open. So it is much easier. This data is available to any kind of potential attack vector is also out there in the open. You cannot for me, why AI is important is even if you have a hundred member team, you will never be able to figure out all the different attack vectors on thousands of blockchains. AI allows you to do that in an autonomous fashion. ⁓ Again, there are different use cases that are developing right now, be it from triaging different alerts that are coming out from your SIM, be it constantly in your app secure trying to do a blue team, red team exercise on your infrastructure. ⁓ Just because of the pace at which this entire ecosystem is developing, you need more than just humans to be able to attack and attack parallelly. ⁓ I do know that most CISOs have a fear of AI and I did have that too. I think over the holidays, I got really blackpilled by cloud code. And now I think the entire team is on cloud because I just realized the potential that it has. ⁓ We've been always early adopter of AI technology because we believe that with sufficient guardrails, you can have an infrastructure which will help you rather than go against you. And if the attackers are already using AI, you are at a handicap by not incorporating AI into your security program.
James Berthoty (04:47)
So I think, let's go ahead. I don't wanna spend the whole time talking about AI security, because I think there's a lot of other interesting stuff, but I am curious, like this is an area where everyone is sort of struggling to figure out what's the thing to be doing. And so especially from a CTO's perspective, which I think could be a lot more valuable when it comes to protecting like the running application and things. what are, when you're... Thinking about those AI adoption pieces, are you thinking more in terms of like the auto remediation stuff, prioritization, or is it more around when you talk about guardrails? Is it like baking guardrails in using like the out of the box frameworks, or are you looking at like third party security tools for doing those guardrails? Like, yeah, just what's your perspective on some of the areas within that?
Srijan R Shetty (05:31)
So I think ⁓ I'll start with first infrastructure. So because you have different infrastructure components and as your team grows, you'll just keep on adding more infrastructure. We actually use ExaForce, which is an AI SOC to make sure that on the infrastructure layer, we have certain AI agents which are looking through all the alerts, they try edges and give us information about what are the important things. ⁓ This is the core bedrock where the application sits. Then you have the CI CD pipeline and the supply chain vectors, right? So whenever we do push out codes, have DAST static code analysis tools. We use a bunch of different tools over here, which do AI, linting, unit tests to make sure that there is no pattern of code which could be vulnerable to security issues. Then finally, which is the developer experience, right? Which is probably the leaf node of this entire infrastructure. How do you make sure that developers are moving fast at the same time? They're not doing something which could like incorporating bad security practices. One is obviously you have these LNM models like Claude. I think we are exploring now how to have like prompt injection security to make sure that they are not ⁓ like their systems are not infected. We also use like all the good stuff like Sentinel-1 for MDM to make sure that someone does not accidentally clone a repo and have a crypto jacking software running on their software as well. So on all different levels, we have thought through about how we can use AI to make it secure. We want to make sure that the team is working fast. don't want like as a CTO and CISO, one thing that you can end up doing is just prevent your team from being productive. We are very, very, you're doing that. Like one of the things that I think as a CTO, my core KPI is developer experience. How quickly can a developer create something, push it to production without breaking anything.
James Berthoty (07:18)
Yeah, that's I think when it comes to security goals, I think unfortunately, the way that this is just a soapbox that I have around application security, where we tend to evaluate tools based on like true positive rates, false positive rates, and when really, I think the core goal to have a good security developer relationship should the security team should also be focusing on the developer experience because of exactly what you're saying where there are so many CISOs who. Unfortunately, like they didn't lead this effort necessarily, but if there was like an AI governance committee, they decided what the policy is going to be around AI usage on the employee workstations. Like all that does is make it so developers are going to try to circumvent those controls, however they can, whether it's a personal laptop, whether it's doing things on their phone, like whatever they can do to try to get around the controls that you have in place. So how have you guys tried to tackle that of like allowing people to go quickly, but then also
Srijan R Shetty (07:58)
Yes.
James Berthoty (08:13)
building that like security relationship where security also feels like the developer experience is most important.
Srijan R Shetty (08:20)
I think we assume and you're absolutely right, right? If you put in artificial restrictions for developers and it's completely at odds to the problem statement that developers have. A developer wants to have a product out there. Sales wants to have a product out there. If security comes in and says that I'm going to slow it down and revenue is going to be in H2, this is a loss for everyone in the company. You need revenue to come in quicker. So we've adopted a much more pragmatic approach.
Our AI policy also just has a clear mandate that according to regulation, any kind of PII data, it never goes to any public model out there. If any PII data has to be ever processed, it has to be in our data centers in a model that we self host. That is the most important data protection law that we need to follow. If you're working with something much more generic, ⁓ which is essentially like your code base, which has no PII data, it does not have any IP, etc. we are okay to use enterprise models of these cloud core and anthropic. But the idea is you need to pay for enterprise models, which make sure that your data is not trained. So we've taken a very pragmatic approach over here, because we believe that at least in 2026 and the years going ahead, ⁓ every engineer, every person in the company, not even engineer, is going to become a 100x or a 10x person by leveraging AI. If you tell them that, hey, if I go and tell the security who writes the minutes,
that you're not supposed to use AI to transcribe the minutes. I'm pretty sure they're going to find out a way. And it's very easy to circumvent all these policies, right? It's not hard. There are so many tools out there right now that can record audio by just connecting to the microphone jack. And you can not prevent that. That's impossible. So it's better to adopt a way which is more employee friendly and you have control over it. So this is a policy that we actually extensively discussed. And we came to a pragmatic solution to make sure that everyone uses it.
James Berthoty (10:14)
Yeah, I totally agree. ⁓ And I want to pivot ⁓ out of AI just to make sure that we're talking about the other stuff as far as I think something that I come across a lot working with, ⁓ there is a, I'm going to say weird amount, but it's just because it's a unusual concentration of ⁓ security tool adoption within FinTech crypto because of the pressures and the risk is so high where I've just seen a lot of focus on that area. And a question I get a lot is about
Srijan R Shetty (10:19)
Yes.
James Berthoty (10:44)
the specifics of like trying to threat model a crypto centric organization. ⁓ I can say what my number, when it comes to prioritizing the different risks that can happen and the different attack vectors that can affect a ⁓ crypto centric organization. My first thought is always supply chain because of what you're saying about open source development. Almost every major supply chain malware we've seen has focused on. ⁓trying to extract crypto from either developer wallets or getting into crypto based systems. And I'm wondering, like, first of all, what you're seeing in prioritizing, but then also how you're broadly, if there's anything special about threat modeling a crypto company as opposed to any other bank regulatory sort of ⁓ industry.
Srijan R Shetty (11:29)
Yeah, so I think that's very good question. ⁓ The most important attack vector for a crypto or a web theory or digital assets company is where do they custody their assets? ⁓ And you need to figure out and build the guardrails over here, make sure that this is the one thing that you cannot go wrong with, because any lapse over here means that your company can completely go bust. ⁓ What we've done over here is ⁓ the way we think about it, there are two different factors. One is supply chain.
And the other one is social engineering. These are the two main threat actors that we tend to think about. The way we handle supply chain is we have solutions. One of them obviously views depend about from GitHub, GitHub Advanced Security and X of course also does supply chain. But we make sure that none of the developers have any company assets ever. And that is probably the most obvious thing you need to do. If they ever use a wallet, it is always a wallet which is a developer wallet which will have
probably $100 or $200, you don't need more than that. In fact, what we do right now is because in crypto for development, you don't even need the original contract and you can just create another, like you can create a USDC contract on test set, which could be worth 1 million, which is equal to zero because test set. So we create our custom contracts and have that. So there is no risk of money being lost over there. The social engineering one is interesting because Most of the recent hacks that have happened in crypto major exchanges were due to social engineering. There is no obvious answer. Obviously, we have an endpoint detection software, we use Sentinel-1 for protection, it was canned. But the most common thing that ends up happening is someone asks you, like this is called the recruiter. ⁓ This is the recruiter attack vector. Someone reaches out to you in LinkedIn, sets up an interview, asks you to download a GitHub repo, which then sits in your laptop forever.
We've taken a very hardcore approach over here. We format everyone's laptops in a month. ⁓ This is probably a very, this is not, this is a nuclear option for most people, but this works because your laptop is always clean every time you reset, because you cannot control what your people are going to do. For social engineering attack vectors, you have all the good things, you Gmail phishing protection, you have Outlook phishing protection, you can integrate a set of different suites to actually filter that out. But there will always be a way wherein something can be installed. We also believe in the zero trust model so people can work out of anywhere. So we want to make sure that while you have that freedom, we can have the assurance that nothing is going wrong by probably recycling and formatting your laptop every month. This is for most of the operations engineering team we try to enforce this rule. Again, this is not a conventional way to do it. This is probably something that most teams will be averse to do. But we've asked our teams to do this.
James Berthoty (14:19)
No, there's definitely, I think what's challenging for people about this problem when it comes to controlling employee endpoints, especially developers. ⁓ I mean, you think about on one hand, it's sort of a nuclear option to format every month. But on the other hand, there are plenty of people who do like remote development environments where that's essentially what's happening, where they're getting a new machine every time they connect. And if you're just using your machine as a developer machine, like it's not really, it shouldn't be much different than that. ⁓
Srijan R Shetty (14:33)
Yes.
Yes. Yes.
Yes.
James Berthoty (14:47)
And think what's really challenging for people trying to make these buying decisions is it's a huge commitment. Like, are you going to stand up a virtual environment? Are you going to try to do it all locally? Are you going to try to manage it? Like when it even comes to working with developers, ⁓ how have you navigated that piece? Because back when I was a systems administrator forever ago, like almost every developer that was onboarding would ask for an exclusion from the MDM. And then they would ask for as many exclusions or exclusion policies. ⁓ I had one developer that refused to
He was like, I'm going to turn down the job if you put any monitoring on my computer at all. So how do you try to navigate those pieces or is the expectation just different because it's a crypto based or a digital assets company?
Srijan R Shetty (15:28)
funny thing was I was one of those developers who never wanted marketing stuff on my laptop and now I enforce this policy and ask everyone to put it in. So we've explored a bunch of different options. We've explored dev containers. ⁓ But the problem is all of these kind of constrain what you can do on your laptop. ⁓ And even the virtual online solutions are not that great. ⁓
James Berthoty (15:47)
that's hard. I mean, I've
tried to manage like a virtual staging environment. Like that stuff's nightmarish to try to develop in.
Srijan R Shetty (15:52)
Yes, 100%. And we tend to give the best laptop out there. So if it's M4 Pro with 34 GB, like 56 GB, we do give it out to our developers because you want them to be really fast. Like I said, my primary KPI is making sure that DevEx is great. One way to actually sandbox this whole thing is developers don't have access to any custody assets. They do have access to our core infrastructure, but we have multi-level security when we use all these different kinds of wallet products, we use a qualified custodian and we use cold wallet custody. So none of the developers can actually withdraw any funds that we have. This is one of the core things that you need to make sure. Role-based access control, go back to your basics, principle of least privilege, role-based access control, make sure that a person has only as much access as required. We use a zero trust network, which essentially means that if you're not signed into the zero trust network, you can't even initiate any of these requests. I do not think that the dev containers or virtual management like VMs are there wherein you can start using them for daily development. You do need your local environment. That kind of has changed in the last month. Earlier I thought people will do offline first coding, but because now everyone is using cloud or open AI or Gemini to code in the command line, they do need a good internet connection. So I do think in this year, probably dev containers and these technology will become really great. Wherein you can use them, but right now it's not there. So we tend to install MDM's anti malware, anti phishing protection, have zero trust in there. And we also make sure that we format the laptops as a nuclear option.
James Berthoty (17:35)
Yeah. No, and I think I honestly, I don't think it's that bad of an approach if you just think of it as like a local VDI, because there's even like there's solutions that exist out there that are basically that even I've seen where it's like you can boot into a VDI locally. That's just a virtual environment and it's getting wiped every day anyways. ⁓
Srijan R Shetty (17:41)
Yes. Guess. I format my laptop every week. I have this policy that there should be nothing on my laptop, which is critical. And I just format it every now and then. I just did it on a flight once to see how easily I can recover my configuration. It's not that bad. Once you start having it in your mind that everything is online and you just format at any point of time, it's just easy.
James Berthoty (18:12)
Yep.
When it's an interesting, you just, all I'm thinking about is like enterprise CISO at some place that's got like a million different users that aren't developers on windows laptops. And just the idea that like they're formatting every week is like they it's lucky if they can reboot once a year. Yep. ⁓
Srijan R Shetty (18:26)
Yeah, I didn't think that could happen. I think we lucky that we are a smaller team, so we are not a big team.
James Berthoty (18:32)
Yeah. And so when it comes to ⁓ that like developer training piece of the puzzle, as far as both like how, like the workflows for managing these tools, when to report things, like, first of all, how do you build trust on the, just if you think something suspicious, like tell somebody because this is serious. And then I'm going to ask as well about like traditional security training. That's like, cross-site scripting, SQL injection, like these more esoteric AppSec type things.
Srijan R Shetty (19:07)
⁓ I think we do do like, think those standard practices you do training every now and then. So we do it every three months. But the problem is you need to have enough confidence in PR and reviews. So the second level check is very critical over here. ⁓ I think it divides into three basic aspects. One, train. We do train our developers every three months.
Then you have automated tools like SEMGREP, SNIC, which automatically look at all these patterns and highlight it. Then you need a human reviewer in the loop who will actually review the code every now and then. Even in your best intentions, I think these things can slip in. ⁓ You need to have protections against it. Like if they happen, how do you protect yourself is the most important question. ⁓ I do not think any code base, there is no code base which will never have bugs. That's just a reality that we live in that
If you want pace of development, you want features to be developed, there'll always be bugs. And bugs will also come in from views. have the unknown unknowns of the bigger problem. I might know about SQL injection. I'll use a good ORM tool, which will always make sure that the queries are sanitized. I might know about cross-site scripting and I will have a protection over there. But in the future, if something comes in, how do you protect against that? So there's a culture of learning as well in our team, wherein we do promote all the developers to...
do these sessions every week about things that they're learning. ⁓ I don't want to be the person to bring in AI again. We do use AI tools to actually do security reviews right now, because I think that is a good layer, which can actually take all the context of the world and figure out patterns which are malicious.
James Berthoty (20:43)
No, and that's, I do think it's worth bringing AI back into it because of when we think about how things are changing so quickly, like even the dev containers idea, like part of the adoption of that is the push towards using tools like Cloud Code and being able to run multiple agents simultaneously and you can have their own sandbox environment and their opening pull requests by themselves. So I'm just curious, what's your realistic perspective on, before we get to the security aspect of it, but just even
Srijan R Shetty (20:57)
Yes.
Yeah.
James Berthoty (21:12)
how is AI changing the developer experience or workflow? ⁓ Is it like mostly hype, this idea of being able to run like 30 agents that are all, I just don't know who can like track 30 agents worth of code at the same time, ⁓ as opposed to just like using cloud code on the IDE. Is there something in between that's changing from like a pipeline deployment development perspective?
Srijan R Shetty (21:34)
So I think we've divided it into two parts. you can, so you cannot use AI for both testing and feature development. You need to select one of them. So if someone is using it for feature development on the terminal, they are shooting up a cloud code. I don't think anyone can do probably like more than three different parallel context. I max out at one. So I can do one single thing and then I move on because it's very difficult to switch between different contexts, especially at like mature code bases, probably at newer code bases, which are hobbies, projects, can do it.
⁓ Then what we do is you need to extensively test. once you if the AI writes the feature, then the testing on us is on you. ⁓ So there will always be a human in the loop who's going to make sure that whatever is going on is good is reviewed. We do not allow court to just go in without all the checks and balances that are in place. ⁓ The again, with I think a bunch of over the last month, people have been starting using the terminal again.
from IDs, which is a very good shift because I am a Vim user. I've never been able to use an ID. ⁓ Yeah. So it's great for me. I see all of these people going back to the terminal. happy I never left it. ⁓ Yeah, so I've been using Vim, so it's just become easier. The workflow just goes in. It's also very lightweight. I think all these editors used to take like six, seven GPs of RAM, so now it's much easier to do. ⁓
James Berthoty (22:36)
⁓ no, I didn't know it was gonna turn into this. ⁓
⁓ jeez. Yeah, I could not have guessed it.
Srijan R Shetty (23:02)
Then I think one major feature is the security review that has come in. ⁓ It's become really good, wherein it can actually point out potential problems. We do have a pipeline which always runs on CI CD. We are a very big proponent of shift-life security. So we have multiple pipelines with multiple providers which tend to do analysis on the code and do point out that hey, there might be a security issue, both static code analysis and dynamic code analysis, ⁓ apart from just like supply chain vectors that are important to be analyzed.
James Berthoty (23:31)
So it sounds like you've got ⁓ like your standard ⁓ in pipeline security stack, but then you've added, is the security review like the cloud code security review?
Srijan R Shetty (23:41)
We're experimenting with it right now using GitHub. So GitHub as an advanced security, is, GitHub was a pioneer. We forget about it, but Co-pilot came out three years ago. And they were the pioneer in this whole thing.
James Berthoty (23:43)
Okay. Okay. ⁓
Well, that's so I was going to ask about there's two interesting co-pilot flows that I was going to ask if your team's been adopting. Like one is the, think there's something very cool and nerve wracking about product managers, customer success managers, being able to just like at co-pilot in Slack and say, change the color of this button, change the width of this and being able to just open a PR directly that way. But I don't know how much people are doing that.
Srijan R Shetty (24:20)
No. Yeah.
James Berthoty (24:23)
And then the second piece is ⁓ exactly what you're saying around trying to integrate it into a pipeline where like on the one hand, like these companies are all in an interesting place from a marketing perspective because they have to say the code we're generating is secure. It's the most secure thing ever. But then also saying like, but we also run additional security scans on it as it's getting generated. But then you're also using cloud code locally and some different methodology. like, how do you think about the effectiveness of those approaches?
Srijan R Shetty (24:53)
We've always taken a, I think we do multiple agents right now, just so that you can get the benefit of the entire world. So usually developers will be coding locally. So they have a skill, which is like security review, which will make sure that the code is good. ⁓ In the pipeline, you have different vendors doing static analysis, dynamic analysis. When a PR is generated, we just go to GitHub Copilot and then we ask it to review it. That will do a review. So these are three different touch points that we have right now. In which all of these agents come in. I also really like, like I think this is the first thing that we tried getting done is you can have all of these have IDs. There's Jules by Google, is Copilot has agents. So you could just prompt it in and forget about it, come in later and see how it's doing. So that is the fourth, but I don't think that really took off. ⁓ Apart from me, I don't think anyone used that in the company. Everyone likes local development. And this was the first experiment I realized that pushing developers to do cloud based development or even with a GitHub dev containers is not going to happen. ⁓ they're just too lazy to do it and you need to do something.
James Berthoty (25:59)
Well, that's the, own thoughts and experience on this side has been the disconnect, I think, between developer users and how they're interacting with these things. And then companies that are trying to broaden who a developer even is anymore, because you've got stuff like lovable on the other side that's more of like a gooey experience. And I think those cloud agent workflows are potentially meant to be more for like that kind of user.
Srijan R Shetty (26:21)
Yes.
James Berthoty (26:29)
to be able to do some like basic changes, but then anything that's on the backend would be more of that local. Cause I very similarly don't really use any of the cloud-based stuff because I wanna like stop it. Like I notice it's thinking in a weird way and I'm like, whoa, hold on, like go do what you were doing before. like, I, yeah.
Srijan R Shetty (26:38)
Yeah.
Yes.
Yes.
So think that one-shotting works, like one-shotting only works for building a landing page because sales or marketing wants to do a new kind of an advert. So they can create a landing page, do it on a custom domain that does not affect the primary product. That's a completely independent workflow that we do not consider part of the core workflows. But anything that has to do with the rest of it, we're a regulated company. So every change requires approval and stakeholders sign off.
We try to compress it to as fast as possible, but we can't just go and develop things in 10 minutes. ⁓ That is not something which is possible in a regulated environment at all, which is actually frowned upon to be very honest. I think ⁓ if an audit comes in and they see that we got something live in production in 10 minutes, that will be flagged in audit. I do not want to be in that position, please.
James Berthoty (27:36)
Yeah, I mean, here's, ⁓ it's always an interesting balance in my experience trying to navigate these frameworks because a lot of auditors, like you can really stretch the meaning of some stuff when it comes to like, ⁓ you know, what counts as a review, right? Like when that law or not, when that regulation was put in place, the idea of a review was like, here's our quarterly release plan and security needs to like run a two day long SAS scan and then
Srijan R Shetty (27:49)
Yes.
James Berthoty (28:05)
provide a formal review on the code change and then deploy it. But now that review looks much more like NPR comments for a hundred small changes a day. And so I think what makes it challenging regulatory wise is how quickly that environment's changed. So how do you guys approach, like you mentioned the human in the loop aspect of it. What's the interplay there as far as like how you're tackling like branch protection type things with reviewers and all that.
Srijan R Shetty (28:07)
Yeah.
Yes.
So I am a big believer of deploying as many times a day as possible ⁓ because this is not, I think I measure in terms of the quantum of change. If the quantum of change is shorter, it's very easy to understand what is going to change in the code base. It is very deterministic. If you're putting in 10 different features and deploying it, the world can break. If you know you're going to make a very small change in very small system,
and then deploy it, you know that all these subsystems are not going to get affected. We're also very heavy. So I am confident to use these AI tools because we have a very good end-to-end regression suite. So what we do is every major workflow that is ever used, we have created these test suite which automatically run every hour. It is kind of a synthetic monitoring system in our dev staging pre-prod and that will assert whether all the assertions are true or not. So even a slight deviation, we get to know within an hour that it has broken.
This gives me enough confidence that if you do not even check something, push it into development, we will get to know that something is broken in possibly an hour. So it's not before you actually adopt these tools, you have to make sure that your testing program is really good. Then we also have manual UAT human reviews, which actually make sure that everything is in line. We also talk to the regulators, we try to educate them about, hey, this is the latest and the greatest in the security. Ecosystem, we should develop it. This is how the world is evolving. And this is for the better. I remember I had a conversation with one of the auditors and I was explaining Zero Trust security. And it took me at least two days to explain it to them. Because they're like, why don't you have open VPN installed? Why don't you have a DMZ? And I'm like, that's a very old model. I don't think it makes sense. And the world has evolved towards Zero Trust and you should do as well.
James Berthoty (30:23)
Yep. I was gonna wrap up because we're about at time, but I think what you said about creating in-depth smoke tests within those different environments is probably one of the biggest challenges that I've seen. And I think it is what breaks a lot of security relationships at the core because ⁓ everyone's afraid to patch because they don't know if things are going to break when they change versions. Everyone's afraid to fix issues because they don't know what's going to break.
Srijan R Shetty (30:35)
Yes.
James Berthoty (30:51)
And I think most companies don't feel super confident in their testing infrastructure. do you have any like high level thoughts or advice on how to build that in a robust way for people?
Srijan R Shetty (31:06)
Funny thing is I was just talking to my QA lead and I was just telling him with the advent of AI, the most important thing that is going to like the most important role is testing. Like now all developers are just testers. So people used to mock QA teams and now QA is kind of the role for every developer. ⁓ We did take, I don't know, I think in retrospect, it seems like it was a good decision to invest in the smoke testing infrastructure and the end to end infrastructure. It was a painful experience of pushing all the devs to ask them to write these tests, just emulating the workflow of an end user. But now it's paying off dividends. You can never know. can only join the dots. That's Steve Job quotes, right? You can only join the dots looking behind. ⁓ You need, like even on a unit test, right? Most developers hate writing unit tests. We have a coverage of 99 % on our code base. And this is like a non-trivial code base of a million lines of code. Someone has to be the BDFL, the benevolent dictator who goes and says that you need to get this done, otherwise I'm not letting the PR go in. Fortunately, we have multiple people in the team who have taken this role on and which make and like a code base, you cannot release the code till the unit test coverage is met. ⁓ You need to have the checks and balances. You need to build a team from the beginning and tell them that this is for the better. This actually gives you velocity in the future rather than right now.
⁓ So if you don't have this, you will actually slow down. And I don't know how to play. Like you can only experience it. You can only experience the velocity once you do it yourself.
James Berthoty (32:43)
Yeah, I think those are all great suggestions. And think ultimately it comes down to the focus and emphasis a lot like security does where, like I think a lot of the idea of shift left being in a failure mode at the moment, depending on what you mean by that, is that people just sort of thought if we hand developers these alerts, then they'll fix them. And I think you could say the same thing about testing where it's like, oh, if I just tell the developers we only have 20 % test coverage, then they'll just go write more tests.
Srijan R Shetty (32:57)
Yes.
James Berthoty (33:11)
But it requires a lot more intentional prioritization and work that has to come both from top down and bottom up to give them examples of how to do it and make it a priority to go ship it.
Srijan R Shetty (33:22)
So we have sprints which are only testing sprints. So the way we do it is for a month. Yeah. So what we do is if you're, if one month is just feature development, we spend the next one month or two just testing and making sure the infrastructure is back to where it is. ⁓ And I do enforce this a lot because I know like, and the problem is probably from revenue. Business does not care about testing and maintenance. So it is the responsibility of the CTO and the CISO to tell the team that maintenance is as critical as feature development.
James Berthoty (33:26)
Every developer's dream. That's amazing.
Srijan R Shetty (33:53)
So that we don't have technical debt to make sure that the entire code base is solid.
James Berthoty (33:59)
And this is exactly, think security is the same issue where ⁓ like security is just a different kind of technical debt and people who don't prioritize other technical debt like testing aren't gonna prioritize the security stuff either. Cool.
Srijan R Shetty (34:14)
It requires a top-down involvement, I'm 100 % sure. Everyone, all the CXOs should align to the fact that security is a priority, especially in the world right now where you have so many threat vectors which are affecting everyone. It is for your own protection that you need to have a very strong security program.
James Berthoty (34:30)
Cool. Well, on that note, thank you so much for the time. sure we could nerd out about development practices and AppSec all day. So I really appreciate it. Where should people go to learn more about you and the company and everything?
Srijan R Shetty (34:43)
So our website is fuze.finance. We provide a developer platform. You can just hop in over there and you should be able to see everything about us.
James Berthoty (34:51)
Cool. Sounds good. Well, thank you so much for your time today.
Srijan R Shetty (34:53)
Thanks a lot, James.
