Speaker: 0:00

Now, this is where we really want to learn from your like vast experience, like more than a decade of creating like software systems that not just scales but are secure. So one of the things I I talk regularly is how do you ensure speed or also maintaining compliance? Or the other ways, how do you make sure that you have all the gates and all guard grids but not slowing them down? So, what would you say the foundational architectural principles that you follow for for secure data and AI workflows?

Speaker 1: 0:27

Yeah, so it's a great question. So a lot of the times it could go different ways, and it's always a balance of making sure that you're one, trying to move fast, but at the same time, you're not giving up on the the portion that might get you in jail. Let's just put it that way, right?

Speaker: 0:46

Good morning, good afternoon, good evening, time appropriate greetings. My name is Dewan Ahmed. I'm your host for the Ship Talk Podcast, and I'm super excited to welcome Devan Shah, Chief Architect Data Security at IBM. Welcome, Devan.

Speaker 1: 1:03

Thank you for having me on the podcast.

Speaker: 1:06

Super glad to have you. Devan and I actually used to work at IBM Software Lab in Toronto. Uh, and back in the day, , we worked a bit and played a lot of pool. Uh, do you still have time to play pool?

Speaker 1: 1:19

Here and there during lunchtime or during in-between meetings, or sometimes take meetings from there, , which are just chit-chatting or one-on-ones. But yes, still try to get there.

Speaker: 1:29

So I I know a lot Devan, but our audience doesn't know, and they'd love to know how you transitioned or how your journey began. I think that's one of our favorite questions we ask all our guests is how did you did you always want to be a software engineer and then you imagine being a chief architect? Like what was your aspiration, let's say in your high school, and then how did you come into this role?

Speaker 1: 1:54

Yeah, so I I started off always tinkering around with computers, playing with computers, taking them apart, trying to put them back together, not always successful, but and then I started as a as a chef. So I worked as part of intern, not intern, but like as a student as part of in Wonderland, so amusement park here in in Canada, where I started off as a chef and then made my way up to first first cook or executive chef. And then all of a sudden got an opportunity to join IBM as a as a student, right? And then started that journey from then onwards. This was back in 2013-ish, right? And from that point onwards, I've been with IBM across multiple different roles, starting off all the way in DB2, going through the accessibility, and then starting my application security, and then moving into data security, as well as now AI security in the new realm as well. So a lot of different roles started in QA all the way to software development, architecture, and then chief architect, spanning across a large data security portfolio, , over 450 um developers or are working on the products of data security.

Speaker: 3:05

That that's an army of developers. So I guess that you're still cooking with a lot of different tools, but the ingredients are not traditional cooking ingredients, it's like S-Bomb software build-of materials. So I remember like back in the day, I think it was like 2016, 2017, or maybe even 2018, , there was a popular open source project like Tekton. Uh when I was at IBM, I was working on Tekton. Is that still a thing?

Speaker 1: 3:33

Yeah, it's actually great that you bring that up. So Tekton, as part of it, was working with Red Hat, and then it started becoming the base foundation of what we now call DevOps pipelines, or within IBM, we call it one pipeline, or SPS security pipeline services, right? Which is now the bedrock or base foundation that we actually build all of our CI and also CD with Argo CD framework. So we have a team within IBM that manages the central deployment pipelines that helps us, all the teams, all the software teams that are running SaaS offerings or on-prem deliveries to be able to use Tecton as their CI pipeline. And it also integrates with the CD pipelines as well to make sure that whatever we're delivering, it's not just building the code and compiling the code. It also runs all the tests, the unit tests, the E2E test, all the security scanning that are needed, like your dynamic scanning, your static scanning, , all of that is done, or Nessus scanning, Quala scans, all those scans are done within this pipeline so that at the end you get like an auditable material that you can use for like SOX compliance or ITSS or you can use it for NIST and ISO and so on, which makes a huge difference in the overall productivity for the overall software development lifecycle, so that you don't have to focus on a lot of those things you kind of take for granted now. But it took a while to kind of get to that maturity and say, I will now focus on my code, but everything else is handled for me. If there's some issue, it will trigger a violation. I need to go fix it and look at it, versus having to deal with those individual pieces. So it so yes, Tecton has taken a life of its own, essentially, but it's helping the rest of IBM be more efficient.

Speaker: 5:18

Yeah, because I remember when I I used to work at Red Hat, Tekton also powers OpenShift pipelines, right?

Speaker 1: 5:24

Yes, exactly.

Speaker: 5:25

Yeah, yeah. So you mentioned about the CI part, Tekton. Um how about the CD part? What sort of tools is your team? And again, like 400 devs, it's it's huge. Uh so I want to hear what tool you're using for sort of for continuous delivery, but also like how you how your team is enforcing like best practices, because you you probably have an SRA team of your own just for this huge number of devs.

Speaker 1: 5:53

Yep. Yeah, so our primary tool that we use for CD is is Argo CD. So just actually recently, we've actually switched off using Jenkins that we were using in the past, right? Uh to actually now use Argo CD. So everything is controlled and managed within GitHub, right? So we define all of the Kubernetes CRs, including like middleware provisioning or changes or updates, anything related to like Kafka, Redis, Postgres, things like that, are all managed through through GitHub and through Argo CD to actually do the deployments or any changes, any drifts. Uh, all of that is managed through Argo CD itself. And as part of, yes, we do have a dedicated SRE team that helps with all of our SaaS offerings, right? We're also starting to help customers. So we have actually seen customers for some of our software products or on-prem products, where customers are actually also using a GitOps process. It may be Argo CD or different tooling, but they're being able to kind of use even for on-prem products to kind of deploy and manage them through Argo CD or something called Atlantis to be able to kind of deploy and manage Terraform State, for example, right? So we're seeing a lot of adoption coming in as part of the CD portion with Argo CD as well as Atlantis for the different different use cases and needs that you need.

Speaker: 7:13

And and when people hear about this solid process you have, right? You have your your Tekton and your Argo CD, then 450 devs are using it. It didn't happen overnight, right? Like you you started somewhere and then there's iterations and then struggles and pain points and lessons. Uh, could you please share maybe briefly that what were your observations? And again, like you have the vision of an architect, so you you kind of like saw this thing evolve. Uh, what were some of the lessons learned on how engineering teams choose these tools?

Speaker 1: 7:48

Yeah. Yeah. So I'll I'll speak on the Tecton portion first, right? So before Tekton, as part of our CI process, we were using Travis, right? So as part of Travis CI, easily integrated into GitHub, very easy for developers to kind of review and kind of look at the logs when builds are running, they're failing, they can see it right there, right? So as we did the transition from Travis to to Tekton part of one pipeline, we started noticing that it was taking longer. So builds were taking longer. Uh like we were in the realm of like it used to take seven to ten minutes, it was starting to go into 30 minutes, right? Um, so we started looking at why, right? And and that was one of the big pieces or challenges that we had to overcome. So we worked with the tech, the tekton team and the one pipeline team to kind of see what was taking up the majority of that time. And what what we ended up resulting in is the build process, like building container and everything, unit testing everything was still the same amount of time, right? It was still the seven to ten minutes. But what we noticed is in Travis, we were not running the static scan, dynamic scan, the open source scanning. We weren't running all the static scanning and things like that. But it turns out that when we went all into Tekton in one pipeline, for every single repository, it was actually running all of these different checks. So, in all in all, if you count the overall productivity, we've actually gained a lot because we used to do only we used to do that always at the end, or we sometimes do it at the end, sometimes we forget and things like that. But now it's always done as part of our process, which made a huge difference. So it was acceptable for that time to increase because we were actually getting a lot more value out of it compared to just what it was doing traditionally. But on top of that, it was it was a huge change to get it rolled out to all the developers to now finally understand that this is the new way of looking at logs. There's a new way of reviewing if builds are failing. And these are the additional checks that you need to make sure you're aware of as you're going through your pull request process, right? Making sure that the security scans are accounted for and things like that. So those, it's kind of like a culture change, right? Going from what you traditionally know and liked probably to something different, but it is still helping you. So now folks are kind of appreciating it because it's helped them through audits, right? Everything's ready to go. You don't have to jump around and try to find things after the fact.

Speaker: 10:13

You you mentioned about cultural change. I think one huge cultural change or more mindset change is coming, is a lot of our code or what we're contributing to is AI generated. Uh, and then again, everyone's favorite two-letter word these days. Uh, do you think our CICD pipelines are becoming security pipelines these days? Just because how would you ensure that the code that's running in production is still following the same best practices and still has the same standard?

Speaker 1: 10:43

Yep. Yeah, great question. So as part of AI pipelines or security pipelines or DevOps pipelines or DevSecOps pipelines, right? So traditionally we've always been in the realm of DevOps pipelines, right? And then slowly we've gone into like the DevSecOps pipelines, where you've started adding the static scanning, dynamic scanning from a security standpoint, right? And then that's what we were doing probably like a year and a half or two years ago, right? Uh and now with all of the AI, which is in twofolds, right? One of which is, as you mentioned, like AI that is being used by developers who are writing code. And then there's also your product teams building AI features into products, right? So I'll touch on the first one where within IBM we use we use a tool called Bob, right, which is our AI buddy or AI coding agent that we use within the product, right? So there's a few ways that we're actually making sure that all the code that is generated adheres to best practices and the standards that are laid out by within IBM, right? So within Bob, we're able to define what we call rules or policies or kind of contextual documents that say for any code that is being written in this repository, please make sure it follows these guidelines, right? So that is helping us to make sure that whatever code is being generated by Bob, it's actually adhering to the best practices and standards that are not just defined by overall IBM, but also defined within the team, right? To say that, oh, within my own team, I'm gonna use helper functions or I'm gonna use this SDK, I'm gonna use this package. All of that is controlled within what we call this rules file, right? So that's the first aspect to make sure you have those governing rules defined. And then at the same time, during code reviews, right? Nowadays you can also have AI agents do code reviews for you as well. So if you are using either Bob or another tool like Cursor or Cloud or something like that to help you with code reviews, make sure to provide guidelines as part of that as well, right? Because if you just say go review the code, it might, who knows, do whatever it wants to do or whatever what feels like doing, but you give it the guide guardrails to say, please follow this structured review. This is what are things that you should check for, look out for these things and these things. Very similar to like if you're a human was to do the review, right? They know that in their head that this is what they're gonna look for, right? So what we did was we wrote it down, right, and say, this is what we should look for, and put it that as context, and that's what's making the difference, where the code that is being created by AI is actually production-ready code versus it just being used for like vibe coding or POCs and things like that itself.

Speaker: 13:29

Uh I love that point and I'd like to touch on that. So um as a human reviewer, so if I if I look at a bunch of code and say, okay, here you should use switch instead of if, or here you're trying to use a complex method which would be difficult to maintain. Like your code works, like it's still giving the same output based on this set of inputs. I could make those comments. Uh are we there yet in terms of using AI for code review where you're not just making sure the code works, um, but also it's long-term maintainable. I'd like to know more, like how you're adding those rules. Are those rules advanced yet?

Speaker 1: 14:10

Yeah, so we just started adding those rules. So it's I would say it's very basic right now, right? Uh, in terms of like, oh, make sure that within the, if you're within this repository, make sure you're using this helper package because it already has how to do JWT token validation, it already has how to encrypt and decrypt things versus going and building because if you don't tell that information or context, the AI is just gonna go and build its own function to do that versus using an existing function that you already have within your common packages or common package inventory list that you want to use across your microservices, right? So that that was a big so that was a big, big item that we had to make sure we we put in place. But something along the lines like the example you're giving, instead of using switch or if statements or instead of using multi-for loops, maybe you want to optimize that. So a lot of that is actually natively being provided by the LLMs or frontier LLM models, where they know in terms of best practices around how to code specific scenarios and use cases. So so far we haven't noticed the reliance that, oh, instead of using a switch, go use an if, instead of if, go use switch. Uh even within as your coding, it also is providing suggestions at the same time where in a situation where your variable that you're basing it off of, if it's just one conditional variable, then you can easily use switch, right? Uh instead of it having being multiconditional, then you might have to go use the if and else conditions, right? So it's able to know that context and and be able to actually distinguish between the two. As a matter of fact, like I was I still write code, even though as an architect. Uh and I was writing something, and and Bob came and said, Hey, you may want to switch it from an if-else condition that you're writing here to a switch case because you only have one variable checking that you're doing. I'm like, oh, this is useful. So I'm like, okay, switch it out, right? Um so that type of thing is helpful. Uh, and as part of having the AI agent do code reviews, it also helps you with that aspect as well. And also from a maintainability point of view, as well. If you have those guidelines defined that say, make sure that my code is readable, maintainable, as well, it will make sure that all of that is done and make sure it uses the common components at the same time as well.

Speaker: 16:33

So for those listeners who are listening, architects do write code. So they want this confirmed that they don't do only architect-y things, they they do write code. And this is not to scare away any any first line or second line managers that why not producing lines of codes? But but you know, in all seriousness, we need to keep having that builder mindset if if we want to understand what struggles our teams are having. Uh now they want like the the last part of this segment is not every company's IBM or AWS or our Netflix, right? So, how do you think that um organizations are struggling to add AI or integrate AI into their software delivery? And the the the point I'm trying to make is you mentioned that it's not a binary issue on AI generated code or not. It's it's a multi-layer problem where you have AI generated code, you have AI in your review, your team is building AI features. There's a lot to consider. What would be your suggestion for companies?

Speaker 1: 17:39

Yes. So the biggest portion is to make sure that if you are using AI in these different flows, to make sure that you have the right protections in place, right? Making sure that your the model that you're using is as all the clearances from an ethics standpoint, compliance standpoint, has the right guardrails for like prompt injection, making sure all any of the data that you're feeding into the AI models, either it be code or either it be as part of your product use cases, could be customer data, right? You're making sure that that data is actually protected. Because as you would imagine, it's garbage in, garbage out, right? So if somebody poisons the data set, right, that is gonna be fed into the AI model, your AI model is gonna be confused as hell, right? So it wouldn't be able to differentiate between real versus whatever was the poison data, right? So that's those are those are some of the guardrails that you would need to put in place. And nowadays it's not just AI. We're starting to move into the world of agentic, right? Where you have agents, agents talking to agents, agents talking to MCP servers, agents talking to direct data or API endpoints and things like that, right? And even in that realm, you got to make sure does the agent have the right permissions, right? Because if you just give the agent full permissions, it can it can go and delete your account, right? It can decide, oh, I don't know who this is, I'm gonna delete you, right? So you got to make sure you're also providing the what is called like just in time token provisioning or just-in-time access provisioning to make sure it has the least privilege possible to only do the job that it needs, right? So these are some of the guardrails to kind of put in place overall, right, as part of whichever AI tooling you're using, either it be using it to code or either it being using it within your product to build software for customers to be use AI as part of the product.

Speaker: 19:32

I think this is an excellent, it's an excellent segue to data security in in the AI era to talk about that. And you mentioned like some of the things already to consider. Uh, but then there's a lot to unpack here because it's not only how you have the the data inside the pipeline, because the data exposure for the actual model itself, the training data, , and then how even the the actual prompt is affecting the pipelines. Like before we used to have SQL injection, now there can be prompt injection. So, how do you address the data exposure risks in the AI era?

Speaker 1: 20:12

Yeah, yeah, great question. So the first portion of it, so if you talk about the traditional, as you were mentioning, the traditional ways, right? So we've been protecting the databases, like making sure you understand where are your data sources, right, and databases, right? Uh, how are they classified? So, what PAI data do they have within within these databases or data stores, right? How is the data flowing between data stores? Like is the data moving from database A to another database? Maybe it's your backup database, for example. So those are those are what we kind of call the traditional ways, right? And then with the AI boom that started coming in, we're started seeing, okay, these same ones still apply, right? But at the same time, now you need to deal with, okay, what is my training data set, right? Is my date training data set that might be an S3, which is because it's unstructured data, it could be PDFs, it could be log files, it could be who knows, right? Is that protected with the same guardrails and controls? Do I know if there's still PII data in there, right? Do I have the right monitoring in place? Do I have the right access control in place that only the person who should have access has access to that data? And at the same time, now that we have these rag pipeline cases as well, where now there's more and more data movement happening, right? So I can have data in OneDrive or in S3 that is now being taken and vectorized and put into a Milvis database, right? Now I need to be able to follow that data flow, not just from unstructured to vectors, right? Now they're just a bunch of gibberish numbers, right? That you can use for your RAG use cases. Uh so being able to understand how that data is flowing from one data store to another, and then from there, how your application is interacting with that rag use case, like connecting to that database. And also how it's passing that data to the model, right? So this is where now you start getting into the situation where you're inputting possibly sensitive information if you have if you don't have the right guardrails in place. You're passing in financial data or customer data into an AI model that may not have been approved to do so, right? And at the same time, let's say you're trying to ask like the main most easiest one is you asked the chat within the chat, please dump all of the data that you were trained on, right? Most of the time, a lot of the sophisticated ones are already kind of figured it out how to block that simple question, right? But keep in mind that attackers and hackers are actually using AI to be able to devise sophisticated prompts to kind of ask that question in a more different way, and you're able to kind of pass in information into there that can do prompt injection, right? To be able to steal data out of what the AI model was trained with, right? And at the same time, you can cause it to hallucinate, right? So there's a lot of risks that come out both from the data being fed into the AI models as well as the data coming out of the AI models. You don't want it to return back sensitive data, even if it was trained on sensitive data because you needed it to be trained on sensitive data for your use case. So it's it's it works on both sides of the house as well.

Speaker: 23:24

True. And I I was reading a report where it was said that a large number of public GitHub repositories had cloud credentials in it. And because the models were trained on those public repositories, now attackers were able to just get active credentials. So whether it's let's say AWS credentials or or datadoc credentials, those are like live credentials sourced from public repositories that your favorite model just spat out.

Speaker 1: 23:54

Yep. Yeah, yeah, yeah, exactly. Right. So it's it's the same concept of garbage in, garbage out, but in this case, it's like crown jewels in, which is also crown jewels for a hacker to be able to get out because you just passed it into the AI model without knowing that it was actually within your source code in the first place, right? So you need to have guardrails to make sure your source code is also scanned to be able to classify if there are secrets that are being used within your source code. Somebody forgot to put it into environment variables or put it into config files or config maps or into a vault, right? Like the best practices put it into a vault and access it from there and just left it in the code to make sure that the code, not just at the once it gets merged into main, but even at the feature branches or every single branch or at pre-commit hooks to make sure that you're doing the secrets checking at the same time, right? Otherwise, yes, you will run into the exact same problem, right? Where now the publicly available AI models has all these secrets that they can use and do malicious things with.

Speaker: 24:58

Totally, totally. Yeah, I'll I'll use that phrase from now on, like crown jewel in, crown jewel out, similar to garbage in, garbage out. Now, um, how does DSPM still fit in this and and why do the gaps remain? And just like me, for those of our listeners who don't know much about the DSPM or we're guilty of using too many tech jargons, could you please also tell what that is?

Speaker 1: 25:22

Yeah, yeah. So DSPM is data security posture management, right? So its main premise is essentially being able to go across your cloud environments, not just cloud, but on-prem as well, , for your structured data spaces, right? So you're talking about DB2, MySQL, Oracle, so on and so forth, as well as some of your data sources that you have within the cloud, within AWS, could be S3 buckets or OneDrive and things like that, right? So traditionally what DSPM is doing is kind of crawling through, discovering all those assets, right? You can consider it as shadow data discovery, right? So it finds all the data sources and then it classifies them, right? So it's going in and saying, okay, you have PII data in these ones, you have financial data in these ones, you have some health data in these ones, and so on and so forth, and builds you an inventory, right? So that's the first step, right? The second step of DSPM is essentially to be able to now provide you with vulnerability information, which is more on the posture side, right? To say, oh, this S3 bucket that you have here is open to the public, right? Anybody can view the data in this bucket, or this bucket is not encrypted, or this database or data store is not encrypted, right? So it's providing you with posture-related information around your data stores, right? And then the last piece is how is the data moving? So one very good example that I that I really like to use is GDPR has a policy that data for the European citizens should not leave essentially Europe. But let's say that for whatever reason, during the DSPM discovery phase and detection phase, it it goes and finds that your database in Europe is being replicated into the US for whatever silly reason, right? You just moved and violated GDPR because you moved all of the European data from Europe essentially to the US, right? To violate GDPR. So it's able to tell you that information as well. So that's what we kind of call data security posture management. So it provides you with why the data is important. It also tells you what are the possible vulnerabilities against that data for hackers to get into it, and also helps to explain like where that data is flowing so that you can use all this information together to make a decision on how you should go about protecting your data across your landscape, either hybrid, like multi-cloud landscape, because it's not just most customers don't just have one cloud vendor. It's AWS, Azure, Google, IBM Cloud, so on and so forth. And of course the on-prem, traditional and mainframes as well for first.

Speaker: 27:53

Yeah, I like that point because I think that that's another question a lot of our listeners would have. Uh, what would be the the challenges of securing data across clouds, like say multi-cloud or hybrid cloud? Because if you have a single cloud, single geo, it's not leaving anywhere. Of course, it's like rainbows and sunshine, but typically that's not the case for large enterprises. So, what have you seen? The additional challenges, then how does your team deal with it?

Speaker 1: 28:22

Yeah. So the biggest challenges that we've seen, or what customers think they're looking at, is trying to use the guardrails that are already provided within the cloud vendors, right? So AWS has a set of guardrails to help protect databases and data stores. Azure has the same, IBM Cloud has the same. You may have your own on-prem controls that also do the same, but none of them talk to each other, right? So when you're an organization that is kind of saying, oh, I'm the CISO that wants to define this regulation, right? I'm gonna have to implement it five, six, seven times across all the clouds that I'm using, across my on-premise environment and things like that. And that's where a tooling that comes is the central view, right? You define the policy once and be able to enforce it wherever it needs to be enforced, right? And this is the scenario where let's say I define a discovery policy, being able to discover across my hybrid cloud environment. If I define like policies around specific vulnerabilities that matter, or even masking or redaction policies, depending on what data is allowed or not allowed, I want to define it once and let it propagate across the environment, right? So that's the biggest challenge where when someone, when a customer sees it at the first time, they're like, yeah, I have the guardrails already in place in all these cloud vendors. It's great for when you're only using one cloud or when you're starting off small, right? Like startups and things like that. But once you start expanding, it starts becoming a larger and larger challenge, having to deal with putting all these controls in place. And also the compliance regulations also start kicking in and saying, I need you to fill out this thing, that thing, this thing, that thing. And you would have to go to each individual place and find all that information versus just saying, hey, AU1 tool, give me all the information I need and enforce all the policies I need you to enforce across my hybrid cloud environment. Um, so that's the biggest challenge that our customers are running into is that central governance and compliance and defining the security practices around it.

Speaker: 30:19

Thanks. Thanks for that explanation. Uh that's a nice segue to our next topic, which is how to think about AI security. And again, you mentioned about challenges, and this is a huge challenge because we're not even sure like how to think about you have your AI models, you have your inference pipelines, the model APIs. So let's say you as a chief architect, you join a new company, and then you have to create a strategy for defining AI security um for all of the things for your pipelines, but also including the the models and then the data that it uses. So, what would be your strategy?

Speaker 1: 31:02

Yeah, so I I would kind of break that strategy into a few a few things, right? So the overarching AI kind of security framework or AI protection framework, we talked about securing the data, right? So securing the data is essentially making sure that your data is protected, like we talked about earlier. But as as you were saying, right, the next set of pieces is around secure the model, right? So securing the model includes a lot of the stuff around making sure that any of the sensitive information that is going into the model is kind of sensitized or is being kind of doing all the vulnerability scanning and things that you need to do on the model itself. So if you if you imagine traditionally we're doing static scan or source code scans of your source code, think of the model as a form of source code because it has technically been learned and understood something, right? So being able to have scanners that can actually do vulnerability scanning of the model, right? You've also got your supply chain as well, right? So making sure you're also monitoring that model for drift and things like that. Uh the other portion is pen testing, right? So you want to be able to push at it a lot of the different things that you would normally do for pen testing, like prompt injection, for example, right? And we also have what you traditionally do as data leakage tests and things like that, right? Or inference tests and making sure that you're able to identify a lot of the different vulnerabilities that could exist from an inference point of view, right? Like jailbreaking is another example. Uh there could be evasion attacks, right? Someone is trying to jump from one context to another context and so on, or or leakage of confidential data, right? So being able to make sure that you're you kind of have the guardrails in place for that as well, right? And the next portion of it is kind of touched on a little bit as well, is secure the usage, right? So securing the usage is is primarily around like the guardrails, right? Defining a set of policies or or more runtime policies, right, that says, oh, as you're asking me a question, don't allow you to put SSN numbers or or confidential information in the input prompts, right? At least that way you're kind of preventing some of that sensitive information to be passed into the model during the inference phase itself, right? So defining those guardrails more on the runtime security aspect, right? Uh instead of putting it on the other side of the output coming out of the model, right? And the the other portion of it would be securing the actual infrastructure. That's one of the pieces that that people always forget that yes, it's the data as well as the model um scanning and then the model usage, but at the same time, you also need to make sure that your infrastructure is also secure, right?

Speaker: 33:54

And what I refer to here is someone if someone just walks with your hard drive or orange.

Speaker 1: 33:59

Exactly, right? Yeah, exactly. You gotta make sure your network is secure, making sure you're using TLS and things like that, make sure your cloud storage is secure, wherever the model may be stored, right? It's not like that's not prone to attacks either, right? So making sure that you have have those guardrails in place as well, and finally being able to kind of provide a governance and compliance lens across the entire AI lifecycle, as well as being able to kind of use something of a compliance framework to kind of manage all of this, right? Because you you do need to funnel this into the different regulations that you need to meet. Like there's an EU AI Act as well, right? And there's a few additional ones that are coming in in the US, , very similar to how GDPR expanded and and everyone started piggybacking off of that. Essentially the same is now happening for AI governance and compliance as well. Um that's starting to kick in overall.

Speaker: 34:58

Perfect timing for governance and compliance section. Uh-h . So we we can talk about a lot of theory and best practices, but but you're someone who's kind of living and breathing it. Like you're helping large customers across industries to ensure that they have governance and compliance. Um, we don't have to name specific companies, but could you please talk about some industries you're helping ensure they have governance and compliance in their delivery pipelines with AI? And what would be the gaps that still remain?

unknown: 35:31

Yep.

Speaker 1: 35:32

Yeah, so a lot of the customers that span the different industries. So we're talking about financial, right? So these are banks and insurance, right? We have also got the health sector, right, to make sure like all the healthcare companies as well, and even insurance companies that handle health -related insurance, right? So those were those are kind of the two big ones. We've also got some that are in the the automotive industry as well, right? Because everyone needs protection, right? No matter regardless of which industry you're in. And what we're seeing is they're slowly evolving. One of the biggest fears that everyone is starting to have is how do I make sure that this is governed and how do I make sure that I have the right compliance in place so that things don't go haywire, right? And that's where we're kind of noticing like the governing process that we're giving is make sure that one, you understand where all of your models are, right? Understand where your data plus your models are, right? So make sure you have an inventory of all of this information, right? And and a lot of the times what you end up discovering is that there's shadow AI, like some developer in the company just decided to start using their own LLM model that is not approved by the company, and they started using it for work purposes, right? So being able to identify where those shadow AI resides. This could include agents as well as models, right? Uh not necessarily just prone to one, right? So being able to discover what those are, data models as well as agents, right? And then making sure you kind of define what are the governing policies. So, yes, there's gonna be compliance regulations that drive what are some of the things that you should do, right? But at the same time, you may within your own organization have certain guidelines that you want to also put in place yourself. Like here, as an example, within IBM, we also have a set of guidelines that we need to adhere to from an AI point of view, right? Making sure you have the prompt injection in place, making sure you have inference tests, making sure you're doing model training and tuning to make sure you handle drift, right? Making sure you have all that visibility. There's also the supply chain aspect, right? So as an example, if if you're using a model that is just right off the shelf, right, how do you know that that model is not prone to attacks as well, right? Uh how do you know what was used in that model or trained for that model? If you're using that as a base model and building and using it, like adding more stuff to it, how do you make sure that you're updating the base the same way we do updating your source code, right? The new libraries available, you upgrade, it fixes a bunch of vulnerabilities, right? So the same applies in that in that aspect as well. And then the next part would be the pen testing, right? So now that I have these agents as well as models, making sure I do proactive pen testing against them, right? And this is where it would run through the variety of different tests, right? So NIST actually released a while back, actually, what they call the OASP top 10 for LLMs, right? So we're all aware of the OAuth's top 25 for application, right? There's an equivalent version for LLMs, right? So these are like the ones that you you would go after, which includes things like prompt injection, jailbreaking, and things like that, right? So making sure that as part of a pen test exercise, you're actually going and making sure that your pipeline is prone to those, like regardless of which AI models that you may be using within your organization, right? And and then the last portion is all this information is great in its own little individual cycles, right? But when you're looking at it or trying to reply to governance or compliance questions, you want to be able to take all of this information and provide it as part of an auditing exercise, right? To say, these are all of the checks and balances that I was asked to do. Here's all the evidence, and this is where governance tooling comes in place, where it kind of takes the information across all these different pillars, , not just the security pillar that we've been talking about here, but it also takes it out from like making sure you're doing the drift analysis, is your model governance aspect in place, right? Making sure your if your model is being pulled from some random place, right, to make sure it's also correct and things like that. So it provides you that overarching view so that someone can just look at that plane of glass view and say, oh, okay, my organization is healthy or not healthy from an overall AI security and governance standpoint, right? Uh alongside with infusing the data aspect as well. Uh, because as I mentioned earlier, it's gonna be garbage in, garbage out, right? So making sure you have that governance across both the data and AI pillar in one cohesive view or console, right? And that's what customers are still on that journey to get there, right? Uh so the data portion of it has been well understood, right? So there's a lot of tooling that is offered by within IBM as well, like Guardian, for example, right, to be able to help you on your data journey, right? And now expanding that to also help you on your AI journey. Uh, now that folks are starting to realize in the beginning, it was like, oh, AI is great, right? I'm gonna go use it for anything and everything. And now it's kind of being how do I make sure I put these governing processes in place to not get sued or not be in violation to compliance regulations as an example. That's what's I don't know if the long-winded answer, but hopefully you provided information.

Speaker: 41:23

No, no, certainly it did. And that's that's that leads us to our final segment, which is architecting for software delivery in in multi-cloud environments. Now, this is where we really want to learn from your like vast experience, like more than a decade of creating like software systems that not just scales but are secure. So one of the things I I talk regularly is how do you ensure speed or also maintaining compliance? Or the other ways, how do you make sure that you have all the gates and or guardrails but not slowing them down? So, what would you say the foundational architectural principles that that you follow for for secure data and AI workflows?

Speaker 1: 42:08

Yeah, so it's a great question. So a lot of the times it could go different ways, and it's always a balance of making sure that you're one, trying to move fast, but at the same time, you're not giving up on the the portions that might get you in jail, let's just put it that way, right? So you gotta make sure that you have a good balance of the two, right? So if I if I was to let's say build out a new product, which is currently being worked on on the side here with an IBM as well, like we have new products coming out very fast, very frequent, right? So making sure that as part of a new product launch, you say, here are the 10 or 20 things that are bare minimum, right? Like without these things, you're going nowhere, right? Um those are the big pieces, and this includes like making sure you have your CI pipelines, your CD pipelines, and have the security scanning as part of it for application scanning, dynamic scanning, as well as for AI inventory of all the AI models and stuff that you use, making sure that you have the AI guardrails. We've even got some rules around like making sure which AI models you're allowed to use. There's an entire review process where let's say I want to use this model, right? We have to get the entire model reviewed. So you understand all the weights that are being used as part of the models, right? What are the data that was used to train that model? All that information is kind of collected and analyzed. And of course, if there's already a model that's already been approved, then you can then then you're good to go, right? Um, so those are kind of some of the pieces that you need to kind of keep in mind. You can think of it as it's a tax on building a new product, but at the same time, you need to be aware of those. Otherwise, when you're architecting and trying to move fast, it's great within the startup world. But then when you start getting into the situation where you're trying to give it, sell it to enterprise customers. And they also have their own regulations, is where you start falling short and you're gonna kind of have a huge impact if you don't have these kind of checks and balances in place. Of course, it's not like a list of 100, 200, 300 things, right? But at least following that bare minimum 10 to 15 things to make sure that you're able to at least do those correctly, right? Uh and be able to get out the door. Uh and the bigger part part of it is being in a large organization, it helps mainly because there's tooling available where you don't have to worry about a lot of those things, right? So having the centralized CICD pipelines through either Tekton or Argos, having the security AI security guidelines defined and also tooling available to help you as well, right? That makes a huge difference where a new software product that's trying to launch, they just say, okay, I will use this, this, this, this, because the decisions have already been evaluated for these are the tools that would be used within my industry or within my product line, right? But if you are a startup, right, or if you are kind of moving towards from startup to a more mature, you would you may want to look at what are those tooling that is available that's gonna help me provide flexibility, right? But at the same time provide the the governance and the the compliance portion that is needed at the same time, right?

Speaker: 45:26

That's that's a very detailed answer. And I I really appreciate your your consideration with both speed and security, because when I talk to developers, sometimes they feel that security is there to stop them or slow them. Uh sometimes when we talk to let's say decision makers, , we think in compliance and compliance and all gates. But as you rightly said, that we have to ensure that we we are delivering product fast, but without doing the things that put us on in jail. Yes. Uh now, if our listeners would like to learn more about your work, your team's work, where what would be the best place to find those?

Speaker 1: 46:07

Uh yeah, so the best place will be LinkedIn. We'll be posting a few things around data security as well as AI security in the coming days slash weeks, right? Uh and at the same time, we do also have a few articles that we've posted or blogs that we've published as well around what does it look like in the new modern world for SDLC, right? But with the AI spin against SDLC. We also have partnership with Anthropic, , that actually a paper that was published around that as well, that kind of lays out what the guidelines and kind of process end-to-end would look like in the modernization of SDLC, right? Uh using AI and agentic kind of constructs to help you in that process, right? Both on the side of protecting as well as on the side of usage, , like as a developer using the AI models.

Speaker: 46:57

Fantastic. That was Devan Shah, his journey from being a chef to the chief architect, data security at IBM. We discussed about his team of a huge number of developers and the internal DevOps tooling they use. We talked about data security, we talked about model security, we talked about how organizations can talk about AI integrating in their software delivery workflow. And last but not the least, we talked about legal and compliance requirements that would prevent us from going into jail. So hopefully that that was an interesting and important episode. Thank you so much, Devan, for taking the time. And listeners, this was Ship Talk season 4 AI for software delivery. Hope you can tune in for our next episode.