The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Исследование Coverity показало улучшение качества открытого кода

24.09.2009 21:43

Компания Coverity, известный производитель инструментария статистического анализа кода, опубликовала очередное исследование, основанное на анализе 11 миллиардов строк кода из 280 проектов СПО, включая Firefox, Linux, PHP, Ruby и Samba.

Один из выводов - целостность, качество и уровень безопасности открытого кода повышаются. С 2006 года, когда было проведено первое исследование, с помощью сервиса автоматической проверки кода было выявлено более 11 тыс. уязвимостей в 280 предоставленных программах, что дало возможность разработчикам исправить недочёты. Coverity обнаружила, что количество ошибок, обнаруженных статистическим анализом, в целом уменьшилось на 16 процентов, а общее количество ошибок снизилось от одной на 3333 строки до одной на 4,000 строк кода.

Coverity разбивает протестированные проекты на три категории, отличающиеся используемым для их исследования анализатором. Проект перемещается в следующую категорию после того как в его коде будут устранены все замечания. В первой (низшей) находятся 144 проекта, во второй - 36, в третьей - 4 (OpenPAM, Ruby, Samba и TOR). Наиболее распространёнными проблемами, обнаруживаемыми на протяжении нескольких лет, всё ещё являются нулевые указатели, утечки ресурсов и неумышленное игнорирование вычисленных значений.

  1. Главная ссылка к новости (http://www.coverity.com/html/p...)
  2. OpenNews: Опубликованы результаты тестирования 2500 открытых проектов
  3. OpenNews: Найденная уязвимость показала важность постоянного мониторинга вносимого кода
  4. OpenNews: Отчет по итогам анализа кода 250 открытых проектов
  5. OpenNews: Одиннадцать открытых проектов исправили все замечания "Coverity" теста
  6. OpenNews: Второй этап тестирования качества открытого ПО
Автор новости: JT
Лицензия: CC-BY
Тип: К сведению
Короткая ссылка: https://opennet.ru/23560-security
Ключевые слова: security, audit, code, coverity
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (20) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Zenitur (?), 23:14, 24/09/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Хм. Оказывается, возросшее количество находимых ошибок символизирует не то, что код стал хуже, а что сообщество лучше ищет ошибки!
     
     
  • 2.2, ононим (?), 23:20, 24/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    так и кодовая база тоже растет, ни так ли?
     
     
  • 3.6, Zenitur (?), 01:05, 25/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Я о том и хотел сказать, что увеличение количества найденных ошибок связано не с тем, что новый код хуже, а в том, что ищут лучше.
     
  • 2.3, hatelinux (?), 00:08, 25/09/2009 [^] [^^] [^^^] [ответить]  
  • –3 +/
    >Хм. Оказывается, возросшее количество находимых ошибок символизирует не то, что код стал хуже, а что сообщество лучше ищет ошибки!

    тоесть качество ошибок растет
    это радует

     

  • 1.4, ffsdmad (??), 00:09, 25/09/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    похоже они пиарят свою систему путём прогонки ей над OpenSource
    но интересно, не уж проприетарчики пользуются услугами подобных компаний, разве не проще просто не проверять, всё равно ни кто не знает
     
     
  • 2.5, pavlinux (ok), 00:59, 25/09/2009 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вы можете с ними списаться, заслать им свой код, они проверять и
    250 страничный отчёт пришлют, ещё год курить можно выдавая начальству
    по 20 багов в месяц за победоносно найденые, устраненные и описанные. :)

    Обычно не более 100.000 строк, но у меня 45.000 тока взяли. :(

     
  • 2.10, Aleksey (??), 10:24, 25/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Дешевле с точки зрения поддержки найти такие ошибки на этапе разработки.
     
  • 2.11, uZver (??), 11:22, 25/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    > но интересно, не уж проприетарчики пользуются услугами подобных компаний, разве не проще просто не проверять, всё равно ни кто не знает

    пользуются подобным совтом. Не проще ибо цена бага в продакшене очень велика. Дешевле купить систему проверки кода и постоянно гонять ее по проекту + фиксать ВСЕ замечание выдвинутые проверкой.

     

  • 1.7, hatelinux (?), 02:09, 25/09/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    зашлите им код qt
    интересно скоко в ней автомат машина найдет глюком ))
     
     
  • 2.8, Zenitur (?), 02:16, 25/09/2009 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Мало... Глючит не Qt, а новый KDE. Qt работает лучше и быстрее предыдущей версии.
     
     
  • 3.9, hatelinux (?), 05:37, 25/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    отправте как тест от группы опеннет (с)
    вот и узнаем
    и под ошибками подразумевалось скоко плохого кода найдет ихний "автомат машина"
    а не как реально работает qt
     

  • 1.12, Karbofos (??), 15:33, 25/09/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    какие-нибудь бесплатные\открытые проекты есть? не нужно ссылок на поисковик, нужено мнение, основанное на личном опыте.
    благодарю.
     
     
  • 2.13, Aleksey (??), 17:13, 25/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Для C++ ничего вменяемого нет. Бесплатные тулзы обычно столько ложных срабатываний делают, что через некоторое время на все эти варнинги забиваешь.
     

  • 1.14, Andrey (??), 22:23, 25/09/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Кстати, в отчете упомянута проблема:

    > ...
    >   struct tun_struct *tun = __tun_get(tfile);
    > struct sock *sk = tun->sk;
    > unsigned int mask = 0;
    >
    > The unusual situation in this particular defect is that the misbehavior happened at compile time. gcc looked at the assignment to sk, which used tun

    as if it was guaranteed to be a valid non-NULL pointer, and decided that there was no point in performing the if (!tun) test below. The if() block was
    optimized out. It’s in the source code, but it is NOT in the machine code that the compiler output. The programmers included a test to check
    whether tun was valid, and return an error if it was not. The compiler removed that test, resulting in binaries that would allow processing to continue
    past the intended checkpoint, even when tun’s value was invalid.
    > ...

    Вот тут-то и конец статическому анализу исходных текстов. Нужен еще проект по анализу соответствия полученного машинного кода исходному :)

     
     
  • 2.16, Alexey (??), 15:38, 26/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    struct sock *sk = tun->sk;
    Вот эта штука уже ошибка, т.к.если tun указывает в null, то в релизной версии эта конструкция может вызывать неопределенное поведение. Нормальный инструмент покажет, что указатель нигде не проверяется перед использованием. Так что все нормально.
     
     
  • 3.18, Andrey (??), 00:43, 28/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    > struct sock *sk = tun->sk;
    > Вот эта штука уже ошибка,

    Там в исходном коде, якобы, есть проверка на ноль. Но она была удалена компилятором, т. к. он был уверен, что в этом месте ноль не может быть никогда.
    Да и вообще можно было бы иметь функцию
    struct sock* tun_get_sk(...);
    Ведь они там такой же подход использовали, но для другой структуры.

     
     
  • 4.19, ximaera (?), 16:42, 28/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Проверка на ноль там позже. Ошибка в адресации должна возникнуть до этой проверки.
     

  • 1.15, Aleksey Salow (?), 11:59, 26/09/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Наиболее распространёнными проблемами, обнаруживаемыми на протяжении нескольких лет, всё ещё являются нулевые указатели, утечки ресурсов и неумышленное игнорирование вычисленных значений.

    Хех, вот вам и среды без автоматического управления ресурсами. Пока C/C++ жиф, такие баги будут находить пачками.

     
     
  • 2.17, я (?), 15:59, 26/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    > Хех, вот вам и среды без автоматического управления ресурсами. Пока C/C++ жиф, такие баги будут находить пачками.

    А, ну да, в яве "утечки ресурсов" официально ошибками не являются. Только вот это не выход из ситуации.

    > игнорирование вычисленных значений.

    а это что за монстр? printf() вместо (void)print()?

     
  • 2.20, ximaera (?), 16:43, 28/09/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >> Наиболее распространёнными проблемами, обнаруживаемыми на протяжении нескольких лет, всё ещё являются нулевые указатели, утечки ресурсов и неумышленное игнорирование вычисленных значений.
    >Хех, вот вам и среды без автоматического управления ресурсами. Пока C/C++ жиф,
    >такие баги будут находить пачками.

    Как будто в Java-программах не может быть утечек памяти.


     
     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2022 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру