Okay, so we are in time so we can welcome Philippe and on his dog and please if you still see some space next to each other, try to move to the middle so more people can come in.
So, welcome, I'm going to talk today about a favorite topic which is AI and L.M.s and GNI.
And excuse me, speak up.
Okay.
Okay, now it's better.
You hear me all right?
In the back, it doesn't saturate better like that.
So, I'm going to talk about our favorite topic which is AI and GNI that we all love to hate.
Me, in particular, actually, I'm not so much of a ludic but I have a no AI badge in the back of my laptop.
And not of this was generated with AI by the way.
So, Philippe and I'm the lead of an open source project.
It's actually now a small foundation called abort code.
And everything we do is free an open source code data and standard.
To help people use more open source.
So, figure out what the code comes from, what the license or the security issues.
And I'm sure we can all benefit from that.
I double the beat in standards.
I'm a co-founder of something called SPDX for S-bounds.
And I'm also a co-controller to cyclone DX because standard you need more of them so you can pick which one to support.
And I'm also behind a small standard called package URL which happened to be since mid December, a commas standard.
And on the way to ISO, it's a very stupid string to identify package in S-bomb and SCA tools and VomT database.
You will hear about that if you don't, who has ever heard about Perl or package URL in the room?
Good, so it's pretty cool.
You will have to surface with that whether you like it or not if you're doing somehow application security at some level.
So, we're building tools, data, standards, everything is free as open source.
That's important.
The origin that we have, of course, AI is a thing the world.
That's a serious issue and how can we make sure we reuse AI responsibly?
And there's the two core issue that I will bring up.
One is an issue of license.
Because if you think about open source, open source is defined by license.
Code that's generated by a bot.
The tree is not out yet, but is eventually non-corporatable.
So, there's no open source anymore.
There's also the related problem which is LLMs are massively trained on an open source code.
The code we write.
And it can really regurgitate, speak back this code very efficiently because they memorize it.
Which brings not only copyright issue, but also security issue.
You know, bag in, garbage in, garbage out.
So, you have a wonderful way to eventually propagate security bags from the training code to the code that's being generated.
So, who has not heard about AI and LLM?
So, somebody was living the cave for the last three years.
Wonderful.
That's great.
That's a rare thing.
We need to put you on a pedestal.
Because you will save humanity.
Eventually, you're the last one of us.
That's not so far to the thing.
Okay.
We're talking about the risk of the AI generated code.
And also another topic which is eventually AI is used as a feature in code.
It's not so much not only generated code, but also using an LLM,
a chat feature or whatever, especially in the world of cyber security.
It has really, really funky outcomes.
And eventually, having the ability to identify when code the AI generated is really important.
Whatever I'm going to show you today, and I'll do a short demonstration in July,
I'm not able to detect the AI generated code.
There's no EM dash in code to spot the AI generated code.
What I can instead do is detect strikingly,
which is strikingly similar to your open source code that was used to feed the beast.
And that's what we're focusing on at least part of what I'm talking about.
Now, you can at least do funny stuff and even useful stuff in the AI.
One of them is to generate points.
That's actually AI generated, which would describe how you would do AI generated code detection.
I'll make sure I put the link to the slides in my talk.
I didn't do it yet, but you have the full downloadable,
a library of his file and PDF.
I make sure it's on first them.
So there's another problem is there's a lot of open-washing in the space.
You know, open AI is not open.
And most of open space AI is not open source itself.
There is also a lot of open source, which is essentially central,
which opens any kind of AI will not be happening,
then so flow by torture some of them.
The good thing at least for now is that the code that's the AI generated very often doesn't compile yet.
It's a good thing you send that it's an easy way to spot.
It doesn't compile, doesn't pass the test, it's a good chance to see AI generated.
We have, as I said, not only a problem of open-washing,
but also a problem which is a lot of innovation.
And I don't like this kind of innovation about licensing.
We have a lot of new, what I call, open source, open-washing licenses,
which look like open source, but are not.
And that's so straight, not so much on secret, but on open source at large,
because it's very easy to get full if you're not really savvy about spotting these.
And sometimes they take an MIT, a BSD, or an Apache license, and in sort of few things.
We're seeing at least one or two new license a week,
which are funky, non-open source license.
They all come from AI projects or AI-related projects.
He's in point, for instance, if you're doubling with a source available,
or downloadable model from MITA, Lama 4,
good luck for you, you're basing your up, you cannot touch.
The license, please, says, you cannot choose this model if you're basing your up.
That's wonderful. What can go wrong with that?
So, I think that we have to treat AI, and accept sometimes to wonderful,
positive booster, sometimes it even compiles and run.
It's rare, but that can help.
But again, we need to ensure we understand what we're dealing with.
If you imagine taking all the code from the new project on the GPL,
and create a small language model of that,
I'm not a lawyer, but I cannot imagine a way where the output of generating code from that model
would not be also under the GPL.
Just derive in a weird, funky way with weight and math behind it,
but still eventually directly derived from that.
There's also interesting that, in some case,
and I think it's probably going too far, you have corporations which are
probiting AI, generated code, or probiting AI use.
You also have stupid corporations, and maybe some of you have been subjected to these abuse,
where you have managers that ask you every other day,
have been using more, have you been using more AI?
Which AI have you been using? Why are you not using more AI?
Which I think is absolutely terrible as a metric for performance.
I hope, how many of you are subjected to this kind of abuse in your corporation or business?
Oh, man, more than people that know Pearl, that's terrible.
Oh, we're leaving really in weird world.
So, the AI generates its search project.
The test base is a small between code training data,
where we've indexed about 260,000 open source project source code.
And what we did is to ask Chagipiti to generate code similar to a package URL.
So, essentially generate code similar to this package.
It's probably not a problem that you would use in real life,
but it's a possible point, and we saved each file in a code file.
And then we used or tool to rebuild for that to scan this file, this 100 files,
on the most common JavaScript project,
and basically run the code matching between index of 200,000 and this 100 generated files.
What we found is it's not scientific,
at least 20% of the case, strikingly similar code.
So, that's how the set-up looks like.
A lot of matching read, that everything's open source,
the whole point is you essentially collect check sums for your index,
and you match them back.
Except the check sums are not really check sums that would be too brittle.
We wouldn't find anything.
In particular, when you generate code,
we's depending on the parameter called the model temperature.
You will have essentially the same control flow,
completely different name for the variables, the functions, and else.
So, you need to adjust to this kind of things.
And initial approach, where to say, let's use AI to detect
if there are similarities with a code that exists in the AI generated code.
It worked, actually, okay, except it was extremely expensive.
I just spent all my free token budget with all the AI company there.
The focus of this project is to say, let's find strikingly similar code fragments
that make them from another project.
The problem is it doesn't work well with traditional techniques.
If you think about just an inverted index,
there's too much content to match details to get in.
You get too much noise very quickly.
We didn't try also the approach, but we research it extensively,
which is used in a search engine called Bing from Microsoft.
It's a project called BitcoinL, which is an alternative to inverted index indices,
which is interesting, and it probably something you want to consider in the future.
And you have a few companies in the space,
which are doing what I call traditional code fragment matching companies.
Commercial companies like BlackDuck,
semi commercial company like SKNOSS,
a proprietary company like Fossa or FOSID.
They all use the exact same algorithm,
which was devised by a guy in Berkeley in the late 1990s, early 2000s.
And that's really work well,
because it's not about to detect the wide variations we have when we use it.
You can point twice the same model with the same point.
You will get eventually slightly different results, so that's the problem.
So the approach is going to a first we break the code into chunks.
That means literally we parse the code in tokens,
and we detect boundaries using a content defined algorithm
to have chunks which are roughly of the same size.
And then we compute what's called FOSID hash.
Some of you may be aware of things like SSDEEP,
which is a tool to find approximate matching files,
where you use in security.
We're not using SSDEEP, but the principles are similar,
meaning you abstract the code fragment to bit string,
and you have way to match approximately validating distance,
in having distance if two code fragments are the same.
The thing in our case is what's interesting is that the precision
of the matching can be tuned at correct time,
depending on how large the bit string you want to be.
The best way to understand how this works is this.
Imagine two cats, pictures.
A brown and a gray that have a slightly different tail different eyes.
If you resize the image down to say 32 bits by 32 bits,
they look exactly the same.
That's essentially what we're doing here using as our approach,
but it's sizing down cat pictures,
which is always, of course, a security favorite.
So the initial project plan was to go through
each of these steps, I won't forget that.
But again, this didn't work well.
We were not able to detect a lot of the code,
because of these variations in the literature.
That's one problem.
And you know, good stuff, die hard.
We found an algorithm devised by a guy,
which happened to be the author of a venerable version
control system called CVS,
which creates, which was based on RCS,
which then led to subversion.
They eventually took it with a few segues in Bazaar
and other version control systems.
And I think the guy, I don't know if he's dead or not,
but he's retired.
At the minimum he's retired, working in Dutch university.
And he wrote a piece of code to actually
transform a stream of code tokens
in something that's generic and makes sense.
It's simple, a views, it's time tested,
it's like what almost 40 years.
And we call that code stemming, because that looks cool.
But the sense is to the same way you stem
language when you index it for information retrieval,
where two words which share the same start
will be just abstracted to that start.
Here we're doing the same with code.
We have another problem which I won't dive into too much,
which is how do you distribute eventually the fingerprints,
widely, so we don't create that this massive centralized database,
which is locking mechanism.
We have some single federated code to help with that
that we're progressively deploying,
which means that eventually you have access to this
to run on prem without having any of us in the picture.
It's important to liberate the data.
So, current status, we have something which works.
It's based on boring technology, I love boring.
It's proven there's nothing funky.
We use old code, we resist when we have
a request of newbies that says, hey, you know why don't use these new tools,
these new things?
No, we use boring, working things.
And we make sure we could also extract low-level libraries
that could be reused for the purpose at the same time.
So, before going there, I'm going to go and do the mandatory live demo,
which for sure will not work because we're alive.
And if I can find...
Shiza.
I see there's a few Germans in the room, right?
Normally, you're supposed to use French to swear.
But here, I'm using Germans because that's less recognizable.
Okay.
I'm just going to go there, we'll find it when we add the other,
that's a test instance.
And I'm going to search for test project.
I'm sure we're going to have one.
So, this is the tool we use at the phone tank called Scanko.
You can just look for it, download and run.
It can scanko for origin, like AI generated code,
but also a lot of things.
Scank containers do wrong off the hookups, lot of other stuff.
But match to match code, there we go.
And this looks like a good design project.
So, what we did here is scank for some code that was the AI generated.
If I recall correctly, the point was,
generate some code similar to this JavaScript library that does
basics before encoding.
We run these three pipelines in sequence,
what's interesting to see the results here.
There was one package that was detected,
which is eventually the project that we asked to generate code for.
So, it sounds a bit as a totology,
but interesting thing, asked for a prompt and
LLM to generate code about a certain package you'll get it out.
And if we dive a bit into this,
we see three matched resources,
and if we do dive into one of them,
and see a code you're here,
we can see the match fragments
that are essentially the same as our scene upstream.
And you could dive into the details.
You would be looking, you see some sections,
which are not highlighted.
It's just a side effect of the algorithm.
But you look at this code, you says.
Yes, there's no question that this has been obviously derived
from this upstream project.
And, and except for a few non-match regions,
such as the same code, and again,
this is literally exactly verbatim the code
with a few magnification.
So, that's the proof that we're not boasting there.
So, you don't have to trust me.
Next up, the key things also is being able to detect
the case where you have code that's used as a feature.
So, that's what we're working on next.
Together, we're helping people that build LLM using code.
In particular, there's a project at a hanging face,
which they call big code,
and they're building a dataset called the stack.
They're eventually helping them to run
or tools can code at scale,
to ensure that the provenance and license of the code they index
is actually known,
which is a good thing because at least you can trace
when you have potentially generated code from their models,
where this came from accurately.
The next frontier is really to treat models
as software components.
Meaning, there's some companies that probably don't want
to use Chinese models.
It's the case in Germany,
where I think it's been prohibited by the German government,
in some case.
I think DeepSeek has been prohibited.
It's the case in some US corporation
doing business with the US federal government.
I don't care about the reason.
I think frankly, it's overblown and bullshit,
but in any case it's interesting
from a technical point of view to say,
can we detect when a model is based on DeepSeek?
And I would be in fine tune, for instance, on DeepSeek?
It turns out from the early things we've been looking at
that if you treat the sequence of weight in a model
as a subject of fingerprinting,
we can actually find strikingly similar similarities
between the model and its fine tune versions.
In many cases,
so when you have quantization,
it's harder and it doesn't work.
But when you don't quantize,
you have essentially a few number of the weights
which are being updated at each generation of fine tuning,
and the rest is truly the same,
and we find these very efficiently.
The last point is to detect
when you have AI,
used using APIs and libraries.
So it's easier,
we already have the code to detect
code similarities to the tech libraries.
It's going to be just about tagging them,
so you have LangChain,
well known library in Python,
for instance, you want to make sure that you know that you
are using LangChain,
which means it's like using AI,
featuring your code.
And API importance,
something that's like yes,
simple as just doing a grip on URL.
And that's it.
This was founded in part by
the EU program called NGI search,
so if you're basing the EU in part
sums to your taxes,
thank you very much.
The code is yours,
it's not ours, it's for use to use.
And if you have questions,
I'm taking some questions there.
Go ahead.
Thank you very much.
Yes, I have a question about
transform somehow.
Do you use the actual representation,
the actual representation of source code
or transforming to intermediate representation,
like kind of abstract syntax tree
and when analyzed with tree
to find matches and flow of a code
and not exact words and constructions use?
So the question is,
do we use some kind of intermediate representation of the code
when we're processing?
So the answer is yes and no.
We transform the code,
we parse it,
we is a library from GitHub called Trissier.
And we basically have streams of tokens
that we then generalize with this algorithm from GitHub.
So it's really more of a syntactic base approach.
We don't deal with abstract syntax trees,
control flow and all that.
It's extensive to be done.
But it works very well.
The problem is at scale,
doing anything that deals with abstract syntax tree.
There's a guy here working also with a
bot code project,
which does incredibly sophisticated
static analysis to find actually reachable,
vulnerable code.
That's very expensive in terms of compute.
Here we're trying really to have massive matching
and we need to be able to turn out this very fast.
So we're doing some compromise,
but in practice it works pretty fine.
Another last question.
Okay, well, thank you very much.
Thank you.