Get Secure and Stay Secure in the world of agentic AI

Hey everyone, thanks for joining us for

the next session of our Agentic DevOps

Live series. My name is Anna. I'll be

your producer for this session. I'm an

event planner for Reactor joining you

from Redmond, Washington.

Before we start, I do have some quick

housekeeping.

Please take a moment to read our code of

conduct.

We seek to provide a respectful

environment for both our audience and

presenters.

While we absolutely encourage engagement

in the chat, we ask that you please be

mindful of your commentary, remain

professional and on topic.

Keep an eye on that chat. We'll be

dropping helpful links and checking for

questions for our presenters to answer

live.

Our session is being recorded. It will

be available to view on demand right

here on the Reactor channel.

With that, I would love to turn it over

to our presenters for today. Rupita

Rohan, thank you so much for join.

>> Thank you so much Anna for that lovely

introduction. Welcome everyone to the

another reactor series. Specifically

today is the Agent DevOps Live. Um with

me is Rohan. I'll let him introduce

himself and then I'll introduce myself

and walk you through what to expect.

>> Hey everyone, my name is Rohan Parak.

I'm staff product manager here at GitHub

advanced security team.

>> And I'm Lupita Caravis. I am an ACE and

application security executive. I've

been with GitHub for about three years.

And my focus is technically the security

stuff, but now in the new era of AI,

they have come to be better together in

every way. And so what we're going to be

talking about today is how to get secure

and stay secure in the world of agentic

AI. For those of you joining us for the

first time, the reactor series serves as

an opportunity for you all to receive

ungated content. So, we absolutely

really hope everyone registers for all

of these events in this series so that

you can get up to speed and in the know

of what's happening. So, let's go ahead

and get started with the first slide.

We're going to talk a little bit about

application security, right? In terms of

what that means. So Rohan is going to be

leading uh the slide deck here for me.

But basically if you've been in this

space long enough, which I have for

about a decade, you've have experience,

you know, different opportunities to

like use different solutions, but

traditionally it's kind of always been a

siloed series of events that occur

between security and development. And

now we're realizing application security

is a team sport. It requires both teams

to collaborate in order to succeed. And

I know from a GitHub perspective, we

have proudly made that experience so

much better. That collaboration because

it's embedded into the native experience

that they're in in their flow state just

works really well. However, the industry

reality is that there's still

remediation trends that are remaining

stagnant. applications are being pushed

to production with known risks for

whatever reason prioritizing you know

the experience the features the

functionality and so sometimes security

still becomes an afterthought so like as

quarters and quarters go by you you see

those numbers like trending upward and

to the right so what I found to be the

primary cause of these issues are two

things

if we look at in more detail

securing this the developer workflow is

is tough because like how do you

prioritize or like how do you know what

to actually fix?

Even though code is being developed more

faster, why are we not actually fixing

these vulnerabilities as they're coming

in? I've heard like many security

professionals say it's the developers

fault that they just don't care about

security, but I've worked with thousands

of developers. I was a developer at one

point and that's just not the case. The

main issue is that apps tools have never

been designed to fit the flow of the

developer experience. They failed to

understand that applications, you know,

are built very quickly, especially now

with the area of AI where Copilot is

providing suggestions out of the gate.

But that pace just doesn't align with

like what we're seeing with the security

type of attacks that are now being

created. So that being said, like

because traditionally it's been bolted

on, not built in, and they've sat

outside of like the, you know, developer

flow state, it's created a lot of

friction, and developers really don't

have the time or the interest, you know,

to remediate. So, I wouldn't say it's a

thing about motivation, but more so like

just figuring out like how we can make

it so that they naturally have security

embedded into the process. So, it's sort

of like a plug-and-play, right? Because

without that, it just becomes super

expensive because you don't know if you

should be fixing this finding or that

finding or or how to prioritize what's

most important to the business. So I I'm

a strong believer that if we don't

figure out the remediation piece in

terms of it being automated that we're

just going to you know break this cycle.

So how do we dig into those details and

how do we define that? So if we look at

what we're working with here on this

next slide we have the CISO who wants

risk reduction and prevention and the

CTO who wants innovation and

productivity.

Well,

that can be a little bit of a challenge,

right? Deciding like what takes

priority. But at the end of the day,

it's like despite the trade-offs, we

know that there's real issues with AI

now being used to create

more complex type of attacks. And so

it's super important that we are

building security into the process by

default. Right? So security wants

engineers to reduce the risk.

Development wants to keep moving fast.

But how do we kind of like merge those

conflicting goals? Well, let's look at

AI in general on this next slide.

Is it the vict is it is it a villain or

is it a hero? There's like competing

thoughts about this, right? But for the

past decade, organizations have been

dealing with the security challenge of

like discovering more vulnerabilities

and fixing more vulnerabilities, but the

backlog just like keeps to be the same.

And sometimes people don't even know

what they don't know because they choose

not to know, right? As soon as you know,

then you're responsible for going in and

remediating or mitigating those

findings. And that can be a challenge in

terms of timelines, priorities, and and

what gets pushed to production. So the

security debt for most organizations has

been compounding. And so

here's the good news or the bad news. I

say AI is changing everything, right?

Is it a villain? Is it a hero? I don't

know. I think we're going to dive into

like both scenarios and see like what

that really means. So on this next

slide, let's look at the as if it were

the villain.

AI has fundamentally changed the

equation. And as we know the number of

reported AI enabled cyber attacks has

grown by like 47% globally. This

surpasses around 28 million AIdriven

incidents. These actors are using AI to

accelerate and automate attacks that are

just becoming way more complex. I think

I just saw something online about uh

someone using Chad GPT and Claude to

infiltrate Mexico's government and that

that's scary, right? So, how do we

prevent these types of things from

happening? It's not just about looking

for vulnerabilities. It's actually about

fixing them. We here at GitHub say found

means fix. That is our philosophy and

approach to tackling this problem. I

always say when it comes to developing

software

and applying application security

concepts, the cheapest flaw to fix is

one that is never written. Right? So if

you can shift left as close as possible

to the moments where developers are

writing and coming up and creating that

code, by the time it gets to QA or by

the time it gets to security checks, it

would have already reduced the number of

attacks that could potentially have an

impact.

This is a challenge that every

organization has. I've worked with small

companies, big companies, and they all

kind of have a different level of

security tolerance, security posture.

And so what we're hoping today is to

show you like what's going to happen if

we don't change our culture.

So that being said, when we look at this

graph here, um if nothing changes, we'll

see what is known as a collapse of apps.

And I'm sure you've seen this in the

news about all these cool tools that are

popping up with like AI functionality,

being able to detect stuff, but I always

like to bring it back to like what

application security actually is. And

from a static analysis perspective, I

always say if you look under the hood,

mathematically speaking, it is an

NPcomplete problem. Now we have made

waves and have you know been able to now

deterministically provide better

analysis with AI but there is still a

bit of a gap. So it's never apples to

apples that you can compare one solution

versus another solution. So it really

comes back to the philosophy and

approach of how things are being

analyzed. And when with codekill the way

that we do it it it's designed to reduce

the noise actually find where the true

impact lives. So I call it the best fix

location. So when you're looking at you

know the flow the data flow the control

flow the semantic analysis that's being

applied you really want to just focus on

the the points of execution that could

potentially cause an incident. That way

your developers aren't spending time

going through figuring out is it a false

positive? are there false negatives etc.

So if the rate of vulnerabilities

continues uh to trend in the way we're

seeing in this slide the end result is

that we're going to have a collapse. So

the reason I joined GitHub is because I

saw that it made sense to have that

experience embedded right where the

developers live to continue that flow

state. I always say plug-andplay, right?

If it's something that just happens

naturally without them having to

configure, run scripts,

uh, switch portals, context switching,

none of that, then they're more likely

to adopt. That way the solutions don't

just become shelfware.

So now let's look at AI as the hero,

right?

I always say there is a path forward in

looking at what we can do if we use AI

not just to accelerate the development

but to transform the entire security

posture. What if AI helps you get secure

through agentic remediation that fixes

vulnerabilities at scale that helps you

stay secure through agentic prevention.

So it stops issues before they're even

introduced. So like in this scenario,

remediation accelerates the agents

handle all the fixes. So it increases

speed and it helps you scale the modern

development

and prevention works because it actually

helps you uh see those vulnerabilities

plateau and that just helps you catch

those things upstream before they even

make it to production. So you're not

just looking at keeping up pace with

security debt, but you're also reducing

it. And this is what we call the appsac

renaissance. So using AI as a force

multiplier for security is not just

development speed, but it's also making

sure that you have everything you need

to succeed without having to think about

these steps.

That being said,

our whole philosophy on this next slide

here is to make sure your code is secure

and high quality by default. And I mean

that by saying that whether it's AI or

human or agents creating the code, I

know it's bold of us to say this, but

all software should be by default,

regardless of what it is, included

security checks, third party checks, as

well as um secret checks.

So this isn't just about adding another

tool or an extra step. It's about making

security just like the natural outcome

for building the software. Gardner

actually calls this secure shifting

security down. So embedding it deep into

the platform so every generated line of

code is verified updated holding the

quality and security at the highest

standards. So I think with this approach

developers won't have to choose between

speed or security. I think with the

right technology they'll get the best of

both worlds.

Let's look at what we have today in this

space. We have agentic prevention

already. So anytime you work with

copilot and you ask it a question

regarding whatever it is you're

building, it will automatically do a

code QL scan check for secrets and look

at your third party libraries. So this

is happening naturally. Like I said,

you're still going to want to have that

additional verification,

but as you see in this slide here, when

you click through, it's going to ask

you, you know, do you want me to run

CodeQL? And it does it, and then it

reruns it for you. And so, it just has

that extra layer of protection.

Now, what is a dentic remediation look

like? I think some of the biggest

challenges we've seen is just as I

mentioned earlier with the traditional

tools, there's always been a lot of

noise because there's never been a right

way to analyze applications because it

changes based on the language, the

compiler, the framework, whether you're

actually following best practices in

terms of like the way you're designing

and architecting. And so with that comes

just a almost like push back. And so

being able to prioritize those security

alerts based on what's most important to

the business is key. And what we've

understood from our customers is that

the the main thing that leads them to

kind of identify which risks lead in

prioritization is if it's something in

production, if it's, you know, currently

live, is it active? So that way they can

focus on those first and then go back

and like work on any internal projects

that may have some security debt but

might not have an immediate impact.

That being said, we've done enough with

some slides. We're going to show this

awesome cool video just to give you some

hype about where we're going. And then

after that, I'm going to hand it over to

Roan to actually show you guys this

whole experience live.

Hey guys, did this video have uh audio?

>> Yes.

>> Okay, we're going to want to pause and

reshare because we did not share audio

when we shared our screen today.

So, sorry about that.

>> We are live. So,

>> we are This is evidence everybody.

So, Rohan, when you so stop sharing and

then reshare your screen and you'll see

there's a little uh selection on the

bottom of the screen that'll say also

share system audio.

Perfect.

Heat. Heat.

Hey,

hey,

hey.

All right.

Cool. Let's let's talk more about this,

right? You know, Lupita mentioned that

how additional context that can come in

as much as possible, you know, can help

prioritization of risk that is coming

from the Oops.

>> It's cuz everyone in the chat loves the

beat. It just had to come back.

>> All right.

>> Yes, we are live.

>> I'll actually go off screen. So I can

monitor the chat if there's any

questions.

All right, I will run through slides

very quickly so that we can reach the

place where we wanted to talk about

how do you prioritize better, right? How

do you prioritize better with more

business contexts, more security context

that can uh help developers and security

teams and I think that's the the

important piece what we are going to

talk about and that's what this

integration is about as well. In fact, I

saw in the chat some time back where no

it was somebody mentioned that it was

all about prioritization and based on

the maturity level of the teams involved

right and in this case right you know

how do you prioritize better by bringing

in additional context from runtime on on

the on the on uh GitHub side if you look

at like security app uh context and how

do we typically

what's the anatomy of a security

application Typically, it's going to be

first party code and third party code.

First party code is code written by

yourself, your teams, which would

include which can have like your custom

code, but it can also accidentally get

secrets and cred credentials into the

code repository as well as third party

code which is more a lot of that is

coming from open source and third party

dependencies that you knowingly or in

many cases unknowingly would import in

your projects. But at the same time in

that projects those repositories are

packaged together in the form of

container images or container runtime

the third party code can come in from

there as

a developer you are primarily

responsible the code that you have

created right and your your your

ownership around is around that whereas

security teams are focusing on securing

the code that is coming from you from

your developers but at the same time

also coming from those third party

ecosystems like dependencies container

images that can come into your code as

Because at the end of the day the risk

both of them represent the same same

level of risk.

If you also look kind of uh wear the hat

of a sec ops persona, their pain point

is like there are just too many

recommendations, too many security

issues, vulnerabilities, findings that

are presented to them. And for them,

it's very difficult because they are now

looking at across the enterprise, across

all the application and look at like who

is the owner owner for a specific issue,

right? Who is going to fix it? Who is

going to kind of be held accountable for

certain risk that comes into uh your

first party code and and third party

code? And how do you mobilize developers

to be able to go on and fix those

issues? And it's not just kind of being

able to assign ownership. It it's also

about guiding providing the right

guidance to the development team so that

they can number one prioritize what

needs to be fixed and number two also

identify how that needs to be fixed.

From an application security pertains

the number of scans is not a problem

today. Different type of scanners is not

a problem today. The problem is you know

how do you bring in more context more

prioritization to that so that you can

remediate faster in the context of the

risk that matters the most because a lot

of risk that comes from apps no may not

matter at all and that's why we'll talk

about secure code to cloud workflows

that is enabled through GitHub advanced

security and Microsoft defender for

cloud uh integration

let's start with how the end outcome of

that would look like on GitHub for from

a development and security perspective

Let's go to security section on this

demo repository and we'll go to

dependabot. For those of you who don't

know, dependabot is a dependency

management and software composition

analysis product. It helps you identify

vulnerabilities in all the open source

packages that your your repositories

might be importing. And in this case,

this is an organizationwide view of all

the dependency related issues,

dependabot related alerts that you have

open on in your environment. And as you

can see, there are some 223

open dependabot alerts in this

particular organization. Um there's

already some context in the form of know

what kind of package it is, whether it

is critical or high, whether it's a

direct dependency or not or or whether

it is a dependency in development or or

not. But with this integration and like

I said I'm going to show you the end

outcome. You will have the additional

ability to prioritize these alerts based

on the runtime context itself. So when

you as a developer or an appsec persona

see a list of alerts your natural

question is is that important right? Uh

the importance can be brought in in the

form of hey is this even deployed

somewhere? So we can go and search for

has deployment.

And now you can see there are out of

those 200 plus uh alerts there are only

48 alerts that are open that have an

active deployment. And this information

is coming from Microsoft Defender for

cloud integration. And we'll talk about

more that in a minute. But already you

are much more focused now in terms of

being able to prioritize and remediate

issues as compared to previously where

you had did not had this information.

But further down 48 might be just too

many even know for some smaller teams

which is where you can go and add

filters like runtime risk where you have

runtime risk indicators like critical

resource internet exposed sensitive data

or lateral movement. Again indicators

coming from Microsoft Defender for cloud

for the for the artifact for the uh

workload that is running corresponding

to these im these repositories that are

on GitHub. So let's filter on anything

that is internet exposed.

And you can see now there are only 21

alerts that we need to focus. But these

are definitely alerts that we need to

focus because these are alerts on

repositories that have a corresponding

artifact corresponding container in this

case running in production which is

internet facing. But at the same time,

you already have a lot of information

that allows you as a developer and as a

apps sec person on GitHub to be able to

go on prioritize things that matter the

most. We remember we started from 200

plus alerts and now right now we are

only at 21 of those alerts

organizationwide.

Now the question that you might have is

how are we getting this information? I I

already mentioned this is coming from uh

from Microsoft Defender but like where

can I review that information on GitHub?

So if you go to packages section on your

organizations

and visit this linked artifact section,

this is what we are right now calling it

as a virtual registry.

We GitHub has exposed APIs. These are

public API endpoints that can be used by

anyone to populate the information about

these records. So in this case, let's

see example of this Sava web shop which

is the repository that we are focusing

on. And what we can see is for that

particular repository there were 128

deployment records that were available

and all of these deployment records in

this example were coming from Microsoft

Defender for cloud but you can actually

use the APIs to populate it natively as

well. The important information that you

see here is that there are these

containers that are running in

production. uh it tells you even the the

zone know what's the the Kubernetes

cluster in this case you know AKS

cluster name and of course know all

these runtime information about

artifacts is linked to the repository

and more importantly to a specific

workflow and and build as well which

means you have the ability to pinpoint

to a specific code commit where which

led to an artifact building through a

workflow which is what is right now

running in production. But if you

remember we were talking about whether

something has a deployment or not as a

filter on alerts which is available on

dependabot and actually code scanning

alerts as well. So the presence of a

deployment record which has an active

deployment means that you have no code

running from this particular repository

in in deployed and it has uh information

like critical resources intern sensitive

data all that information being

populated directly from Microsoft

defender for cloud and into GitHub

ecosystem itself. So this is where

you'll be able to track a lot of those

artifacts in runtime. But you know uh

there information about that know the

deployment records and it's actually not

just deployment records. We can even get

storage records if those images were say

pushed to an Azure container registry

and so on so forth.

Now just to kind of recap what we saw

right now, right now what we saw here is

was the ability to get more runtime

context from Microsoft Defender into

GitHub and then being able to use that

runtime context to be able to go on

filter dependabot alerts and actually

even code scanning alerts. You know this

these filters are available for both uh

dependabot and code scanning. So if

you'll take an example in this case code

scanning has 114 open alerts but we can

again look for

internet exposed ones

and now there are only 18 alerts that

really need matter the most rest can

wait you know first but first you know

these 18 alerts needs to be resolved.

All right. Uh this was on the GitHub

side, right? The application security

persona or the developer who is or

security app you know user who is

constantly trying to prioritize what

matters the most on on dependabot and

codekill. But let's also look at from a

security operations persona.

This is Microsoft Defender for Cloud and

what we are doing is right now looking

at the attack path analysis for certain

subscriptions and there are a bunch of

recommendations that are present here

but let's try to kind of drill down and

focus on a few things. I'm going to look

at risk factors that uh involve internet

exposure and sensitive data. If you

remember these were the same risk

factors that have propagated from

Microsoft Defender for cloud to uh

GitHub. But let's go and apply this.

And I'm going to add one more filter

where we'll say that the resource type

is storage account because we want to

identify

recommendations that where the target

could be a storage account which might

be processing sensitive data. And let's

try to find a relevant workload here.

Yeah, let's take a look at this one.

internet exposed container with high

severity vulnerabilities that could

allow lateral movement to a critical

Azure storage account. Now uh a lot of

information is tied kind of end to end

by defender. Here in this case you can

see is that uh there is a running

container Java webop

which is uh associated with the storage

account which is you know processing a

lot of sensitive data. It's a crown

jewel storage account. this uh container

was built through a particular container

image which is on Azure container

registry which was associated which is

associated with the GitHub repository.

So defender uh and the Microsoft

integration you know with GitHub is able

to do this code to cloud correlation

where we are now able to automatically

go and associate a GitHub repository to

running container images. And for this

to work, you just have to go to your

defender account and enable your

connections essentially by create uh

making a connection into GitHub using it

uh the Microsoft uh DevOps security app

and and that should be sufficient. So

like from a call of action call to

action if you are in defender and GitHub

advanced security customer make sure

that you have uh enabled the connection

from Microsoft Defender to GitHub and if

you already have one you might have to

and and you have not you have done it

like a few months back you might have to

update and review the permissions of the

app but you know that's that's all you

have to do but but going back to this

attack path analysis you know it was

identified that this was this container

was part of a pod which is essentially

exposed through a service which is

internetf facing But let's go back and

look at the container and what are the

recommendations associated with this

container and there are quite a few u

take example of let's say uh update load

dash right and in this case if I go to

associated cvees

there were some CVS identified by

running a scan on the container itself

by Microsoft defender but it was able to

do map and correlate those CVEes those

vulnerabilities to an existing GitHub

alert as

So it is able to identify that the same

CV was identified in by GitHub using the

dependabot scan while scanning the code

repository. Same time the same CVE exist

in the current time container itself as

detected by Microsoft defender for

cloud.

Let's take another example now where we

can go back here to containers

recommendation.

I'm going to look at update busy box.

Now in the associated CV section,

let it load.

You don't see a GitHub related alerts

here. And this is perhaps if you

remember one of the slides that we're

talking about, you know, these

vulnerabilities are coming from not

coming from the code or the repository

itself, but from the image that was

built or the base image where the the

the repository or the code exists now.

But it still needs remediation, right?

And you can go and identif ass assign

this particular uh issue directly from

Microsoft Defender for cloud into GitHub

issue itself. So I can go and click on

take action. In this case, I've already

done that once. So if I click on view

issues on GitHub to uh the update busy

box uh recommendation has been

essentially converted into a GitHub

issue, you can see there are labels for

different cloud. It has all the details

that can help developer fix this issue

in the base image itself and being able

to uh reduce this risk.

Now let's go back and also look at the

additional things that can happen right

now with with your connection from MDC

into GitHub you will be able to see uh a

lot of uh recommendations coming from

GitHub directly. So in this case you can

see there's a recommendation which says

GitHub repositories should have

dependency vulnerabilities resolved.

GitHub repositories should have code

scanning findings resolved. So if I

click on code scanning findings you will

be able to see all the code scanning

findings corresponding to that

repository uh as identified by code

scanning on GitHub but now on Microsoft

Defender. So from a secop secops

perspective you have visibility into not

just the alerts and findings that are

identified and detected in runtime by by

Microsoft defender but also by uh

identif vulnerabilities and issues and

identified by GitHub now on on Microsoft

defender for cloud as well.

All right. Um so that's

uh essentially the key aspect of this

integration right and know if you kind

of take a step back and try to revise

what we just saw there were kind of two

things here one was as an appseac user

or as a developer if you want additional

context about uh the vulnerabilities

that are needs to be fixed through

github advanced security you can bring

in a lot of additional context from

Microsoft defender for cloud but as a

security operations as a cloud security

persona If you want visibility on a

workload in on on the risk that those

workload represent end to end, not just

the runtime one, but also from GitHub uh

using its SE and SAS findings and secret

findings for that matter. You can bring

all of that information on Microsoft

Defender as well. Um

that being said, let me jump into the

slide and talk a little bit more about

this integration. U

the there were two aspects to it like

you know obviously we mentioned about

you know being able to kind of leverage

the third party virtual registry

platform on on GitHub to be able to get

all of that runtime context into GitHub

from defender. uh but that's combined

with you know advisory database and you

know CV container information gives you

a holistic remediation platform on

GitHub which by the way at the end of

the day you can go and assign code

scanning alert to copilot and it can go

and remediate those vulnerabilities for

you. So the agentic platform in the form

of code coding agent is present there to

be able to help you remediate those

findings those issues once you have

identified what what what are the issues

that you'd want to focus more

so don't need any trade-off right know

we at the start of the session Rupita

talked about the the kind of friction

between these two functions but that

does not necessarily have to be the case

you know if these two functions can work

you know hand in and you know closely

together with the abilities that this

integration provide to our customers. uh

more details are present on this blog

you know and I can answer more questions

also you know if there are any chat but

that was it lupita do you don't want to

add anything

>> can you guys hear me awesome yeah we

actually have some great questions in

the chat I think we can kind of work

from the top down if that's okay so I

believe the first one that came through

was how we will how to configure

dependabot at the org level.

>> Dependabot configuration at the org

level is something um

h

I don't want to say something which I'm

not sure. So I think you know I'll

probably find something

uh later and we'll try to kind of post

it but I think there are yeah I I don't

have the answer at the top of my head so

I I'll have to kind of refrain from

giving any answer which might not be

accurate at this point.

>> Yeah and and I think that's more related

to the GitHub configuration. So within

GitHub if you have the dependabot

license or it comes with all enterprise

um

all enterprise accounts but there is

some additional features if you have

code security license which then you can

uh go ahead and apply the configuration

there. Um but once you kind of get that

going I think more so the interesting

question that we have here is is

regarding the defender connection. So

one of the things that came up was do

different versions of the binary

deployed get tracked differently.

>> Yeah. Uh but before that I think you

know I can answer the question the

previous question right like you know if

if you have GitHub advanced security

licenses you should be able to go to the

uh advanced security configuration

settings and you know create a security

configuration which includes like config

that is for secrets code security and

for dependency scanning as well which is

where you can enable depend about alerts

and security updates and essentially

applied across all of your organization

right Uh

okay let's go to the next question. Do

different versions of the binary

deployed get tracked

uh differently? So the way it works is

if the the artifacts that you are

building would be essentially created

through GitHub actions, right? And uh

GitHub actions would and as a result of

that GitHub uh would have information

about

uh all the artifacts. So if you go to

packages

and linked artifacts

uh you will have the details of all

different versions of that artifact

itself. In this case it's just a

specific sh but if there are like newer

versions released you will be have able

to have the information. In this case

you can see this is like 109 and this is

10.

So all of the them are being tracked

separately because of their check sums

and uh yes short answer is the different

versions will be tracked separately and

let's say a new version does not in this

case was not internet exposed and

sensitive data so you'll not have that

information

in the alerts I hope that answers the

question

>> great and then the next question does it

track dependencies first party third

party open source separately from the

base application real curious of the

dependency manageer management on

deployed assets to VMs.

>> So dependabot focuses on the

dependencies that you can identified in

the codebase itself, right? And

typically that's that happens through

manifest files, right? It's essentially

depending on which ecosystem, which

package management, you know, which

language framework that you are kind of

your code represents. uh you will be

able to identify all the dependencies

primarily that are open source and third

party uh anything that comes from uh

container images right I think that will

be more coming then build that the

images are built and then scanned

through defender for cloud either by

image scanning or runtime scanning so

real curious of the dependency

management on deployed assets so yeah I

think uh once it is deployed you know it

will be a combination of the uh third

party and open-source

uh packages or dependencies coming from

code as well as the base images that

would have be no that base images that

have their code running and then live in

production on uh defender on Azure

rather.

>> Okay,

>> awesome. The next question is can we

also connect offender for cloud with our

GitHub co-pilot spaces? Is there an NCP

server specifically for security or just

in general such as Azure Copilot which

is not really good?

>> Yeah. Uh I think uh defender for cloud

my understanding is that there is a work

going on on um an MCP side of things

like in exposing some of those

capabilities through an MCP server. Uh I

I will not speak for the the MDC team

but I know because we work closely with

them and I think they are working on

potentially an MCP server in future. So

stay tuned for that.

Excellent. Any other questions?

>> I'm looking at the chat here.

>> Yep.

Um,

I love the engagement, by the way,

seeing where everyone's tuning in from.

If there's no other questions, then I

think we can go ahead and wrap up.

Hopefully, this was helpful. As

mentioned, we have these sessions every

few weeks, so feel free to register for

them all, come back on. We always have a

rotating set of speakers that come live

and talk about topics that you guys want

us to discuss.

So with that, I'll go ahead and thank

everyone for their time and sign off.

Thank you all for joining and thanks

again to our speakers.

This session is part of a series. To

register for future shows and watch past

episodes on demand, you can follow the

link on the screen or in the chat.

We're always looking to improve our

sessions and your experience. If you

have any feedback for us, we would love

to hear what you have to say. You can

find that link on the screen or in the

chat. And we'll see you at the next one.

Hey, back.