Когда три правительственных агентства США собираются вместе, чтобы «настоятельно поощрять» разработчиков применять определенные методы, вам следует обратить на это внимание. CISA, NSA и ODNI, признавая угрозу киберхакеров и после атаки SolarWinds, объявили, что они будут совместно публиковать сборник рекомендаций по обеспечению безопасности цепочки поставок программного обеспечения для предотвращения подобных уязвимостей в будущем. . В объявлении было ясно указано, что цель документа — побудить разработчиков применять передовой опыт, заявив, что «Эти принципы включают планирование требований безопасности, проектирование архитектуры программного обеспечения с точки зрения безопасности, добавление функций безопасности и поддержание безопасности программного обеспечения и базовой инфраструктуры.
Это руководство состоит из трех частей и будет выпущено одновременно с жизненным циклом цепочки поставок программного обеспечения. Часть 1 серии, посвященный рекомендациям для разработчиков программного обеспечения, был выпущен в августе 2022 года. Остальные две части будут выпущены в ближайшем будущем: часть 2 будет посвящена поставщикам программного обеспечения, а часть 3 — клиентам, получающим программное обеспечение. Конечная цель состоит в том, что эта серия поможет наладить общение между этими тремя ключевыми заинтересованными сторонами и среди специалистов по кибербезопасности, чтобы способствовать повышению устойчивости и улучшению общего состояния. безопасность цепочки поставок программного обеспечения.
Хотя не всегда ясно, кто несет ответственность за обеспечение безопасности программного обеспечения, независимо от того, кто может нести общую ответственность в вашей конкретной организации. новый гид ясно дает понять, что все разработчики должны ознакомиться с этими новыми передовыми практиками и что все они играют роль в обеспечении безопасности цепочки поставок программного обеспечения. Или, если можно быть более откровенным: Разработчики, вы играете решающую роль в обеспечении безопасности цепочки поставок программного обеспечения вашей организации! По этой причине мы подумали, что вам будет полезно прочитать (относительно) краткое изложение первой части руководства специально для вас. Вот оно.
Краткое описание руководства:
Среди обширных списков потенциальных угроз, упомянутых в этом практическом руководстве для разработчиков, есть несколько ключевых уязвимостей, которые следует обязательно устранить и подготовиться к ним:
- Функции, которые не были должным образом задокументированы или реализуют рискованные функции.
- Незаметные изменения в основных предположениях безопасности между моментом оценки безопасности и доставкой кода.
- Корпоративные изменения в участниках цепочки поставок
- Нестандартные методы кодирования или безопасности
Менеджмент, финансы и менеджеры программ — все они несут ответственность за обеспечение безопасности цепочки поставок программного обеспечения, но целостность безопасность цепочки поставок программного обеспечения часто зависит от бдительности разработчиков программного обеспечения и осведомленности всех участников цепочки поставок. Часть 1 руководства посвящена роли разработчиков и угрозам, присущим каждому этапу процесса разработки, а также предлагает рекомендации по стратегиям смягчения последствий, которые должны стать стандартной практикой.
Этап № 1: Безопасные критерии продукта и управление им
Безопасная разработка начинается с признания важности безопасности цепочки поставок программного обеспечения всеми ключевыми заинтересованными сторонами в группах разработчиков и продуктов. Сценарии угроз являются общими и могут быть понятны каждому; Задача состоит в том, чтобы добиться того, чтобы все были единодушны в отношении принятой политики смягчения последствий. Эти политики должны охватывать весь процесс: проектирование и архитектуру, моделирование угроз, кодирование, планы тестирования безопасности, критерии выпуска и способы управления уязвимостями в будущем. Часть этого также включает в себя оценку возможностей команд и обеспечение их надлежащего обучения для выполнения своих задач, а затем определение методов документирования, а также периодические проверки безопасности и оценки угроз.
Этап №2: Разработка безопасного кода
Когда дело доходит до разработки кода, правильные методы безопасного кодирования уже изложены в SSDF. По этой причине, поскольку язык программирования не был определен заранее, соображения безопасности также должны быть частью этого решения. Гид дает полезные рекомендации для разработчиков, рассматривая широкий спектр сценариев, таких как внедрение вредоносного исходного кода «инсайдерами» (например, разработчиками), программное обеспечение с открытым исходным кодом и лучшие практики борьбы с ним. Как создать безопасную среду для кодирования (включая конфигурации безопасной сборки и сторонние программные инструменты) и впоследствии протестировать безопасность интегрированного продукта. Поскольку уязвимости могут возникнуть и после поставки, существуют также рекомендации по устранению обнаруженных уязвимостей и обеспечению того, чтобы будущие внешние расширения программного обеспечения не ставили под угрозу целостность безопасности продукта.
Этап 3. Укрепите среду сборки.
После безопасной разработки кода безопасность цепочки поставок программного обеспечения требует, чтобы среда сборки была ужесточена до тех же стандартов, что и само программное обеспечение. Компрометация системы сборки — привлекательный способ проникновения в код, поскольку он происходит на этапе процесса разработки, который, естественно, менее тщательно исследуется разработчиками.
Этап №4: Доставка кода
Последний недостаток, рассматриваемый в руководстве, касается заключительного этапа цепочки поставок программного обеспечения — доставки кода. Даже если до этого момента код был должным образом защищен, все еще остаются две ключевые уязвимости в цепочке поставок, которые необходимо устранить. Первый — это окончательная проверка пакета, которую можно использовать, например, путем непреднамеренного раскрытия метаданных, учетных данных разработчика или инвентаризации открытого исходного кода. Другим шагом, который часто проверяют на наличие слабых мест, является система распределения, которая может быть скомпрометирована атакой «человек посередине», которая может захватить один или несколько этапов доставки.
Применяя эти методы снижения рисков на уровне разработки программного обеспечения, поставщики программного обеспечения могут избежать слабых мест, которые могут привести, например, к проникновению обновлений, манипуляциям с подписью кода и «сюрпризам», скрытым в открытом исходном коде.
Нет такого понятия, как бесплатный обед: скрытая стоимость стороннего программного обеспечения
Одним из ключевых вклад в скорость разработки стала возможность эффективно включать стороннее программное обеспечение. Это позволило разработчикам сосредоточиться, например, на инновациях или функциях, используя при этом готовые компоненты для масштабируемости или интерфейсов. Увеличение использования стороннего программного обеспечения создало серьезную проблему для безопасности цепочки поставок программного обеспечения. Помимо проведения оценки такого кода в соответствии с теми же стандартами, которые используются для оценки вашего собственного, руководство предлагает сканировать бинарники на наличие уязвимостей и оценивать возникающие при этом риски. Результаты этой оценки должны учитываться при принятии решения об использовании или не использовании конкретного программного компонента. При выборе программного компонента необходимо также учитывать его источник; включение сторонних компонентов в ваш исходный код — это начало длительных отношений, и вам следует стремиться работать с партнерами, которым вы можете доверять. Владение кодом, практика написания кода и политика управления версиями — это лишь несколько моментов, которые следует учитывать при выборе надежного источника. Просто подумайте обо всех будущих обновлениях, выпусках и работах по техническому обслуживанию каждого компонента по мере обнаружения новых угроз. Задача будет заключаться в том, чтобы отслеживать все изменения, вносимые сторонними организациями, оценивать уязвимости и реагировать соответствующим образом, иногда в условиях жесткого дефицита времени.
Повысьте безопасность цепочки поставок программного обеспечения с помощью SBOM
Одним из ключевых методов обеспечения долгосрочной целостности вашей цепочки поставок программного обеспечения является поддержание обновленной Спецификация программного обеспечения (СБОМ). SBOM — это подробный перечень программных компонентов, составляющих данное решение.
Это сэкономит ваше время и усилия и, что наиболее важно, уменьшит вашу подверженность постоянным угрозам. Каждый программный компонент, встроенный в ваш продукт, должен иметь свою собственную SBOM, которая должна быть проверена и объединена в единую «основную» SBOM для продукта. Если вы собираетесь включить компоненты, которые не входят в состав SBOM, вам необходимо будет провести собственный анализ с использованием инструментов анализа состава программного обеспечения (SCA).
Чем точнее и описательнее SBOM, тем легче его поддерживать и использовать. Учитывая головокружительную скорость обновления компонентов программного обеспечения, хорошо структурированный СБОМ принесет дивиденды, когда придет время отслеживать и записывать каждое обновление, исправление или выпуск. Что еще более важно, как только угроза безопасности обнаружена, каждый момент имеет решающее значение. запомнить: безопасность вашей цепочки поставок программного обеспечения всегда будет таким же сильным, как и ваше самое слабое звено. Когда под угрозой находятся десятки программных компонентов, вы будете благодарны за SBOM, в котором есть ответы на все вопросы.
Для эффективного рабочего процесса полезная SBOM должна включать как минимум эти три компонента:
- Поля данных – Это дескрипторы реализованных вами компонентов. Возможность легко определить, какие компоненты использовались, даже спустя долгое время после завершения разработки, помогает эффективно отслеживать их на наличие уязвимостей.
- Поддержка автоматизации – Автоматический мониторинг SBOM требует, чтобы они также были идентифицированы в одном из принятых машиночитаемых форматов.
- Практика и обещания – Управление SBOM требует общего понимания методов обслуживания, таких как частота версий, зависимости, известные неизвестные, распространение и доставка, контроль доступа и способы устранения ошибок.
Совместное использование SBOM среди заинтересованных сторон конкретного продукта (разработчика программного обеспечения, поставщика программного обеспечения и клиента) помогает повысить прозрачность и согласованность, повышая способность цепочки поставок программного обеспечения защищать продукт от угроз безопасности. Следует отметить, что, учитывая все движущиеся части цепочки поставок программного обеспечения, последовательное поддержание такого SBOM, на который можно легко ссылаться, контролировать и поддерживать, является сложной задачей.
Заключительные слова: как вывести безопасность цепочки поставок программного обеспечения на новый уровень?
Поскольку безопасность цепочки поставок программного обеспечения становится все более важной, организациям постоянно приходится создавать прозрачное доверие к программному обеспечению, которое они поставляют или используют. Поскольку ожидается, что внедрение SBOM в качестве передовой практики будет расти, наличие инструмента, который позволит вам преодолеть эту проблему, является ключевым шагом на пути к обеспечению безопасности цепочки поставок программного обеспечения. Вот почему мы недавно запустили первый научно обоснованный центр безопасности для программных продуктов. позволяя пользователям укрепить доверие к своему программному обеспечению среди команд и организаций. Эта удобная платформа поможет командам разработчиков снизить риски в цепочке поставок программного обеспечения, сделав SBOM доступным, простым в использовании и, что наиболее важно,сделать безопасность программных продуктов прозрачной для клиентов, покупателей и групп безопасности..
Если вы, как разработчик программного обеспечения, обеспокоены угрозами безопасности вашей цепочки поставок программного обеспечения, мы настоятельно рекомендуем вам опробуй платформу; его можно использовать бесплатно, без каких-либо условий. Внедрив наш рабочий процесс, вы сможете делиться своими SBOM по всей цепочке поставок.
Этот контент предоставлен вам Scribe Security, ведущим поставщиком комплексных решений для обеспечения безопасности цепочки поставок программного обеспечения, обеспечивающим современную безопасность артефактов кода, а также процессов разработки и доставки кода по всей цепочке поставок программного обеспечения. Подробнее.
Статьи по теме
