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