CWE пакетных менеджеров
Всем привет!
Интересное исследование провёл Автор статьи. Он проанализировал все доступные ему CVE, характерные для пакетных менеджеров.
После этого он собрал и систематизировал информацию о CWE, которые встречаются как на стороне клиента, так и на стороне реестра.
Например:
🍭 Archive extraction writes outside the target directory
🍭 Argument injection into git, hg, svn, and friends
🍭 Integrity checks that fail open
🍭 Stored XSS in rendered package pages
🍭 Publishing or replacing someone else’s package и не только
Интересно, что указанный список характерен для многих реестров – в независимости от того, с какими пакетами они работают и когда были разработаны.
Для каждой CWE приводится краткое описание (именно от Автора) и примеры CVE, на основании которых был сделан вывод.
Всем привет!
Интересное исследование провёл Автор статьи. Он проанализировал все доступные ему CVE, характерные для пакетных менеджеров.
После этого он собрал и систематизировал информацию о CWE, которые встречаются как на стороне клиента, так и на стороне реестра.
Например:
🍭 Archive extraction writes outside the target directory
🍭 Argument injection into git, hg, svn, and friends
🍭 Integrity checks that fail open
🍭 Stored XSS in rendered package pages
🍭 Publishing or replacing someone else’s package и не только
Интересно, что указанный список характерен для многих реестров – в независимости от того, с какими пакетами они работают и когда были разработаны.
Для каждой CWE приводится краткое описание (именно от Автора) и примеры CVE, на основании которых был сделан вывод.
Andrew Nesbitt
Package Manager CWEs
Recurring weakness classes in package managers
👍3
Package Proxy: защита supply chain с Cloudflare
Всем привет!
Package Proxy – open-source инструмент, который содержит в себе набор встроенных проверок для работы с пакетами, получаемыми с и использованием популярных пакетных менеджеров:
Примеры проверок:
🍭 Выпущен не более 10 дней назад (можно параметризировать)
🍭 (Не) входит в перечень разрешённых к установке версий
🍭 Версия пакета не является «yanked»
🍭 Способ загрузки пакета в индекс (не) изменился и не только
Дополнительно можно указать
Из нюансов – «локально» установить не получится, решение работает только с Cloudflare.
Подробнее можно прочитать в GitHub-репозитории или вот в этой статье.
Всем привет!
Package Proxy – open-source инструмент, который содержит в себе набор встроенных проверок для работы с пакетами, получаемыми с и использованием популярных пакетных менеджеров:
npm, pip, uv и cargo).Примеры проверок:
🍭 Выпущен не более 10 дней назад (можно параметризировать)
🍭 (Не) входит в перечень разрешённых к установке версий
🍭 Версия пакета не является «yanked»
🍭 Способ загрузки пакета в индекс (не) изменился и не только
Дополнительно можно указать
webhook-url, на который будет отправлена информация о заблокированном пакете.Из нюансов – «локально» установить не получится, решение работает только с Cloudflare.
Подробнее можно прочитать в GitHub-репозитории или вот в этой статье.
GitHub
GitHub - thinkst/package-proxy: Inline proxy for software package registries to provide observability and policy controls to installs.
Inline proxy for software package registries to provide observability and policy controls to installs. - thinkst/package-proxy
👎2
Модели угроз пакетных менеджеров
Всем привет!
Недавно мы писали про CWE, характерные для пакетных менеджеров. Но это лишь «начало истории».
Автор статьи – Andrew Nesbitt – написал вторую часть, посвященную модели угроз пакетных индексов.
Именно её перевела на русский язык команда CodeScoring и разместила на Habr’e.
Самое интересное то, что Andrew рассматривает механизмы, которые «работают так, как и задумано», поэтому на них не заводят CVE, но их можно использовать для совершения атак.
Как и в предыдущей статье, внимание уделяется как клиентской части (логике пакетного менеджера), так и серверной (логике пакетного индекса).
Внутри можно найти:
🍭 Выполнение кода до/в момент установки
🍭 Однозначная идентификация имени пакета
🍭 Распределение имён
🍭 Неизменяемость опубликованных версий
🍭 Происхождение от исходного кода до артефакта и не только
Помимо понимания возможных ИБ-нюансов статья рассматривает (пусть и не очень детально) логику работы разных пакетных индексов и то, как сильно разные действия могут отличаться в зависимости от используемой технологии.
Это помогает лучше понять, как оно «работает на самом деле» и чего стоит ожидать.
Кроме этого, в статье очень много отсылок на «Package Manager CWEs», что делает её ещё более наглядной.
Однозначно рекомендуем к прочтению!
Всем привет!
Недавно мы писали про CWE, характерные для пакетных менеджеров. Но это лишь «начало истории».
Автор статьи – Andrew Nesbitt – написал вторую часть, посвященную модели угроз пакетных индексов.
Именно её перевела на русский язык команда CodeScoring и разместила на Habr’e.
Самое интересное то, что Andrew рассматривает механизмы, которые «работают так, как и задумано», поэтому на них не заводят CVE, но их можно использовать для совершения атак.
Как и в предыдущей статье, внимание уделяется как клиентской части (логике пакетного менеджера), так и серверной (логике пакетного индекса).
Внутри можно найти:
🍭 Выполнение кода до/в момент установки
🍭 Однозначная идентификация имени пакета
🍭 Распределение имён
🍭 Неизменяемость опубликованных версий
🍭 Происхождение от исходного кода до артефакта и не только
Помимо понимания возможных ИБ-нюансов статья рассматривает (пусть и не очень детально) логику работы разных пакетных индексов и то, как сильно разные действия могут отличаться в зависимости от используемой технологии.
Это помогает лучше понять, как оно «работает на самом деле» и чего стоит ожидать.
Кроме этого, в статье очень много отсылок на «Package Manager CWEs», что делает её ещё более наглядной.
Однозначно рекомендуем к прочтению!
Хабр
Модели угроз пакетных менеджеров
Привет Хабр! На фоне громких новостей об очередных атаках на цепочку поставки открытого программного обеспечения защитники фокусируются на вопросе проверки этих самых пакетов и выстраивании слоев...
👍6🔥4❤2
Secrets Ninja: валидация секретов
Всем привет!
Secrets Ninja – open-source проект, задача которого помочь в валидации найденных секретов, например, при анализе ПО или конфигурационных файлов.
Он поддерживает много сервисов, среди которых:
🍭 Bitbucket, GitLab, GitHub
🍭 Jira
🍭 MongoDB
🍭 NpmToken
🍭 PostgresQL и не только
Работает максимально просто: выбираем нужны сервис, указываем секрет, копируем
Можно установить локально (через(но лучше всё-таки для целей ознакомления с сервисом) .
Всем привет!
Secrets Ninja – open-source проект, задача которого помочь в валидации найденных секретов, например, при анализе ПО или конфигурационных файлов.
Он поддерживает много сервисов, среди которых:
🍭 Bitbucket, GitLab, GitHub
🍭 Jira
🍭 MongoDB
🍭 NpmToken
🍭 PostgresQL и не только
Работает максимально просто: выбираем нужны сервис, указываем секрет, копируем
curl-запрос и смотрим на ответную реакцию.Можно установить локально (через
npm или с использованием Docker) или использовать online-сервис GitHub
GitHub - NikhilPanwar/secrets-ninja: Secrets Ninja is an GUI tool for validating & investigating API keys discovered during pentesting…
Secrets Ninja is an GUI tool for validating & investigating API keys discovered during pentesting & bug bounty hunting. - NikhilPanwar/secrets-ninja
Observability с Monoscope
Всем привет!
Если вы в поисках observability-решения, которое работает с S3 и использует возможности LLM, то, возможно, Monoscope может вас заинтересовать.
Основные возможности Monoscope:
🍭 Возможность написания запросов «на обычном» языке с использованием LLM
🍭 Подключение агентов, которые будут сообщать об аномалиях
🍭 Оповещения, направляемые по электронной почте
🍭 Наличие графического web-интерфейса, в котором можно посмотреть информацию по событиям
Возможна локальная установка через Docker Compose. Есть ещё облачная версия, которая обладает большими возможностями (разница приведена в GitHub-repository).
Посмотреть на то, как это выглядит и уточнить подробности про возможности можно в репозитории проекта или на сайте с документацией.
Всем привет!
Если вы в поисках observability-решения, которое работает с S3 и использует возможности LLM, то, возможно, Monoscope может вас заинтересовать.
Основные возможности Monoscope:
🍭 Возможность написания запросов «на обычном» языке с использованием LLM
🍭 Подключение агентов, которые будут сообщать об аномалиях
🍭 Оповещения, направляемые по электронной почте
🍭 Наличие графического web-интерфейса, в котором можно посмотреть информацию по событиям
Возможна локальная установка через Docker Compose. Есть ещё облачная версия, которая обладает большими возможностями (разница приведена в GitHub-repository).
Посмотреть на то, как это выглядит и уточнить подробности про возможности можно в репозитории проекта или на сайте с документацией.
GitHub
GitHub - monoscope-tech/monoscope: Monoscope lets you ingest and explore your logs, traces and metrics. We store these in S3 compatible…
Monoscope lets you ingest and explore your logs, traces and metrics. We store these in S3 compatible buckets. Query in natural language via LLMs. - monoscope-tech/monoscope
👍2❤1
k8scout: визуализация путей атак в Kubernetes
Всем привет!
k8scout решает простую, но интересную задачу: «Допустим, что в кластере есть
Утилита анализирует возможности компрометированного
Например:
🍭 Повышение привилегий до
🍭 Горизонтальное перемещение (
🍭 Побег из контейнера (через привилегированные контейнеры,
🍭 Попытки изменения ресурсов кластера
🍭 Изменение конфигурации
Результаты работы представлены в виде интерактивной карты (пример которой можно увидеть в GitHub-репозитории проекта).
Каждая сработка содержит идентификатор MITRE ATT&CK, уровень риска и пошаговый путь того, как это было сделано.
Подробности, по классике, в GitHub-репозитории проекта.
Важно: утилита совершает активные действия, которые могут повлиять на работоспособность кластера. Использовать аккуратно ☺️
Всем привет!
k8scout решает простую, но интересную задачу: «Допустим, что в кластере есть
pod с RCE. К чему это может привести?».Утилита анализирует возможности компрометированного
pod и пытается совершить разные «нехорошие действия».Например:
🍭 Повышение привилегий до
cluster-admin🍭 Горизонтальное перемещение (
exec в другие pod, «кража» их токенов)🍭 Побег из контейнера (через привилегированные контейнеры,
hostPID, hostNetwork, hostPath и т.д.)🍭 Попытки изменения ресурсов кластера
🍭 Изменение конфигурации
webhooks, созданных в кластере и т.д.Результаты работы представлены в виде интерактивной карты (пример которой можно увидеть в GitHub-репозитории проекта).
Каждая сработка содержит идентификатор MITRE ATT&CK, уровень риска и пошаговый путь того, как это было сделано.
Подробности, по классике, в GitHub-репозитории проекта.
Важно: утилита совершает активные действия, которые могут повлиять на работоспособность кластера. Использовать аккуратно ☺️
GitHub
GitHub - k8scout/k8scout: Drop a single binary into a compromised Kubernetes pod and instantly map every realistic attack path…
Drop a single binary into a compromised Kubernetes pod and instantly map every realistic attack path to cluster-admin, node escape, secret theft, and cloud IAM takeover. - k8scout/k8scout
AppSec: вопросы для собеседований
Всем привет!
Мало кто любит собеседования, но все же иногда их приходится проходить для получения желанной работы.
Чтобы было чуть проще подготовиться, можно посмотреть на вот этот вот репозиторий. Да, он не будет учитывать специфику российского рынка, но всё равно может быть полезен.
Например, для практики – «А как бы я ответил на этот вопрос?». Возможно, что при чтении перечня найдётся область, в которой требуется изучение дополнительных материалов и т.д.
Примеры рассматриваемых вопросов:
🍭 Базовые. Объяснить несколько уязвимостей из OWASP Top 10, разница между SAST и SCA и т.д.
🍭 Общие. Точки «встраивания» ИБ в процессы разработки, что и кто делает и т.д.
🍭 Сценарные. Вы нашли X уязвимостей от инструмента Y, что вы будете с ними делать и почему?
🍭 Синтетические. Перед вами пример исходного кода. Есть ли тут уязвимость, какая и чем она опасна, при каких условиях?
🍭 Концептуальные. Как противодействовать brute force атакам, как именно SSL/TLS помогает в защите, разница между шифрованием и хэшированием и т.д.
Помимо безопасной разработки в репозитории есть аналогичные «опросники» и по иным темам: API Security, AI Security, Container Security и не только.
Всем привет!
Мало кто любит собеседования, но все же иногда их приходится проходить для получения желанной работы.
Чтобы было чуть проще подготовиться, можно посмотреть на вот этот вот репозиторий. Да, он не будет учитывать специфику российского рынка, но всё равно может быть полезен.
Например, для практики – «А как бы я ответил на этот вопрос?». Возможно, что при чтении перечня найдётся область, в которой требуется изучение дополнительных материалов и т.д.
Примеры рассматриваемых вопросов:
🍭 Базовые. Объяснить несколько уязвимостей из OWASP Top 10, разница между SAST и SCA и т.д.
🍭 Общие. Точки «встраивания» ИБ в процессы разработки, что и кто делает и т.д.
🍭 Сценарные. Вы нашли X уязвимостей от инструмента Y, что вы будете с ними делать и почему?
🍭 Синтетические. Перед вами пример исходного кода. Есть ли тут уязвимость, какая и чем она опасна, при каких условиях?
🍭 Концептуальные. Как противодействовать brute force атакам, как именно SSL/TLS помогает в защите, разница между шифрованием и хэшированием и т.д.
Помимо безопасной разработки в репозитории есть аналогичные «опросники» и по иным темам: API Security, AI Security, Container Security и не только.
GitHub
security-interview-questions/application-security-interview-questions.md at main · jassics/security-interview-questions
Security interview questions with possible explanation for roles in AppSec, Pentesting, Cloud Security, DevSecOps, Network Security and so on - jassics/security-interview-questions
👍4
State of MCP Security 2026.pdf
2.5 MB
State of MCP Security 2026
Всем привет!
В приложении можно найти небольшой (~ 10 страниц) отчёт, посвященный безопасности MCP-серверов.
«Мы просканировали более 11 000 публично доступных MCP серверов. В отчёте можно найти нюансы, связанные с безопасностью, что мы нашли» - так начинается отчёт.
Примеры статистики из отчёта:
🍭 232 сервера позволяли выполнять произвольный код, запускать команды, десериализировали непроверенные данные и т.д.
🍭 78% из проверенных серверов не использовали dependency pinning
🍭 1617 содержат известные уязвимости. Перечень наиолее часто встречающихся приведён в отчёте
🍭 260 – запускали install scripts на рабочем месте пользователя
🍭 В 31% случаев наблюдались нюансы, связанные с аутентификацией (возможность анонимных вызовов)
Никакой воды, только цифры и немного комментариев – отлично подойдёт для быстрого изучения.
Кстати, Авторы заметили интересную корреляцию – чем больше у MCP-сервера «звёзд» на GitHub, тем больше у него нюансов с безопасностью.
Всем привет!
В приложении можно найти небольшой (~ 10 страниц) отчёт, посвященный безопасности MCP-серверов.
«Мы просканировали более 11 000 публично доступных MCP серверов. В отчёте можно найти нюансы, связанные с безопасностью, что мы нашли» - так начинается отчёт.
Примеры статистики из отчёта:
🍭 232 сервера позволяли выполнять произвольный код, запускать команды, десериализировали непроверенные данные и т.д.
🍭 78% из проверенных серверов не использовали dependency pinning
🍭 1617 содержат известные уязвимости. Перечень наиолее часто встречающихся приведён в отчёте
🍭 260 – запускали install scripts на рабочем месте пользователя
🍭 В 31% случаев наблюдались нюансы, связанные с аутентификацией (возможность анонимных вызовов)
Никакой воды, только цифры и немного комментариев – отлично подойдёт для быстрого изучения.
Кстати, Авторы заметили интересную корреляцию – чем больше у MCP-сервера «звёзд» на GitHub, тем больше у него нюансов с безопасностью.
❤2🔥1
SAIL Framework 2.0 2026.pdf
27.7 MB
Secure AI Lifecycle Framework 2.0
Всем привет!
В приложении можно найти документ, в котором описан SAIL – Secure AI Lifecycle Framework 2.0 (~ 50 страниц).
Он представляет из себя практическое руководство о создании и запуске AI-приложений и агентов в «безопасном режиме».
Материал структурирован по разделам:
🍭 Executive Summary. Описание используемого подхода
🍭 Shape of the Agentic Attack Surface. Описание основных ИБ-проблем, с которыми можно столкнуться
🍭 SAIL. Основные разделы framework и их описание
Сам framework разбит на 7 разделов: AI Policy (Plan), AI Discovery (Code/No Code), Agentic Posture (Build), Agentic Red Teaming (Test), Runtime Controls (Deploy), Sandbox (Operate), Govern (Monitor & Retire).
Чтобы им удобнее было пользоваться, для каждого раздела (домена) определён перечень характерных рисков. Всего доступно описание 91 риска.
Описание содержит идентификатор (ID), риск, описание, пример, подверженные активы, способы устранения, соотношения со стандартами.
В завершении материала представлен небольшой пример (use case), который наглядно описывает использование SAIL 2.0.
Всем привет!
В приложении можно найти документ, в котором описан SAIL – Secure AI Lifecycle Framework 2.0 (~ 50 страниц).
Он представляет из себя практическое руководство о создании и запуске AI-приложений и агентов в «безопасном режиме».
Материал структурирован по разделам:
🍭 Executive Summary. Описание используемого подхода
🍭 Shape of the Agentic Attack Surface. Описание основных ИБ-проблем, с которыми можно столкнуться
🍭 SAIL. Основные разделы framework и их описание
Сам framework разбит на 7 разделов: AI Policy (Plan), AI Discovery (Code/No Code), Agentic Posture (Build), Agentic Red Teaming (Test), Runtime Controls (Deploy), Sandbox (Operate), Govern (Monitor & Retire).
Чтобы им удобнее было пользоваться, для каждого раздела (домена) определён перечень характерных рисков. Всего доступно описание 91 риска.
Описание содержит идентификатор (ID), риск, описание, пример, подверженные активы, способы устранения, соотношения со стандартами.
В завершении материала представлен небольшой пример (use case), который наглядно описывает использование SAIL 2.0.
GuardDog: 3.0
Всем привет!
GuardDog – проект от Datadog, который позволяет идентифицировать вредоносные пакеты за счёт анализа исходного кода и метаданных о пакете.
Мы про него уже писали (тут и тут). Можно проследить постепенное развитие проекта: добавление возможностей расширения правил анализа пользователями, поддержка новых пакетных менеджеров и т.д.
Недавно было выпущено ещё одно крупное обновление – GuradDog 3.0!
Из основных изменений можно выделить:
🍭 Отказ от Semgrep в сторону YARA-правил. Почему?Ответ есть в статье 😊
🍭 Новая модель оценки рисков пакетов
🍭 Новый набор правил для идентификации подозрительных пакетов (через определение capabilities и через определение threat indicators)
🍭 Поддержка Nono в качестве «песочницы» при проведении анализа
🍭 Улучшение производительности и не только
Подробнее обо всех изменениях можно прочесть в статье. В ней есть всё, что нужно – причины изменений, описания, комментарии.
Рекомендуем!
Всем привет!
GuardDog – проект от Datadog, который позволяет идентифицировать вредоносные пакеты за счёт анализа исходного кода и метаданных о пакете.
Мы про него уже писали (тут и тут). Можно проследить постепенное развитие проекта: добавление возможностей расширения правил анализа пользователями, поддержка новых пакетных менеджеров и т.д.
Недавно было выпущено ещё одно крупное обновление – GuradDog 3.0!
Из основных изменений можно выделить:
🍭 Отказ от Semgrep в сторону YARA-правил. Почему?
🍭 Новая модель оценки рисков пакетов
🍭 Новый набор правил для идентификации подозрительных пакетов (через определение capabilities и через определение threat indicators)
🍭 Поддержка Nono в качестве «песочницы» при проведении анализа
🍭 Улучшение производительности и не только
Подробнее обо всех изменениях можно прочесть в статье. В ней есть всё, что нужно – причины изменений, описания, комментарии.
Рекомендуем!
Datadoghq
Introducing GuardDog 3.0: A new rules engine, transparent sandboxing, and more
Release of GuardDog 3.0, an open-source tool to identify malicious packages, featuring a new YARA-based rules engine, a risk scoring engine, and built-in sandboxing.
❤2
Использование LLM в SAST
Всем привет!
Статический анализ – один из самых первых видов анализа ПО, который только появился.
«Разобрать» исходный код, сформировать промежуточное представление, определить потоки данных и применить набор правил для поиска опасных конструкций.
На практике, конечно, всё намного сложнее, но подход достаточно понятный и оправданный. Нюанс заключается в большом количестве ложных срабатываний.
И картина (вроде бы) меняется с появлением LLM: вместо разбора ложных сработок можно сосредоточиться на том, как исправить то, что актуально.
Но так ли всё радужно на самом деле? В небольшой статье Автор представил своё мнение на этот счёт.
Он структурировал мысли по следующим разделам:
🍭 Good. Разметка. Да, тут LLM показывают очень хорошие результаты. Ведь, если упростить, то речь про понимание кода и ответы на вопросы
🍭 Bad. Галлюцинации, (не) всегда идемпотентные результаты, относительные возможности по поиску ИБ-дефектов в исходном коде
🍭Ugly Costly. Чем больше сработок – тем больше приходится платить. Вопросы «доверия» человека «к машине»
И, по мнению Автора, получается, что стандартные детерминированные подходы увеличивают Recall и могут «поймать всё на свете», а LLM – Precision (понимают, что из этого на самом деле применимо)
А что вы думаете по этому поводу и согласны ли вы с этим списком, что бы вы в него добавили?
Всем привет!
Статический анализ – один из самых первых видов анализа ПО, который только появился.
«Разобрать» исходный код, сформировать промежуточное представление, определить потоки данных и применить набор правил для поиска опасных конструкций.
На практике, конечно, всё намного сложнее, но подход достаточно понятный и оправданный. Нюанс заключается в большом количестве ложных срабатываний.
И картина (вроде бы) меняется с появлением LLM: вместо разбора ложных сработок можно сосредоточиться на том, как исправить то, что актуально.
Но так ли всё радужно на самом деле? В небольшой статье Автор представил своё мнение на этот счёт.
Он структурировал мысли по следующим разделам:
🍭 Good. Разметка. Да, тут LLM показывают очень хорошие результаты. Ведь, если упростить, то речь про понимание кода и ответы на вопросы
🍭 Bad. Галлюцинации, (не) всегда идемпотентные результаты, относительные возможности по поиску ИБ-дефектов в исходном коде
🍭
И, по мнению Автора, получается, что стандартные детерминированные подходы увеличивают Recall и могут «поймать всё на свете», а LLM – Precision (понимают, что из этого на самом деле применимо)
А что вы думаете по этому поводу и согласны ли вы с этим списком, что бы вы в него добавили?
A Security Engineer
LLMs in SAST: Good, Bad, Costly | A Security Engineer
Where LLMs actually help in static analysis — triage, explanations, and hybrid recall/precision — and where they hallucinate, drift, and quietly burn money at scale.
🔥3❤1💯1
Migratowl: анализ обновления зависимостей
Всем привет!
«Если я обновлю зависимость X на иную версию, то сломается ли что-нибудь и если да, то как мне это чинить?» - именно на этот вопрос может ответить Migratowl.
Её принцип работы следующий: клонирует репозиторий, анализирует манифесты, устанавливает зависимости и анализирует результаты сборки с использованием LLM.
Всё это запускается в изолированном контейнере.
В результате пользователь получает информацию:
🍭 Сломало ли обновление что-нибудь?
🍭 Что именно «пошло не так»?
🍭 Описание изменений из changelog
🍭 Предложение по решению проблемы на «обычном» языке
Согласно мнению Авторов утилиты она может быть использована, как дополнение для SCA-решений.
Как минимум, потому что Migratowl не предоставляет информации о CVE, которые есть в пакетах.
Установка, настройка, примеры результатов работы – всё это можно найти в GitHub-репозитории проекта или на сайте.
Всем привет!
«Если я обновлю зависимость X на иную версию, то сломается ли что-нибудь и если да, то как мне это чинить?» - именно на этот вопрос может ответить Migratowl.
Её принцип работы следующий: клонирует репозиторий, анализирует манифесты, устанавливает зависимости и анализирует результаты сборки с использованием LLM.
Всё это запускается в изолированном контейнере.
В результате пользователь получает информацию:
🍭 Сломало ли обновление что-нибудь?
🍭 Что именно «пошло не так»?
🍭 Описание изменений из changelog
🍭 Предложение по решению проблемы на «обычном» языке
Согласно мнению Авторов утилиты она может быть использована, как дополнение для SCA-решений.
Как минимум, потому что Migratowl не предоставляет информации о CVE, которые есть в пакетах.
Установка, настройка, примеры результатов работы – всё это можно найти в GitHub-репозитории проекта или на сайте.
GitHub
GitHub - bitkaio/migratowl: AI dependency migration analyzer — reads every changelog so you don't have to.
AI dependency migration analyzer — reads every changelog so you don't have to. - bitkaio/migratowl
👍2
LFK: Lightning Fast Kubernetes Navigator
Всем привет!
Если вам надоел k9s или вы хотите «что-нибудь» новое, то LFK может вас заинтересовать!
Да, всё так – ещё один TUI для работы с кластером Kubernetes.
Он предлагает следующее:
🍭 Удобная навигация от кластера то метаинформации о существующих ресурсах
🍭 Отображение данных о потребляемых ресурсах
🍭 Vim-style навигация!
🍭 Работа с несколькими кластерами
🍭 Разные возможности по работе с ресурсами: от поиска до создания и изменения
🍭 Возможность персональной настройки и ещё много всего
Детальное описание возможностей LFK представлено в GitHub-репозитории.
Помимо этого там очень-очень-очень много скриншотов и небольших демо, которые наглядно демонстрируют утилиту и её возможности.
Всем привет!
Если вам надоел k9s или вы хотите «что-нибудь» новое, то LFK может вас заинтересовать!
Да, всё так – ещё один TUI для работы с кластером Kubernetes.
Он предлагает следующее:
🍭 Удобная навигация от кластера то метаинформации о существующих ресурсах
🍭 Отображение данных о потребляемых ресурсах
🍭 Vim-style навигация!
🍭 Работа с несколькими кластерами
🍭 Разные возможности по работе с ресурсами: от поиска до создания и изменения
🍭 Возможность персональной настройки и ещё много всего
Детальное описание возможностей LFK представлено в GitHub-репозитории.
Помимо этого там очень-очень-очень много скриншотов и небольших демо, которые наглядно демонстрируют утилиту и её возможности.
GitHub
GitHub - janosmiko/lfk: ⚡ LFK is a lightning-fast, keyboard-focused, yazi-inspired terminal user interface for navigating and managing…
⚡ LFK is a lightning-fast, keyboard-focused, yazi-inspired terminal user interface for navigating and managing Kubernetes clusters. Built for speed and efficiency, it brings a three-column Miller c...
👍2❤1