🎯 Зачем спрашивают
- Проверить, думает ли кандидат о безопасности с самого начала разработки, а не «когда придёт ИБ».
- Понять, знает ли он базовые практики автоматизации (линтеры, аудит зависимостей, CI/CD-интеграции).
- Выявить, ориентируется ли в разных уровнях проверки (SAST, DAST, секреты, конфиги).
- Увидеть, понимает ли кандидат trade-offs.
- Оценить зрелость кандидата
📝 Ответ
О безопасности вашего приложения следует думать перед тем как начинать саму разработку.
Есть множество различных инструментов, используя которые можно построить автоматизированный конвейер проверки. Пойдем по принципу простоты интеграции в ваш проекте.
Линтеры
Подмножество статических анализаторов. Выявляют опасные конструкции прямо в процессе написания кода. Легко интегрировать в проект.
- ESLint — основной линтер для JS/TS:
eslint-plugin-node— помогает проверить корректное использование Node.js API;eslint-plugin-security— выявляет конструкции вродеeval, небезопасного использованияchild_process.execи т.п.;eslint-plugin-no-secrets— ищет возможные секреты в коде (пароли, ключи).
Проверка зависимостей
Большинство уязвимостей в — в npm-пакетах, поэтому нужны такие инструменты:
- npm audit — встроенный инструмент npm, проверяет зависимости на известные уявзимости.
- yarn audit — аналог для Yarn.
- Snyk — SaaS-инструмент. Проверяет зависимости и Docker-образы. Умеет предлагать фиксы (обновления).
- OWASP Dependency-Check — можно интегрировать в CI/CD.
Никто не отменял ваш зоркий глаз…
Прежде чем установить зависимость, подумайте, а надо ли оно вам вообще. Хорошая практика — не раздувать зависимости проекта, так как это бьет по перфомансу и увеличивает шанс получить уязвимость.
Если же вы решили установить библиотеку, пробейте ее по известным базам уявзимостей:
GitHubGitHub Advisory Database
GitHub Advisory Database
A database of software vulnerabilities, using data from maintainer-submitted advisories and from other vulnerability databases.
GitHub
OSV - Open Source VulnerabilitiesOSV - Open Source Vulnerabilities
Comprehensive vulnerability database for your open source projects and dependencies.
Cтатический анализ кода (SAST)
Cтатические анализаторы кода, анализируют последний на уязвимости, баги и code smells. Считайте линтер для уязвимостей.
- NodeJsScan — статический анализатор безопасности именно для Node.js приложений.
Динамический и интерактивный анализ (DAST)
Инструменты, которые проверяют приложение в рабочем состоянии, не требует доступа к исходникам. Цель — выявить уязвимости при выполнении.
Проверка секретов и конфигов
Статические анализаторы, находящие специфичные проблемы. Чаще всего — анализ конфигов, чтобы не утекли секреты/пароли/явки.
- git-secrets — сканер коммитов, ищет секреты в git-истории.
- trufflehog — сканирует репозиторий на наличие ключей/паролей.
- dotenv-linter — проверка
.envфайлов.
Если пишете в проекте тесты, не забудьте добавить тестовые файлы в игнор для проверки. Частый кейс, когда используется фейковый пароль или секрет в тесте, а сканером это воспринимается как утечка.
Встроенные возможности в CI/CD инструменты
- GitHub Actions:
- codeql
- GitLab CI:
- SAST
- DAST
- Dependency Scanning
- Secret Detection
⚖️ Компромиссы
✅ Плюсы | ❌ Минусы |
Автоматизация снижает риск человеческого фактора, предотвращает релиз потенциальных уязвимостей | Может быть много false positives срабатываний
|
ㅤ | Некоторые инструменты дорогие (Snyk, Burp Suite Pro) |
ㅤ | Интеграция в CI/CD замедляет pipeline |
🔎 Встречные вопросы
- Как встроить security-проверки так, чтобы они не замедляли разработку?
- Какие уязвимости линтеры не смогут найти, но найдёт DAST?
🚩 Красные флаги
- Достаточно ESLint, больше ничего не нужно.
- Просто npm audit — и всё покрыто.
- Безопасность = задача DevOps, разработчик не должен думать
🛠 Практика
TODO