SCSW Распространенной аналогией, когда речь идет о ведомостях материалов программного обеспечения (SBOM), является список ингредиентов, найденных на упаковках продуктов, который позволяет потребителям знать, что находится в картофельных чипсах, которые они собираются съесть.
Точно так же SBOM — это перечень компонентов программного обеспечения, важнейший инструмент в то время, когда приложения представляют собой набор кода из нескольких источников, многие из которых не принадлежат команде разработчиков организации.
«Когда дело доходит до SBOM, это так же важно, [as the nutrition labels on food] потому что это риск не для вашего физического здоровья, а для вашего бизнеса», — сказал Марк Ламберт, вице-президент по продуктам в ArmorCode. Регистр. «Риск, которому вы потенциально подвергаете свой бизнес, когда используете программное обеспечение, заключается в том, что вы не понимаете, из чего оно состоит».
Когда это происходит, «вы… подвергаете себя уязвимости, которая находится вне вашего контроля. Если вы не видите этого, вы не можете принять меры предосторожности, чтобы убедиться, что вы не слишком уязвимы».
Вот почему SBOM за последние несколько лет стали центральным элементом расширяющейся картины управления цепочками поставок программного обеспечения по мере увеличения уровня угроз. Благодаря растущему использованию программного обеспечения с открытым исходным кодом и повторно используемых программных компонентов, вкладу из нескольких источников, ускорению темпов выпуска кода и конвейерам непрерывной интеграции и непрерывной доставки (CI/CD) современная разработка стала более быстрой и сложной.
«Поскольку цепочка поставок программного обеспечения становится все более сложной, очень важно знать, какой открытый исходный код вы косвенно используете как часть сторонних библиотек, сервисов, API или инструментов», — сказал Ламберт.
Злоумышленники знают, что, внедряя вредоносный код на любом этапе процесса разработки или используя уязвимости в компоненте, они могут перейти вверх по течению и заразить несколько систем, как это видно на примере взлома SolarWinds в 2020 году и злоупотребления уязвимостью Log4j.
Необходимость знать
SBOM также являются ключевым пунктом национального плана кибербезопасности, разработанного администрацией Байдена и опубликованного на этой неделе. Они не только сообщают организациям, из каких компонентов состоит программное обеспечение, которое они приносят, но и какой код в нем содержится.
SBOM гарантирует, что «вы знаете не только ингредиенты вашего программного обеспечения, но и ингредиенты этих ингредиентов, иногда называемые транзитивными зависимостями», — сказал Дональд Фишер, соучредитель и генеральный директор Tidelift. Регистр. «В открытом исходном коде многие пакеты вызывают другие пакеты, о которых вы можете знать или не знать, что используете, и SBOM могут помочь вам полностью понять эти отношения».
Обнаружение уязвимости Apache Log4j в декабре 2021 года потрясло весь технический мир, потому что широко используемый инструмент ведения журнала широко использовался для взлома уязвимых систем с помощью одной инъекции вредоносного кода.
Его использование было настолько широким, что затронуло большинство организаций, многие из которых не знали, что они затронуты. В течение нескольких недель после обнаружения уязвимости поступали сообщения о 10 миллионах попыток использования Log4j в час.
«Log4j используется в подавляющем большинстве программ», — сказал Ламберт из ArmorCode, добавив, что это подчеркивает необходимость SBOM. “Когда [the flaw in] Log4j был идентифицирован, все мы мгновенно подверглись уязвимости. Log4j сосредоточил внимание на всем. Проблема существовала некоторое время».
SBOM выходят на сцену
Этот последний возобновившийся интерес к SBOM можно в какой-то степени проследить до усилий Национального управления по телекоммуникациям и информации, подразделения Министерства торговли США, в 2018 году, когда стандарты по этому вопросу были опубликованы три года спустя. Распоряжение президента Байдена от мая 2021 года призвало федеральное правительство улучшить свою ИТ-безопасность после атак SolarWinds и Log4j, которые затронули государственные учреждения.
«Как это обычно бывает, EO превратил SBOM из приятной функции в полуобязательное решение, которое в настоящее время оценивается в большинстве государственных учреждений и крупных предприятий», — пишет старший аналитик TAG Cyber Джон Массерини в своем отчете. сообщение в блоге для ReversingLabs.
Проблема заключается в том, что внедрение и управление SBOM выполняется вручную, что является плохой новостью для администраторов и разработчиков. Постоянная напряженность при разговоре о безопасности цепочки поставок программного обеспечения заключается в обеспечении того, чтобы требования безопасности не препятствовали увеличению скорости современной разработки программного обеспечения.
Автоматизация — это ключ
Вот почему важна автоматизация процесса SBOM. Стандарт NIST включает несколько элементов, от используемого программного компонента и его поставщика до номеров версий и доступа к репозиторию компонента. Уровни версий должны быть сопоставлены с уровнями выпуска, обнаруженными потенциальными угрозами и определенными рисками.
«Развертывание больших приложений, от операционных систем с открытым исходным кодом до приложений собственной разработки и сторонних «упакованных» стеков чревато контекстуальными проблемами, методами инвентаризации и ручной проверкой, все из которых подвержены ошибкам, — пишет Массерини.
Хотя процесс выявления и сообщения о проблемах систематизирован, «он не решает проблему ручного ведения такой инвентаризации и последовательной проверки ее содержимого», — говорит он.
По словам Ламберта, автоматизация должна внедряться на каждом этапе процесса, от создания и публикации SBOM до их приема, а затем внедрять устранение уязвимостей в свои текущие программы безопасности приложений без необходимости внедрения новых рабочих процессов.
Что делать с SBOM
Есть и другие соображения. SBOM предоставляют много информации, но организациям необходимо решить, как они собираются ее использовать. По словам Фишера, «SBOM» — это удобная универсальная аббревиатура для более широкого набора вопросов цепочки поставок программного обеспечения.
Они также являются частью более крупного кэша технологий безопасности цепочки поставок, таких как SLSA (уровни цепочки поставок для программных артефактов), фреймворк для обеспечения целостности программных артефактов по всей цепочке поставок, созданный на основе внутренней Google инструмент и теперь является отраслевым проектом, в который входят такие организации, как Intel, VMware, The Linux Foundation и Cloud Native Computing Foundation.
«SBOM сами по себе не панацея», — сказал он. «Мы должны понять, в чем они хороши, а где менее полезны. Они хорошо помогают вам понять компоненты, которые входят в ваше программное обеспечение. Они гораздо менее полезны для фактического улучшения профиля безопасности этих компонентов».
Существует несколько основных стандартных форматов SBOM: обмен данными программного пакета (SPDX), CycloneDX и теги идентификации программного обеспечения (SWID).
По словам Ламберта, сейчас необходим безопасный и централизованный обмен уязвимостями, где компании могут обмениваться информацией о уязвимостях. По его мнению, иметь данные SBOM полезно, но если уязвимость обнаружена, сообщение о ней по-прежнему осуществляется напрямую, и эта информация должна распространяться быстрее и шире.
Платить обслуживающему персоналу
По словам Фишера, еще одна возникающая проблема заключается в том, что SBOM и тому подобное означают дополнительную работу для тех, кто поддерживает программное обеспечение с открытым исходным кодом, которое используется в большинстве приложений. И большинство сопровождающих — 60 процентов, по словам Фишера, — неоплачиваемые, в основном добровольцы.
«Как правило, им не хватает согласования, а тем более стимула для рассмотрения длинных контрольных списков безопасных методов разработки», — сказал он. «На фоне растущего внимания правительства и отрасли к кибербезопасности в связи с громкими уязвимостями, такими как те, которые затронули SolarWinds и Log4j, требования к этим волонтерам-мейнтейнерам растут в геометрической прогрессии».
Для повышения безопасности требуются инструменты, такие как SBOM, и люди. Пришло время начать платить специалистам по сопровождению программного обеспечения с открытым исходным кодом, как компании платят всем, кто отвечает за безопасность программного обеспечения.
SBOM, как и многие инструменты, используемые для обеспечения безопасности цепочки поставок, все еще относительно новы и нуждаются в доработке. Учитывая скорость, с которой злоумышленники придумывают способы атаковать цепочку поставок, чем быстрее происходит созревание, тем лучше.
«У SBOM есть путь, но это хорошее решение», — сказал Ламберт. «Иметь стандарт — это неплохо. Отсутствие стандартов — это проблема». ®
