1000 Глаз, Которые Не Хотят Проверять Код Проектов С Открытым Исходным Кодом



1000 глаз, которые не хотят проверять код проектов с открытым исходным кодом

Существует миф о том, что программное обеспечение с открытым исходным кодом лучше и безопаснее, чем проприетарное.

Много раз это справедливо подвергалось сомнению.

Есть примеры, когда в открытом коде обнаруживались эпические уязвимости, которые долгие годы скрывались от разработчиков и пользователей.

Я считаю, что качество проекта зависит от того, как менеджеры по разработке построили процесс и какие методологии/инструменты используют, а не от того, является ли проект открытым или закрытым.

Однако остается убеждение, что открытый исходный код — это хорошо.

Мол, тысячи людей могут изучить код, и кто-то заметит ошибку.

Не буду развивать мысль, думаю, вы поняли, о чем я.

Как разработчик PVS-Studio, нашедший несколько тысяч ошибки в open source проектах я к этому отношусь очень скептически.

Во-первых, я сомневаюсь, что очень часто кто-то из этих абстрактных сторонних людей действительно занимается поиском ошибок и уязвимостей.

Во-вторых, будучи таким редким человеком, могу сказать, что разработчикам зачастую наплевать на эти старания.

То есть сами разработчики могут быть не заинтересованы в качестве и надежности своих проектов.

Их интересуют новые функции или что-то еще, а не потенциальные проблемы и дефекты безопасности.

Много раз мои сообщения о найденных ошибках игнорировались или откладывались авторами проектов с открытым исходным кодом.

Вам нужны доказательства? Пожалуйста.

Сегодня у меня просто красивый смелый пример.

Написать эту мини-заметку меня побудило неожиданное письмо от баг-трекера проекта Samba. Я сначала даже не понял, что это за письмо.

Оказывается, мы дошли до ошибок, которые я записал 9 лет назад! Ошибка 9320 — PVS-Studio. .



1000 глаз, которые не хотят проверять код проектов с открытым исходным кодом

Уже девять лет никого не волнует, что в проекте есть баги.

Девять лет спустя никого не волнует, что проект содержит старые версии библиотек с потенциальными уязвимостями вроде CWE-14 .

Да, собственно, даже сейчас, пока я пишу эти строки, в коде присутствуют такие же опасные вызовы Мемсет .

Например, здесь:

  
   

static void md_result(MD_CTX * ctx, unsigned char *dst) { SHA256_CTX tmp; memcpy(&tmp, ctx, sizeof(*ctx)); SHA256_Final(dst, &tmp); memset(&tmp, 0, sizeof(tmp)); }

Или здесь:

static void calc(struct md2 *m, const void *v) { unsigned char x[48], L; const unsigned char *p = v; int i, j, t; .

memcpy(m->state, x, 16); memset(x, 0, sizeof(x)); }

Проблемы этих Мемсет компилятор удалит его, а личные данные продолжат находиться в памяти.

Если вы далеки от этой темы, то эта статья поможет вам разобраться, что к чему» Безопасное удаление личных данных ".

Возможно, именно эти ошибки и дефекты безопасности не представляют собой каких-либо реальных проблем или угроз.

Дело в другом.

Разработчиков проекта это не волнует. А сторонним разработчикам плевать.

Никто не берет и не исправляет хотя бы те ошибки, которые можно взять и найти с помощью PVS-Studio. И даже уже найденные ошибки исправлять не спешат. Разбомбили.

Стало легче.

Спасибо за внимание :).

Я обращусь к этой заметке, когда кто-нибудь снова начнет спорить о том, что открытый исходный код безопаснее.

Теги: #информационная безопасность #программирование #Управление разработкой #открытый исходный код #статический анализ кода #качество кода #открытый исходный код #процесс разработки #ошибки программы #cwe #исправление ошибок

Вместе с данным постом часто просматривают:

Автор Статьи


Зарегистрирован: 2019-12-10 15:07:06
Баллов опыта: 0
Всего постов на сайте: 0
Всего комментарий на сайте: 0
Dima Manisha

Dima Manisha

Эксперт Wmlog. Профессиональный веб-мастер, SEO-специалист, дизайнер, маркетолог и интернет-предприниматель.