Security Wine (бывший - DevSecOps Wine)

Security Templates Сегодня без сложных постов, уязвимостей и исследований. Вместо этого мы хотим поделиться парой полезных шаблонов! Первый из них — шаблон моделирования угроз по STRIDE для Miro от самого Head of Product Security Miro. Этот шаблон наглядно демонстрирует процесс моделирования угроз и включает сопутствующие диаграммы, которые помогают на каждом этапе составления списка угроз. Второй — это целый набор шаблонов от Robert Auger. Роберт делится материалами, которые помогали ему на его пути в построении программ bug bounty, управления уязвимостями, внешнего пентеста и реагирования на инциденты. Во всех своих шаблонах Роберт опирается на свой опыт в таких компаниях, как PayPal, eBay, Box, Workday и Coinbase. В качестве примера к посту приложена упрощенная диаграмма процесса bug bounty. Еще нам в целом понравился чеклист в подготовки построения процесса vulnerability management, который также учитывает AppSec-процессы. По нему хорошо можно проследить попытку автора передать именно свой личный опыт. #templates #process

Harnessing LLMs for Automating BOLA Detection Одна из самых распространённых уязвимостей в веб-приложениях — это broken access control. На сегодняшний день SAST и DAST бесполезны при их поиске, и всем известно, что выявление таких уязвимостей решается исключительно ручным тестированием с помощью плагинов для Burp, таких как Autorize, AuthMatrix, Authz. Однако, недавно мы наткнулись на статью от Unit42 (Palo Alto Networks) о том, как они автоматизировали поиск уязвимостей типа broken object level authorization (BOLA) с помощью ИИ. В качестве входных данных используется спецификация OpenAPI, после чего механизм ищет потенциально уязвимые API, где происходит обращение к объектам (например, username, email, teamId, invoiceId, visitId). Далее строится дерево зависимостей между этими эндпоинтами и формируются тестовые кейсы, в которых инструмент пробует различные сценарии обращения к объектам на основе имеющихся доступов двух пользователей. Если один из пользователей имеет доступ к объектам другого, то существует высокая вероятность наличия уязвимости BOLA. Звучит достаточно интересно и логично автоматизировать такого рода тестирования! В результате исследователи обнаружили уязвимости в Grafana (CVE-2024-1313), Harbor (CVE-2024-22278) и Easy!Appointments (целых 15 CVE). Они также отметили, что эксперименты показывают: обратная связь от людей постоянно улучшает точность и надёжность ИИ. В конце статьи также много полезных ссылок на смежные исследования Unit42. P.S. Кстати, вот еще один прекрасный пример поиска CVE с помощью LLM - анализ вылетов на предмет полезности при фаззинге браузера. #ai

А между тем череда интересных митапов продолжается. Вот и Купер.тех (ex-СберМаркет) подготовил свой DevSecOps митап со спикерами из RuStore, Positive Technologies, Купер.тех (ex СберМаркет), SolidLab и MTS Web Services. Дата: 21 августа в 19:00 Место: Москва, офис Купера + онлайн На митапе будут представлены доклады на следующие темы*: - Как выстроить DAST на Open-Source: гибкое использование Nuclei и ZAP под сервисы компании - Вредные советов для вашего ASPM. - Написали свою DSO-платформу, но все равно купили ASOC. Да как так-то?… - Опыт тестирования Defect Dojo SASTами - Какой должен быть SAST? *по итогам каждого доклада и в афтерпати - обсуждение тем со спикерами Зарегистрироваться на митап можно тут: это чтобы попасть в офлайн или чтобы не пропустить ссылку на трансляцию, если интересно присоединиться в онлайне. #event #инфо

Container and Kubernetes Security Fundamentals Я уверен, что многие из вас заметили, что мы редко затрагиваем вопросы безопасности Kubernetes и контейнеров, хотя обладаем соответствующей экспертизой. Поэтому вечерком, под чашечку расслабляющего чая, давайте преисполнимся оркестрации.... Мы не могли пройти мимо и решили опубликовать уже не новую, но постоянно обновляемую серию видео и статей от известного исследователя Rory McCune под названием "Kubernetes Security and Container Security Fundamentals" (ссылка на статьи). Материалы охватывают важные аспекты безопасности Kubernetes, включая его компоненты, а также такие механизмы безопасности контейнеров, как capabilities, namespaces, AppArmor, SELinux, cgroups и seccomp-фильтры. В одном из последних материалов, опубликованных около двух недель назад, рассматривается вопрос авторизации в Kubernetes, включая модули авторизации (AlwaysAllow, AlwaysDeny, Node Authorizer, ABAC, RBAC) и авторизацию на уровне компонентов. Rory McCune известен своими статьями еще с тех времен, когда работал в Aqua Security. Большую известность он получил как соавтор Kubernetes Benchmark и Docker Benchmark от CIS, а также как автор документа "Guidance for Containers and Container Orchestration Tools" для PCI DSS. Этот курс идеально подходит для начинающих, а учиться никогда не поздно! Даже ночью 🙃 #k8s #docker #containersecurity

AppSec != DevSecOps Нашу команду часто подключают к процессам выстраивания безопасной разработки в компаниях. В свете продолжающихся изменений регуляторики будут ещё чаще. Помимо вопросов относящихся к специфике HR, существует пул hard skills задач, которые начинаются с четкого определения зоны ответственности человека и требуемых компетенций. Сегодняшний пост посвящен рефлексии и размышлениям о разнице между AppSec, DevSecOps и ProdSec на фоне неоднозначного видения этих ролей в компаниях, что часто приводит к недопониманию на интервью и затрудняет подбор подходящего сотрудника. Все, что вы прочитаете далее, является субъективным рассуждением на основе эмпирики. AppSec Цель: Обеспечение безопасности приложения. Это отражено в KPI, включая количество найденных уязвимостей, охват тестируемых приложений и глубину анализа. В задачи входят анализ архитектуры, моделирование угроз, ревью кода и тестирование безопасности. Роль AppSec существует достаточно давно, с начала 2000-х годов, когда появилась организация OWASP. Хотя о результативности этой роли можно порассуждать, подробнее писали в относительно старом посте. DevSecOps Цель: Автоматизация процессов безопасности и интеграция безопасности в DevOps. В KPI входит адаптация инструментов безопасности в SDLC и автоматизация проверок безопасности на уровне CI/CD. Сюда часто включается безопасность платформ Kubernetes и облачных сервисов. Концепция DevSecOps начала формироваться в 2012-2014 годах. Несмотря на явные различия в целях и задачах, часто можно встретить распределение ролей в командах, где AppSec-инженер в крупной компании, способной разделить ответственность, занимается встраиванием инструментов в CI/CD. При этом у инженера явный уклон именно в безопасность веба и мобильных приложений. В итоге мы видим, что внедрение произошло, но нередко оно выполнено неэффективно, не учитывая многие аспекты, к которым приходят опытные DevOps-инженеры. На рынке AppSec также существует множество кандидатов, приходящих на интервью с единственным опытом встраивания сканеров, многие из которых никогда не работали с инструментами вроде Burp Suite. Product Security Кто такие Product Security, о которых мы слышим все чаще последние 2-3 года, особенно на интернациональной рынке? Это команды, занимающиеся безопасностью продукта в целом, включая управление уязвимостями продукта и его инфраструктуры, а также облачную безопасность. Некоторые компании даже имеют команды Product Security как единственных специалистов по безопасности. ProdSec также тесно взаимодействует с Product Management, что нечасто встречается в AppSec. ProdSec интегрирует безопасность в жизненный цикл пользователя, внедряя MFA, историю входов, CAPTCHA и другие механизмы, тесно сотрудничая не только с dev и product, но и с маркетингом и другими бизнес-направлениями. Команде ProdSec, как и AppSec, не обязательно иметь в составе DevSecOps-инженера, который может существовать отдельно в команде DevOps. Это зарождающееся разделение, где ProdSec получает больше доменов ИБ под управление, обусловлено, на мой взгляд, как и тесным переплетением слоев абстракций (cloud-native инфраструктура) так и непониманием старой школы инфраструктурных безопасников особенностей разработки и того, что нужно делать, чтобы быть гармоничным участником процесса. Любое изменение конфигурации в облаке, применение патча или правила на WAF может сильно повлиять на работу пользователя. Поэтому любое изменение для продуктов, независимо от инфраструктурного или прикладного слоя, может проходить аналогичный цикл SDLC, как и любое изменение кода. P.S. И в этом процессе возникновения новых ролей можно разглядеть интересный элемент, дополняющий наш любимый shift left. Этакий shift right: когда приложения и процессы становятся все более сложными и запутанными, а мы чтобы приоритезировать необъятное фокусируемся прежде всего на опыте клиента, на том, что находится максимально справа. А затем "раскручиваем" то необходимое, что нужно для того чтобы его опыт состоялся (включая требования к ИБ и соответствие регуляторике). #имхо

Devici Threat Modeling Tool Если вы хотя бы немного следите за интернациональным аппсек-комьюнити, то вы наверняка сталкивались с материалами Криса Ромео (Chris Romeo). У Криса за плечами огромное количество докладов на конференциях, включая RSA Conference и OWASP Global AppSec, подкастов, блогов и исследований, значительная часть которых посвящена моделированию угроз. Недавно Крис основал собственный стартап Devici для автоматизации моделирования угроз. Поскольку Devici поддерживает 3 модели угроз бесплатно и практически без ограничений для команд до 10 человек, а у Криса безупречная репутация, мы с командой не могли пройти мимо и решили попробовать этот сервис. Идея следующая: - Создается модель угроз в виде сущности, которая может иметь различные статусы, частоту обновлений, критичность и даже время, потраченное на моделирование. - Команда совместно составляет архитектуру приложения, где для каждого компонента назначается атрибут в свободной форме, например, Database, API, WAF, User, Admin, MySQL, RDS, CloudTrail и т.д. В этом помогает небольшой AI, который подбирает нужные атрибуты по запросу пользователя. - На основе выбранных атрибутов инструмент назначает список угроз. Связь осуществляется через преднастроенную библиотеку угроз, привязанных к атрибутам. Также к каждой угрозе прилагается рекомендация по устранению. - Далее команда анализирует все назначенные угрозы по всем компонентам, в результате чего формируется to-do лист, назначаемый конкретным ответственным. За исключением местами непродуманного UX и не всегда мгновенных откликов, инструмент выглядит интересным и перспективным. Индивидуальные исследователи могут использовать инструмент для поиска идей для своих моделей угроз, а команды, работающие за рубежом, могут рассмотреть Devici в качестве дополнения к своим процессам. Авторы также экспериментируют с инновациями и представили новый класс инструментов Design-SAST, который позволяет формировать модель угроз на основе анализированного кода. В будущем возможна генерация списка угроз с помощью AI на базе назначенных атрибутов. #threatmodeling

Немного аналитики от Gartner: с правого края "повзрослевший" DevSecOps; слева "молодые" Policy as Code, AI ассистенты и прочее... Любуемся, прогнозируем, готовимся к выходным. #Gartner #Hypecycle

Security Guardrails Существует термин, введённый Джейсоном Чаном, бывшим директором по информационной безопасности Netflix, который называется "безопасная асфальтированная дорога" (secure paved roads). Этот термин используется в контексте интеграции безопасности таким образом, чтобы она оставалась невидимой. Предположим, разработчики пишут код или администраторы деплоят ресурсы в облако, не осознавая, что делают это безопасно, не придерживаясь при этом множества руководящих принципов. Звучит как сказка, но в настоящее время это всё чаще обсуждается в контексте реализации так называемых Security Guardrails. Это достаточно общий термин, в рамках которого разработчикам и администраторам по умолчанию предоставляются заведомо безопасные функции, классы, ресурсы и механизмы для повседневной работы. Например, вот авторы статьи предоставили разработчикам кастомные классы Terraform CDK для создания ресурсов RDS. Вместо того чтобы создавать RDS с множеством мисконфигураций, как это обычно происходит, разработчики могут воспользоваться классом DatabaseInstance, в котором уже встроены шифрование, ограничение публичного доступа и другие меры безопасности. Затем они передают класс на исполнение функции generate_databases, и безопасники ликуют. Развивая данную концепцию, мы приходим к ситуации, когда внутренним пользователям предоставляются исключительно безопасные по умолчанию утилиты, сервисы, механизмы SSO, аутентификации и авторизации, где пользователь заведомо не может сделать что-то неправильно. Это противоречит подходу большинства вендоров, которые стремятся сделать запуск сервисов максимально простым, не зная всех особенностей каждого заказчика. Соответственно, это приводит к поддержке команды безопасности, которая создает Security Guardrails под нужды организации, делая их, при этом, простыми в эксплуатации. Такие команды безопасности обрели название Security Platform Engineers, статьей про которых мы тоже решили поделиться в продолжении повестки. В России развитие таких команд особенно заметно на фоне стремительно появляющихся AppSec платформ, разрабатываемых in-house (привет Альфа-Банк, VK, Yandex и другие). Это действительно интересная ниша, где видится появление большого количества стартапов. Например, Semgrep даже сделали бесплатный курс про Secure Guardrails, где они объясняют своё видение их применения в контексте своего инструмента.

Phantom Secrets: Undetected Secrets Expose Major Corporations Недавно мы затронули тему появления секретов в неожиданных местах, таких как бинарные файлы. Сегодня мы обсудим обнаружение секретов в удаленных ветках публичных репозиториев. В статье от Aqua исследователи рассказали, как они обнаружили около 18% пропущенных секретов в 50 000 публичных репозиториях, используя команду git clone --mirror вместо стандартного git clone. Авторы подробно объясняют разницу между выполнением этих двух команд и углубляются в нюансы кэширования на платформах управления исходным кодом (SCM). Почему же ветки на самом деле не удаляются и извлекаются через git clone —mirror? Если коротко, то удаленные ветки в Git не удаляются полностью, так как они могут быть полезны для восстановления данных или истории изменений. Это связано с тем, что Git, по своему замыслу, должен сохранять максимальную доступность и возможность восстановления данных даже после их удаления на локальном уровне. Когда вы удаляете локальную ветку, удаленные ветки могут оставаться в виде "висячих" ссылок на удаленном репозитории. Эти ссылки могут быть извлечены при использовании команды git clone --mirror, так как она клонирует все ссылки, включая те, которые были удалены локально. У этого явления даже есть оспариваемая CVE-2022-24975 (GitBleed). Вывод достаточно простой: секрет, который однажды попал в репозиторий, можно считать автоматически скомпрометированным. Для многих использование данного подхода не будет чем-то новым. Соответственно, используйте функции защиты от случайных коммитов (push protection) от ваших SCM и pre-commit хуки, чтобы избегать появления секретов в репозиториях. Если это всё же произошло, то, согласно статье, техподдержка может помочь. Кстати, вслед за статьей Gitleaks и TruffleHog добавили поддержку сканирования через --mirror. Также советуем почитать рекомендации от GitHub - "Best practices for preventing data leaks in your organization". А как эту проблему решаете Вы? #secrets

Binary secret scanning helped us prevent (what might have been) the worst supply chain attack you can imagine Если история с CrowdStrike – это реализовавшаяся катастрофа в цепочке поставок, то команде JFrog удалось предотвратить атаку, которая потенциально могла бы быть еще более ужасающей. В своей статье команда JFrog Security Research рассказывает, как в одном из публичных репозиториев Docker Hub был обнаружен легаси GitHub токен с админ-правами от репозиториев таких проектов, как python, pypa, psf и pypi. Обладатель данного токена теоретически мог бы скрыть вредоносный код в CPython, который является репозиторием некоторых основных библиотек, составляющих ядро языка программирования Python и скомпилированных из кода на C. Из-за популярности Python, вставка вредоносного кода, который в конечном итоге попадет в дистрибутивы Python, могла бы означать распространение бэкдора на десятки миллионов машин по всему миру. Токен был найден в бинарном файле .pyc. Как это произошло? 1) Автор добавил авторизационный токен в исходный код. 2) Запустил исходный код (Python-скрипт), который был скомпилирован в бинарный файл .pyc с авторизационным токеном. 3) Удалил авторизационный токен из исходного кода, но не очистил .pyc. 4) Загрузил как очищенный исходный код, так и неочищенный бинарный файл .pyc в Docker-образ. Какие выводы делают авторы статьи? - В бинарных файлах тоже могут быть секреты, которые надо искать (отсылка на решение от JFrog). - Убедитесь, что вы не используете старые GitHub токены (которые были заменены на новые, более безопасные, в 2021 году). - Предоставляйте доступ к токенам с наименьшими правами. Отчет об инциденте от самих PyPi можно найти здесь. #secrets #supplychain

#Gartner #Architecture

RedFlag Сегодня на очереди очередной open-source инструмент на стыке AI и AppSec. Цель проекта RedFlag - отдать на AI анализ всех pull requests, чтобы отделить те, которые могут быть проигнорированы, и те, которым команде безопасности нужно уделить особое внимание при ревью. Вот, например, есть набор комитов в проект zed из 29 pull requests (PR), из которых RedFlag отметил 12 в своем отчете. Для одного из коммитов, который добавляет новую команду diagnostics, инструмент предоставил сводку, список измененных файлов, подсветил риск, связанный с модификацией логики обработки путей файлов, и порекомендовал протестировать новую команду на инъекции и directory traversal в рамках тест-кейса. К инструменту также есть сопутствующая статья. Для того, чтобы инструмент оживить, необходимо подключить языковую модель Claude v3 Sonnet через Amazon Bedrock, а также обеспечить доступ к Jira, чтобы инструмент мог обрабатывать соответствующие тикеты. Далее в статье идет история успеха, где авторы анализировали релиз проекта своей организации, состоящего из 400 PR, из которых было отобрано около 100 PR. Стоимость такого анализа составила всего 8 долларов. В ходе девяти подобных релизов было обнаружено 6 высоких и 8 средних уязвимостей с точностью инструмента около 92%. Интересен не столько сам инструмент, сколько его идея, простота реализации (это небольшой Python-проект, поддерживаемый двумя мейнтейнерами) и ощутимые результаты. #ai

Cloud Threat Landscape У Wiz, известного вендора занимающегося решениями для безопасности облака, есть вполне достойный внимания ресурс для из изучения - Cloud Threat Landscape. Что здесь можно найти? Обновляемый перечень инцидентов с указанием задействуемых инструментов, технологий, группировок, способов получения доступа. Есть отдельная категория для атак на supply chain. Группировки с ссылкой на инциденты и оперируемые техники. Техники с ссылкой на ATT&CK тактики. Техники протегированы с разбивкой на облачные атаки, атаки на kubernetes, CI/CD и тд. Инструменты, используемые при различных ранее известных атаках, упоминаемых в инцидентах, включая названия криптомайнеров, ransomware и тулкитов. Технологии, на которые нацелены атаки (Docker, Confluence, Redis, Kuberentes и тд), включая способы обнаружения в них уязвимостей (Nuclei, Metaspolit, база CISA KEV) Данный ресурс мало чем отличается от многочисленных awesome-подборок на github, которые никогда не успевают обновляться в след за появлением огромного количества новых статей, инструментов и техник. В некотором смысла данный ресурс даже хуже, так как полностью поддерживается вендором Wiz без участия сообщества 😅 Тем не менее, обойти данный ресурс мы не могли, ибо он может быть полезен при моделировании угроз для облаков. Кроме того, есть RSS-feed с публикацией атак и инцидентов. А чем вы пользуйтесь при моделировании угроз? #cloud

2024 AppSec and DevSecOps Keynotes На рубеже второй половины года мы решили подготовить подборку записей с известных конференций по безопасности, которых стало уже достаточно много. Каждая ссылка ведет на видеозаписи докладов 2024 года. В этом году на всех конференциях наблюдается значительный уклон в сторону безопасности AI и его применения в сфере безопасности на фоне стремительного развития этого направления. RSA Conference 2024 - одна из крупнейших в мире конференций по ИБ, проводится ежегодно в Сан-Франциско. 300 докладов, включая, конечно же, AppSec и DevSecOps. Чтобы облегчить поиск наиболее релевантных докладов, в чате будут опубликованы ссылки на самые интересные выступления. BSidesSF 2024. Вторая по известности конференция по безопасности. Совсем немного докладов про AppSec, но кое-что также в разрезе применения AI присутствует. fwd:cloudsec 2024. Набирающая популярность конференция по безопасности облаков для тех, кому это актуально. Cloud Native Security Con 2024. Конференция от CNCF охватывает в этом году не только темы безопасности контейнеров и контейнерных сред, но и также безопасность AI/ML, CVE, SBOMы. phd2 2024. Та самая конференция в России, которая не нуждается в представлении. Кроме отдельного трека по безопасности разработки, есть треки, где так или иначе затрагивается тема AppSec, например, в контексте экономической эффективности. Также очень ждем доклады от организаторов БеКон 2024 - конференции по безопасности контейнеров и контейнерных сред. Записей пока нет, но есть слайды. Если вы знаете какие-то конференции релевантные к каналу с доступными записями, присылайте в чат! #talks

*И иллюстрация к предыдущему посту

OWASP Dep-scan В чате участники нашего сообщества поделились проектом Dep-scan — инструментом поиска уязвимостей в зависимостях "нового поколения" от OWASP. Несмотря на то что инструмент не новый, известен он не так сильно как Dependency-Check и Dependency-Track. Отличительная особенность данного инструмента — это предоставление возможности по приоритизации уязвимостей. Dep-scan добавляет к каждой уязвимости графу "Insights". Приоритизация осуществляется за счет так называемого Reachability анализа — анализа кода на предмет того, может ли уязвимый пакет быть затронут опасными методами, например, пользовательским вводом с помощью параметров requests или методов safecode. Механизм построен на базе проекта Atom и поддерживает Java, JavaScript, TypeScript и Python. В проект также добавили режим аудита риска. Этот режим позволяет оценить степень рискованности npm или PyPI-пакетов с помощью заложенной разбивки весов. Баллы риска могут прибавляться, например, если у пакета всего два npm-пользователя, приватный пакет доступен в публичном реестре (привет атаки dependency confusion), либо пакет в принципе достаточно старый. Среди фич авторы отмечают генерацию SBOM за счет интеграции с cdxgen, быстроту сканирования и количество поддерживаемых языков и форматов (Node.js, Java, PHP, Python, Go, .NET, C/C++, Docker, OCI image, YAML). А какие SCA используете вы? И есть ли положительный опыт работ с импортозамещенными инструментами? Обсуждаем в комментариях и чате. #sca

В продолжении понедельничного поста... #Юмор

Enhancing Automated Configuration Security Capabilities with OpenAI Grant Funding OpenAI рассказала о 8 программах получивших грант Cybersecurity Grant Program, направленный на финансирование активностей по улучшению методик защиты с помощью AI. Здесь есть защита LLM от prompt-инъекций, использование AI для OSINT, автоматизация red team и тд. Нам лично понравился и показался релевантным к каналу проект CoGuard. В исследовании команда CoGuard продемонстрировала использование OpenAI API для решения проблемы неправильной настройки ПО. Основные этапы включали: - С использованием LLM из документации по ПО извлекались параметры, важные с точки зрения безопасности. - Для каждого параметра определялись его стандартное и рекомендуемое с точки зрения безопасности значения. - Полученная информация трансформировалась в правила, которые могут быть использованы сканерами конфигураций для проверки безопасности настроек. Использование LLM позволило автоматизировать и упростить добавление новых правил и поддержку актуальных конфигураций, значительно повышая эффективность процессов разработки и обслуживания программного обеспечения. А еще у Cougard есть open-source тула для сканирования конфигурации внутри docker-образов и облачных ресурсов. Среди поддерживаемых Kafka, Tomcat, Kubernetes, MongoDB, MySLA, nginx , postgesql, helm, elasticsearch и другие. #configuration #ai

The Open Source Problem Мы в канале любим статистику, особенно если она хорошо раскрывает глобальные проблемы на примере громких инцидентов. Недавно нам попался интересный ресерч: автор которого взял 5000 pip-пакетов и применил к ним "критерии Цзя Тан", того самого китайского контрибьютора бекдора в xz. Набор критериев простой: права на коммит, китайский часовой пояс и email, в котором сочетается имя и номер. В результате получилось 310 pip-пакетов. Даже у контрибьютеров самого pip есть некий meowmeowcat1211@gmail.com, соответствующий таким критериям. Дополнительно можно почитать здесь и здесь. А теперь взглянем на статистику Blackberry из их отчета о безопасности цепочки поставок ПО, составленного по результатам опроса 1000 старших руководителей: - 51% компаний смогли восстановиться после взлома в течение недели, около 40% потребовалось месяц. - 74% атак исходили от участников цепочки поставок программного обеспечения, о которых компании не знали или не отслеживали до взлома. - Хотя 78% компаний отслеживают влияние атак на цепочку поставок, только 65% информируют своих клиентов об этих инцидентах. Учитывая, что трактовать и ту и другую статистику можно по-разному, выводы делайте сами. Мы, в свою очередь, подбросим очередную новость о том, как в популярный проект polyfill.js китайцы внедрили вредоносный код на 100k+ сайтов. Здесь, правда, история о том, как развивалась атака, более загадочная, ибо домен и GitHub-репозиторий были переданы китайским мейнтейнерам в феврале этого года одним из разработчиков polyfill, принадлежащей компании Fastly. Поясняем: один из рядовых разработчиков компании, которой принадлежит проект polyfill, просто взял и продал проект новым владельцам (за что, скорее всего, получил хорошие деньги). Есть semgrep правило для поиска и замены вредоносных пакетов. Вот также полезный свежий ресерч. #supplychain