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

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

П40. Огнестойкость РБПО и SCA-процесс

Цель

Оценить SCA/OSA-процесс Организации не по чек-листу «есть ли сканер», а по инженерной метафоре огнестойкости — тремя пределами: несущая способность (R), целостность (E), теплоизолирующая способность (I). Проверяемый результат — заполненная карта R/E/I с указанием для каждого предела времени, в течение которого процесс сохраняет управляемость при заданном инциденте.

Откуда метафора В строительной нормативке огнестойкость конструкции описывается пределами R (несущая способность — конструкция держит нагрузку), E (целостность — не пропускает пламя и газы) и I (теплоизоляция — ограничивает прогрев соседнего отсека), измеренными в минутах. Перенос на процесс РБПО: R — выдерживает ли процесс поток компонентов и поставок; E — не пропускает ли неподтверждённые компоненты в сборку; I — ограничивает ли распространение последствий и как быстро восстанавливает безопасное состояние.

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

Это аналитическая практика без инструмента. Возьмите три конкретных «пожара» (сценария-инцидента) и прогоните по ним процесс, заполнив карту R/E/I:

Сценарий 1: критическая RCE в популярной транзитивной библиотеке (масштаб «как log4shell»)
Сценарий 2: компрометация публичного образа/реестра — SBOM перевыпущены задним числом
Сценарий 3: соисполнитель прислал ZIP-поставку с неполным/невалидным SBOM

Для каждого сценария заполните таблицу (см. шаблон Карта огнестойкости SCA процесса):

| Предел | Вопрос                                              | Признаки наличия                                  | Предел времени |
|--------|-----------------------------------------------------|---------------------------------------------------|----------------|
| R      | Процесс выдерживает объём и темп?                   | владельцы, SLA, автоматизация, масштабируемый      | ? мин/часов    |
|        |                                                     | реестр, воспроизводимость сборок                  |                |
| E      | Неподтверждённый компонент не попадёт в сборку?     | controlled repo, SBOM quality gate, license       | ? мин/часов    |
|        |                                                     | verdict, vuln triage, unresolved worklist          |                |
| I      | Распространение ограничено, реакция быстрая?         | reachability, surface control, быстрый выпуск      | ? мин/часов    |
|        |                                                     | патча, SCA-to-SOC, временная блокировка периметра |                |

Метрика для колонки «Предел времени» — не «да/нет», а сколько времени процесс остаётся управляемым: от детекта инцидента до момента, когда (R) сборки снова идут, (E) гейт гарантированно режет уязвимый компонент, (I) выпущена безопасная версия и закрыт периметр.

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

Три заполненные карты R/E/I, где видно «слабый предел» каждого сценария. Ориентир по заполнению для сценария 1 (RCE в транзитиве):

| Предел | Признак у нас                                  | Предел времени         |
|--------|------------------------------------------------|------------------------|
| R      | SBOM в Dependency-Track, поиск по PURL за минуты| R ≈ 30 мин (найти все  |
|        |                                                | продукты с библиотекой)|
| E      | CI security gate режет по severity+VEX          | E ≈ держит, гейт активен|
| I      | reachability не считаем -> чиним всё подряд     | I ≈ 2–3 дня (слабый     |
|        |                                                | предел, нет приоритизации) |

Признак хорошей работы: для каждого сценария явно назван предел, который «прогорает» первым (узкое место), и сформулировано одно конкретное улучшение, поднимающее именно этот предел (например: «добавить reachability-анализ, чтобы I сократился с дней до часов»).

Связь пределов с другими практиками группы Сценарий 2 (компрометация реестра) напрямую завязан на честность образа из П37. Контейнерный образ слои секреты и удаленные файлы и П38. Честный SBOM контейнерного образа: если SBOM перевыпущены задним числом, предел E держится только при наличии provenance/attestation (in-toto, SLSA, cosign), иначе гейт верит подделанному SBOM.

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

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

Сдаёте три заполненные карты R/E/I (по одному сценарию на каждый), с указанием «прогорающего первым» предела и одного адресного улучшения под него. На защите устно объясните, почему наличие инструмента не равно огнестойкости и как ваш слабый предел связан с конкретной практикой курса. Эта практика — мостик к итоговой аттестации: тот же язык evidence используется в П36. Итоговый мини-проект.

Зачем это на дне аттестации Метафора огнестойкости даёт экзаменатору воспроизводимый критерий: вместо спора «хороший ли процесс» обсуждается измеримое «сколько он держит при таком-то пожаре и какой предел прогорает первым». Это снижает субъективность оценки.

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