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

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

Что проверять на проекте: OSA-контур и защита цепочки поставки

Чек-лист аудитора. Цель — убедиться, что превентивный контур (OSA) реально стоит на входе, а не существует на бумаге. Каждый пункт проверяется артефактом или прогоном, а не словами.

Главный риск этой темы Самый частый дефект — контур в сканирующем режиме, который всё видит, но ничего не блокирует. «У нас есть OSA» при этом формально верно, а вредоносный пакет всё равно попадает в контур. Различать «увидели» и «не пустили» — первое, что проверяет аудитор.

Чек-лист

  1. Контур стоит на входе, а не только по составу. Есть отдельный механизм проверки пакета до скачивания (OSA), а не только SCA по собранному релизу. Если есть только SCA — превентивного контура нет.

  2. Режим контроля известен и адекватен потоку. Для критичных потоков (production-сборки) — блокирующий режим (плагин к менеджеру артефактов). Сканирующий режим (registry в наблюдении) допустим только там, где блокировка не нужна, и это осознанное решение.

  3. Источники вердикта подключены и обновляются. Фиды malware/protestware, CVE/БДУ, собственный stop-list. Проверить дату последнего обновления фидов — устаревший фид не ловит свежие атаки.

  4. Политика покрывает три класса атак. В правилах есть контроль против: вредоносного пакета (stop-list/malware), путаницы в именах (typosquat-проверка), подрыва апстрима (карантин «молодых» версий / protestware-фид).

  5. Внедрение прошло через warmup → monitoring → blocking. Есть свидетельство поэтапного включения с критериями перехода, а не «включили блок сразу» (что обычно приводит к отключению контура).

  6. Карантин имеет SLA. Для «молодых»/подозрительных версий определён срок разбора и ответственный. Карантин без SLA = скрытый стоп-кран, который рано или поздно отключат.

  7. Есть процедура исключений с пересмотром. Заблокированный пакет можно провести через заявку: кто запрашивает, кто согласует, на какой срок, дата пересмотра. См. П30. Исключения и принятие риска.

  8. Dependency confusion закрыт на уровне конфигурации. Приватные scope/namespace зарезервированы и приоритизированы в конфиге менеджера (приватный индекс выше публичного). Один сканер пакетов этого не закрывает.

  9. Install-скрипты под контролем. Для экосистем с install-хуками (npm) есть политика на --ignore-scripts или изоляция сборки/песочница. Состав «чистый» не означает безопасный postinstall.

  10. Docker-образы проходят через тот же контур. Предсобранное ПО (образы) проверяется OSA так же, как пакеты, и на него строится SBOM. Иначе образы — дыра в периметре (требование контроля предсобранного ПО, ГОСТ Р 56939-2024).

  11. Audit trail полный и читаемый. На каждый вердикт логируются: пакет@версия, экосистема, сработавшее правило, вердикт, автор исключения, дата, основание. Аудитор может восстановить, почему пакет прошёл или нет.

  12. Уведомления доходят до владельца. Срабатывания политики уходят в почту / таск-трекер / ASPM / вебхук, и есть владелец контура, который их разбирает. Логи, которые никто не читает, — не контроль.

Связки