В современной реальности из-за возрастающей роли контейнеризации в процессах разработки не на последнем месте стоит вопрос обеспечения безопасности различных этапов и сущностей, связанных с контейнерами. Осуществление проверок в ручном режиме является трудоёмким занятием, поэтому было бы неплохо сделать хотя бы начальные шаги к автоматизации этого процесса.
В этой статье я поделюсь готовыми скриптами для внедрения нескольких утилит обеспечения безопасности Docker и инструкцией, как развернуть небольшой демо-стенд для проверки этого процесса. Материалами можно воспользоваться, чтобы поэкспериментировать с тем, как организовать процесс тестирования безопасности образов и инструкций Dockerfile. Понятно, что инфраструктура разработки и внедрения у всех разные, поэтому ниже я приведу несколько возможных вариантов.
В своей работе наша компания очень часто имеет дело с различными инструментами статического анализа кода (SAST). Из коробки они все работают средне. Конечно, всё зависит от проекта и используемых в нём технологий, а также, насколько хорошо эти технологии покрываются правилами анализа. На мой взгляд, одним из самых главных критериев при выборе инструмента SAST является возможность настраивать его под особенности своих приложений, а именно писать и изменять правила анализа или, как их чаще называют, Custom Queries.
Мы чаще всего используем Checkmarx - очень интересный и мощный анализатор кода. В этой статье я расскажу про свой опыт написания правил анализа для него.
Привет, Хабр! Я консультант по информационной безопасности в Swordfish Security по части выстраивания безопасного DevOps для наших заказчиков. Я слежу за тем, как развивается тенденция развития компаний в сторону DevSecOps в мире, пытаюсь транслировать самые интересные практики в русскоговорящее сообщество и помогаю выстраивать этот процесс с нашей командой у заказчиков. За последние 2 года тема DevSecOps стала привлекать все больше внимания. Новые инструменты не успевают стать частью быстро растущего набора практик, из-за чего у меня появилось желание поставить некоторую контрольную точку в виде списка инструментов. Отправной точкой стал выход статьи коллег из Mail.ru, где отдельно был выделен раздел по безопасности Kubernetes. Я решил расширить этот список, охватив другие этапы жизненного цикла SDLC и приведя пару новых инструментов.
Значимость анализа сторонних компонентов ПО (англ. Software Composition Analysis — SCA) в процессе разработки растет по мере выхода ежегодных отчетов об уязвимостях open source библиотек, которые публикуются компаниями Synopsys, Sonatype, Snyk, White Source. Согласно отчету The State of Open Source Security Vulnerabilities 2020 число выявленных уязвимостей в open source в 2019 выросло почти в 1.5 раза в сравнении с предыдущим годом, в то время как компоненты с открытым кодом используются от 60% до 80% проектов. Если обратиться к независимому мнению, то процессы SCA являются отдельной практикой OWASP SAMM и BSIMM в качестве показателя зрелости, а в первой половине 2020 года OWASP выпустила новый стандарт OWASP Software Component Verification Standard (SCVS), предоставляющий лучшие практики по проверке сторонних компонент в цепочке поставок ПО.