Что такое Software Composition Analysis (SCA)

Мы уже неоднократно упоминали в этом канале про open source, лицензии и разное вокруг них. Сегодня хотим дать максимально ёмкое и по возможности коротко определение термину, который это всё объединяет — SCA, он же Software Composition Analysis, он же композиционный/компоненты анализ программ/кода/софта/ПО.

SCA — это процесс, где:
1. на вход подаётся код в произвольной форме (репозиторий, директория с файлами, Docker-образ, бинарник и т.п.);
2. этот код сканируется на наличие и зависимость от всех возможных open source компонентов через поиск файлов манифестов (типа package.json, poetry.lock, Dockerfile и т.п.) и через умное сравнение файлов с компонентными базами с примесью всякой магии типа нечётких хэшей;
3. по списку этих компонентов проверяются лицензии и их совместимость с заявленной лицензией самого продукта и между собой;
4. и вишенкой на торте по списку этих компонентов ищутся известные уязвимости по открытым и полуоткрытым базам (например, National Vulnerability Database, Github Advisory и другим).

На вид просто, но по факту внутри множество особенностей и нюансов. Например, на выходе второго шага формируется ещё одна аббревиатура — SBoM, Software Bill of Materials, про его суть, форматы и при чём тут недавний приказ Байдена о кибербезопасности мы расскажем отдельно. Также отдельно расскажем, почему поиск уязвимостей по уже известной компонентной базе (сюрприз-сюрприз) совсем нетривиальная задача.

SCA не так известен среди русскоязычных разработчиков как SAST (статический анализ кода) или DAST (динамический анализ кода), но набирает очки с каждой новой историей найденной уязвимости в распространённой open source библиотеке.

Хорошая новость в том, что множество SCA-like инструментов в той или иной степени присутствуют в экосистемах менеджеров пакетов, IDE, систем контроля версий или в виде отдельных инструментов. К сожалению, не все они удобны, точны или просты в использовании. But we're getting there.

Ну и если короткое описание только разожгло ваше любопытство, посмотрите обзорный доклад про эволюцию подходов SCA с прошедшего Data Fest Online v2: https://www.youtube.com/watch?v=9fydREfnKb4. Красочные слайды и висящая голова на белом фоне в комплекте.

#видоснавыходные #словарькодмайнера

Что такое Software Bill of Materials (SBOM)

Продолжаем рубрику #словарькодмайнера.

Мы, конечно, живём в своём пузыре, но внутри него немного нелепая аббревиатура SBOM за последний год стала всплывать в разы чаще, чем раньше. Даже Байден про неё говорил, и теперь все IT проекты для госорганов США должны содержать этот самый SBOM, это уже не шутки.

Software Bill of Materials — это список всех open source и других сторонних компонент, использующихся в кодовой базе программного продукта. По каждой компоненте SBOM минимально содержит информацию о названии, версии и лицензии. Некоторые форматы обязательным указывают ещё и тип компонента (например, «фреймворк» или «библиотека»).

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

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

Самые известных форматы SBOM это:
- CycloneDX https://cyclonedx.org/
- SPDX https://spdx.dev/
- SWID https://csrc.nist.gov/projects/Software-Identification-SWID
- табличка в Excel 🤭

Иногда SBOM пишут BOM, BoM, SBoM, и вообще как только не угорают. Вообще BOM пришёл из производства, где представляет собой опись всех деталей, из которых состоит продукт.

Для генерации SBOM используется два основных источника информации:
1. манифесты и lock-файлы пакетных менеджеров
2. непосредственный поиск скопированных файлов или частей кода в кодовой базе

Про то, какими инструментами генерировать SBOM и как потом использовать, мы расскажем отдельно.

Подробнее про SBOM советуем читать на сайте National Telecommunications and Information Administration:
https://www.ntia.gov/SBOM

Supply Chain Attack

Продолжаем пополнять #словарькодмайнера.

Атака на цепочку поставок, или в оригинале Supply Chain Attack — один из самых актуальных и популярных в последнее время у взломщиков и других «русских хакеров» способов получения доступа на сервера своих жертв.

Нашумевший взлом SolarWinds, затронувший сотни тысяч клиентов по всему миру, включая крупные корпорации и правительственные агентства США — тоже был реализован через Supply Chain Attack. Очень громкими были случаи внедрения в цепочку поставок хардварных криптовалютных кошельков несколько лет назад. По факту попытки взломов таким путём происходят каждый день и, судя по всему, их будет только больше.

Уточним, Supply Chain Attack — это и внедрения в цепи поставки софта, и вполне себе физические внедрения, когда при транспортировке железки с конвейера до потребителя с ней могут сделать что-то нехорошее.

Попробуем на пальцах объяснить, как это работает.

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

Допустим, ваша компания очень заботится о безопасности своей сети и серверов. Но с огромной вероятностью она использует какой-нибудь существующий внешний программный продукт, для простоты возьмём CRM. Такие продукты требуют регулярных обновлений, но что интереснее — они зависят от других компонентов. Например, какой-нибудь open source библиотеки, либо ещё какого-то коммерческого продукта. В этом случае злоумышленнику может быть проще внедриться в ту самую библиотеку или менее защищенный коммерческий продукт и подождать, когда цепочка поставок сама сделает своё дело.

Частным случаем таких атак являются Dependency Confusion Breach и Typosquatting Attack. Когда атакующий публикует в популярные индексы зараженные библиотеки, рассчитывая, что программист опечатается при установке компонента, либо система сборки возьмёт библиотеку из индекса вместо локального пакета.

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

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

Для искушенных советуем изучить относительно свежие рекомендации от Cybersecurity and Infrastructure Security Agency при поддержке NIST: https://www.cisa.gov/sites/default/files/publications/defending_against_software_supply_chain_attacks_508_1.pdf

Что такое PURL?
#словарькодмайнера

Питонист работает с PyPi и легко ориентируется в названиях подключаемых пакетов. Фронтендер аналогично работает с NPM. Но что если вам надо в рамках одной системы хранить, использовать и различать пакеты из разных экосистем?

Эту задачу и призван решить PURL — package "mostly universal" URL, т.е. практически универсальный URL (идентификатор) пакета. Это далеко не единственная, но наш взгляд одна из самых удачных схем идентификации пакетов, применимая к любому пакетному менеджеру и технологии.

Идентификатор составляют семь компонентов, объединённых в строку:

scheme:type/namespace/name@version?qualifiers#subpath

```- scheme — константа со значением pkg
- type — обозначение пакетного менеджера (из словаря)
- namespace — например, groupId в Maven
- name и version говорят сами за себя
- qualifiers — дополнительная опциональная информация, например указание на архитектуру или операционную систему
- subpath — опциональный путь внутри пакета, относительно его корня

На примерах:

pkg:deb/debian/curl@7.50.3-1?arch=i386&distro=jessie
pkg:gem/ruby-advisory-db-check@0.12.4
pkg:github/package-url/purl-spec@244fd47e07d1004f0aed9c
pkg:golang/google.golang.org/genproto#googleapis/api/annotations
pkg:maven/org.apache.xmlgraphics/batik-anim@1.9.1?packaging=sources
pkg:npm/foobar@12.3.1
pkg:nuget/EnterpriseLibrary.Common@6.0.1304
pkg:pypi/django@1.11.1
`

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

Подробно изучить стандарт можно по ссылке: https://github.com/package-url/purl-spec