Hugging Face's logo

Join the conversation

Join the community of Machine Learners and AI enthusiasts.

Sign Up
Back to feed
ZennyKenny 
posted an update 4 days ago
Post
1,893
Trying to train a locally deployable model on a LoRa adapter that's just wicked strong at running sec evals on PRs because these general purpose code review solutions always seem to miss glaring security stuff.

The clear finding from the v1 training run was that "less code = more secure" lmfao.

Model basically scores functions better the less stuff they do. It's right I guess in a kind of demented way. Pack it up boys, we've got the solution.
Kreout

A useful check for that length shortcut might be paired vulnerable/fixed versions of the same function, with similar token counts. Then include a few fixes that deliberately add validation code: the safer version is longer. Does the ranking still prefer the shorter vulnerable version? I would keep whole repositories out of training for that check, so near-duplicate functions cannot make the result look better than it is.

·
ZennyKenny

Yeah usually the fixed versions of whatever functions just remove the vulnerable code, so it's logical why it's happened like this, it's just kind of funny that it selects so heavily for less code.
dipankarsarkar

Fixes that just delete code are rarer than they feel, at least in PrimeVul.
I counted its paired config: 4,382 vulnerable/fixed versions of the same function.
The fix is longer in 3,659 (84%) and shorter in 577 (13%). Median about +58 characters, +2 lines.
Most CVE fixes add a bounds or length check.

So on those pairs a "less code = safer" scorer is not at chance.
It ranks the vulnerable version above its own fix about 84% of the time.
That makes them a sharp probe for the v1 adapter: well below 50% pairwise means it learned length.

Where did your v1 secure examples come from, fix commits or separate clean repos?

·
ZennyKenny

Dataset is curated from various fix commits, PrimeVul samples, and some grey-area licensed stuff that I don't want to divulge publicly. Resulting model is going to be open-weight so the community will benefit from the output.

dipankarsarkar

Then hold the PrimeVul pairs out by commit before using them as the probe.
If a fix commit was in training, a pass on its pair is memory, not judgment, and the 84% length baseline gets muddier, not cleaner.
Pairs from commits you did not train on are still a clean length test.
Do you keep the training commit hashes, so the probe can be filtered against them?

·
ZennyKenny
•
edited 2 days ago

Definitely marking my trained pairs as seen to avoid memorisation.
In this post