Безопасность зависимостей и анализ состава программного обеспечения
Проверяйте сторонние библиотеки с помощью инструментов SCA, фиксируйте версии зависимостей и интегрируйте автоматические оповещения об уязвимостях в конвейер CI/CD.
«Безопасность зависимостей и анализ состава программного обеспечения» — бесплатный урок Cloud & IT Cert Prep на CoddyKit. Это урок 3 из 4. Ты можешь прочитать весь урок бесплатно ниже — а потом практиковать его прямо в браузере с встроенным редактором кода и ИИ-репетитором 24/7. Это часть пути обучения Cloud & IT Cert Prep, и твой прогресс синхронизируется между веб-версией и приложением CoddyKit. Курс Cloud & IT Cert Prep содержит 4 уроков всего.
Риск зависимостей открытого исходного кода
Современные приложения в значительной степени состоят из сторонних библиотек и фреймворков с открытым исходным кодом. Типичное приложение Node.js может иметь более 1 000 транзитивных зависимостей, а проект на Java может подтягивать сотни артефактов Maven. Каждая зависимость представляет собой потенциальную поверхность атаки. Уязвимость Log4Shell (CVE-2021-44228) в библиотеке Log4j показала, что одна зависимость может за несколько дней после раскрытия информации сделать миллионы приложений по всему миру немедленно уязвимыми для эксплуатации.
Что такое анализ состава программного обеспечения
Инструменты анализа состава программного обеспечения (SCA) автоматически составляют перечень всех компонентов с открытым исходным кодом в приложении, включая транзитивные зависимости (зависимости Ваших зависимостей), и постоянно сопоставляют их с базами данных уязвимостей в поиске известных CVE. SCA создаёт спецификацию состава программного обеспечения (SBOM) с перечнем каждого компонента и его версии, что позволяет быстро определить затронутые системы при раскрытии новых уязвимостей.
# SCA tool usage examples:
# npm audit (Node.js):
# npm audit
# -> Reports vulnerabilities in package.json dependencies
# -> Shows severity, CVE ID, affected package, fix version
# OWASP Dependency-Check (Java/Python/etc.):
# dependency-check --project 'MyApp' --scan ./lib/
# -> Generates HTML/XML report with CVE findings
# Snyk scan:
# snyk test
# -> Reports vulns + 'snyk fix' applies patches automaticallyТранзитивные зависимости: скрытый риск
Транзитивные зависимости — это библиотеки, от которых зависят Ваши непосредственные зависимости, хотя Вы явно их не выбирали. Например, у Вас может быть непосредственная зависимость от пакета A, который зависит от пакета B (версии 1.2), а тот — от пакета C (версии 3.0, содержащей уязвимость). Вы не знаете о пакете C, но приложение выполняет его код. Инструменты SCA обходят всё дерево зависимостей и выявляют эти скрытые уязвимости, которые разработчики не могут напрямую видеть.
# Dependency tree example:
# Your package.json:
# 'express': '^4.18.0' (direct dependency)
# 'lodash': '^4.17.21' (direct dependency)
# Transitive dependencies (you didn't choose these):
# express -> 'qs' 6.11.0 (URL parsing)
# express -> 'body-parser' 1.20 -> 'qs' 6.11.0
# lodash (self-contained in this case)
# If 'qs' 6.10.x had a prototype pollution CVE,
# you are vulnerable via express even though
# you never directly imported 'qs'.Спецификация состава программного обеспечения (SBOM)
Спецификация состава программного обеспечения (SBOM) — это формальный машиночитаемый перечень всех компонентов программного продукта, похожий на список ингредиентов продукта питания. Форматы SBOM включают SPDX (Linux Foundation) и CycloneDX (OWASP). Указ президента US № 14028 (2021) обязал предоставлять SBOM для программного обеспечения, продаваемого федеральному правительству. Имея SBOM, команды безопасности могут немедленно запросить: «какие из наших продуктов содержат Log4j?» — и получить ответ за минуты, а не за дни ручного поиска.
# Generate SBOM with syft:
# syft packages . -o spdx-json > sbom.spdx.json
# SBOM content example (SPDX JSON):
# {
# 'packages': [
# { 'name': 'express', 'version': '4.18.2', 'license': 'MIT' },
# { 'name': 'lodash', 'version': '4.17.21','license': 'MIT' },
# { 'name': 'log4j-core','version': '2.14.0','license': 'Apache-2.0'}
# ]
# }
# When Log4Shell announced, query SBOM:
# grep -i 'log4j-core' sbom.spdx.json -> FOUND in 3 projectsФиксация версий зависимостей и файлы блокировки
Фиксация версий зависимостей задаёт точные версии зависимостей вместо гибких диапазонов (^1.2.3 или *). Файлы блокировки (package-lock.json, yarn.lock, Pipfile.lock, Gemfile.lock) сохраняют точную версию каждой зависимости, выбранную во время установки. Их следует добавлять в систему контроля исходного кода, чтобы каждый участник команды и конвейер CI/CD использовали одинаковые версии зависимостей и чтобы предотвратить атаки на цепочку поставок, при которых версии пакетов подменяются между установками.
# Version range vs pinned versions:
# FLEXIBLE (can pull different versions each install):
# 'express': '^4.0.0' -> installs latest 4.x.x
# 'lodash': '*' -> installs any version!
# PINNED (always same version):
# 'express': '4.18.2' -> always exactly 4.18.2
# Lock file (package-lock.json):
# Records EXACT resolved version of every transitive dep.
# Commit this file! It ensures reproducible builds.
# Never .gitignore lock files (security anti-pattern).Атаки на цепочку поставок: typosquatting и Dependency Confusion
Атаки на цепочку поставок направлены на экосистему зависимостей. Typosquatting заключается в публикации вредоносных пакетов с именами, похожими на имена популярных пакетов (например, lodahs вместо lodash), в надежде, что разработчики ошибутся при вводе имени. Атаки Dependency Confusion используют порядок поиска реестров менеджерами пакетов: атакующий публикует вредоносный пакет с тем же именем, что и внутренний закрытый пакет, но с более высоким номером версии, из-за чего менеджер пакетов устанавливает вместо него вредоносную общедоступную версию.
# Dependency Confusion Attack (Alex Birsan 2021):
# Company uses internal package 'company-utils' v1.0.0
# Hosted on: internal.registry.company.com
# Attacker publishes 'company-utils' v9.9.9 to npmjs.com
# (public registry with higher version number)
# npm install resolves: 'find highest version across ALL registries'
# -> Installs v9.9.9 from public npm (attacker's malicious package!)
# -> Instead of v1.0.0 from internal registry
# Defense: use namespace scoping (@company/utils)
# or configure npm to ONLY use internal registry for private packagesИнструменты SCA на рынке
В отрасли широко используются несколько инструментов SCA. Snyk выполняет удобное для разработчиков сканирование зависимостей и автоматически создаёт запросы на исправление. OWASP Dependency-Check — бесплатный, широко распространённый инструмент для Java, .NET, Python и Ruby. GitHub Dependabot автоматически открывает запросы на включение изменений для обновления уязвимых зависимостей в репозиториях GitHub. JFrog Xray и Sonatype Nexus IQ интегрируют SCA в репозитории артефактов и блокируют попадание уязвимых сборок в рабочую среду.
Интеграция SCA в конвейеры CI/CD
SCA наиболее эффективен, когда интегрирован в качестве контроля качества в конвейер CI/CD. При каждом запросе на включение изменений и каждой сборке конвейер запускает инструмент SCA и прерывает сборку, если в зависимостях обнаружены CVE с критическим или высоким уровнем серьёзности. Такой подход с переносом проверок на ранние этапы выявляет уязвимые зависимости до их попадания в рабочую среду, а не спустя месяцы во время ручной проверки безопасности или после взлома. Команды должны определить чёткие пороги серьёзности уязвимостей: одни должны блокировать развёртывание, а другие — только формировать предупреждения.
# GitHub Actions SCA pipeline step:
# - name: Run Snyk SCA scan
# uses: snyk/actions/node@master
# env:
# SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
# with:
# args: --severity-threshold=high
# --fail-on=upgradable
# # Build fails if any HIGH or CRITICAL vuln found
# # that has an available fix (--fail-on=upgradable)
# # No fix available? Generates warning, doesn't block
# # (acknowledging risk explicitly is better than blocking forever)Оценка состояния пакетов с открытым исходным кодом
Перед добавлением зависимости оцените её уровень безопасности по нескольким признакам. Активность сопровождения: проект активно поддерживается? Когда были выполнены последний коммит и выпуск? История известных уязвимостей: сколько CVE было обнаружено и как быстро они устранялись? Число загрузок: широко используемые пакеты привлекают больше внимания специалистов по безопасности. Число зависимостей: пакеты с меньшим числом зависимостей создают меньший транзитивный риск. OpenSSF Scorecard обеспечивает автоматическую оценку практик безопасности проектов с открытым исходным кодом.
Стратегии устранения уязвимостей
Если SCA выявляет уязвимую зависимость, существует несколько стратегий устранения проблемы. Обновите её до исправленной версии — это предпочтительный вариант, если он доступен. Виртуальное исправление с помощью правил WAF может нейтрализовать известные пути эксплуатации, пока готовится обновление. Удалите зависимость, если она больше не нужна. Примите риск с документированным обоснованием, если уязвимость нельзя использовать в конкретном контексте (например, уязвимость на серверной стороне в библиотеке для клиентской стороны). Никогда не оставляйте критические уязвимости без устранения или документированного принятия риска.
Соблюдение лицензий для зависимостей
Инструменты SCA выполняют две задачи: выявляют уязвимости безопасности и отмечают проблемы соблюдения лицензий в зависимостях с открытым исходным кодом. К распространённым проблемным лицензиям относятся GPL v2/v3 (копилефт — требует также открыть исходный код Вашего продукта, если Вы его распространяете), AGPL (распространяет требования GPL на сетевые службы) и SSPL. Использование библиотеки под лицензией GPL в проприетарном коммерческом программном обеспечении без коммерческой лицензии может создать серьёзные юридические риски. Такие инструменты SCA, как FOSSA, Black Duck и WhiteSource, автоматизируют проверку лицензий наряду с обнаружением уязвимостей, обеспечивая соблюдение обязательств перед сообществом открытого исходного кода.
# License compliance risk levels:
# PERMISSIVE (low risk for commercial use):
# MIT, Apache 2.0, BSD 2/3-Clause
# -> Can use in proprietary code, just keep attribution
# WEAK COPYLEFT (medium risk - check usage):
# LGPL -> can link dynamically without open-sourcing your code
# MPL 2.0 -> modifications to MPL files must be open-sourced
# STRONG COPYLEFT (high risk for proprietary products):
# GPL v2, GPL v3 -> if you distribute code using GPL library,
# your entire product must also be GPL
# AGPL -> extends GPL to SaaS/network services
# SCA policy: block AGPL/GPL in commercial product
# -> Review any exception requests manuallyБыстрая проверка
Проверьте своё понимание концепций CompTIA Security+ (SY0-701) из этого урока.
Итоги урока
В этом уроке Вы узнали, что инструменты SCA сканируют всё дерево зависимостей, включая транзитивные зависимости, в поиске известных CVE; SBOM предоставляют машиночитаемый перечень, позволяющий быстро реагировать на раскрытие новых уязвимостей; а интеграция SCA в качестве контроля качества CI/CD выявляет уязвимые зависимости до их попадания в рабочую среду. Далее мы рассмотрим DevSecOps и перенос контролей безопасности на ранние этапы полного конвейера CI/CD.
Часто задаваемые вопросы
Урок «Безопасность зависимостей и анализ состава программного обеспечения» бесплатный?
Да — полный текст урока «Безопасность зависимостей и анализ состава программного обеспечения» бесплатно доступен здесь в веб-версии. Чтобы практиковать его интерактивно (встроенный редактор кода и ИИ-репетитор 24/7) и разблокировать остальной курс Cloud & IT Cert Prep, подпишись на CoddyKit PRO. Курс Cloud & IT Cert Prep содержит 4 уроков всего.
Чему я научусь в уроке «Безопасность зависимостей и анализ состава программного обеспечения»?
Проверяйте сторонние библиотеки с помощью инструментов SCA, фиксируйте версии зависимостей и интегрируйте автоматические оповещения об уязвимостях в конвейер CI/CD. Ты практикуешь Cloud & IT Cert Prep с помощью реального кода, который запускаешь прямо в браузере, и ИИ-репетитор 24/7 отвечает на твои вопросы во время урока.
Нужен ли мне опыт, чтобы начать Cloud & IT Cert Prep?
Предыдущий опыт не требуется. Cloud & IT Cert Prep на CoddyKit структурирован для всех уровней — от новичков до продвинутых, поэтому ты можешь начать отсюда или с самого начала и учиться в своем темпе. Это урок 3 из 4.
Сколько времени занимает урок «Безопасность зависимостей и анализ состава программного обеспечения»?
Большинство уроков CoddyKit занимают около 5–10 минут. Каждый из них компактный и интерактивный, поэтому ты постоянно делаешь прогресс и продолжаешь с того же места в веб-версии и приложении.
Можно ли писать и запускать код в этом уроке Cloud & IT Cert Prep?
Да. Каждый урок Cloud & IT Cert Prep включает встроенный редактор кода, поэтому ты пишешь и запускаешь реальный код прямо в браузере и получаешь моментальную обратную связь от AI — локальная установка не требуется.
Все уроки этого курса
- Проверка входных данных и кодирование выходных данных
- Безопасное управление секретами и переменными окружения
- Безопасность зависимостей и анализ состава программного обеспечения
- DevSecOps: перенос безопасности в начало конвейеров