ИТ-индустрия откладывает SBOM, хотя ей следовало бы работать над лучшими практиками.

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

Правительство США ввело регулирование в отношении спецификаций программного обеспечения (SBOM) с составлением «рецептов» программного обеспечения. По сути, это ключевые элементы для создания более разумного способа выявления потенциальных проблем безопасности. Неудивительно, что существуют негативные реакции и мнения по поводу этой организации.

В ответе Совета ITI, крупного игрока в сфере технологий, SBOM охарактеризованы как «не готовы» и что весь разговор должен быть более «зрелым», прежде чем ИТ-отрасль сможет рассмотреть дополнительное бремя создания и поддержания этих записей. Тем более, что в правилах не оговариваются критерии, которые будут использоваться.

Это очень сомнительный подход. ИТ-сектор не должен сопротивляться этому регулированию, а должен приветствовать его, возглавить его реализацию и создать вокруг него зрелую дискуссию, а не просто ждать, пока оно произойдет.

Статус СБОМ
Спецификации материалов — не новая идея. Они также известны как списки ингредиентов или рецепты продуктов. Они широко распространены в производстве и представляют собой организованный стандартизированный список всего, что необходимо для производства продукта.

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

SBOM — это список всех компонентов с открытым исходным кодом и сторонних производителей, содержащихся в программном обеспечении, но это еще не все: он содержит номера версий, лицензии и статус исправлений каждого компонента. Как и в производстве, это становится ключевым справочным материалом, когда что-то идет не так. Компании, использующие программное обеспечение с открытым исходным кодом, могут сразу определить, где могут скрываться уязвимости, если что-то пойдет не так.

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

Уязвимость Log4Shell — прекрасный пример. Log4j, как следует из названия, используется для регистрации ошибок и событий и сообщения о них администраторам. Если кто-то посещает веб-сайт и получает ошибку 404, это, скорее всего, будет зарегистрировано Log4j — если произойдет несколько таких ошибок, это указывает на проблему. Его полезность сделала его повсеместным, что, как ни странно, сделало его несколько неясным — виртуальное программное обеспечение, используемое повсюду, о котором никто даже не задумывался. Когда выяснилось, что Log4j можно использовать для внедрения кода, это означало, что миллионы серверов могут быть атакованы и захвачены. База данных уязвимостей NIST присваивает Log4Shell рейтинг CVSS (Common Vulnerability Scoring System) 10, наивысший возможный рейтинг.

Повсеместное распространение Log4j означало, что, наоборот, было легко узнать, нужен ли патч или нет, поскольку почти каждый сервер нуждался в обновлении. Будущие уязвимости, возможно, не будут столь широко распространены, но они по-прежнему распространены, что делает SBOM чрезвычайно ценными.

Необходимость руководить, а не сопротивляться
Большая часть оппозиции регулированию SBOM была связана с практичностью, а не с принципами. «Доступные в настоящее время отраслевые инструменты создают SBOM с различной степенью сложности, качества и полноты. Наличие многочисленных, иногда непоследовательных или даже противоречивых усилий указывает на недостаточную зрелость SBOM», — говорится в ответе Совета ITI.

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

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

Пока это происходит, мы можем увидеть еще одну уязвимость во всем Log4Shell. Если это произойдет, правительство США сможет указать на свое регулирование и заявить, что оно навязало отрасль эти изменения. Если внедренные протоколы SBOM не соответствуют поставленной задаче и не поддерживают необходимый ответ, отрасль столкнется с чем-то более или менее неизбежным.

SBOM станут ключом к устранению следующей крупной уязвимости и невероятно полезны в борьбе за смягчение последствий более мелких уязвимостей. Проблемы с внедрением SBOM сегодня не следует рассматривать как препятствие; Вместо этого ИТ-индустрия должна разработать график и работать совместно для решения этих проблем, а не отказываться от любых попыток принятия законодательства. Усилия по оказанию давления должны быть сосредоточены на том, как это может работать, а не на том, может ли это вообще произойти.