П17. OSA controlled repository policy

Контекст практики Controlled repository — это управляемая прокладка между разработчиком и публичным реестром (npm registry, PyPI), через которую идут все скачивания. Эта практика — проектная, без запуска инструмента: вы пишете политику приёма пакетов для одной экосистемы. Контролируемый результат — не «настроенный Nexus», а документ, по которому любой пакет получает однозначный вердикт allow / warn / quarantine / block с владельцем и SLA.

Цель

Получить политику controlled repository на 1 страницу для одной экосистемы (npm или PyPI), в которой: - описан жизненный цикл контура: warmup → monitoring → blocking (с критериями перехода между фазами); - задана таблица правил «условие → действие» из четырёх вердиктов (allow, warn, quarantine, block); - для quarantine указан SLA (сколько держим «молодую» версию и кто разбирает); - описана процедура исключения (кто, на каком основании, на какой срок) и состав audit trail.

Проверяемый результат: по политике можно «прогнать» 3 тестовых кейса и для каждого получить один вердикт без обращения к автору документа.

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

Действие — заполнить шаблон политики. Каркас (Markdown, кладётся в репозиторий регламентов):

## Область
Экосистема: npm. Контур: все раннеры CI + dev-машины через прокси.

## Фазы внедрения
| Фаза       | Что делает контур                          | Критерий перехода к следующей фазе |
|------------|--------------------------------------------|------------------------------------|
| warmup     | пропускает всё, строит baseline-список     | собрано N дней статистики, baseline согласован |
| monitoring | пропускает, но помечает нарушения (warn)   | < X ложных block/нед на ревью      |
| blocking   | физически не отдаёт пакеты из block-правил | —                                  |

## Правила (объединяются по приоритету сверху вниз)
| Условие срабатывания                                  | Вердикт     | Владелец / SLA            |
|-------------------------------------------------------|-------------|---------------------------|
| Пакет в stop-list или классифицирован как malware     | block       | 3-я линия, разбор 1 день  |
| Имя похоже на внутренний scope (dependency confusion) | block       | 3-я линия, разбор 1 день  |
| Версия выпущена < 14 дней назад («молодая»)           | quarantine  | AppSec, релиз из карантина по SLA |
| Лицензия из стоп-листа                                 | warn→block  | юристы + владелец продукта |
| Всё прочее, прошедшее baseline                        | allow       | —                         |

## Карантин (SLA)
Срок выдержки: 14 дней с даты публикации версии. Досрочный релиз — по ручному ревью AppSec.
Просроченный карантин без решения эскалируется владельцу продукта.

## Исключения
Кто запрашивает / кто утверждает / основание / срок пересмотра / запись в реестр исключений.

## Audit trail
Лог: timestamp, пакет@версия, инициатор, вердикт, правило, кто утвердил исключение.

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

Готовая политика проходит тест на однозначность — три кейса дают ровно один вердикт:

Признак, что политика готова: коллега, не писавший её, проходит те же 3 кейса и получает те же вердикты. Для каждого block/quarantine в audit trail появляется запись с правилом и владельцем.

Карантин без SLA убивает политику Самая частая ошибка — поставить quarantine на «молодые» версии и не описать, кто и за сколько их выпускает. Через неделю разработка встаёт (нужная версия висит в карантине бессрочно), и контур переводят обратно в monitoring административно. SLA и владелец для карантина так же обязательны, как само правило.

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

• Кейс даёт два вердикта одновременно. Правила не упорядочены по приоритету. В OSA-движках условия объединяются сверху вниз — block по malware должен стоять выше quarantine по возрасту версии. Добавьте явный порядок применения.
• Нет фазы warmup, сразу blocking. Без baseline первый же npm ci упрётся в десятки block на легитимные транзитивные пакеты. Фазы нужны именно чтобы собрать «нормальный» список до включения блокировки.
• Dependency confusion не закрыт. Политика проверяет malware, но не описывает, что делать с публичным пакетом, чьё имя совпадает с приватным scope. Само по себе наличие OSA-proxy не спасает — нужно ещё резервирование имён и приоритет внутреннего индекса (см. конспект М08).
• «Warn» ничем не отличается от «allow». Если за warn не закреплено действие (запись в реестр, задача на ревью), он эквивалентен пропуску. Либо у warn есть последствие, либо его не должно быть в таблице.

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

Показать преподавателю: (1) политику на 1 страницу с фазами warmup/monitoring/blocking и критериями перехода; (2) таблицу правил с четырьмя вердиктами, приоритетом и владельцами; (3) пройденные 3 тестовых кейса с однозначным вердиктом по каждому; (4) описанный SLA карантина и процедуру исключений. Устно — почему blocking-режим даёт реальный отказ, а scanning-режим только видимость (мост к П18. OSA Proxy режимы и ограничения).

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

• М08. Защита цепочки поставки и OSA — родительский модуль (таксономия атак и OSA-контур).
• П18. OSA Proxy режимы и ограничения · П16. GitLab CI security gate · П30. Исключения и принятие риска
• Требования к controlled repository · Политика приемки сторонних компонентов · Реестр исключений · Журналирование и audit trail
• ГОСТ Р 56939-2024 — контроль сторонних элементов и анализ кода из цепочек поставок на ВПО.