Контрольные вопросы

Базовый уровень 1. Назовите три типа evidence и четыре статуса в методике оценки инструмента под ТЗ. Почему устный ответ на демо — слабейший тип? 2. Какие пакетные менеджеры подтверждены для OSA Proxy в режиме Firewall, а какие из списка ТЗ попадают в зону «риск несоответствия»? 3. Чем «поддержка Conan в SCA-манифестах» отличается от «Conan в OSA Proxy Firewall»? Почему это две разные строки матрицы? 4. Какие средства сборки C/C++ подтверждены для build scan, а какое прямо не подтверждено и требует демонстрации?

Средний уровень 5. Почему включение языков Bash, Perl, SQL/PLSQL/PGSQL в один список с пакетными экосистемами делает требование заведомо «не подтверждённым»? Как переформулировать? 6. Где проходит граница «binary analysis»: что распознаётся (архивы/контейнеры), а что ненадёжно (stripped, .a/.so) и почему сборочный контекст это меняет? 7. Для каких технологий заявлена reachability (анализ вызовов) и какие IDE покрыты плагинами? Что из реального стека C/C++-разработки сюда не попадает? 8. В чём разница между поставкой Offline и on-premise в контексте ТЗ, и почему это нельзя оставить нерешённым к закупке? 9. Почему требования к исполнителю (ФСТЭК, ISO 9001, опыт, ИБ-подразделение) выносятся в отдельный чек-лист, а не в техническую матрицу?

Продвинутый уровень 10. Сформулируйте бинарное Go/No-Go условие для qmake-сборки, которое наблюдается на артефакте, а не оценочно. 11. Почему правило консервативности («не подтверждено документацией — не закрыто») снижает риск закупки, и какова цена ложного «соответствует» по обязательному требованию? 12. Как разделить ТЗ по режимам продукта (OSA Proxy / плагин репозитория / CLI-агент / IDE), чтобы ТЗ не требовало от Proxy того, что умеет только агент?

Кейс-задачи

Кейс 1. Спор о Conda Поставщик на демо сказал: «Conda поддерживается». В документации Conda есть в списке SCA-экосистем, но в разделе OSA Proxy её нет. ТЗ требует Firewall-блокировку Conda. Какой статус вы поставите, к какому режиму, и какой сценарий пилота назначите?

Кейс 2. qmake-проект с форком C/C++ legacy-проект Организации собирается через qmake, статически линкует внутренний форк open-source-библиотеки и системные .so. После build scan в SBOM форк опознан как «оригинальная» библиотека, а часть .a ушла в unresolved. Что это значит для оценки риска компонента, какие пункты пилота сработали и какое решение Go/No-Go обоснованно?

Кейс 3. Полное соответствие на бумаге Коллега принёс матрицу, где все 40 требований ТЗ имеют статус «соответствует», evidence у трети — «устно на демо». Назовите минимум три строки, которые вы заведомо оспорите, и переведите их в корректные статусы со сценариями пилота.

Самопроверка

Если вы можете для любого требования ТЗ за минуту назвать режим, тип evidence и статус и предложить наблюдаемый сценарий пилота — материал освоен. См. конспект и Критерии Go No-Go после пилота.