Securing Developer Tools: Package Managers

Случались ли у вас ситуации, когда антивирусный агент начинает генерировать алерты о вредоносной активности будучи установленным на сборщике? Вероятно, вы столкнулись с вредоносами, описанными в этой статьей - "Securing Developer Tools: Package Managers". Речь пойдет о вредоносных пакетах, запускаемых с помощью Composer, Bundler, Bower, Yarn и других пакетных менеджерах. Приведены также разные меры по митигации.

В Golang, кстати, часть проблем supply chain попытались решить архитектурно. Начиная c того, что сборщики не могут ничего поставить за пределами зафиксированных хэшей в go.sum и заканчивая невозможностью запускать код во время сборки. Об этой подробнее в статье "How Go Mitigates Supply Chain Attacks".

#dev

Уязвимость в репозитории NPM, позволяющая добавить сопровождающего без подтверждения

“В репозитории пакетов NPM выявлена проблема с безопасностью, позволяющая владельцу пакета добавить в число сопровождающих любого пользователя, без получения от этого пользователя согласия и без информирования о совершённом действии. Проблема усугубляется тем, что после добавления стороннего пользователя в число сопровождающих, изначальный автор пакета мог удалить себя из списка сопровождающих и сторонний пользователь оставался единственным лицом, отвечающим за пакет.

Проблемой могли воспользоваться создатели вредоносных пакетов для добавления в число сопровождающих известных разработчиков или крупных компаний с целью повышения доверия пользователей и создания иллюзии, что заслуженные разработчики отвечают за пакет, хотя на деле не имеют к нему никакого отношения и даже не знают о его существовании. Например, атакующий мог разместить вредоносный пакет, сменить сопровождающего и пригласить пользователей протестировать новую разработку крупной компании. Уязвимость также могла применяться для очернения репутации определённых разработчиков, представляя их как инициаторов сомнительных акций и вредоносных действий.”

https://opennet.ru/57108/

#dev #news

Наиболее распространенные уязвимости в мобильных приложениях

Вы могли заметить, что я почти не пишу ничего про безопасность мобильных приложений (и вы окажетесь правы), но сегодня я хочу сделать исключение.

Открываем короткую неделю со статьи "Наиболее распространенные уязвимости в мобильных приложениях". Это авторский список уязвимостей на основе опыта их нахождения собственным инструментом динамического анализа мобильных приложений. Здесь есть и примеры небезопасного кода и варианты митигации. Как сам автор пишет, они мало чем отличаются от OWASP, даже не смотря на то, что последняя версия Mobile Top 10 вышла в далеком 2016 году.

#dev #mobile

CIS Software Supply Chain Security Guide

Вот это пушка, конечно, вышла. Набор требований безопасности CIS с разбивкой на код, сборку, зависимости, артефакты и деплоймент.

#dev #ops #cicd

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. Публикация артефактов в публичных репозиториях. Сценарии, когда ошибочно допущенная команда (например, 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://yangx.top/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

Здесь очень характерно поведение 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 #прогнозы