10 категорий инструментов безопасности, необходимых для повышения безопасности цепочки поставок программного обеспечения

Эрика Чиковски

Сотрудник ОГО, ОГО |

По мере того, как лидеры безопасности продвигаются в создании программ безопасности цепочки поставок программного обеспечения, они сталкиваются с ситуацией хороших и плохих новостей с доступными им инструментами - буквально: технологии быстро развиваются как во благо, так и во вред.

Хорошая новость о быстро развивающейся технологии безопасности цепочки поставок программного обеспечения заключается в том, что быстрый темп инноваций открывает все больше возможностей для повышения прозрачности и прозрачности огромного количества компонентов и кода, которые входят в состав портфелей программного обеспечения.

Плохая новость, однако, заключается в том, что эксперименты и инновации идут в разных направлениях одновременно, а набор инструментов представляет собой запутанную смесь новых и развивающихся аббревиатур категорий и нишевых продуктов.

Некоторые из них представляют собой более традиционные инструменты безопасности приложений, которые становятся все более удобными для разработчиков. Другие представляют собой традиционные инструменты разработчиков, которые наращивают средства контроля и функции, ориентированные на безопасность, для решения проблем, связанных с рисками в цепочке поставок. Третьи появляются из мира DevSecOps, специально созданные для содействия взаимному сотрудничеству между этими племенами.

«Одна из причин, по которой так сложно получить четкое представление о безопасности цепочки поставок программного обеспечения, заключается в том, что в цепочке поставок так много звеньев, где что-то может пойти не так», — говорит CSO Том Гоингс, консультант по продуктам из Tanium. «У вас могут быть уязвимости, внедренные непосредственно в программное обеспечение, как пример SolarWinds, приведенный несколько лет назад, уязвимости в общих библиотеках, таких как Log4j, или даже что-то вроде скомпрометированного центра сертификации (CA)».

В то время как несколько стеков и платформ продуктов для обеспечения безопасности цепочки поставок программного обеспечения, несколько стеков и платформ продуктов для обеспечения безопасности цепочки поставок программного обеспечения начинают консолидироваться на рынке, набор функций этих продуктов огромен.

Основная категория инструментов, вокруг которой обычно концентрируются эти платформы, — это анализ состава программного обеспечения (SCA) и инструменты, генерирующие спецификации программного обеспечения (SBOM), так называемые «списки ингредиентов» современного программного обеспечения. Хотя SCA и SBOM, как правило, составляют основу многих инструментов безопасности цепочки поставок программного обеспечения, на самом деле это должно быть лишь верхушкой айсберга для директоров по информационной безопасности, пытающихся разработать дорожную карту для поддержки комплексной программы управления рисками в цепочке поставок.

«Когда они рассматривают безопасность цепочки поставок, люди сосредотачиваются на использовании таких инструментов, как SCA, и они обращают внимание на SBOM», — говорит CSO Дейл Гарднер, старший директор и аналитик по безопасности приложений в Gartner. «Это очень важные части решения. Но на самом деле это всего лишь частичное решение».

Задействовано множество других движущихся частей, включая управление секретами, сопоставление и управление зависимостями, безопасность конвейера CI/CD, эффективное управление репозиторием и многое другое. Большинство экспертов сходятся во мнении, что командам безопасности будет сложно найти все необходимое у одного поставщика.

«Я бы сказал, что не существует ни одного поставщика, который бы решал все проблемы, связанные с безопасностью цепочки поставок программного обеспечения, таким образом, чтобы он отвечал требованиям всех организаций», — объясняет Майкл Борн, старший менеджер по безопасности приложений в консалтинговой фирме Coalfire. Он сообщает CSO, что отсутствие консолидации не обязательно является чем-то плохим. «Это потенциально может подвергнуть организации рискам, связанным с привязкой к поставщику, и может означать, что организация взрослеет или меняется быстрее, чем может угнаться поставщик».

Эта фрагментация является результатом не только органических инноваций, исходящих из нескольких различных технических точек зрения (инструменты, ориентированные на разработку, инструменты, ориентированные на эксплуатацию, инструменты, ориентированные на безопасность), но также и того факта, что рассматривается ряд различных вариантов использования.

«Нам нужно четко определить, о каком риске или о каком варианте использования мы говорим, чтобы иметь возможность найти правильные программные решения или общий набор решений для их решения», — объясняет Шэрон Чанд, специалист по кибербезопасности. руководитель цепочки поставок по обеспечению безопасности рисков в подразделении Deloitte по оказанию услуг в области киберрисков. «Потому что какое решение мне действительно нужно, будет зависеть от того, где я нахожусь в этом сценарии безопасности цепочки поставок программного обеспечения. Если я производитель программного обеспечения, это будет выглядеть иначе, чем если бы я был потребителем программного обеспечения. И чаще, чем не каждый будет и тем, и другим в определенные моменты общего жизненного цикла цепочки поставок».