Speaker: 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: 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: 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: Thank you for having
me on the podcast.
Speaker: 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: 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: 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: 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: 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: 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: Yeah, because I
remember when I I used to work
at Red Hat, Tekton also powers
OpenShift pipelines, right?
Speaker 1: Yes, exactly.
Speaker: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: And what I refer to
here is someone if someone just
walks with your hard drive or
orange.
Speaker 1: 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: 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: Yep.
Speaker 1: 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: 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: 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: 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: 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: 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.