Как читать авторский курс и нормативные материалы

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

Практическая работа: проектирование политики controlled repository

Цель

Спроектировать рабочую политику OSA-контура для одной экосистемы (npm или PyPI), которая: - блокирует три класса supply-chain атак на входе; - не останавливает разработку (есть карантин с SLA и процедура исключений); - оставляет audit trail для аудитора.

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

Исходные данные (зафиксировать)

Перед началом запишите контекст (это часть сдачи): - экосистема: npm / pypi; - режим контура: блокирующий (плагин к менеджеру артефактов) или OSA Proxy; - источники вердикта: фиды malware/protestware, CVE/БДУ, stop-list Организации; - дата проектирования политики.

Порядок выполнения

Шаг 1. Смоделируйте три атакующих пакета

Подберите по одному примеру на каждый класс (можно гипотетические имена):

Класс атаки	Ваш пример	Чем опасен
Вредоносный пакет	`…` (напр. `node-ipc`-подобный)	нагрузка на `install`
Путаница в именах	`…` (напр. `djngo`, `reqests`)	typo/combo/brandjacking
Подрыв апстрима	`…` (новая версия популярного пакета)	бэкдор в свежем релизе

Шаг 2. Опишите три этапа внедрения политики

Политику нельзя включить сразу в блок — это остановит сборки. Распишите:

warmup — контур работает только в наблюдении, собирает статистику запрашиваемых пакетов, формируется baseline; блокировок нет;
monitoring — срабатывания политики логируются и уведомляют владельца, но пакет проходит; вылавливаются ложные блокировки;
blocking — политика блокирует/карантинит реально; разработка идёт через процедуру исключений.

Укажите критерий перехода между этапами (например: «переходим в blocking, когда за 2 недели monitoring ложных срабатываний < N»).

Шаг 3. Заполните таблицу правил (минимум 5 правил)

Условие (с логикой объединения)	Действие	Уведомление
`package in stop_list OR is_malware`	block	задача на 3-ю линию
`is_protestware`	block	уведомить владельца контура
`release_age < 14 дней`	quarantine	задача на SAST-ревью
`name ~ typosquat(popular_packages)`	block	предупреждение разработчику
`critical_cve AND has_exploit AND has_fixed_version`	quarantine	задача напрямую разработчику
`license NOT IN allowlist`	quarantine	уведомить юристов

Адаптируйте под свою экосистему; объедините хотя бы два условия логическим AND.

Шаг 4. Опишите карантин и исключения

что значит «карантин» в вашем контуре: версия не отдаётся, но заявка на разбор создана; SLA разбора (например, 3 рабочих дня);
процедура исключения: кто запрашивает, кто согласует, на какой срок, когда пересмотр. Сошлитесь на М14 и П30. Исключения и принятие риска.

Шаг 5. Опишите audit trail

Какие поля логируются на каждый вердикт: пакет@версия, экосистема, сработавшее правило, вердикт, автор исключения (если было), дата, основание. Этого достаточно, чтобы аудитор восстановил, почему пакет прошёл или нет.

Что вы должны увидеть (ожидаемый результат)

Прогон трёх тестовых пакетов из шага 1 даёт три разных вердикта:

requests@2.31.0     -> allow       (нет срабатываний)
reqests@9.9.9       -> block       (правило typosquat)
left-pad@99.0.0     -> quarantine  (release_age < 14d) -> задача SAST

Если все три пакета получают allow — политика слишком слабая; если легитимный requests блокируется — слишком жёсткая или вы не в режиме warmup/monitoring.

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

Все пакеты проходят. Не настроены источники вердикта или контур в режиме warmup — для теста blocking временно переключите этап.
Карантин блокирует всё подряд. Слишком агрессивное release_age без allowlist для доверенных майнтейнеров — добавьте исключения по scope/namespace.
Правила конфликтуют (один пакет под block и под quarantine). Задайте приоритет: block > quarantine > allow.
Dependency confusion проходит мимо. Контур фильтрует содержимое, но не приоритет индексов — отдельно проверьте, что приватный scope/index имеет приоритет над публичным.

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

Показать преподавателю: 1. таблицу политики (≥5 правил, ≥1 объединение условий через AND); 2. три этапа warmup → monitoring → blocking с критерием перехода; 3. описание карантина с SLA и процедуры исключений; 4. перечень полей audit trail; 5. прогон трёх тестовых пакетов с тремя разными вердиктами.

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

П17. OSA controlled repository policy — эталон политики controlled repo.
П18. OSA Proxy режимы и ограничения — границы применимости proxy-режима.
ГОСТ Р 56939-2024 — контроль элементов от сторонних поставщиков и анализ кода из цепочек поставок на ВПО.