Пиков / КАПО
Библиотека
Как читать авторский курс и нормативные материалы

Это учебные материалы, а не заключение о соответствии конкретного продукта. Организационные модели курса отделяйте от терминов стандарта: ППК в опубликованном проекте — машиночитаемый перечень, а живой реестр его версий является практикой сопровождения. Термин OSA в разных материалах имеет разный охват. Статус и обязательность нормативного документа проверяются отдельно; проект КАПО опубликован как проект первой редакции.

П18. OSA Proxy режимы и ограничения

Контекст практики OSA подключается к контуру разработки тремя способами, и у каждого свой предел отказа: одни физически не отдают пакет, другие только показывают проблему постфактум. Эта практика — аналитическая, без запуска движка: вы строите матрицу «способ подключения × что реально может OSA» и явно отмечаете, где «увидели» подменяется иллюзией «не пустили». Контролируемый результат — карта применимости, по которой видно, какой режим закрывает какой класс атак.

Цель

Получить матрицу режимов OSA на 1 страницу, в которой для трёх способов подключения (плагин к менеджеру артефактов, OSA Proxy, CLI/agent в pipeline) указано: - тип отказа: блокирующий (пакет не доставлен) или наблюдающий/сканирующий (пакет доставлен, проблема залогирована); - момент срабатывания относительно install (до доставки / после доставки / на сборке); - какой класс supply-chain атак режим реально перекрывает, а какой — нет; - известные ограничения (install-скрипты, офлайн-фиды, dependency confusion).

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

Команда или действие

Действие — заполнить и обосновать матрицу. Каркас:

| Способ подключения        | Тип отказа     | Момент          | Перекрывает                       | НЕ перекрывает / лимит            |
|---------------------------|----------------|-----------------|-----------------------------------|-----------------------------------|
| Плагин к Nexus/JFrog      | блокирующий    | до доставки     | malware/typosquat в block-правиле | install-скрипты после allow       |
| OSA Proxy (прокси трафика)| блокирующий*   | до доставки     | исключение версий из выдачи индекса | приватные имена без резервирования |
| Registry scan (Harbor/GL) | наблюдающий     | после доставки  | видимость уязвимых образов        | образ уже в реестре — не отказ     |
| CLI/agent в CI (Grype etc)| gate по exit   | на сборке       | падение pipeline по порогу        | dev-машину разработчика не трогает |

* блокирующий — только если proxy стоит на пути скачивания и менеджер настроен ходить через него.

Для каждой строки письменно ответить: «Если атака класса X, остановит ли этот режим её до выполнения вредоносного кода?»

Что вы должны увидеть

Заполненная матрица проходит три сценария — для каждого один корректный режим и явно отбракованный:

Сценарий Корректный режим Почему не другой
Нужно физически не отдать пакет из stop-list разработчику на dev-машине Плагин к Nexus/JFrog (блокирующий) CLI-gate в CI не трогает dev-машину; registry scan лишь логирует
Контейнерный образ уже лежит в Harbor, надо узнать про уязвимые слои Registry scan (наблюдающий) это видимость, не блокировка — образ уже доставлен
Остановить релиз на High/Critical в зависимостях CLI/agent gate в pipeline proxy/плагин не оценивают порог критичности всего релиза

Признак готовности: в матрице явно стоит пометка, что наблюдающий режим ≠ блокировка (Harbor/GitLab в scanning-режиме показывают проблему, но пакет/образ уже в контуре), и что --ignore-scripts — отдельный контроль, который ни один из режимов автоматически не включает.

«Увидели» — это не «не пустили» Самая частая ошибка проектирования OSA — поставить registry scan (наблюдающий режим) и считать контур защищённым. Сканер покажет уязвимый образ, но образ уже в реестре и доступен на скачивание. Реальный отказ даёт только блокирующий режим (плагин к Nexus/JFrog на пути доставки) или gate по exit-коду на сборке. В матрице это должно стоять разными столбцами «Тип отказа».

Если не получилось

Критерий зачёта

Показать преподавателю: (1) матрицу из ≥4 строк с разделением «блокирующий/наблюдающий» и моментом срабатывания; (2) разобранные 3 сценария с корректным и отбракованным режимом; (3) явно выписанные ограничения — install-скрипты, dependency confusion, офлайн-фиды. Устно — в чём разница точки контроля у OSA (доступ к пакету) и SCA/CI-gate (состав релиза), и почему наблюдающий режим нельзя считать блокировкой.

Нормативная связка