ПО с открытым кодом (и особенно со свободными лицензиями) стало фундаментом многих (или даже большинства) информационных систем. Однако открытость кода, баг-трекера, списков рассылок и публичный способ передачи патчей/PR используются злоумышленниками.
Делают то же самое, что и white hats, например занимаются анализом кода и фаззингом (fuzzing), при наличии исходных кодов это делать легче, чем бинарники. Многие OSS-проекты не занимаются этим сами (fuzzing-ом), за них это делают бигтехи, белые и черные шляпы
Пользуются ситуацией, связанной с так называемыми silent patches (см. 1, 2). Это когда уязвимость исправляется, релиз выпускается, но CVE не создается и в changelog тоже не говорится про исправление уязвимостей. По второй ссылке описано как это можно детектировать с хорошей точностью с помощью LLM
Непрерывный анализ коммитов и PR (по аналогии с п.2), зачастую коммит/PR появляется раньше, чем создана запись CVE и/или выпущен релиз. В описании коммита может быть как явно указано что-то типа "fix segfault" (что большой долей вероятности будет являться уязвимостью), либо чуть более завуалировано, например "add additional check for array index". В любом случае, даже простенькая LLM классифирует такой коммит как потенциальную уязвимость для последующего анализа
Анализ сообщений баг-трекера (mailing list), а иногда (если можно заполучить контактные данные) и попытки связаться с автором бага вне трекера, чтобы заполучить дополнительную информацию, например, coredump
От выпуска исправления до попадания этого релиза (или его бэкпорта) в рамках дистрибутива ОС проходит время, пока мейнтенеры дистрибутива интегрируют исправление. Но если какое-то другое ПО "таскает" проблемное ПО(например библиотеку) с собой (в рамках контейнера, статически линкует/как-то еще интегрирует в себя), то надо ждать пока зависимое ПО произведет обновление проблемной зависимости
Злоумышленники могут втереться в доверие, стать мейнтейнерами проекта. В мире OSS, зачастую, разработчики одного проекта не имеют никакого представления о своих "коллегах" с правом на коммит в master (main). Пример с xz уже стал каноническим для этого сценария
Каких-то универсальных способов решения этих проблем нет, но вот о чем стоит задуматься: когда вы затаскиваете в свой проект библиотеку или стороннее ПО типа БД с открытым кодом:
есть ли вообще у проекта CI, есть ли тесты, есть ли статический анализ кода (и динамический если применимо), занимаются ли разработчики фаззингом. Могут быть сторонние CI/фаззеры, наиболее значимыми OSS-проектами занимается Google в рамках проекта OSS-Fuzz
публикуются ли CVE (почитать changelog и сравнить с CVE, иногда сразу понятно, что это игнорируется)
почитать CVE (если их добросовестно публикуют), возможно вместо бесконечных buffer-overflow и use-after-free вы решите, что стоит выбрать ПО на другом языке, где целые классы уязвимостей исключены (с библиотеками конечно сложнее если вы сами разрабатываете на таком языке)
как вы будете доставлять обновления ваших зависимостей себе (если через дистрибутив ОС, то как быстро мейнтенеры дистрибутива применяют патчи безопасности)
есть ли "покровители" у проекта в виде организаций или это тот самый проект из мема "a project some random person in Nebraska has been thanklessly maintaining since 2003" (случай с "Heartbleed" в OpenSSL навсегда попала в историю)
если вы нашли какое-то стороннее ПО с открытым кодом, а оно выглядит не сильно популярным сомнительным по многим критериям, но именно оно подходит вам лучше всего, то стоит задуматься о том, чтобы вложиться в него - дописать тесты, натравить на него анализаторы и привести его к такому "стандарту качества", который вы определили для своего
P.S. Данная заметка призывает не отказываться от OSS в своих проектах, а тщательно анализировать свои зависимости и вкладываться в те, которые вы используете, а в случае коммерческой разработки закладывать это на ресурсы.