🖼️ Distroless Контейнеры или минимализм ради безопасности и эффективности

В эпоху, когда любой проект зависит от модулей (да-да, log4j тому яркий пример) концепция distroless контейнеров от Google выступает как маяк безопасности. Эти контейнеры, лишенные лишнего балласта в виде стандартных инструментов и библиотек операционных систем, представляют собой идеальное сочетание минимализма и функциональности. Но что делает их такими особенными и почему они становятся неотъемлемой частью современной разработки и кибербезопасности?

🤨 Что это такое

Distroless контейнеры — это как "рюкзаки" для вашего приложения, в которые вы кладете только самое необходимое для путешествия. Если обычный контейнер — это рюкзак, в который вы упаковали не только теплую куртку, но и кучу вещей "на всякий случай", которые в итоге только занимают место и утяжеляют ваш багаж, то distroless контейнер очень легкий и содержит только то, что действительно нужно вашему приложению для работы.

🤨 Как это работает

Ключ к созданию distroless контейнера лежит в использовании минимального базового образа, который включает в себя только необходимые библиотеки и зависимости для запуска конкретного приложения. Google предоставляет несколько таких базовых образов через свой проект google/distroless на 💻 GitHub, которые поддерживают языки программирования, такие как Java, Python (применяется в проекте), Go (применяется в проекте), Node.js и другие.

Спасибо @szybnev за рекомендацию

🤨 Что в них такого особенного

🔵 Углубленная Безопасность

Отсутствие shell и лишних утилит сокращает векторы атак, затрудняя эксплуатацию уязвимостей злоумышленниками.

🔵 Эффективность и Производительность

Минимализм distroless контейнеров ведет к уменьшению их размера, что обеспечивает более быструю доставку и развертывание приложений. Да, не такой уж и важный фактор в домашних условиях, но для микросервисной архитектуры это очень хороший способ уйти от 40-минутного развёртывания одного проекта 🥺.

🤨 За пределами очевидного

🔵 Статическая связь как искусство — Distroless контейнеры идеально подходят для статически слинкованных приложений, где все необходимые библиотеки включены непосредственно в исполняемый файл.

🔵 Упрощение CI/CD — Интеграция в процессы непрерывной интеграции и доставки становится более стройной и эффективной благодаря сокращению времени сборки и развертывания, что способствует более быстрому циклу разработки.

Разберём на примере 💻 Gitlab CI/CD и 💻 Kubernetes

FROM golang:1.21.4 AS build

WORKDIR /src
COPY . .
RUN CGO_ENABLED=0 go build -o /bin/app

FROM gcr.io/distroless/base-debian10
COPY --from=build /bin/app /

CMD ["/app"]

❕ Пример использования в gitlab-ci.yml

stages:
  - build
  - deploy

variables:
  # Указываем ваш registry
  DOCKER_IMAGE_NAME: $CI_REGISTRY

build:
  stage: build
  image: docker:19.03.12
  services:
    - docker:19.03.12-dind
  script:
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - docker build -t $DOCKER_IMAGE_NAME:$CI_COMMIT_SHA .
    - docker push $DOCKER_IMAGE_NAME:$CI_COMMIT_SHA

deploy:
  stage: deploy
  image: alpine:latest
  script:
    - apk add --no-cache kubectl
    - kubectl config set-cluster default --server=$KUBE_SERVER --certificate-authority=/etc/deploy/ca.pem
    - kubectl config set-credentials default --token=$KUBE_TOKEN
    - kubectl config set-context default --cluster=default --user=default
    - kubectl config use-context default
    # Указываем использование нашего Distroless контейнера
    - kubectl set image deployment/my-deployment my-container=$DOCKER_IMAGE_NAME:$CI_COMMIT_SHA --namespace=my-namespace
  only:
    - main

😜 Заключение

Distroless контейнеры от Google предлагают уникальный подход к развертыванию приложений, где безопасность и эффективность идут рука об руку с минимализмом и функциональностью. Эта технология открывает новые горизонты для разработчиков, стремящихся к созданию легковесных, безопасных и высокопроизводительных приложений.

#devsecops

🎁 Dev(Sec)Ops RoadMap как найти работу
#карьера #devsecops

В чате канала вчера спрашивали про roadmap для DevSecOps. Что нужно учить?

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

Но мы же люди ленивые? Лично я, да. Все всегда хочется искать что-то самостоятельно, а найти готовый roadmap или mindmap, где за вас умные люди составили график, что вам нужно учить. В таком случае нашёл для Вас несколько интересных материалов:

А Вы точно уверены, что перед тем как стать DevSecOps, вы изучили инструменты DevOps и научились применять эти практики?

▶️ Если нет, то возвращаемся к пункту 1, за красной таблеткой. Если же вы выбурили синюю таблетку, то вот мой ответ на вопрос: "Что нужно знать DevOps инженеру?"
Управления версиями: Gitlab
Инструменты CI/CD: Jenkins, Gitlab, (набирает популярность Agro CD)
Оркестрация контейнеров: kubernetes, docker-compose (более редко необходим Docker Swarm, OpenShift)
Автоматизация развертывания: Ansible, Terraform
Языки программирования: Python, Bash, Go
Хранение секретов: Vault
Мониторинг: Prometheus, Grafana [ Zabbix много где используется, но с контейнеризацией работает хуже, чем его аналоги, поэтому некоторые компании полностью или частично переезжают с него ]
Логгирование: ELK

Если слова выше для вас не показались чем-то незнакомым или как говорит мой друг, "на эльфийском языке", то поздравляю, Вы DevOps инженер :)

▶️ Возвращаясь к теме поста, что нужно учить DevSecOps? Всё то, что знает DevOps и:
Поиск секретов: GitGuardian, Gitleaks, truffleHog, DeepSecrets (последнее от моего знакомого Николая из Yandex, у его инструмента не стандартный подход к поиску секретов)
SCA: Snyk, Syft, Cdxgen, Trivy, Dependency Track
SAST: Semgrep (много фолзит, использовать только вкупе с чем-то), Bearer, CodeQL, Spotbug, Terrascan
DAST: OWASP ZAP, nuclei, Dastardly
Container Security: Grype, Open Policy Agent, kube-hunter (активно не поддерживается), kube-bench , Falco, Tracee, Anchore (активно не поддерживается), Clair

⭐️ Как-то так. На самом деле список тулз у DevSecOps постоянно пополняются. И тем более приходится писать что-то под свои задачи. Надеюсь было полезно. Но DevSecOps

Также отдельное спасибо @belka_e

Отмечу, что сейчас сам занимаюсь разработкой и по сути у меня нет коммерческого опыта ни в разработке, ни в DevSecOps. Так что узнаю всё по ходу выкладывания постов. Но большое спасибо коллегам, кто готов помогать мне!

Выводы:
1. У нас очень мало DAST'ов опенсоурсных, да и коммерческих качественных рабочих решений тоже мало.
2. Простор для разработки коммерческих решений огромен, как и потенциал этой области.
3. DevOps не очень сложно обучиться, а вот DevSecOps уже даёт прикурить знатно, проверено на себе.
4. Методологии и инструменты DevSecOps мало где применяются, так что рынок ждёт новых решений и подходов.
5. Когда я слышал про заоблачные ЗП devsecops инженеров, думал что ситуация как с MLщиками и Data Science в своё время, но нет. Тут реально огромный пул знаний, который включает в себя ещё по меньшей мере appsec и даже пентест.

❤️ @poxek

🤓 Установка Gitlab CE + Gitlab Runner + Gitlab Registry 🖼️
#devsecops #devops #разработка

GitLab — инструмент для совместной работы над проектами разработки программного обеспечения. Он обеспечивает хранение и управление репозиториями Git, а также контроль версий программного кода. GitLab автоматизирует процессы CI/CD: сборку, тестирование и развертывание ПО. Для запуска и автоматического выполнения задач CI/CD в GitLab используется приложение GitLab Runner.

⚖️ Подготовка:
1. Вам нужен сервер на 🖥 Ubuntu 22.04 с минимальными характеристиками 4 Гб ОЗУ и 4 ядра. Я же рекомендую 8 Гб ОЗУ и 8 Ядер.
2. Вам нужен домен.
3. В доменном регистраторе сделайте 2 поддомена: gitlab. и registry.gitlab. и создайте A записи с IP своего сервера
4. Выполнить минимальную настройку по этому гайду и выполнить ssh-keygen -t ed25519

📌 ed25519 более новый стандарт, чем RSA и сейчас best practice использовать этот алгоритм

⚖️ После настройки сервера:
5. Создаете нового пользователя, выдаёте права и добавляете свой ssh ключ в ~/.ssh/authorized_keys
6. Установим zsh как оболочку по умолчанию: chsh -s /bin/zsh
7. Замените в /etc/ssh/sshd_config с # Port 22 на Port 4422. Чтобы наш ssh сервер не мешал гитлабовскому
9. Отключим IPv6 для ufw
sed -i 's+IPV6=yes+IPV6=no+g' /etc/default/ufw
8. Добавьте необходимые порты в ufw: ufw allow 80; ufw allow 443; ufw allow 22; ufw allow 4422; ufw enable и тыкаете y
9. Далее создаете docker-compose.yml

version: '3.8'
services:
  gitlab:
    container_name: gitlab-ce
    image: 'gitlab/gitlab-ce:latest'
    restart: always
    hostname: 'gitlab-ce'
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        external_url 'https://gitlab.redacted.com'
        registry_external_url 'https://registry.gitlab.redacted.com'
        gitlab_rails['registry_enabled'] = true
        letsencrypt['enable'] = true
        letsencrypt['contact_emails'] = ['ВАША_ПОЧТА']
        letsencrypt['auto_renew'] = true
    ports:
      - '80:80'
      - '443:443'
      - '22:22'
    volumes:
      - '/opt/gitlab/config:/etc/gitlab'
      - '/opt/gitlab/logs:/var/log/gitlab'
      - '/opt/gitlab/data:/var/opt/gitlab'
    networks:
      - gitlab

  gitlab-runner:
    container_name: gitlab-runner
    image: gitlab/gitlab-runner:latest
    restart: always
    hostname: 'gitlab-runner'
    depends_on:
      - gitlab
    volumes:
      - '/opt/gitlab-runner/data:/home/gitlab_ci_multi_runner/data'
      - '/opt/gitlab-runner/config:/etc/gitlab-runner'
      - '/var/run/docker.sock:/var/run/docker.sock:rw'
    environment:
      - CI_SERVER_URL=https://gitlab.redacted.com/ci
    networks:
      - gitlab

networks:
  gitlab:
    name: gitlab-network

10. Запускаете конфигурацию docker compose up -d . И ждём... Если скучно, то можно следить за ходом установки docker logs --follow gitlab-ce

12. Посмотрим пасс от аккаунта админа: grep 'Password: ' /opt/gitlab/config/initial_root_password
13. Переходим на gitlab.redacted.com и авторизуемся root:пасс_из_файла

Если всё получилось поднимаю за вас бокал гранатового вина 🍷
Если не получилось, то несу вам тонометр

⚖️ Настройка Gitlab:
0. Проверяем, что все нужные сервисы запустились в разделе Features и потом проверяем health_check
1. Сразу отключаем регистрацию других пользователей (хоть им и потребуется подтверждение от админа, но кто знает какая CVE будет в будущем). Для этого идём сюда и в разделе Sign-up restrictions убираем галочку у Sign-up enabled
2. Далее создадим своего пользователя. Обязательно ставим, что пользователь Administrator
2.1. Возвращаемся на шаг назад и нажимаем Edit по пользователю и задаем ему пароль
3. Логинимся под новым аккаунтом, нас попросит изменить пароль, но мы можем указать во все 3 поля одинаковый пароль
4. Удаляем пользователя root
5. Настроим рейт лимиты. Я поставил 10 запросов на IP и бан на 24 часа + поставил веселый текст для тех, кто будет фаззить мой сервер :))
6. Отключил рекламу и по фану поставил себе первый рабочий день Monday

⚖️ Далее можете поставить себе темную тему, добавить свои ssh ключи и радоваться жизни с полноценным Gitlab CE

🌚 @poxek

Secure Coding Cheatsheets
#appsec #dev #devsecops #red_team #blue_team #SSDLC

Статья на тему безопасной разработки. В статье автор разобрал примеры уязвимостей в коде и как их избегать.

Кому полезен материал: appsec'арям, пентестерам, devsecops'ам и разрабам естественно

Также он показывает примеры не на одном языке, а на:
➡️ C#(.Net)
➡️ PHP
➡️ Go
➡️ Python
➡️ Java
➡️ Android Java
➡️ iOS Swift

Полезно почитать всем, по факту он выбрал самые популярные технологически стеки.
Автор разобрал следующие уязвимости:
➡️ Broken Access Control (Небезопасная управление доступом)
➡️ Cryptographic Failures (Криптографические недостатки)
➡️ Injection (Инъекции)
➡️ Insecure Design (Небезопасный дизайн проектирования)
➡️ Security Misconfiguration (Небезопасная настройка чего либо)
➡️ Vulnerable and Outdated Components (Уязвимые и/или не обновленные компоненты)
➡️ Inadequate Supply Chain Security (Уязвимость в цепочке поставок)
➡️ Insecure Authentication/Authorization (Небезопасная аутентификация/авторизация)
➡️ Insufficient Input/Output Validation (Недостаточная фильтрация ввода/вывода)
➡️ Insecure Communication (Небезопасная передача информации)
➡️ Improper Credential Usage (Неправильное хранение учетных данных)
➡️ Inadequate Privacy Controls (Неправильный контроль конфиденциальности)

Каждый найдет для себя что-то)

➡️ Статеечка

🌚 @poxek

👩‍💻 Attacking NodeJS Application.

- Use flat Promise chains;
- Set request size limits;
- Do not block the event loop;
- Perform input validation;
- Perform output escaping;
- Perform application activity logging;
- Monitor the event loop;
- Take precautions against brute-forcing;
- Use Anti-CSRF tokens;
- Prevent HTTP Parameter Pollution;
- Do not use dangerous functions;
- Use appropriate security headers;
- Listen to errors when using EventEmitter;
- Set cookie flags appropriately;
- Avoid eval(), setTimeout(), and setInterval();
- Avoid new Function();
- Avoid code serialization in JavaScript;
- Use a Node.js security linter;
- References.

#devsecops

<Cookie> ctrl+c ctrl+v: автоматизируем прохождение авторизации в DAST
#red_team #appsec #devsecops

Представьте: на дворе 2024 год, вы работаете AppSec-специалистом в российской компании и решаете приобрести готовый сканер DAST, который запускается одной кнопкой. Идет импортозамещение в IT-отрасли, отечественные вендоры создали несколько решений на замену зарубежным. Самые популярные – Solar appScreener, Positive Technologies Black Box и SolidWall DAST. Все они включают опцию прохождения аутентификации по форме на странице.

И тут возникает проблема: у вас SSO или другая user-friendly многостраничная авторизация. А в настройках страница обязательно должна содержать два поля для ввода логина и пароля и одну кнопку. Конечно, можно просто подставить валидные cookie или токен, но тогда готовое решение каждый раз будет просить вас повторно пройти аутентификацию и обновить необходимую информацию для доступа. Согласитесь, выглядит как отличная задача для стажеров вашего отдела.

Статья очень актуальная, свежая и я думаю не только для меня наболевшая тема. Поэтому приятного и полезного прочтения)
➡️ Читать далее

🌚 @poxek

Как провести фаззинг REST API с помощью RESTler (все 3 части)
#red_team #appsec #devsecops #api #fuzzing

Предположу, что многие из вас сталкивались с задачей, когда нужно проверять безопасности API, и желательно автоматизированного. Все мы работаем в разных компаниях, где-то используются одни технологии, где-то другие. Но API есть API, тестировать его нужно. Поэтому в этом посте я советую вам прочитать все цикл статей от коллег из Swordfish Security, которые в подробностях написали, как же провести фаззинг-тестирование API c помощью инструмента RESTler, имея на руках только спецификацию API.

1️⃣ Первая часть

2️⃣ Вторая часть

3️⃣ Третья часть

В результате их исследования по API fuzzing они смело смогли сделать вывод, что RESTler – это первый автоматический инструмент для анализа состояния облачных сервисов через их REST API, позволяющий максимально точно настраивать процесс тестирования. Благодаря этому фаззер можно использовать для многих целей.

🌚 @poxek

DevSecOps Assessment Framework (DAF)
#devsecops #assesment

От себя скажу сразу, что пока не тестил, но хорошие знакомые сказали, что штука годная. Если выбираете какой фреймворк использовать, можете начать обкатку с этого. Если что, в чате есть несколько Джетовцев, можно будет направить вопрос в нужный отдел)

Есть множество полезных фреймворков, позволяющих оценить процессы безопасной разработки, например, SAMM, BSIMM, DSOMM, MSDL. Также есть лучшие практики, бенчмарки, рекомендуемые подходы к защите контейнеров и сред контейнерной оркестрации, такие как NSA Kubernetes Hardening Guide, или, например CIS for Kubernetes. Помимо этого, существует множество инструментов, повышающих защищенность при формировании и совершенствовании процессов DevSecOps (SAST, DAST, SCA, Container security, Secret management и другие) со своими рекомендациями по настройкам и их использованию. Но нет чего-то одного, описывающего, что конкретно и в какой последовательности нужно делать, чтобы выстроить процесс безопасной разработки, а также чтобы объективно оценить существующий уровень зрелости безопасной разработки и понять, куда двигаться дальше.

Эту проблему призван решить DevSecOps Assessment Framework (DAF). Он включает в себя не просто набор рекомендаций и лучших подходов из разных областей DevSecOps, но еще и большой экспертный опыт нашего сообщества, структурированный и адаптированный под современные реалии. Некоторые практики из общеизвестных фреймворков не добавлены в DAF, но при этом сформированы новые и более детальные. Все модели, домены, поддомены и практики описаны понятным языком во избежание двусмысленностей и разных толкований.

В открытый доступ выложены не все наши наработки по DAF. Но мы считаем, что основная часть фреймворка DAF все же должна быть публичным достоянием

💻 Github repo

🌚 @poxek | 📹 YouTube | 🌚 Мерч Похек

Abusing GitLab Runners
#gitlab #devsecops

Не самая новая техника hijack'а других gitlab runner'ов, но тем не менее эффективная, если вы получаете доступ к gitlab и/или токен раннера. В этой статье автор хотел бы объяснить, что такое Runners, как они работают и как вы можете использовать их во время пентестов.

➡️Research

➡️Github PoC

Использование:

usage: hijack-runner.py [-h] [--target TARGET] [--register REGISTER] [--attack ATTACK] [--tag TAG]
                        [--clone]

Abuse GitLab Runners

optional arguments:
  -h, --help           show this help message and exit
  --target TARGET      The GitLab instance to target
  --register REGISTER  Register a token
  --attack ATTACK      Use Runner token to steal data
  --tag TAG            Taglist separated with commas
  --clone              Will clone the repo locally

🌚 @poxek | 📺 YT | 📺 RT | 📺 VK | 🌚 Магазин мерча

IaC и DevSecOps: выбираем лучшие инструменты анализа и защиты инфраструктурного кода
#IaC #DevSecOps #appsec #безопаснаяразработка

Сегодня мы вновь будем говорить об особенностях статического сканирования, но на этот раз переключим фокус с программного кода на код инфраструктурный.

Частично этот вопрос обсуждался в статье про безопасность контейнеризированных приложений в DevSecOps. В этой статье будут рассмотрены краткие теоретические сведения о подходе “Инфрастуркутра как кодˮ, место безопасности IaC в цикле DevSecOps, методы статического анализа конфигурационных файлов и ключевые особенности работы с инструментом KICS.

➡️Читать далее

🌚 @poxek | 📺 YT | 📺 RT | 📺 VK | 🌚 Магазин мерча

Привет, Похекеры! Сегодня у нас на разделочной доске новая тулза от Synacktiv – Octoscan. Если вам, как и мне, приходиться копаться в GitHub в поисках секретов/API ключей или иных недосмотров разрабов, то этот инструмент точно для вас.

Octoscan – это скрипт на Golang, который автоматизирует процесс сбора информации о GitHub-организациях и пользователях. Зачем это нужно? ☯️ Ну, представьте, что вы пентестите компанию и хотите узнать, какие репозитории они используют, какие сотрудники имеют доступ к критически важным данным, какие секреты случайно закоммитили в публичные репозитории (дада, такое ещё бывает). Octoscan поможет вам собрать все эти данные в одном месте.

➡️Что умеет Octoscan?

▪️Собирает информацию об организациях: список репозиториев, участников, команд.
▪️Ищет секреты в коде: API-ключи, пароли, токены.
▪️Анализирует историю коммитов: выявляет потенциально уязвимые места.
▪️Генерирует отчеты в формате JSON и Markdown.

Как это работает?

Octoscan использует API GitHub для сбора информации. Вам понадобится токен доступа, чтобы не упираться в лимиты API. Скрипт довольно прост в установке и использовании:

Установка из сорцов: go mod tidy; go build
Установка через докер: docker pull ghcr.io/synacktiv/octoscan:latest
Использование: octoscan dl --token ghp_<token> --org apache --repo incubator-answer

➡️Почему это круто?
Octoscan экономит кучу времени при проведении разведки в GitHub. Вместо того, чтобы вручную перебирать репозитории и профили пользователей, вы можете получить всю необходимую информацию за несколько минут. Это особенно полезно при пентесте больших организаций с множеством репозиториев.

➡️Для кого это?

Пентестеры: для автоматизации сбора информации о целях.
Багхантеры: для поиска уязвимостей в публичных репозиториях.
DevSecOps: для мониторинга репозиториев на наличие секретов и уязвимостей.

➡️Что касается аналогов, вот несколько альтернативных инструментов для GitHub reconnaissance:

GitGot (последнее обновление год назад): Инструмент для поиска конфиденциальной информации в публичных репозиториях GitHub.
Gitrob (официально в архиве с 2023 года): Инструмент для поиска потенциально конфиденциальных файлов, закоммиченных в публичные репозитории.
TruffleHog (классика, но немного не та направленность): Сканирует репозитории на предмет секретов, используя энтропию и регулярные выражения.
Gitleaks (классика, но немного не та направленность): Инструмент для обнаружения хардкоженных секретов и других конфиденциальных данных в Git-репозиториях.

p.s. octoscan получил последнее обновление месяц назад :)

➡️ Ссылка на репозиторий: https://github.com/synacktiv/octoscan

#pentest #github #reconnaissance #security #infosec #CICD #appsec #devsecops

Миша Черешнев из Swordfish Security – Безопасность контейнеров и о жизни в devsecops
#подкаст #DevSecOps #container #контейнеры

Миша расскажет о своем пути в ИБ и о текущей работе. Будет немного о Cloud Native, Rekor и о том, как пройти у него собес.

➡️Таймкоды
00:00 Вступление
00:25 Как попасть в ИБ
00:50 Чем DevSecOps отличается от AppSec?
01:59 Что такое контейнерная безопасность?
04:10 Что такое Supply Chain
07:44 Атаки на Supply Chain
21:39 Уровень развития ИБ в РФ
24:48 Недостатки ИБ в РФ
25:26 Вопросы с собеседований ИБ
29:42 Блиц
30:34 Заключение

🔗 Заценить подкастик

🌚 @poxek | 🌚 @poxek_backup | 📺 YT | 📺 RT | 📺 VK | 🌚 Магазин мерча

🖼️ Kubernetes Security Hardening: от основ до продвинутых техник защиты
#k8s #security_hardening #kubernetes #container #контейнер #devsecops #appsec

Кластеры Kubernetes, будучи основой современной облачной инфраструктуры, часто становятся привлекательной мишенью для атак. Согласно данным от NSA и CISA, Kubernetes обычно атакуют с тремя основными целями: кража данных, использование вычислительных ресурсов (например, для майнинга криптовалюты) и организация DDoS-атак. В этой статье мы разберем комплексный подход к настройке безопасности Kubernetes от простых базовых мер до продвинутых техник защиты.

➡️Уровни безопасности Kubernetes
Прежде чем начать настройку безопасности, важно понимать, что защита Kubernetes должна осуществляться на нескольких уровнях:

1️⃣ Безопасность на уровне хоста (Host Level Security)
Это базовый уровень защиты, включающий настройку безопасности непосредственно на серверах, где запущены компоненты Kubernetes.

2️⃣ Безопасность на уровне кластера (Cluster Level Security)
Этот уровень включает настройку безопасности компонентов управления Kubernetes, API-сервера, etcd и других критических компонентов.

3️⃣ Безопасность на уровне рабочих нагрузок (Workload Level Security)
Этот уровень относится к безопасности развертываемых приложений, контейнеров и объектов Kubernetes.

🔗Читать дальше

p.s. я только погружаюсь в тему, могут быть ошибки или пробелы в знаниях. Открыт к доработке статьи, пишите в комментах ваши пожелания, что добавить в статью или какую ещё тему разобрать связанную с k8s.

🌚 @poxek | 🌚 blog.poxek.cc | 📺 YT | 📺 RT | 📺 VK | 🌚 Магазин мерча

CI/CD под прицелом: реальные сценарии атак и методы противодействия
#CICD #DevSecOps #AppSec #IAM #cloud #облако #безопаснаяразработка

Почему CI/CD так важен? Он представляет собой автоматизированный конвейер сборки и доставки ПО и, если говорить в контексте безопасности, существует целый ряд критичных инцидентов безопасности, например внедрение бэкдоров в ПО, подмена артефактов (supply chain), утечка чувствительных данных клиентов, компрометация deployment environment и так далее.

🔗 А если посмотреть на проблемы в контексте разработки публичного облака?

🌚 @poxek | 🌚 Блог | 📺 YT | 📺 RT | 📺 VK | 🌚 Мерч

Cellebrite + Corellium = 😧
#mobile #Apple #cellebrite #corellium #DevSecOps

Cellebrite объявила о соглашении по приобретению Corellium — лидера в области виртуализации Arm-устройств. Эта сделка объединяет передовые технологии и экспертизу обеих компаний, чтобы вывести на новый уровень исследования уязвимостей, анализ вредоносного ПО, DevSecOps для смарт-устройств и мобильный пентест. Благодаря этому решению клиенты из госсектора, обороны, разведки и частного бизнеса получат:
➡️Более быстрое выявление уязвимостей и эксплойтов для мобильных устройств
➡️Возможность интерактивно работать с виртуальными устройствами, что существенно ускорит расследования и разработку
➡️Повышенную эффективность и скорость DevSecOps для всех устройств на базе Arm
➡️Динамичный, нативный мобильный пентест

Corellium интегрирует свою уникальную платформу виртуализации, позволяя специалистам буквально «гулять» по устройству, исследовать его содержимое без риска изменения данных. Основатель Corellium Крис Уэйд станет новым CTO Cellebrite. Сделка оценивается в $170 млн наличными плюс до $30 млн при достижении определённых KPI за два года. Ожидается, что приобретение расширит присутствие Cellebrite в обоих секторах рынка, а также усилит её платформу цифровых расследований и решения для безопасной разработки IoT, мобильных и автомобильных систем. Закрытие сделки запланировано на лето 2025 года, после одобрения регуляторов.

🔗Источник

Также нашёл статью с историями, как взламывали смартфоны ВОТь. Автор статьи админ канала

🌚 @poxek | 🌚 Блог | 📺 YT | 📺 RT | 📺 VK | 🌚 Мерч

Security Gate (DevSecOps cicd)
#devsecops #appsec #CICD #SAST #DAST #SCA #docker

Предисловие
Всем приветы! Меня зовут Антон, я Tech Lead DevSecOps в местной биг-тех компании. Хочу начать с кратенького предисловия, почему я решил написать что-нибудь про DevSecOps. Я довольно-таки часто сталкиваюсь с непониманием, что же автоматизируют и для чего нужны DevSecOps инженеры, где их место в компании и в современном ИБ. Да и что далеко ходить, многие коллеги DevOps, сами считают, что с добавлением trivy или sonarqube в пайплайны, ты уже носишь гордое звание DevSecOps.

🔗Поэтому в этой статье поговорим о том, как должны выглядеть DevSecOps пайплайны, чтобы они трансформировались во что-то зрелое. В Security Gate!

🌚 @poxek | 🌚 Блог | 📺 YT | 📺 RT | 📺 VK | 🌚 Мерч

TARmageddon — баг в библиотеке async-tar и ее форках (Rust)
#TARmageddon #devsecops #CVE #Rust #tar

TARmageddon (CVE-2025-62518) — логическая уязвимость в экосистеме async-tar и ее форках tokio-tar и astral-tokio-tar. Парсер ориентируется на значение из ustar-заголовка, которое может быть нулевым, при этом игнорируется или не согласуется PAX-size. В результате реальный блок данных остается в потоке и его заголовки интерпретируются как новые записи внешнего архива.

➡️Что дает эксплуатация

RCE/hijack сборки — при установке/распаковке пакета атакующий может привести к перезаписи файлов конфигурации сборки, что позволяет перенаправить сборку на вредоносный backend и исполнить код в CI/локальной среде.
Bypass сканеров/supply-chain contamination — сканер проверяет чистый внешний TAR и помечает пакет как безопасный, затем уязвимый распаковщик вносит незадекларированные файлы в результирующий артефакт/deploy.

➡️Эксплуатация

Создаем внешний TAR, где для одной записи в PAX-extended-header указано size > 0, а в стандартном ustar-заголовке поле размера равно 0 (ustar size хранится в восьмеричном виде).
В теле этой записи лежит вложенный TAR, начинающийся с корректных TAR-заголовков (в PoC помечены как INNER_FILE).
Корректные реализации (например, GNU tar) при распаковке дадут последовательность normal.txt -> blob.bin -> marker.txt, уязвимые парсеры — normal.txt -> blob.bin -> INNER_FILE -> marker.txt.
Появление INNER_FILE в выводе уязвимого парсера — индикатор бага.

➡️Как защититься

Обновить до патченых версий или заменить на активно поддерживаемую реализацию, например на патч-ветку/форк, рекомендованный исследователями.
Распаковывать архивы в изолированные песочницы, валидировать содержимое против ожидаемого манифеста/контента до переезда в рабочую директорию, запрет перезаписи ключевых файлов и post-extract-сканирование на неожиданные записи. 
Идентифицировать проекты, использующие уязвимые библиотеки, и приоритезировать обновления/ремедиацию в supply-chain.

🔗Источник
🪲PoC

🌚 @poxek | 📲 MAX |🌚 Блог | 📺 YT | 📺 RT | 📺 VK | ❤️ Мерч

PromptPwnd: Как AI-агенты взламывают CI/CD пайплайны
#appsec #llm #prompt #ai #agent #cicd #pipeline #devsecops

Исследователи из Aikido Security продемонстрировали новый класс атак PromptPwnd, который использует уязвимости prompt injection в AI-агентах, интегрированных в CI/CD. Это первая подтвержденная демонстрация компрометации CI/CD в реальных условиях через AI, уже затронувшая как минимум пять компаний из списка Fortune 500.

➡️Механика атаки: Просто, но эффективно

Атака эксплуатирует предсказуемый рабочий процесс: недоверенные данные, такие как заголовки issue или описания pull request, напрямую вставляются в промпт, который обрабатывает AI-агент. Манипулируя этим текстом, злоумышленник может заставить агента выполнить несанкционированные действия. В PoC-атаке на Google Gemini CLI, вредоносные инструкции, спрятанные в issue, заставили агента слить секретные ключи (API keys, токены доступа) прямо в публичный тред.

➡️Три кита уязвимости

PromptPwnd становится возможным при совпадении трех фундаментальных недостатков безопасности:

1. Прямое внедрение недоверенных данных: Пользовательский контент без санации попадает в AI-промпты.
2. Слепое доверие к AI: Вывод AI-модели ошибочно считается доверенным и исполняется в CI/CD.
3. Избыточные привилегии: AI-агентам предоставляются высокопривилегированные токены и доступ к инструментам, включая выполнение shell-команд.

➡️Почему это критично?

• Supply Chain Risk: Атака компрометирует не просто отдельное приложение, а весь пайплайн разработки, открывая возможность для внедрения бэкдоров в код.
• Низкий порог входа: Не требуется сложных эксплойтов — достаточно грамотно составленного текста.
• Широкая поверхность атаки: Любой, кто может создать issue или pull request, потенциально может инициировать атаку.

➡️Как защититься?

Защита от PromptPwnd требует многоуровневого подхода, основанного на принципе Zero Trust по отношению к AI-агентам:

• Ограничивайте права: Предоставляйте агентам минимально необходимые привилегии. Отключайте выполнение shell-команд и модификацию репозиториев, если это не является абсолютно необходимым.
• Контролируйте триггеры: Ограничьте запуск AI-воркфлоу только для доверенных пользователей, избегая автоматического запуска от публичных issue.
• Валидируйте вводы и выводы: Тщательно очищайте все недоверенные данные перед передачей в AI и валидируйте вывод модели перед исполнением.
• Используйте короткоживущие токены: Минимизируйте риски утечки, используя токены с ограниченным сроком действия и узкой областью видимости.
• Внедряйте аудит и мониторинг: Регулярно проверяйте активность AI-агентов, их права и конфигурации.

🔗Источник

🌚 @poxek | 📲 MAX |🌚 Блог | 📺 YT | 📺 RT | 📺 VK | ❤️ Мерч