Привет, Хаброжители!

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

Именно об этом мы хотим рассказать в связи с выходом книги “Прозрачное программное обеспечение: Безопасность цепочек поставок ПО” Криса Хьюза, Тони Тернера.

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

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

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

«Прозрачное программное обеспечение» — ценный источник знаний для специалистов по кибербезопасности и безопасности приложений, а также для профессионалов, работающих в области безопасности промышленных систем управления, облачной безопасности, мобильной безопасности, DevOps и DevSecOps.

Мы подобрали интересную статью, чтобы ещё подробнее рассмотреть актуальный и, безусловно, важный вопрос о необходимости прозрачности в кибербезопасности. И нам, конечно же, любопытно познакомиться с методическим руководством для разработчиков, которое рекомендует Агентство национальной безопасности (АНБ).
Приятного чтения!

Обеспечение безопасности цепочки поставок программного продукта

Методическое руководство для разработчиков, рекомендуемое Агентством национальной безопасности (АНБ)



Трудно было бы, наверное, в наши дни, пребывая в среде публикаций на тему кибербезопасности и соответствующих высказываний руководства, не заметить дискуссий по вопросам обеспечения безопасности цепочки поставок программного обеспечения. Тема, конечно же далеко не новая и уже достаточно избитая, но недавние серьезные инциденты, в частности взлом кода поставщика программного обеспечения SolarWinds, и последовавшая за ним публикация Директивы президента США о кибербезопасности 14028, а также крупный инцидент с безопасностью программы с открытым исходным кодом (OSS) Log4j, поместили эту тему в центр внимания всех ведущих специалистов в области технологии и обеспечения безопасности. Эти вопросы касаются и будут касаться как поставляемого/проприетарного программного обеспечения, так и OSS-программ (первое в подавляющем большинстве состоит из второго, но это уже совсем другая тема). Раздел 4 директивы президента был полностью посвящен повышению безопасности цепочки поставок ПО. Разумеется, эта директива породила целый ряд последующих действий и руководств, в числе которых принадлежащие Национальному институту по стандартизации и технологии (NIST) Концепция безопасной разработки программного обеспечения (SSDF), Руководство по управлению киберрисками цепочки поставок (C-SCRM) и имеющийся в нем конкретный ответ на требования раздела 4, сфокусированный, в частности, на цепочке поставок ПО.

Как уже было сказано, атаки на цепочки поставок программного обеспечения — явление далеко не новое: в таких источниках, как Cloud Native Computing Foundation (CNCF), можно найти каталог взломов цепочек поставок начиная с 2003 года. Имеется также постоянно обновляемый набор данных о взломах — IQT Labs Software Supply Chain Compromises — A Living Dataset, который также берет свое начало в 2003 году. Последний представляет собой попытку IQT Lab создать актуальный набор данных, составленный из публичных сообщений о взломах цепочек поставок программного обеспечения. Но при том, что атаки на цепочки поставок программного обеспечения имеют почти 20-летнюю историю, темпы их неуклонно возрастают. Об этом можно судить по публикациям исследований, помещенным, в частности, в материал ассоциации Usenix Дэном Гиром (Dan Geer), Бентцом Тозером (Bentz Tozer) и Джоном Спидом Мейерсом (John Speed Meyers) под названием «For Good Measure — Counting Broken Links: A Quant’s View of Software Supply Chain Security».


Источник: For Good Measure: Counting Broken Links: A Quant’s View of Software Supply Chain Security

В связи с участившимися атаками на цепочки поставок программного обеспечения и усугублением последствий вышеупомянутых и заслуживающих особого внимания инцидентов наблюдается рост числа важных противодействующих этим тенденциям устремлений, в числе которых выработка таких документов, как Software Bill of Materials (SBOM), Vulnerability Exploitability eXchange (VEX), Security Levels for Software Artifacts (SLSA) и некоторых других, призванных помочь в решении вопросов обеспечения безопасности цепочек поставок программного обеспечения. Кроме того, наблюдается рост количества критически важных рекомендаций от таких организаций, как NIST, а также от таких коммерческих титанов индустрии, как Google, Microsoft, AWS, а теперь еще и от Агентства национальной безопасности (АНБ).

В этой статье рассматривается руководство АНБ по обеспечению безопасности цепочек поставок программного обеспечения, его различные разделы и основные выводы. Руководство АНБ подготовлено группой, получившей название Рабочая группа по цепочкам поставок программного обеспечения с надежной средой безопасности — «Enduring Security Framework (ESF)». Сама группа ESF — государственно-частная межотраслевая рабочая группа, возглавляемая АНБ и Агентством по информационной безопасности и безопасности инфраструктуры — CISA, разрабатывающая руководство по безопасности в отношении приоритетных угроз, в частности угроз критической инфраструктуре. В анонсе данной публикации подчеркивается роль разработчика в создании безопасного программного обеспечения и говорится, что статья призвана помочь разработчикам принять рекомендации правительства и промышленности по данному вопросу. Последующие публикации ESF будут посвящены поставщику и потребителю программного обеспечения, учитывая ту уникальную роль, которую каждый из них играет в развернутой цепочке поставок программного обеспечения и ее сопротивляемости угрозам.

В общем виде документ состоит из трех частей:

• Часть 1: Руководство по безопасности для разработчиков программного обеспечения
• Часть 2: Сведения к рассмотрению поставщиками программного обеспечения
• Часть 3: Рекомендации для заказчиков программного обеспечения.

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


Рис. 1. Взаимоотношения и деятельность групп цепочки поставок программного обеспечения

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

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

Безопасное программное обеспечение начинается с Secure Software Development Lifecycle, — SDLC (жизненного цикла разработки безопасного ПО), и в руководстве АНБ приводится множество вариантов, которыми могут воспользоваться команды, в числе которых SSDF от NIST, «Secure Software Development Lifecycle Processes» («Процессы жизненного цикла разработки безопасного ПО» от CMU и другие, например недавно объявленные OpenSSF-курсы «Secure Software Development Fundamentals» («Основы разработки безопасного ПО»).

В руководстве особо выделяется не только использование процессов разработки безопасного программного обеспечения, но и создание конкретных компонентов и средств подтверждений, используемых для проверки не только производителем, но и потребителем программного обеспечения для получения гарантии безопасности и устойчивости программного обеспечения к атакам. Эти процессы и конкретные действия выстраиваются из таких передовых методов, как Threat Modeling (моделирование угроз), статический (SAST) и динамический (DAST) анализ кода и тестирование на возможность проникновения в код — Pen Testing, а также из применения мер безопасности при выпуске продукта, в частности использования цифровой подписи, ярким примером чего является все более широкое внедрение Sigstore — стандарта применения подписи, проверки и защиты программного обеспечения. Принятие и использование Sigstore также упоминается в качестве мер обеспечения повышенного доверия в цепочке поставок программного обеспечения в OpenSSF-плане введения мер безопасности для продуктов с открытым исходным кодом — Open Source Security Mobilization Plan.

Критерии безопасных продуктов и управление их безопасностью

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

В знак признательности за большую работу по внедрению методологии DevSecOps, проводимую в Министерстве обороны (Department of Defense, DoD), в руководстве АНБ использована диаграмма процесса безопасной разработки программного обеспечения, взятая из учебного пособия по основам DevSecOps, выпущенного в этом министерстве — «DevSecOps Fundamentals Playbook». Но, в отличие от примера, приведенного в пособии, где в качестве трех субъектов в замкнутом цикле указаны Dev, Sec и Ops, в примере АНБ на первый план выходят три субъекта, о которых говорится во введении к руководству, — разработчики, поставщики и заказчики. Вместо организационных групп, участвующих в процессе разработки программного обеспечения (как в примере, приводимом Министерством обороны), эти три субъекта являются представителями различные организации, участвующих в производстве и потреблении безопасных и устойчивых к атакам программных продуктов, и не вписываются в единые рамки, подразумеваемые в контексте цепочки поставок программного обеспечения.

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

Некоторые из рекомендуемых, хотя и далеко не новых методов, набирают все большую популярность. Например, моделирование угроз уже несколько лет пропагандируется такими лидерами отрасли, как Адам Шостак (Adam Shostack), Роберт Херлбут (Robert Hurlbut) и многими другими. По своей сути, моделирование угроз ни что иное, как размышления о том, что может пойти не так, и как это предотвратить, а более глубокие познания можно получить из таких источников, как Threat Modeling Manifesto (манифест моделирования угроз) или OWASP-проектов Threat Modeling (моделирование угроз). Моделирование угроз может вестись на протяжении всего жизненного цикла разработки программного продукта и рекомендуется NIST для критически важного программного обеспечения, используемого федеральным правительством. На основе Директивы президента США о кибербезопасности, NIST ввел требования об определении критически важного программного обеспечения, а дополнительные рекомендации могут быть найдены в Директиве на странице руководства по цепочке поставок программного обеспечения применительно к критически важному программному продукту. Для организаций, желающих начать работу, в качестве варианта средства с открытым кодом имеется такой инструмент, как OWASP-программа Threat Dragon, способная оказать помощь в составлении диаграмм потоков данных, ранжировании угроз и предложении мер по их устранению.

Руководство АНБ настоятельно рекомендует пользоваться Планами анализа безопасности и Критериями выпуска продукта. Планы и требования к тестированию часто включают, кроме всего прочего, такие распространенные методы тестирования безопасности, как статический и динамический анализ безопасности приложений SAST/DAST, анализ состава программного обеспечения (Software Composition Analysis, SCA), полученного от сторонних разработчиков, и даже выявление возможностей проникновения в код (Penetration Testing). В экосистеме имеется несколько OSS-программ и вендорских инструментов для проведения тестирования, в числе которых SAST, DAST и SCA. Эти инструменты также все чаще интегрируются с конвейерами непрерывной интеграции и непрерывной доставки (CI/CD), что позволяет «сдвинуть влево» меры обеспечения безопасности, вводя их в действие на более ранних этапах жизненного цикла разработки программ (SDLC), где, по мнению некоторых, это менее затратно и более эффективно.

Наличие этих инструментов и методов тестирования позволяет организациям определить критерии выпуска продукта. К критериям, мешающим выпуску, можно отнести уязвимости, превышающие допустимый риск организации, слабость безопасных методов разработки или, в связи с возросшими требованиями к прозрачности программного обеспечения, особенно в государственном секторе, уклонение от создания SBOM-списка (ведомости о всех сторонних материалах, применяемых в сборках), и от проведения сопоставлений и сверок с этим списком. Несмотря на важность наличия установленных критериев выпуска для снижения риска проецируемого на последующих потребителей программного обеспечения, их выработка сопряжена с серьезными трудностями и требует признания низкой надежности таких широко распространенных методологий оценки уязвимостей, как Общая система оценок уязвимостей (Common Vulnerability Scoring System, CVSS), а также инструментов, генерирующих множество ложных положений, препятствующих скорости разработки, а кроме этого еще и признания непригодности к использованию многих опубликованных элементов списка известных уязвимостей и дефектов безопасности (Common Vulnerabilities and Exposures, CVE). Более подробно проблемы CVSS раскрыты в статье «CVSS: Ubiquitous and Broken» («CVSS: вездесущий и непригодный»). Пробиться сквозь помехи, снижая уровень уязвимостей и обеспечивая скорость разработки, — тонкое искусство, требующее координации усилий мотивированных сотрудников и применения эффективных процессов и технологий. Угрозы, таящиеся в благих намерениях при низкой эффективности критериев безопасности выпуска, рассматриваются исследователем проблем безопасности и писателем Уолтером Хейдоком (Walter Haydock).

АНБ рекомендует организациям иметь продуманные и упорядоченные стратегии и процессы поддержки продуктов и устранения уязвимостей. Они включают в себя создание системы предоставления информации об уязвимостях, групп реагирования на инциденты компьютерной безопасности (Product Security Incident Response Team, PSIRT) и безопасную доставку программного обеспечения на места применения по защищенным протоколам, к числу которых можно отнести HTTPS/TLS.

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

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

Разработка безопасного кода

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

Организациям следует опасаться внутренних угроз, как непреднамеренных, так и заведомо вредоносных, способных вносить изменения в исходный код или же использовать его в преступных целях. Эти угрозы могут быть связаны как с низкой обученностью разработчиков, так и с намеренной вставкой специалистами лазеек в разрабатываемые продукты. У специалистов могут быть сложные жизненные обстоятельства, повышающие их восприимчивость к шантажу и компрометации, или же они могут добавлять некие функции, облегчающие им разработку продукта, приводящие при этом к утрате его безопасности. АНБ также предупреждает о возможности взлома систем удаленной разработки. С распространением парадигмы удаленной работы и разрушением сетевого периметра главной мишенью для злоумышленников становятся конечные точки удаленной разработки, а организациям приходится регулярно сталкиваются с проблемой гигиены конечных точек, особенно в средах использования личных устройств — Bring Your Own Device (BYOD). Кроме того, существует вероятность того, что вектором атаки могут стать сторонние команды разработчиков. К числу других распространенных векторов атак можно отнести бесхозные учетные записи и учетные данные, появляющиеся по причине ухода пользователей из команд и организаций с сохранением активности их аккаунтов, которые могут быть взломаны. Подобные обстоятельства требуют от организаций разработки продуманных стратегий и процессов управления учетными записями и доступом к данным.

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

АНБ доказывает необходимость создания того, на что также в своем руководстве 800-161/Software Supply Chain, обращают внимание такие организации, как NIST, — потока процессов безопасного репозитория (Secure Repository Process Flow). Благодаря ему организациям позволяется выбирать внешние программные компоненты, реализуя при этом для определения состава компонентов и выявления уязвимостей рабочий процесс, проводящий сканирование, например SCA. Этот процесс поможет проверить внешние программные компоненты, предназначенные для разработчиков и их команд, и обеспечить создание внутреннего безопасного репозитория, предоставляющего проверенные и подтвержденные компоненты для внутренней деятельности по разработке программного обеспечения.


Критериям безопасности выпуска продукта, а также надлежащему выявлению и устранению уязвимостей, соответствует использование ранее упомянутых инструментов SAST и DAST. Чтобы убедиться в выявлении и устранении недостатков или вредоносных изменений, команды также должны проводить ночные сборки, включающие тестирование безопасности и регрессионное тестирование. Как уже отмечалось, разработчики могут добавлять функции, облегчающие их работу, но это может привести к появлению лазеек (backdoors). Именно поэтому облегчить неблагоприятные последствия от некоторых из тех случаев, когда добавление функций может привести к возникновению рисков, призваны такие действия, как сопоставление функций с требованиями к ним. В связи с распространенностью удаленной разработки АНБ рекомендует организациям усилить защищенность среды разработки. Эта рекомендация касается не только среды сборки, но и конечных точек или систем, участвующих в разработке или в рабочих процессах. Здесь обеспечить снижение риска удаленной разработки могут такие средства контроля, как VPN-доступ, многофакторная аутентификация (MFA), программное обеспечение для обнаружения и реагирования на конечные точки и т. д.

При создании, тестировании и сохранении исходного кода следует применять методы безопасной разработки (Secure Development Practices). К их числу относятся вышеупомянутые действия по защите среды разработки, а также использование безопасных конфигураций сборки и безопасного набора инструментов и компонентов программного обеспечения от сторонних разработчиков.

В конечном итоге компоненты и программное обеспечение будут интегрированы в готовый продукт, поэтому следует придерживаться продуманной и безопасной практики интеграции кода. Она включает в себя тестирование компонентов сторонних производителей на наличие известных уязвимостей и дефектов безопасности (CVE), перечисленных в Национальной базе данных уязвимостей NIST (National Vulnerability Database, NVD), использование анализаторов зависимостей безопасности и применение при интеграции кода принципов «нулевого доверия» (Zero Trust Principles).

Когда заказчики сообщают о дефектах или уязвимостях, команды разработчиков должны быть готовы отреагировать на такие инциденты и уведомления. Эта реакция включает в себя открытый процесс приема соответствующих сообщений и внутренний процесс рассмотрения, диагностики и оказания помощи в решении проблем. Кроме этого, со стороны других команд исходит вероятность добавления в разработку внешних расширений, которые уже сами по себе могут вносить уязвимости. Расширения, поступающие, к примеру, от команд разработчиков решений или компаний, занимающихся продажей усовершенствованных продуктов — реселлеров, добавляющих ценность к продукту (Value-added reseller, VAR), также должны разрабатываться с соблюдением правил безопасности, а SBOM-списки должны быть доступны для отображения в них дополнительных пакетов компонентов, ранее не включенных в исходный продукт.

Проверка компонентов от сторонних разработчиков

Не секрет, что команды разработчиков все чаще используют в своем коде и продуктах программные компоненты, разработанные на стороне. Зачастую это делается для экономии времени, затрат и труда путем использования доступных программных компонентов, будь то готовое коммерческое ПО (COTS) или бесплатное ПО с открытым кодом (FOSS). Именно здесь ранее упомянутый процесс интеграции кода способен снизить риск внедрения небезопасного кода от сторонних производителей. К другим проблемам следует отнести наличие двоичных файлов сторонних разработчиков, требующее проведения бинарного или SCA-сканирования для определения неизвестных файлов и включенных OSS-компонентов, а также любых потенциально связанных с ними уязвимостей. Также может помочь проверка присутствия исходного кода стороннего производителя в SBOM-списке.

При выборе и интеграции компонентов от сторонних разработчиков оценка любого связанного с ними риска, при доступности исходного кода, должна проводиться с помощью SCA-анализа, а также других методов сканирования, включая SAST и DAST. Команды разработчиков также должны разбираться в происхождении получаемого кода и гарантиях безопасности метода его доставки. Проверка подлинности осуществляется путем отслеживания происхождения программного обеспечения вплоть до его источника и определения цепочки поставок с начальной позиции, и, в зависимости от установленных в организации требований безопасности, могут быть востребованы различные уровни проверок подлинности. Например, согласно системе уровней цепочек поставок программных артефактов — Supply Chain Levels for Software Artifacts (SLSA), на более высоких SLSA-уровнях к проверке подлинности применяются более строгие требования.

АНБ рекомендует приобретать компоненты у известных и надежных поставщиков. Когда речь заходит о качестве безопасности компонентов программного обеспечения, наличие богатой экосистемы производителей и поставщиков ПО еще не означает, что по качеству все они равны. Такие лидеры цепочек поставок ПО, как Джошуа Корман (Joshua Corman), ратуют за подражание лидерам автомобильного производства и использование меньшего числа самых лучших поставщиков, у которых компоненты более высокого качества, что, к примеру, было отражено в его докладе на конференции USENIX «Continuous Acceleration: Why Continuous Everything Needs a Supply Chain Approach».


Особую роль в усугублении проблем, связанных с управлением компонентами сторонних разработчиков, играют OSS-программы. Как отмечается в отчете компании Sonatype «State of the Software Supply Chain 2021» («Состояние цепочки поставок ПО в 2021 году»), по сравнению с прошлым годом наблюдается 73-процентный рост числа загрузок разработчиками OSS-компонентов (свыше 2,2 триллионов загрузок), но также и 650-процентный годовой рост числа атак на цепочки поставок ПО, обусловленный осознанием злоумышленниками эффективности данного вектора атак, проводимых с помощью таких методов, как перепутывание зависимостей (Dependency Confusion), тайпсквоттинг (Typosquatting) и инъекции вредоносного кода (Malicious Code Injection).


Источник: Sonatype «State of the Software Supply Chain 2021»

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

Усиление защищенности среды сборки

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

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

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

Основываясь на этих мерах смягчения угроз, АНБ рекомендует воспользоваться такими расширенными защитными мерами, как герметичные и воспроизводимые сборки. Герметичные сборки обладают полной декларативностью, неизменяемостью и могут работать без доступа к сети. Они также могут включать проверку хэша. Воспроизводимые сборки подтверждают, что, несмотря на изменяющиеся метаданные, бинарные продукты собраны из одного и того же источника. Под воспроизводимостью понимается идентичность входных артефактов, приводящая к побитовой идентичности выходных данных. Имеются также и такие новые системы, как in-toto, стремящиеся защитить целостность цепочки поставок программного обеспечения путем проверки того, что каждая, имеющейся в цепочке задача, выполняется запланированным образом и только уполномоченным персоналом, а также того, что продукт не подделан при его транспортировке.

Некоторые процессы и практические приемы, определенные АНБ, основываются не только на вышеупомянутой структуре SLSA, но и на другой развивающейся структуре от OWASP, известной как Software Component Verification Standard, SCVS (стандарт верификации программных компонентов). Возглавляет SCVS не кто иной, как Стив Спрингетт (Steve Springett), являющийся также создателем набравшего широкую популярность проекта Dependency Track. SCVS состоит из шести семейств контроля, включающих не только среду сборки, но и Inventory (инвентаризацию), SBOM, Package Management (управление пакетами), Component Analysis (анализ компонентов), а также Pedigree and Provenance (определение родословной и происхождения). В SCVS, как и в SLSA, используются различные уровни, приобретающие в процессе продвижения по ним все большую строгость по требованиям и расширенность по возможностям.

Защита программного обеспечения криптографическими подписями набирает все большую популярность и признается в качестве важной части защиты цепочки поставок программного обеспечения, а такими крупными проектами, как Kubernetes, внедряются такие стандарты, как Sigstore, но имеется также возможность задействования эксплуатируемого сервера подписей (Exploited Signing Server). Криптографические подписи помогают защитить целостность программных артефактов и предоставить соответствующие гарантии их потребителям. Но если сервер подписи и сам механизм будут взломаны, эти гарантии станут недостоверными и абсолютно бесполезными. Взлом позволит злоумышленникам легитимно подписывать потенциально вредоносные артефакты и выходные данные, которые станут попадать к ничего не подозревающим потребителям программного обеспечения. Для снижения данного риска АНБ рекомендует такие меры, как проведение строгой многофакторной аутентификации (MFA) и контроля физического доступа к инфраструктуре подписания, а также подписание в изолированных сегментах сети и усиление защищенности самой инфраструктуры подписания. Недавние инциденты, подобные тому, что затронул Twillio и многих других SaaS-провайдеров, показывают, что применения MFA недостаточно, но организации все же должны внедрять такие устойчивые к фишингу формы MFA, как Yubikeys.

Доставка кода

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

В процессе прохождения пакетов и обновлений программного обеспечения через системы их распространения злоумышленники могут попытаться применить какую-либо из тактик их взлома. Это могут быть такие методы, как атаки типа «человек посередине» (Man-In-The-Middle, MiTM), направленные на внедрение вредоносного кода или уязвимостей, чтобы впоследствии ими можно было воспользоваться. Организации могут снизить подобные риски, воспользовавшись механизмами безопасного транзита, а также применив хэширование и цифровые подписи как на уровне продукта, так и на уровне компонентов программного обеспечения.

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

Приложения

Перед завершением статьи стоит отметить, что в руководстве АНБ имеется большой набор весьма ценных приложений. В их числе:

• Переход от рассматриваемых сценариев угроз к NIST SSDF-концепции с отображением конкретных практических приемов и мер по снижению рисков в SSDF для разработчика, поставщика или заказчика.
• Зависимости — перечисление зависимостей и артефактов, которые могут быть предоставлены поставщиком, сторонними поставщиками или заказчиками в интересах поставщиков и разработчиков.

• SLSA — разбор сути составляющих SLSA, а также различных требований, описаний и уровней.
• Артефакты и контрольные списки — примеры и описания артефактов и их предназначений, в частности контрольных списков готовности продукта, проектных документов и журналов сборки. В руководстве на примерах объясняется, какую ценность и для кого именно могут представлять эти артефакты.
• Информационные ресурсы — руководство, содержащее обширный набор ссылок на такие источники, как BSIMM, DoD CIO, Cyber EO, OWASP и многие другие. Многие из этих ссылок были приведены в документе в качестве примеров существующих руководств, которые задействовались и брались за основу Агентством национальной безопасности.

Более подробно с книгой можно ознакомиться на сайте издательства:

» Оглавление
» Отрывок

По факту оплаты бумажной версии книги на e-mail высылается электронная книга.
Для Хаброжителей скидка 25% по купону — Кибербезопасность

P.S. Обращаем ваше внимание на то, что у нас на сайте проходит распродажа.