Вообще ожидаемо увидеть качественные результаты на затертом до дыр dvja Все знают этот проект и все тестируют любые инструменты на нем Поэтому доверие за счет возможности что-то докрутить со стороны вендора под кейс сильно снижается В реальности на закрытом проекте любой из перечисленных SAST ведет себя достаточно плохо и упускает жуткие тривиальные уязвимости....
Какой-то полный бред в статье.
Основной аргумент, почему нельзя обновляться через RUN apt-get upgrade и dist-upgrade — это как раз то, что вместе с обновлениями прилетают CVE. Соответственно, сначала нужно проверять пакеты/образы, а только потом их ставить. Далеко не все вендоры выпускают fix в тот же день, когда появляется информация о 0-day, 1-day или уязвимость обретает идентификатор, поэтому с очередным upgrade может запросто прилететь дыра, о которой можно было бы узнать предварительно просканировав.
Автор дает аргументу 3-ий номер и подписывает — «действительно притянуто», «большинству из вас не нужно». Больше реальных фактов против этого нет. Да, это сложно, но это единственный реальный способ получить прозрачную картину о том, что у вас крутится в образе.
Я бы еще добавил один аргумент — " Необходимость прозрачности". Во многих организациях принято вести SBOM (Software Bill of Materials), то есть перечень всех установленных пакетов в xml. Это может понадобится внешнему подрядчику, чтобы передать заказчику, а он в свою очередь проверил, что уязвимостей ни в одном пакете нет. С помощью SBOM можно также быстро выяснить, какие компоненты в системе попали под аффект из-за какой-нибудь новой уязвимости широко распространенной библиотеки, чтобы быстро выпустить компенсирующие меры. Как это делать с upgrade тоже неясно.
Интересная подборка
Можно было бы сделать большую по разным сферам в ИБ
На crunchbase.com очень много любопытных стартапов по безопасности
Тот же nightfall.ai ( Cloud Native DLP с AI по подписке), Perimeter 81 (Network-as-a-service) и так далее
По поводу AppSec.Hub в этой статье я также немного коснулся нашего инструмента.
Мы в своих практиках используем коммерческое решение собственной разработки AppSec.Hub, которое помимо управления уязвимостями, умеет также создавать и экспортировать готовые DevSecOps-пайплайны в CI/CD системы.
Сейчас он активно развивается, продается и используется у наших заказчиков. Мы хотели отдельно написать статью по управлению уязвимостями и немного больше рассказать про оркестрацию и AppSec.Hub.
Спасибо за отзыв! Сейчас у нас в планах разобрать инструменты SAST, DAST, Vulnerability management детально в отдельных статьях. Учтем также ваши пожелания по threat modeling.
Вообще ожидаемо увидеть качественные результаты на затертом до дыр dvja
Все знают этот проект и все тестируют любые инструменты на нем
Поэтому доверие за счет возможности что-то докрутить со стороны вендора под кейс сильно снижается
В реальности на закрытом проекте любой из перечисленных SAST ведет себя достаточно плохо и упускает жуткие тривиальные уязвимости....
SonarQube не делает taint-анализ, поэтому полноценным SAST по сути не является....
Основной аргумент, почему нельзя обновляться через RUN apt-get upgrade и dist-upgrade — это как раз то, что вместе с обновлениями прилетают CVE. Соответственно, сначала нужно проверять пакеты/образы, а только потом их ставить. Далеко не все вендоры выпускают fix в тот же день, когда появляется информация о 0-day, 1-day или уязвимость обретает идентификатор, поэтому с очередным upgrade может запросто прилететь дыра, о которой можно было бы узнать предварительно просканировав.
Автор дает аргументу 3-ий номер и подписывает — «действительно притянуто», «большинству из вас не нужно». Больше реальных фактов против этого нет. Да, это сложно, но это единственный реальный способ получить прозрачную картину о том, что у вас крутится в образе.
Я бы еще добавил один аргумент — " Необходимость прозрачности". Во многих организациях принято вести SBOM (Software Bill of Materials), то есть перечень всех установленных пакетов в xml. Это может понадобится внешнему подрядчику, чтобы передать заказчику, а он в свою очередь проверил, что уязвимостей ни в одном пакете нет. С помощью SBOM можно также быстро выяснить, какие компоненты в системе попали под аффект из-за какой-нибудь новой уязвимости широко распространенной библиотеки, чтобы быстро выпустить компенсирующие меры. Как это делать с upgrade тоже неясно.
Можно было бы сделать большую по разным сферам в ИБ
На crunchbase.com очень много любопытных стартапов по безопасности
Тот же nightfall.ai ( Cloud Native DLP с AI по подписке), Perimeter 81 (Network-as-a-service) и так далее
По поводу AppSec.Hub в этой статье я также немного коснулся нашего инструмента.
Сейчас он активно развивается, продается и используется у наших заказчиков. Мы хотели отдельно написать статью по управлению уязвимостями и немного больше рассказать про оркестрацию и AppSec.Hub.