Market resolves YES if a vulnerability/backdoor is intentionally introduced into an open source project used heavily by developers for the purpose of developing software, or if in my estimation it appears to directly target developer users. The market will resolve 12/31/24, so it must be discovered by then to qualify. Must be a project with at least 1k GitHub stars at the time of discovery.
Examples of projects I would consider part of developer toolchains under most circumstances (not an exhaustive list):
• homebrew (maybe arbitrary, but my assumption is that mostly developers use this)
• Linters/formatters
• LSPs
• Text editors and plugins/etc
• AI code assistants
• Programming environment/version managers (pipenv, rbenv, nvm, etc)
Examples of projects I would not consider in-scope under most circumstances:
• The Linux kernel
• curl
• OpenSSH
• General LLMs
• Most libraries that are simply imported into other software projects
Related questions
How will this resolve if something was added before the xz backdoor was reported, and found now that more people are looking?
Also, what if there's another attack in xz already, targeting developers, like joeyh suggests with gcc here: https://joeyh.name/blog/entry/reflections_on_distrusting_xz/
Does it count if a general-use library is backdoored and it, among other things, gets into developer tools? (I think this happened with https://snyk.io/blog/a-post-mortem-of-the-malicious-event-stream-backdoor/ )?
Does it count if a general-use library is backdoored with the specific intent to exclusively target a developer tool?
@jacksonpolack I would try to determine if the primary intent was to affect developer tool chains, but that may be difficult to assess. Evidence might include e.g. introducing a vulnerability in ProjectA and then promoting its use in a developer tool ProjectB. If there is no such evidence, I will be conservative in what counts as incidental vs intentional.