Управление зависимостями и toolchain проектов¶
Требования применяются к языку, runtime, framework, средствам сборки и
сторонним пакетам backend-, frontend- и mobile-приложений. Платформенный
документ может дополнительно ограничивать допустимый toolchain или package
manager. Уровни обязательности определены в корневом README.md.
DEV-DEP-001. Источник, версия и целостность¶
Уровень: MUST
Применяется к: toolchain, runtime и каждой прямой или транзитивной зависимости
Язык, runtime, основной framework, package manager, средство сборки и генератор кода, влияющий на артефакт, должны иметь один машинно-читаемый источник версии. Плавающие обозначения и выбор произвольной установленной версии запрещены.
Зависимость должна поступать из объявленного доверенного registry или проверенного repository, иметь точную разрешённую версию и проверяемую целостность. Конфигурация должна предотвращать dependency confusion и подмену источника.
Источник container image регулируется отдельным DEP-IMG-004; для него статус
доверенного или утверждённого registry не обязателен.
Проект должен хранить поддерживаемый package manager lock-файл. CI и release-сборка должны устанавливать зависимости без изменения lock-файла и завершаться ошибкой при расхождении с manifest. Плавающая версия и автоматическое обновление lock-файла в release pipeline запрещены.
Обоснование¶
Проверяемый источник и зафиксированное дерево делают сборку воспроизводимой и ограничивают подмену кода.
Проверка¶
- review источников версий, registry, manifest и lock-файла;
- сравнение фактических версий toolchain в локальной среде, CI и release-сборке;
- чистая повторная установка с запретом изменения lock-файла;
- проверка checksum и запрета незаявленного источника.
Исключения¶
Компонент, версия которого однозначно определяется зафиксированным родительским toolchain, не требует дублирующей декларации. Package manager без lock-файла требует другого машинно-проверяемого способа фиксации точных версий и целостности. Новый источник требует ADR и security review.
DEV-DEP-002. Лицензии и поддержка¶
Уровень: MUST
Применяется к: toolchain, runtime и dependency graph, влияющим на сборку или production
CI должен проверять лицензии прямых и транзитивных зависимостей. Язык, runtime, основной framework и зависимости production не должны использоваться после окончания поддержки владельцем технологии. Запрещённая лицензия или неподдерживаемая версия должна блокировать release.
Обоснование¶
Транзитивная зависимость несёт те же эксплуатационные, правовые и security- риски, что и прямая.
Проверка¶
- license scanning полного дерева;
- проверка статуса поддержки toolchain, runtime и основного framework;
- тест блокирующего порога pipeline;
- контроль срока и владельца исключений.
Исключения¶
Временное принятие запрещённой лицензии или неподдерживаемой версии требует утверждённого исключения с владельцем, сроком и компенсирующими мерами.
DEV-DEP-003. Необходимость зависимости¶
Уровень: MUST
Применяется к: добавлению или сохранению прямой зависимости
Зависимость должна использоваться сборкой, проверкой или runtime-компонентом. Новая зависимость не должна дублировать уже принятую возможность без проверяемого преимущества. При оценке клиентской зависимости должны учитываться размер поставляемого артефакта, permissions и собираемые SDK данные. Неиспользуемая зависимость должна удаляться вместе с её конфигурацией и разрешениями.
Обоснование¶
Каждый пакет увеличивает поверхность атаки, размер и стоимость обновления.
Проверка¶
- статический анализ использования;
- review назначения, дублирования, размера и permissions;
- проверка удаления конфигурации и недостижимого кода.
Исключения¶
Build dependency может отсутствовать в runtime-артефакте, но остаётся в области
проверок источника и лицензий, а при включённом vulnerability scan — в области
DEV-DEP-004.
DEV-DEP-004. Сканирование уязвимостей зависимостей¶
Уровень: SHOULD
Применяется к: dependency graph, влияющему на сборку или production
CI следует проверять известные уязвимости прямых и транзитивных зависимостей. Конфигурацию источника данных, severity, ignored findings и условий отказа следует хранить в Git. Уязвимость выше принятого проектом порога следует блокировать release.
Обоснование¶
Сканирование помогает обнаруживать известные риски в транзитивном составе, но не является обязательным release gate для каждого проекта.
Проверка¶
- dependency scanning полного дерева;
- контролируемый vulnerable fixture;
- проверка блокирующего порога pipeline.
Исключения¶
Проект MAY не выполнять vulnerability scan без ADR. Ignore включённого scan требует владельца, причины, срока и компенсирующих мер.