Comments 10
С аудитом исходных кодов не все так однозначно.
Нельзя передавать исходники широко используемого продукта в аудит только людям, которым не вполне доверяешь. Например, какой-нибудь хакерской группировке или спецслужбам (любым). Они могут найти и припасти для исключительного использования какие-нибудь уязвимости.
Но есть и обратная сторона. Использовать непроверенный продукт на критически важных системах тоже нельзя. Разработчик может в чьих-то интересах сознательно создать в продукте дыры.
Впрочем, проблема имеет решения.
Вариант первый. Разработка персонального продукта для каждого, кто хочет аудита.
Да, дорого. Но зато обнаруженные уязвимости не могут быть использованы аудитором против других пользователей.
Вариант второй. Аудит у нескольких групп, вызывающих доверие, плюс открытый общественный аудит.
В этом случае снижается вероятность, что какой-либо аудитор сможет обнаружить и "приватизировать" уязвимость.
Естественно, абсолютных гарантий никаких: уязвимости могут быть пропущены при любом аудите, доверенный аудитор может обмануть доверие. Но и "закрытый" код вполне может быть подвержен исследованиям на уязвимости, что показывает вал обнаруживаемых уязвимостей, включая очень опасные, в закрытых системах.
Разработка персонального продукта для каждого, кто хочет аудита.
Да, дорого. Но зато обнаруженные уязвимости не могут быть использованы аудитором против других пользователей.
Вы хоть каким то боком к программированию относитесь или опять пропускаете голосование в думе?
Как предлагаете это реализовывать? Есть в продукте функция — «обмен по сети», у нее есть входные и выходные параметры и какой то определенный функционал внутри. Т.е. для одного мы ее так программируем, для другого по другому? Это как вообще? 2+2 для каждого клиента считаем по разному?
Все проще, чем кажется.
Для потребителя, который жаждет аудита, разрабатывается с нуля новый продукт новой командой без доступа к кодовой базе старого проекта. И да, каждая функция должна быть написана заново другим человеком, с новыми ошибками и уязвимостями.
Сторонние библиотеки — не головная боль разработчика продукта. Он не может предоставить исходники чужого закрытого продукта, а чужой открытый и без того доступен.
Я понимаю, что первый вариант так себе решение, и второй всяко получше будет, но разработка с нуля персонального продукта не является чем-то абсолютно невозможным.
Разные компании как-то умудряются разработать свои независимые решения
Дополнительной альтернативой является доверие к аудиторам клиента (а я рассматриваю случай, когда доверия нет) или отказ в аудите (и потеря клиента).
Положим, можно разработать систему под конкретного заказчика и отдать ему код на аудит, но есть пакостный момент. Аудитом будет заниматься ограниченный круг специалистов и чем это грозит вполне понятно. Стоит вспомнить, что в открытых продуктах до сих пор обнаруживают уязвимости, несмотря на общедоступность исходников и несравненно бОльший круг исследователей.
Крайне неоднозначный вопрос, пока не имеющий универсального решения.
Например, если продукт разрабатывал условный Эпам, а тестирование проводит условный Люксофт, то шансы на пропущенный косяк резко падают. Хотя проверять код будет меньше людей (по сравнению с open source), они будут заниматься только аудитом. Полный рабочий день, проверяя по максимуму. Допускаю, что в пересчете на мифические человеко-часы сферического сеньора выйдет больше, чем аудит неограниченным кругом пользователей неопределенной квалификации. Потому что каждый аутсорсер заинтересован, чтобы поддержка досталась именно ему — говорят, она приносит гораздо больше, чем другие этапы жизни продукта.
У этого подхода есть и минусы. Как минимум, усложняется управление проектом и увеличиваются сроки. Разумеется, получается дороже. Хуже, если подрядчики увлекаются
Тут дело в том, что помимо багов самой программы есть и баги компиляторов и иже с ним. Достаточно вспомнить, например в мире Линукса, ряд условий при компиляции програм — определённые версии компиляторов, жёсткий состав ключей компиляции… Всё это было.
> Допускаю, что в пересчете на мифические человеко-часы сферического сеньора выйдет больше
Часы можеи и из сферической области, но за них расплачиваются полновесной монетой :)
> все-таки я не менеджер
Поверьте, от них тоже зависит весьма многое. Поварился в кухне тестирования и имел возможность наблюдать чудеса полёта фантазии менеджеров.
1. Есть такая штука как пиар. Доля Макафи и Симантика в госорганах практически равна нулю, поэтому им сертификация уже не нужна. А раз не нужна, то можно и заявления делать. Вот Майкрософт как-то не спешит делать заявления об отказе предоставления исходных кодов на сертификацию
2. Обновления. Если мы говорим об антивирусах Макафи и Симантик, то что их сертифицируй, что не сертифицируй — отказаться от обновлений нельзя. А с обновлениями может прилететь что угодно (ну почти что угодно). Более того — задержка времени на сертификацию и проверку кода может быть критически важна
Даже самого крупного аудитора (3-ю сторону) можно купить.
Я слышал, не так давно большая четверка стала большой тройкой, когда вскрылся такой факт. Правда свято место пусто не бывает, и теперь это снова четверка)
Аудит программного кода необходим. Безопасность через неясность — зло