Code Review Hotspots with Semgrep
Автор сегодняшней статьи предлагает поделить сработки на две группы -
Интереснее не сами баги, которые здесь подсвечиваются, а подход в разделении ответственности. Какие правила считать достаточно надежными, чтобы их сработки асайнить сразу на разраба, а не на ИБ?
В теории можно обратиться к последнему отчету Veracode - State of Software Security v12. В отчете приводится разного рода интересная статистика в контексте сканеров класса SAST/DAST/SCA. В частности, здесь есть перечень CWE, которые лучше всего находятся для того или иного класса сканера (картинка приложена к посту выше). Любопытно, что Cryptographic Issues и Credentials Management относятся к категории уязвимостей, которые гораздо чаще находятся именно SAST'ами, в то время как в вышеупомянутой статье они относятся к хотспотам. Что же делать?
Здесь позволю себе высказать собственное мнение, как мы делим сработки на
#dev #sast
Автор сегодняшней статьи предлагает поделить сработки на две группы -
security
и hotspots
. Сработки группы security
имеют низкий уровень ложных срабатываний и предназначаются для разработчиков, в то время как сработки группы hotspots
только свидетельствуют о подрзрении на уязвимость и попадают под ответственность security-инженеров. Вся статья дальше вращается вокруг хотспотов и способов их поиска через инструмент semgrep. К хотспотам относят hardoced secrets, небезопасную криптографию, мисконфиги, переполнения буфера и тд.Интереснее не сами баги, которые здесь подсвечиваются, а подход в разделении ответственности. Какие правила считать достаточно надежными, чтобы их сработки асайнить сразу на разраба, а не на ИБ?
В теории можно обратиться к последнему отчету Veracode - State of Software Security v12. В отчете приводится разного рода интересная статистика в контексте сканеров класса SAST/DAST/SCA. В частности, здесь есть перечень CWE, которые лучше всего находятся для того или иного класса сканера (картинка приложена к посту выше). Любопытно, что Cryptographic Issues и Credentials Management относятся к категории уязвимостей, которые гораздо чаще находятся именно SAST'ами, в то время как в вышеупомянутой статье они относятся к хотспотам. Что же делать?
Здесь позволю себе высказать собственное мнение, как мы делим сработки на
security
и hotspots
в Альфе. Для многих оно покажется очевидным. Чем больше уязвимость поддается паттернам, а не механизмам data flow, тем лучше она будет находиться через SAST и тем более уверены вы в ней будете. Сюда относятся hardocded credentials, небезопасный CORS, мисконфиги (в т.ч. Docker / Kubernetes) и другие уязвимости, которые можно допустить, указав в коде непрерывный набор строк кода. SQL-инъекции, XSS, SSRF и прочие уязвимости, подразумевающие прием данных от пользователя через request-объекты имеют свойства приобретать сложную логику развития, а значит и более высокую степень FP/FN. Нередко, влияние на правила нахождения таких уязвимостей в контексте data flow стоит вам от 3 непрерывных месяцев работы в codeql/checkmarx в соусе из перегоревших appsec'ов. В это же время паттерновые уязвимости довольно легко корректируются с помощью того же semgrep. #dev #sast
Securing Developer Tools: Package Managers
Случались ли у вас ситуации, когда антивирусный агент начинает генерировать алерты о вредоносной активности будучи установленным на сборщике? Вероятно, вы столкнулись с вредоносами, описанными в этой статьей - "Securing Developer Tools: Package Managers". Речь пойдет о вредоносных пакетах, запускаемых с помощью Composer, Bundler, Bower, Yarn и других пакетных менеджерах. Приведены также разные меры по митигации.
В Golang, кстати, часть проблем supply chain попытались решить архитектурно. Начиная c того, что сборщики не могут ничего поставить за пределами зафиксированных хэшей в
#dev
Случались ли у вас ситуации, когда антивирусный агент начинает генерировать алерты о вредоносной активности будучи установленным на сборщике? Вероятно, вы столкнулись с вредоносами, описанными в этой статьей - "Securing Developer Tools: Package Managers". Речь пойдет о вредоносных пакетах, запускаемых с помощью Composer, Bundler, Bower, Yarn и других пакетных менеджерах. Приведены также разные меры по митигации.
В Golang, кстати, часть проблем supply chain попытались решить архитектурно. Начиная c того, что сборщики не могут ничего поставить за пределами зафиксированных хэшей в
go.sum
и заканчивая невозможностью запускать код во время сборки. Об этой подробнее в статье "How Go Mitigates Supply Chain Attacks".#dev
Sonarsource
Securing Developer Tools: Package Managers
Yarn, Pip, Composer & friends: Learn about 3 types of vulnerabilities we found in popular package managers that can be used by attackers to target developers.
Уязвимость в репозитории NPM, позволяющая добавить сопровождающего без подтверждения
“В репозитории пакетов NPM выявлена проблема с безопасностью, позволяющая владельцу пакета добавить в число сопровождающих любого пользователя, без получения от этого пользователя согласия и без информирования о совершённом действии. Проблема усугубляется тем, что после добавления стороннего пользователя в число сопровождающих, изначальный автор пакета мог удалить себя из списка сопровождающих и сторонний пользователь оставался единственным лицом, отвечающим за пакет.
Проблемой могли воспользоваться создатели вредоносных пакетов для добавления в число сопровождающих известных разработчиков или крупных компаний с целью повышения доверия пользователей и создания иллюзии, что заслуженные разработчики отвечают за пакет, хотя на деле не имеют к нему никакого отношения и даже не знают о его существовании. Например, атакующий мог разместить вредоносный пакет, сменить сопровождающего и пригласить пользователей протестировать новую разработку крупной компании. Уязвимость также могла применяться для очернения репутации определённых разработчиков, представляя их как инициаторов сомнительных акций и вредоносных действий.”
https://opennet.ru/57108/
#dev #news
“В репозитории пакетов NPM выявлена проблема с безопасностью, позволяющая владельцу пакета добавить в число сопровождающих любого пользователя, без получения от этого пользователя согласия и без информирования о совершённом действии. Проблема усугубляется тем, что после добавления стороннего пользователя в число сопровождающих, изначальный автор пакета мог удалить себя из списка сопровождающих и сторонний пользователь оставался единственным лицом, отвечающим за пакет.
Проблемой могли воспользоваться создатели вредоносных пакетов для добавления в число сопровождающих известных разработчиков или крупных компаний с целью повышения доверия пользователей и создания иллюзии, что заслуженные разработчики отвечают за пакет, хотя на деле не имеют к нему никакого отношения и даже не знают о его существовании. Например, атакующий мог разместить вредоносный пакет, сменить сопровождающего и пригласить пользователей протестировать новую разработку крупной компании. Уязвимость также могла применяться для очернения репутации определённых разработчиков, представляя их как инициаторов сомнительных акций и вредоносных действий.”
https://opennet.ru/57108/
#dev #news
CI/CD Security - то, без чего DevSecOps не имеет смысла
13 и 14 июня 2022 года в Кампусе Сколково пройдет конференция DevOps Conf & TechLead Conf 2022, где я буду выступать с докладом "CI/CD Security - то, без чего DevSecOps не имеет смысла". Поговорим про безопасность пайплайнов: мисконфигурации CI/CD, небезопасная среда разработки и непроработанная модель угроз для внутренних разработчиков и администраторов. Почему все эти вещи, как итог, приводят к тому, что внедрение DevSecOps перестает нести в себе ценность. Расскажу про наш опыт в Альфа-Банке и постараюсь разобраться, что надо сделать, чтобы занять золотую середину между паранойей и удобством разработки.
#talks
13 и 14 июня 2022 года в Кампусе Сколково пройдет конференция DevOps Conf & TechLead Conf 2022, где я буду выступать с докладом "CI/CD Security - то, без чего DevSecOps не имеет смысла". Поговорим про безопасность пайплайнов: мисконфигурации CI/CD, небезопасная среда разработки и непроработанная модель угроз для внутренних разработчиков и администраторов. Почему все эти вещи, как итог, приводят к тому, что внедрение DevSecOps перестает нести в себе ценность. Расскажу про наш опыт в Альфа-Банке и постараюсь разобраться, что надо сделать, чтобы занять золотую середину между паранойей и удобством разработки.
#talks
Наиболее распространенные уязвимости в мобильных приложениях
Вы могли заметить, что я почти не пишу ничего про безопасность мобильных приложений (и вы окажетесь правы), но сегодня я хочу сделать исключение.
Открываем короткую неделю со статьи "Наиболее распространенные уязвимости в мобильных приложениях". Это авторский список уязвимостей на основе опыта их нахождения собственным инструментом динамического анализа мобильных приложений. Здесь есть и примеры небезопасного кода и варианты митигации. Как сам автор пишет, они мало чем отличаются от OWASP, даже не смотря на то, что последняя версия Mobile Top 10 вышла в далеком 2016 году.
#dev #mobile
Вы могли заметить, что я почти не пишу ничего про безопасность мобильных приложений (и вы окажетесь правы), но сегодня я хочу сделать исключение.
Открываем короткую неделю со статьи "Наиболее распространенные уязвимости в мобильных приложениях". Это авторский список уязвимостей на основе опыта их нахождения собственным инструментом динамического анализа мобильных приложений. Здесь есть и примеры небезопасного кода и варианты митигации. Как сам автор пишет, они мало чем отличаются от OWASP, даже не смотря на то, что последняя версия Mobile Top 10 вышла в далеком 2016 году.
#dev #mobile
CIS_SSC.pdf
642.9 KB
DevSecOps Wine
CI/CD Security - то, без чего DevSecOps не имеет смысла 13 и 14 июня 2022 года в Кампусе Сколково пройдет конференция DevOps Conf & TechLead Conf 2022, где я буду выступать с докладом "CI/CD Security - то, без чего DevSecOps не имеет смысла". Поговорим про…
CI/CD Security — то, без чего DevSecOps не имеет смысла
Спустя год после выступления вышла запись моего доклада с DevOps Conf 2022 про безопасность CI/CD. За год, конечно, тема набрала еще больше популярности, из-за чего многие упомянутые тезисы стали терять смысл освщеения, но я все же осмелюсь опубликовать.
CI/CD Security — то, без чего DevSecOps не имеет смысл
Кстати, также советую посмотреть два других достойных доклада на тему безопасности:
- SOAR в Kubernetes малой кровью
- Современная безопасность контейнерных приложений
#cicd
Спустя год после выступления вышла запись моего доклада с DevOps Conf 2022 про безопасность CI/CD. За год, конечно, тема набрала еще больше популярности, из-за чего многие упомянутые тезисы стали терять смысл освщеения, но я все же осмелюсь опубликовать.
CI/CD Security — то, без чего DevSecOps не имеет смысл
Кстати, также советую посмотреть два других достойных доклада на тему безопасности:
- SOAR в Kubernetes малой кровью
- Современная безопасность контейнерных приложений
#cicd
YouTube
CI/CD Security — то, без чего DevSecOps не имеет смысла / Денис Якимов (Альфа-Банк)
Приглашаем на DevOpsConf 2024, которая пройдет 4 и 5 марта 2024 в Москве. Программа, подробности и билеты по ссылке: https://devopsconf.io/moscow/2024
---------
Объединенная конференция DevOpsConf и TechLead Conf
13 и 14 июня 2022
Тезисы и презентация:…
---------
Объединенная конференция DevOpsConf и TechLead Conf
13 и 14 июня 2022
Тезисы и презентация:…
Что не так с ASVS?
Мой небольшой пост в Linkedin про неправильное использование ASVS и его недостатки для неподготовленного читателя, а именно: перегруженность, большое число заимствований и оторванность от риск-ориентированного подхода. Последнее подразумевает то, что оценка на несоответствие ASVS по сути не означает, что ваша система небезопасна. Она означает несоответствие лучшим практикам, которые, на самом деле, не всегда применимы к вашему приложению и имеют смысл для инвестирования ресурсов. Тем не менее, все еще есть мнение, что ASVS это ready-to-use стандарт, требующий минимум кастомизации. В комментариях, кстати, контрибьютеры ASVS озвучили свои мысли по этому вопросу. Кроме того, оттуда же я узнал об очень классном портале OpenCRE, где агрегированы требования из разных стандартов.
Используете ли вы ASVS в своей организации и как?
P.S. Текст продублирован в комментариях
Мой небольшой пост в Linkedin про неправильное использование ASVS и его недостатки для неподготовленного читателя, а именно: перегруженность, большое число заимствований и оторванность от риск-ориентированного подхода. Последнее подразумевает то, что оценка на несоответствие ASVS по сути не означает, что ваша система небезопасна. Она означает несоответствие лучшим практикам, которые, на самом деле, не всегда применимы к вашему приложению и имеют смысл для инвестирования ресурсов. Тем не менее, все еще есть мнение, что ASVS это ready-to-use стандарт, требующий минимум кастомизации. В комментариях, кстати, контрибьютеры ASVS озвучили свои мысли по этому вопросу. Кроме того, оттуда же я узнал об очень классном портале OpenCRE, где агрегированы требования из разных стандартов.
Используете ли вы ASVS в своей организации и как?
P.S. Текст продублирован в комментариях
Linkedin
Sign Up | LinkedIn
500 million+ members | Manage your professional identity. Build and engage with your professional network. Access knowledge, insights and opportunities.
How Secrets Leak in CI/CD Pipelines
Truffle Security, небезызвестные своими способностями отлавливать секреты, решили осветить вопросы их утечки в пайпланах:
https://trufflesecurity.com/blog/secrets-leak-in-ci-cd/
Тема поднималась уже не раз, но давайте систематизируем затронутые сценарии:
1. Раскрытие секретов в логах CI/CD. Сценарии, когда из-за особенностей синтаксиса заданий платформы CI/CD, хранения секретов в формате JSON или использования кодировок в духе base-64 секреты "проходят мимо" систем маскирования и становятся доступными в лог-файлах CI/CD после отработки соответствующих заданий;
2. Утечка секретов второго порядка. Сценарии, когда "утекают" секреты используемые для доступа к зашифрованным файлам репозиториев или к API хранилищ секретов (Hashicorp Vault, etc.);
3. Публикация артефактов в публичных репозиториях. Сценарии, когда ошибочно допущенная команда (например,
Как защититься от этих сценариев?
Помимо стандартных рекомендаций и следований принципам "наименьших привилегий" и "уменьшения поверхности атаки" вот кое-что еще :
1. Один из вариантов, предлагаемых Truffle Security, это натравить truflehog на логи CI/CD (в частности в Circle CI)
2. Использовать стандартные workflow вместо кастомных. Например, автор приводит в пример CircleCI "orbs", pre-built задания, которые из коробки безопасно работают с секретами. Подобное есть и у GitHub Actions.
Если вы хотите потренироваться и разобрать в том числе другие сценарии, то можно использовать специальные обучающие инструменты для освоения материала. Например, проект OWASP WorngSecrets, который предлагает 35 упражнений, снабженных подсказками и ликбезами по разным сценариям безопасной работы с секретами (включая K8s и облачных провайдеров). WrongSecrets отлично дополнит программы повышения осведомленности разработчиков, локальные CTF и поможет выращиванию security champions. WrongSecrets может быть запущен как локально в docker, так и онлайн - на платформах herokuapp.com и fly.dev .
#Dev #Ops #Secrets
Truffle Security, небезызвестные своими способностями отлавливать секреты, решили осветить вопросы их утечки в пайпланах:
https://trufflesecurity.com/blog/secrets-leak-in-ci-cd/
Тема поднималась уже не раз, но давайте систематизируем затронутые сценарии:
1. Раскрытие секретов в логах CI/CD. Сценарии, когда из-за особенностей синтаксиса заданий платформы CI/CD, хранения секретов в формате JSON или использования кодировок в духе base-64 секреты "проходят мимо" систем маскирования и становятся доступными в лог-файлах CI/CD после отработки соответствующих заданий;
2. Утечка секретов второго порядка. Сценарии, когда "утекают" секреты используемые для доступа к зашифрованным файлам репозиториев или к API хранилищ секретов (Hashicorp Vault, etc.);
3. Публикация артефактов в публичных репозиториях. Сценарии, когда ошибочно допущенная команда (например,
npm publish
) публикует в репозитории файл конфигурации с секретами в открытом виде.Как защититься от этих сценариев?
Помимо стандартных рекомендаций и следований принципам "наименьших привилегий" и "уменьшения поверхности атаки" вот кое-что еще :
1. Один из вариантов, предлагаемых Truffle Security, это натравить truflehog на логи CI/CD (в частности в Circle CI)
2. Использовать стандартные workflow вместо кастомных. Например, автор приводит в пример CircleCI "orbs", pre-built задания, которые из коробки безопасно работают с секретами. Подобное есть и у GitHub Actions.
Если вы хотите потренироваться и разобрать в том числе другие сценарии, то можно использовать специальные обучающие инструменты для освоения материала. Например, проект OWASP WorngSecrets, который предлагает 35 упражнений, снабженных подсказками и ликбезами по разным сценариям безопасной работы с секретами (включая K8s и облачных провайдеров). WrongSecrets отлично дополнит программы повышения осведомленности разработчиков, локальные CTF и поможет выращиванию security champions. WrongSecrets может быть запущен как локально в docker, так и онлайн - на платформах herokuapp.com и fly.dev .
#Dev #Ops #Secrets
Про стандартизацию ФСТЭК и сертификацию процессов безопасной разработки
Помните один из первых постов этого канала? https://www.tg-me.com/sec_devops/20 Отечественная стандартизация безопасной разработки продолжает набирать обороты. В пятницу ФСТЭК России опубликовал на regulation.gov Порядок сертификации процессов безопасной разработки программного обеспечения средств защиты информации :
https://regulation.gov.ru/Regulation/Npa/PublicView?npaID=143132
Главная идея, стоящая за проектом проста. Примирить требования регуляторики и Agile. Позволить разработчикам не отправлять каждый релиз на согласование в испытательную лабораторию, а доказав надежность своей CI/CD и пройдя её сертификацию, утверждать - что все продукты этой сертифицированной CI/CD заслуживают доверия.
Цитата из пояснительной записки к проекту:
"Сертификация процессов безопасной разработки программного обеспечения средств защиты информации является добровольной и позволит разработчикам и производителям сертифицированных средств защиты информации в случае проведения данной сертификации проводить испытания средств защиты информации, обусловленные внесением изменений в программное обеспечение средства защиты информации, самостоятельно без привлечения испытательной лаборатории. Что позволит сократить сроки проведения испытаний и затраты разработчиков и производителей сертифицированных средств защиты информации на проведение указанных испытаний средств защиты информации и, как следствие, снизить себестоимость средств защиты информации, применяемых в государственных информационных системах и на объектах критической информационной инфраструктуры."
Какое это имеет отношение к широкому рынку? Очень простое. Несмотря на определенные в документе границы (сертификация средств защиты), аналогичные подходы могут быть спроецированы и на обычные приложения. На компании не являющиеся разработчиками антивирусов, межсетевых экранов и иных специализированных средств.
В частности с февраля 2022 года Банк России в последней редакции своего Профиля защиты*, в разделе 7.4 рассказывает о требованиях к безопасности жизненного цикла. По мнению регулятора (оставим за скобками ряд правовых и технических нюансов) это позволяет избежать оценок соответствия или сертификации каждого релиза ДБО, т.е. по целям является аналогичным проекту ФСТЭК:
https://www.cbr.ru/content/document/file/132666/inf_note_feb_0422.pdf
*Профиль защиты является де-факто стандартом требований регулятора к банковским ДБО, личным кабинетам финансовых организаций, другим приложениям, связанным с финансовыми операциями (не являющимися средствами защиты по ФСТЭК России).
#dev #ops #law
Помните один из первых постов этого канала? https://www.tg-me.com/sec_devops/20 Отечественная стандартизация безопасной разработки продолжает набирать обороты. В пятницу ФСТЭК России опубликовал на regulation.gov Порядок сертификации процессов безопасной разработки программного обеспечения средств защиты информации :
https://regulation.gov.ru/Regulation/Npa/PublicView?npaID=143132
Главная идея, стоящая за проектом проста. Примирить требования регуляторики и Agile. Позволить разработчикам не отправлять каждый релиз на согласование в испытательную лабораторию, а доказав надежность своей CI/CD и пройдя её сертификацию, утверждать - что все продукты этой сертифицированной CI/CD заслуживают доверия.
Цитата из пояснительной записки к проекту:
"Сертификация процессов безопасной разработки программного обеспечения средств защиты информации является добровольной и позволит разработчикам и производителям сертифицированных средств защиты информации в случае проведения данной сертификации проводить испытания средств защиты информации, обусловленные внесением изменений в программное обеспечение средства защиты информации, самостоятельно без привлечения испытательной лаборатории. Что позволит сократить сроки проведения испытаний и затраты разработчиков и производителей сертифицированных средств защиты информации на проведение указанных испытаний средств защиты информации и, как следствие, снизить себестоимость средств защиты информации, применяемых в государственных информационных системах и на объектах критической информационной инфраструктуры."
Какое это имеет отношение к широкому рынку? Очень простое. Несмотря на определенные в документе границы (сертификация средств защиты), аналогичные подходы могут быть спроецированы и на обычные приложения. На компании не являющиеся разработчиками антивирусов, межсетевых экранов и иных специализированных средств.
В частности с февраля 2022 года Банк России в последней редакции своего Профиля защиты*, в разделе 7.4 рассказывает о требованиях к безопасности жизненного цикла. По мнению регулятора (оставим за скобками ряд правовых и технических нюансов) это позволяет избежать оценок соответствия или сертификации каждого релиза ДБО, т.е. по целям является аналогичным проекту ФСТЭК:
https://www.cbr.ru/content/document/file/132666/inf_note_feb_0422.pdf
*Профиль защиты является де-факто стандартом требований регулятора к банковским ДБО, личным кабинетам финансовых организаций, другим приложениям, связанным с финансовыми операциями (не являющимися средствами защиты по ФСТЭК России).
#dev #ops #law
Telegram
DevSecOps Wine
Про стандарты безопасной разработки ФСТЭК
01.11.19 прошло совещание во ФСТЭК касательно обсуждения безопасной разработки
Выделен отдельный программный комитет ПК4 по безопасной разработке в составе ТК362.
Обсуждался проект стандарта "Руководство по безопасной…
01.11.19 прошло совещание во ФСТЭК касательно обсуждения безопасной разработки
Выделен отдельный программный комитет ПК4 по безопасной разработке в составе ТК362.
Обсуждался проект стандарта "Руководство по безопасной…
Опрос в догонку поста: вам актуальна регуляторика и стандарты Российской Федерации в области DevSecOps и AppSec?
Anonymous Poll
52%
Да, актуальна, пишите об этом периодически;
15%
Нет, актуальны только международные требования и практики;
15%
Нет, вообще не интересны "бумажки", даёшь технические посты;
1%
Особое мнение (дать комментарий, что интересно);
17%
Посмотреть статистику.
#Конференция #CoopDays
Прямо сейчас в прямом эфире третья конференция Coop-Days. В программе доклады посвящённые не только AppSec и DevSecOps, но и выступления на темы построения карьеры в ИБ, процессного управления и перспектив развития искусственного интеллекта.
Прямая трансляции доступна по ссылке: https://youtu.be/E2__QfNtwwI (будет доступна в записи).
Программа конференции в сообщении ниже.
Прямо сейчас в прямом эфире третья конференция Coop-Days. В программе доклады посвящённые не только AppSec и DevSecOps, но и выступления на темы построения карьеры в ИБ, процессного управления и перспектив развития искусственного интеллекта.
Прямая трансляции доступна по ссылке: https://youtu.be/E2__QfNtwwI (будет доступна в записи).
Программа конференции в сообщении ниже.
YouTube
Конференция "Сoop-Days 2023" // День информационных технологий и безопасности
5 ноября, 11:00 – 18:00, Конференция «Сoop-Days 2023», День информационных технологий и безопасности, при информационной и технической поддержке центра «Архэ». Подробности здесь - https://arhe.msk.ru/coop-days/2023
Конференция Coop-Days 2023 посвящена двум…
Конференция Coop-Days 2023 посвящена двум…
В эти дни проходит конференция Coop-Days 2023, организованная компанией «РАД КОП». Сегодня в повестке доклады по ИТ и ИБ.
Ознакомиться с программой и посмотреть трансляцию можно по ссылке на сайте культурно-просветительского центра АРХЭ.
Докладчики уже выступают, присоединяйтесь, будет интересно!
Ознакомиться с программой и посмотреть трансляцию можно по ссылке на сайте культурно-просветительского центра АРХЭ.
Докладчики уже выступают, присоединяйтесь, будет интересно!
Трансформирует ли AI работу AppSec и DevSecOps?
В непрерывном потоке новостей об очередных чудо-помощниках или подборках GPT-агентов можно не заметить самой важной проблемы, связанной с AI. Изначально проблематика DevSecOps и современного AppSec, встроенного в CI/CD, возникла из условий рыночной гонки компаний за клиентами. Когда перед организациями встала необходимость быстрее адаптировать приложения к потребностям пользователей и бороться за их внимание и деньги. Ускорять изменения. Обеспечивать сверхбыстрое масштабирование проектов без потери надежности. Это в свою очередь породило потребности в новых инструментах и подходах к работе. Распространились контейнеры и их оркестраторы, набрали популярность low-code платформы и облачные сервисы.
Но все это развивается столь стремительно, что количество накапливающихся ошибок и проблем непрерывно возрастает. А все более сложная экосистема сервисов, инструментов, утилит, фреймворков, стеков технологий - порождают все большее количество сбоев, инцидентов, ошибок, необходимости интеграций, настроек и... дефицит кадров, способных разобраться в этом хаосе. В итоге наша дисциплина превращается в разновидность "алхимии". Когда дефицитные "жрецы безопасного кода" ценятся так сильно, что джуниор с полугодовым опытом работы вполне может претендовать на вакансию 150к netto с удаленкой из региона, а грамотные инженеры с стажем 5+ считаются "прожженными ветеранами" и ценятся как "крыло от боинга".
И это не досужие домыслы, а суровые факты действительности, подтверждаемые статистикой. Например, созданный в 2010 году Consortium for Information & Software Quality (CISQ) оценивает ущерб от некачественного кода и недостатков процессов разработки в 2022 году в 2,41 триллион долларов, а дефицит ИТ-кадров в 300 тысяч человек, и это только в США. Подробнее о результата исследования можно почитать здесь . Но очевидно, что если в развитых с точки зрения ИТ разработки США существуют такие проблемы, то аналогичная ситуация (или хуже) характерна для всего мира, особенно для развивающихся регионов вроде Африки*.
Казалось бы - отличные новости, и впереди много работы. Но тут на сцену выходит AI, который может оказаться фактором существенных и достаточно быстрых изменений в индустрии (буквально на горизонте 3-5 лет). Что-то похожее происходило с классическими веб-дизайнерами, очень востребованными в конце нулевых, но существенно утратившими позиции после появления различных конструкторов а-ля Figma. Или консервативными сисадминами, оттесняемыми на периферию облачными технологиями и виртуализацией. Конечно, это не означает, что веб-дизайнеры или сисадмины "вымерли". Среди них существуют отдельные супер-востребованные гуру, у которых все хорошо. Остаются и середняки. Просто меняется уровень востребованности и падают заработные платы.
И если мы смотрим на такие массовые тренды, то должны задуматься о том, а что будет дальше? Каким инструментарием необходимо овладеть, чтобы быть востребованным и соответствовать актуальному уровню компетенций? И тут нейронные сети с различными специализациями, интегрированные в единое целое с помощью специальных оболочек, позволяющих использовать предустановленные промпты - кажется являются следующей вехой развития индустрии. Они не только помогают автоматизировать типовые задачи, и оказываются встроенными крупными корпорациями в свои сервисы и инструменты "из коробки". Но и снимают существенную часть аналитической нагрузки с опытных специалистов. Заменяя как отдельные роли и направления работы, так и толковых джунов, быстрее и точнее собирая необходимую информацию. Автоматизируя рутинные и хорошо стандартизуемые операции.
В непрерывном потоке новостей об очередных чудо-помощниках или подборках GPT-агентов можно не заметить самой важной проблемы, связанной с AI. Изначально проблематика DevSecOps и современного AppSec, встроенного в CI/CD, возникла из условий рыночной гонки компаний за клиентами. Когда перед организациями встала необходимость быстрее адаптировать приложения к потребностям пользователей и бороться за их внимание и деньги. Ускорять изменения. Обеспечивать сверхбыстрое масштабирование проектов без потери надежности. Это в свою очередь породило потребности в новых инструментах и подходах к работе. Распространились контейнеры и их оркестраторы, набрали популярность low-code платформы и облачные сервисы.
Но все это развивается столь стремительно, что количество накапливающихся ошибок и проблем непрерывно возрастает. А все более сложная экосистема сервисов, инструментов, утилит, фреймворков, стеков технологий - порождают все большее количество сбоев, инцидентов, ошибок, необходимости интеграций, настроек и... дефицит кадров, способных разобраться в этом хаосе. В итоге наша дисциплина превращается в разновидность "алхимии". Когда дефицитные "жрецы безопасного кода" ценятся так сильно, что джуниор с полугодовым опытом работы вполне может претендовать на вакансию 150к netto с удаленкой из региона, а грамотные инженеры с стажем 5+ считаются "прожженными ветеранами" и ценятся как "крыло от боинга".
И это не досужие домыслы, а суровые факты действительности, подтверждаемые статистикой. Например, созданный в 2010 году Consortium for Information & Software Quality (CISQ) оценивает ущерб от некачественного кода и недостатков процессов разработки в 2022 году в 2,41 триллион долларов, а дефицит ИТ-кадров в 300 тысяч человек, и это только в США. Подробнее о результата исследования можно почитать здесь . Но очевидно, что если в развитых с точки зрения ИТ разработки США существуют такие проблемы, то аналогичная ситуация (или хуже) характерна для всего мира, особенно для развивающихся регионов вроде Африки*.
Казалось бы - отличные новости, и впереди много работы. Но тут на сцену выходит AI, который может оказаться фактором существенных и достаточно быстрых изменений в индустрии (буквально на горизонте 3-5 лет). Что-то похожее происходило с классическими веб-дизайнерами, очень востребованными в конце нулевых, но существенно утратившими позиции после появления различных конструкторов а-ля Figma. Или консервативными сисадминами, оттесняемыми на периферию облачными технологиями и виртуализацией. Конечно, это не означает, что веб-дизайнеры или сисадмины "вымерли". Среди них существуют отдельные супер-востребованные гуру, у которых все хорошо. Остаются и середняки. Просто меняется уровень востребованности и падают заработные платы.
И если мы смотрим на такие массовые тренды, то должны задуматься о том, а что будет дальше? Каким инструментарием необходимо овладеть, чтобы быть востребованным и соответствовать актуальному уровню компетенций? И тут нейронные сети с различными специализациями, интегрированные в единое целое с помощью специальных оболочек, позволяющих использовать предустановленные промпты - кажется являются следующей вехой развития индустрии. Они не только помогают автоматизировать типовые задачи, и оказываются встроенными крупными корпорациями в свои сервисы и инструменты "из коробки". Но и снимают существенную часть аналитической нагрузки с опытных специалистов. Заменяя как отдельные роли и направления работы, так и толковых джунов, быстрее и точнее собирая необходимую информацию. Автоматизируя рутинные и хорошо стандартизуемые операции.
Здесь очень характерно поведение Microsoft, который после покупки GitHub, начал интегрировать с ним все больше интересных инструментов, связанных с безопасностью разработки. Например, уже в декабре на базе GitHub должен открыться (если еще не открылся) чат с Copilot, который позволит в числе прочих фич следить за безопасностью создаваемого кода в режиме онлайн. А тут можно посмотреть демо от CEO Microsoft с возможностями Copilot в части интеграции с различными приложениями и внешними источниками данных, в рамках Office 365 и как это позволит автоматизировать самые разные задачи. И это один продукт, одной корпорации, не специализированной на кибербезопасности. Понятное дело, что Microsoft известен своими багами и что в любом случае адаптация к новым возможностям займет какое-то время. Но кажется для всех, кто хочет "держать хвост по ветру" наступает время готовиться к адаптации прямо сейчас. И для тех, кто любит неопределенность и риски открываются возможности по развитию собственных стартапов в новых нишах. Например, почти наверняка потребуются консультанты по обучению команд AppSec и DevSecOps использованию и внедрению нового инструментария, возникнет потребность в защите API агентов GPT, встанут вопросы дообучения и тюнинга моделей, появятся истории про доверие и конфиденциальность вводимых данных, станет накапливаться ещё больше чисто юридических кейсов относительно прав собственности на "выделяемый AI продукт", потребуются стандарты и фреймворки безопасности AI и т.д. и т.п.
И хотя футурология и прогнозы дело не благодарное** (во многом потому, что технологии не существуют в вакууме и многое зависит от сил, занимающихся их внедрением, и заинтересованности субъектов, которые используют эти технологии), кажется, что AI не будет пустым хайпом и в ближайшую декаду мы увидим существенную трансформацию профессии, к которой можно и нужно готовиться прямо сейчас. А что думаете вы?
*Подробнее о состоянии безопасности в развивающихся странах можно посмотреть в замечательном выступлении Евгения Соболева: https://youtu.be/XWSrDseKMaI?si=QStWhX4u3BfSNlUp
**Здесь "на каникулы" рекомендую годную книгу "ИИ-2041. Десять образов нашего будущего" Кай-Фу Ли и Чэнь Цюфань - достаточно взвешенная и многомерная аналитика от профильного специалиста на тему влияния AI на разные области жизни. Сама книга смесь сборника художественных рассказов и научно-популярных заметок к каждому из них, где рассматриваются в том числе аспекты кибербезопасности AI.
#dev #ops #ai #прогнозы
И хотя футурология и прогнозы дело не благодарное** (во многом потому, что технологии не существуют в вакууме и многое зависит от сил, занимающихся их внедрением, и заинтересованности субъектов, которые используют эти технологии), кажется, что AI не будет пустым хайпом и в ближайшую декаду мы увидим существенную трансформацию профессии, к которой можно и нужно готовиться прямо сейчас. А что думаете вы?
*Подробнее о состоянии безопасности в развивающихся странах можно посмотреть в замечательном выступлении Евгения Соболева: https://youtu.be/XWSrDseKMaI?si=QStWhX4u3BfSNlUp
**Здесь "на каникулы" рекомендую годную книгу "ИИ-2041. Десять образов нашего будущего" Кай-Фу Ли и Чэнь Цюфань - достаточно взвешенная и многомерная аналитика от профильного специалиста на тему влияния AI на разные области жизни. Сама книга смесь сборника художественных рассказов и научно-популярных заметок к каждому из них, где рассматриваются в том числе аспекты кибербезопасности AI.
#dev #ops #ai #прогнозы
State-of-SSPM-Report-2023.pdf
5.2 MB
SSPM и защита SaaS сервисов
В развитии вчерашнего лонгрида пример нового класса решений, ещё не сильно распространенного на рынке. SSPM призваны решать проблему контроля и безопасности интеграций компаний со все большим количеством облачных сервисов. Когда тот же самый GPT помощник, или онлайн-репозиторий не просто детектируется, но ставится на непрерывный контроль автоматически. Это подразумевает:
- правильную конфигурацию;
- выявление уязвимостей;
- мониторинг и реагирование на инциденты;
- контроль утечек защищаемой информации;
- управление привилегиями;
и многое другое
Подробнее про риски, подходы и модель работы с SaaS здорового человека можно почитать в прилагаемом отчете AppOmni - одного из вендоров SSPM. По данным авторов отчета в части безопасности SaaS на рынке доминирует ложная уверенность в надежности собственной системы защиты. Так 71% из 644 опрошенных оценивают уровень безопасности своих SaaS между средним и высоким, при том, что 79% из них сталкивались с соответствующими инцидентами за последние 12 месяцев. При этом, большинство опрошенных занимаются ручным контролем интеграции SaaS в организацию, и не осуществляют непрерывный контроль текущего состояния сервисов. Число же используемых сервисов и интеграций непрерывно растет.
Здесь очень хорошо видна коренная проблема ИБ: непрерывное развитие технологий и гонка за новыми интеграциями порождает небезопасный фронтир, который требует автоматизации. Автоматизация требует инвестиций времени и квалификации, либо деньги и сторонние решения с поддержкой. И вот уже на смену универсальным сканерам, IaC утилитам и system hardening решениям приходят "точечные продукты" под узкопрофильные задачи. Так и живем.
#ops #sspm #решение
В развитии вчерашнего лонгрида пример нового класса решений, ещё не сильно распространенного на рынке. SSPM призваны решать проблему контроля и безопасности интеграций компаний со все большим количеством облачных сервисов. Когда тот же самый GPT помощник, или онлайн-репозиторий не просто детектируется, но ставится на непрерывный контроль автоматически. Это подразумевает:
- правильную конфигурацию;
- выявление уязвимостей;
- мониторинг и реагирование на инциденты;
- контроль утечек защищаемой информации;
- управление привилегиями;
и многое другое
Подробнее про риски, подходы и модель работы с SaaS здорового человека можно почитать в прилагаемом отчете AppOmni - одного из вендоров SSPM. По данным авторов отчета в части безопасности SaaS на рынке доминирует ложная уверенность в надежности собственной системы защиты. Так 71% из 644 опрошенных оценивают уровень безопасности своих SaaS между средним и высоким, при том, что 79% из них сталкивались с соответствующими инцидентами за последние 12 месяцев. При этом, большинство опрошенных занимаются ручным контролем интеграции SaaS в организацию, и не осуществляют непрерывный контроль текущего состояния сервисов. Число же используемых сервисов и интеграций непрерывно растет.
Здесь очень хорошо видна коренная проблема ИБ: непрерывное развитие технологий и гонка за новыми интеграциями порождает небезопасный фронтир, который требует автоматизации. Автоматизация требует инвестиций времени и квалификации, либо деньги и сторонние решения с поддержкой. И вот уже на смену универсальным сканерам, IaC утилитам и system hardening решениям приходят "точечные продукты" под узкопрофильные задачи. Так и живем.
#ops #sspm #решение