Открытый код требует хлопот
На форуме Russia Open Source IT Summit отдельная секция была посвящена тому, как решения с открытым кодом могут помочь в сложившихся условиях, а также обсуждению достоинств и недостатков использования решений с открытым кодом
Руководитель центра кибербезопасности CyberART ГК Innostage Антон Кузьмин, сославшись на свой опыт, предупредил, что попытки использования решений с открытым кодом требуют наличия штата разработчиков, без которых нельзя создать ничего реально работающего. Также требуется вычищать ошибки, как случайные, так и внесенные намеренно закладки и разного рода недекларируемые возможности. В итоге через некоторое время от первоначального кода мало что остается. Так что процесс имплементации решений с открытым кодом мало чем отличается от разработки решения своими силами с нуля. Также необходимо иметь команду, которая эксплуатировала бы этот продукт. Но с другой стороны, среди готовых решений с рынка также трудно найти тот, который позволил бы решить стоящие перед потенциальным заказчиком задачи. К тому же в коммерческих продуктах также имеются ошибки и закладки.
Управляющий директор аппарата правления ПАО "АК Барс Банк" Вячеслав Яшкин назвал использование открытого кода давней практикой. Более того, по его оценке, среди крупных компаний нет ни одной, которая бы не использовала такие системы. Однако для этого нужны компетенции и подготовленные кадры, способные поддерживать и развивать. Если же речь идет о системах поддержания информационной безопасности, то критичной является задача выявления и устранения разного рода ошибок и уязвимостей. Соответствующая инфраструктура требует наличия как минимум трех подразделений - сопровождения и поддержки, развития, поиска и устранения ошибок. В "АК Барс" выстроена система безопасной разработки, которая уже несколько раз пересматривалась. И нужно, чтобы к началу проекта внедрения системы с открытым кодом такая работающая инфраструктура уже была. Создавать ее в процессе работы сложно и даже болезненно. И в целом нужна культура работы с открытым кодом, причем ей необходимо следовать как сообществам разработчиков, так и потенциальным потребителям. И в целом рынку нужны максимально готовые к использованию продукты, пусть даже платные или с коммерческими дополнительными модулями. Такие продукты уже есть, и они активно развиваются. Пример - Elastic.
С другой стороны, Вячеслав Яшкин обратил внимание на риски. Для продуктов с открытым кодом также существует риск, что тот или иной проект в силу каких-то причин может перестать развиваться. Так что необходимо всегда иметь запасной план по миграции на что-то другое. Это касается как проприетарных продуктов, так и систем с открытым кодом.
Руководитель отдела безопасности ПО "Лаборатории Касперского" Дмитрий Шмойлов поделился опытом своей компании в области аудита стороннего открытого кода. Любой код, пока его пишут люди, содержит и будет содержать ошибки, но вендор должен их находить и устранять, причем неважно, идет ли речь о собственном коде или стороннем. А сторонний код, в том числе открытый, как отметил Дмитрий Шмойлов, используют все. В "Лаборатории Касперского" построена многоступенчатая процедура проверки внешнего кода, где применяется как ручной анализ, так и автоматизированный. Но все равно, в полном объеме устранить все риски невозможно.
CEO компании "Сайберус открытый код" Сергей Гордейчик обратил внимание, что мало написать хороший продукт - необходимо прилагать серьезные усилия для того, чтобы решение было "живым". Так, необходимо регулярно обновлять базы знаний и сигнатур для антивирусных систем и средств обнаружения вторжений. В итоге систем поддержания информационной безопасности с открытым кодом не так уж и много.
