bad incentives for security work

Posted Jun 25, 2025 23:44 UTC (Wed) by pizza (subscriber, #46)
In reply to: bad incentives for security work by roc
Parent article: Libxml2's "no security embargoes" policy

> Part of the problem here is the security-research culture that celebrates *finding* bugs but does not celebrate *fixing* them.

The sad fact of the matter is that *unfixed* bugs are considerably more valuable than fixed ones.

bad incentives for security work

Posted Jun 26, 2025 3:38 UTC (Thu) by wtarreau (subscriber, #51152) [Link] (4 responses)

> The sad fact of the matter is that *unfixed* bugs are considerably more valuable than fixed ones.

In part but not only. I've met many people telling me their stories of how they got root here and there. It's certainly fun and interesting, but it looks so amazing to most people that they quickly feel like super-heroes or magicians who can do stuff nobody else can do, so very quickly there's some pride in finding bugs only.

And I agree that the heroic part is not finding the bug but fixing it without losing functionality. On the kernel security list we encourage a lot the reporters to provide the fix themselves so as to promote their work, trying to make them understand where the value is (and because once you understand a bug well, you're very close from fixing it). Most often it works well. Some come back later with new bugs and the accompanying proposed patch.

bad incentives for security work

Posted Jun 26, 2025 7:17 UTC (Thu) by tjasper (subscriber, #4310) [Link] (3 responses)

Perhaps, to extend this sentiment, a response to an embargo request from a security researcher is to agree, only if said researcher makes the effort and provides a fix at the same time?

bad incentives for security work

Posted Jun 26, 2025 9:58 UTC (Thu) by Wol (subscriber, #4433) [Link]

Not necessarily, but as an absolute minimum it should come with a decent bug report, that explains WHY it's a security problem, and also a strongly plausible explanation as to why it deserves an embargo.

If the researcher can't be arsed to describe WHY it's a problem, then the assumption should be it isn't.

Cheers,
Wol

Requirements to ask for an embargo

Posted Jun 26, 2025 10:53 UTC (Thu) by farnz (subscriber, #17727) [Link]

Not necessarily a fix, but an embargo request should come with enumerated benefits for the upstream maintainer - obviously, "we will work with you to provide a fix that you're happy to apply" is a benefit, but the judgement about whether the benefits on offer are big enough should be left in the volunteer maintainer's hands.

Fundamentally, this ends up being another case of "you shouldn't expect volunteers to co-operate with you for your benefit out of the goodness of their hearts". Maintainers should be free to co-operate if they want to, but also free to refuse to co-operate if that's the way they feel about you today, and if you want them to co-operate, you should be offering them something that makes them want to co-operate (be that money, assistance, public praise, anything else that motivates them).

bad incentives for security work

Posted Jun 26, 2025 17:15 UTC (Thu) by wtarreau (subscriber, #51152) [Link]

> Perhaps, to extend this sentiment, a response to an embargo request from a security researcher is to agree, only if said researcher makes the effort and provides a fix at the same time?

Unfortunately that doesn't work, because I have an example of a currently pending issue on a project where the reporter asked for an embargo and came with the patch. Stupid reasons again.