Спасибо! Буду ещё смотреть подробнее, потому что, как и говорил, сравнение поверхностное и беглое было. С go один из примеров, для других языков картина схожая была, но буду корректировать методику и продолжать сравнивать.
Довольно утрированно получается. В каждой ситуации есть несколько решений. Если библиотека OpenSSL может привести к рискам, которые убьют бизнес, то, конечно, такие риски будут недопустимы. Как с ними бороться вопрос отдельный, решать надо в комплексе. Если есть понимание, что риски минимальны, то да, можно пользоваться, но на страх и риск. И да, отдел безопасности берёт на себя эту ответственность, но не для того, чтобы просто снять головную боль с кого-то ещё. Подписываясь под рисками они обладают ещё правом за эти риски спросить с авторов и запретить использование чего-то. И далеко не все готовы пойти по пути "расслабиться и не мешать", причём не только из отдела безопасности, потому что уязвимости это реальность, а не какая-то формальность, которую навесили со стороны ИБ, директора, регулятора или ещё кого-то. Это как с техникой безопасности. На стройке надо носить каску. Да мешается, да жарко, да неудобно, но есть причины для этого.
И мы в компании своей работой считаем в том числе и донесение рисков, важности ИБ и её развития внутри компаний и в командах разработчиков в частности. Иначе рост числа атак будет расти в геометрической прогрессии.
Тут сильно будет зависеть от конкретной ситуации. Уведомить клиента хорошо бы в любом случае. Если под общей библиотекой подразумевается open source, то проверить, есть ли патч. Если патч есть, и можно на стороне клиента обновить саму библиотеку безболезненно, то для начала так можно и поступить. Если у клиента стоит firewall, то на первое время могут закрыть с помощью него. А вот про "кушать хочется" не понял. Работа безопасника -- заботиться о безопасности и оценивать риски. Если риски большие, то, конечно, он будет заинтересован от них избавиться. Дальше уже идёт дискуссия, как лучше это сделать максимально беспроблемно для бизнеса и клиентов.
Согласен, но тут цель была именно собрать статистику. Позже ещё вернёмся и с более подробной статьёй на эту тему.
Спасибо! Буду ещё смотреть подробнее, потому что, как и говорил, сравнение поверхностное и беглое было. С go один из примеров, для других языков картина схожая была, но буду корректировать методику и продолжать сравнивать.
Довольно утрированно получается. В каждой ситуации есть несколько решений. Если библиотека OpenSSL может привести к рискам, которые убьют бизнес, то, конечно, такие риски будут недопустимы. Как с ними бороться вопрос отдельный, решать надо в комплексе. Если есть понимание, что риски минимальны, то да, можно пользоваться, но на страх и риск. И да, отдел безопасности берёт на себя эту ответственность, но не для того, чтобы просто снять головную боль с кого-то ещё. Подписываясь под рисками они обладают ещё правом за эти риски спросить с авторов и запретить использование чего-то. И далеко не все готовы пойти по пути "расслабиться и не мешать", причём не только из отдела безопасности, потому что уязвимости это реальность, а не какая-то формальность, которую навесили со стороны ИБ, директора, регулятора или ещё кого-то. Это как с техникой безопасности. На стройке надо носить каску. Да мешается, да жарко, да неудобно, но есть причины для этого.
И мы в компании своей работой считаем в том числе и донесение рисков, важности ИБ и её развития внутри компаний и в командах разработчиков в частности. Иначе рост числа атак будет расти в геометрической прогрессии.
Тут сильно будет зависеть от конкретной ситуации. Уведомить клиента хорошо бы в любом случае. Если под общей библиотекой подразумевается open source, то проверить, есть ли патч. Если патч есть, и можно на стороне клиента обновить саму библиотеку безболезненно, то для начала так можно и поступить. Если у клиента стоит firewall, то на первое время могут закрыть с помощью него. А вот про "кушать хочется" не понял. Работа безопасника -- заботиться о безопасности и оценивать риски. Если риски большие, то, конечно, он будет заинтересован от них избавиться. Дальше уже идёт дискуссия, как лучше это сделать максимально беспроблемно для бизнеса и клиентов.