Были ли у вас ситуации, когда безопасность запрещала внедрение релизов или другие ограничения, и как вы с этим справлялись
Что проверяют
Как вы ведёте себя, когда требования безопасности упираются в сроки: спорите, обходите или ищете решение вместе с безопасниками. Следом спрашивают, какие проверки стояли у вас в конвейере и кто принимал решение о риске.
Как отвечать
Нужен свой случай с конкретикой. Опорный каркас:
- что заблокировало: уязвимая зависимость с известным CVE, находка статического анализа, результат пентеста, требование по персональным данным или сертификации;
- как оценили: достижима ли уязвимость из вашего кода, какой у неё балл по CVSS, есть ли исправленная версия;
- что сделали: обновили библиотеку, закрыли уязвимость в коде, ввели компенсирующую меру (правило WAF, отключение функции через feature flag) или оформили принятие риска с владельцем продукта и сроком исправления;
- что изменили в процессе: проверки, которые теперь срабатывают до релиза, а не в день выкладки.
Для Java-стека называйте конкретные инструменты. Сканеры зависимостей: OWASP Dependency-Check, Snyk, Dependabot или Renovate для обновлений, Trivy или Grype для образов. Статический анализ: SonarQube, Semgrep, SpotBugs с плагином Find Security Bugs. SBOM в формате CycloneDX собирается плагином Maven или Gradle. Узнаваемый пример: Log4Shell (CVE-2021-44228) в log4j-core в декабре 2021, когда многим пришлось срочно поднимать версию, в том числе транзитивной зависимости. В Spring Boot такую версию переопределяют свойством, которым управляет BOM, не дожидаясь нового релиза Boot.
Если прямой блокировки не было, скажите это и расскажите о ближайшем опыте: обновление после отчёта сканера, замечание на ревью, требование убрать секреты из конфига. Покажите, как бы вы действовали.
Где спотыкаются
Рисуют безопасников противником, которого удалось «продавить». Для любой команды с аудитом это тревожный сигнал.
Отвечают общими словами «провели анализ и устранили уязвимости», не называя CVE, инструмент и срок.
Путают прямую зависимость с транзитивной: обновили свою библиотеку, а уязвимая версия продолжает приезжать через другую, что видно только в mvn dependency:tree или gradle dependencies.