Как читать авторский курс и нормативные материалы
Это учебные материалы, а не заключение о соответствии конкретного продукта. Организационные модели курса отделяйте от терминов стандарта: ППК в опубликованном проекте — машиночитаемый перечень, а живой реестр его версий является практикой сопровождения. Термин OSA в разных материалах имеет разный охват. Статус и обязательность нормативного документа проверяются отдельно; проект КАПО опубликован как проект первой редакции.
Билет 18
Теоретический вопрос
Объясните, почему политика приёмки компонентов обязана иметь явный механизм исключений и принятия риска, а не только запреты. Что такое обоснованное исключение (компонент нарушает политику, но риск принят уполномоченной ролью на срок и под условие), и чем оно отличается от «тихого обхода gate»? Почему принятие риска — это управленческое решение со сроком, владельцем и компенсирующей мерой, а не разовая правка статуса в трекере?
Практический вопрос
Мини-кейс Компонент с уязвимостью без патча критичен для релиза, заменить за срок нельзя. Опишите путь обоснованного исключения: что записать в паспорт риска (срок, условие, компенсирующая мера, владелец), кто имеет право его утвердить и как зафиксировать, чтобы при следующем аудите исключение было прослеживаемым, а не «дырой» в процессе. Чем VEX-статус
affectedс принятым риском отличается от необоснованногоnot_affected?
Что должен показать ответ
- Источник факта: реестр исключений и паспорт риска компонента как формальная запись, а не правка статуса.
- Инструмент: процедура принятия риска со сроком, условием и компенсирующей мерой; связка с VEX и явное различие
not_affectedотaffected + risk_accepted. - Владелец решения: утверждение исключения — уполномоченная роль (владелец риска / сервис аудита), не инженер в обход gate.
- Нормативная опора: ГОСТ Р 56939-2024, NIST SP 800-218 SSDF (RV), OWASP SAMM.
- Evidence: паспорт риска, реестр исключений, порядок принятия риска, VEX с issuer/evidence, если заявлен статус применимости.