Иногда кажется, что именно так и происходит 🙃

#lol

🛠🏆 AppSec Labs to pump yourself up Release v.1.5.0

Салюты,
Разместил линк тут - course.geminishkv.tech

Интересный апдейт для тебя про который хотел бы рассказать про лабки, которые делал ранее. Да, именно те лабки, которые покажут тебе основные команды инструментов, как работать с ними, что такое база для работы в AppSec и тд. С ними у тебя получится качать себя и да, в лабах есть намеренные косяки, что бы ты смог разобраться, потому что бездумно копируя и смотря лог - маловероятно, что ты получишь какую то прокачку для себя.

Доработанные материалы в новом релизе

• Добавлено описание и Mermaid-карта лабораторных работ в README.md
• Добавлена информация по pet_project и lab09 в README.md и docs/index.md
• Актуализированы конфиги линтеров и инструментов сборки: .gitattributes, .gitignore, .dockerignore, ruff.toml, mypy.ini, .markdownlint.yaml
• Полностью переписан .dockerignore
• Устранён баг сборки MkDocs: удалена несуществующая страница Metro4Shell.md из навигации mkdocs.yml
• Выровнены отступы в sidebar: переработаны стили sidebar.css
• Обновлены shields на главной странице сайта: добавлены бейджи инструментов безопасности (Semgrep, Checkov, Trivy, OWASP ZAP, Nmap) и GitHub-метрики
• Добавлены тестовые задания по лабораторным работам
• Прочие доработки

Stay Tuned 😉

#appsec #devsecops #roadmap #specialty #toolchain #techsolution #gost #paper #course #reco #sast #sca #dast #sbom #containersecurity #secrets #riskanalys #techsolution

🤔 I.N.V.E.S.T. как пилюля от боли недопонимания

Сегодня хочу еще немного затронуть проектное управление, давай поговорим с тобой про I.N.V.E.S.T. принцип.

I.N.V.E.S.T. используется как фильтр для задач, чтобы не тащить в текущий спринт «все подряд». По сути это: Independent, Negotiable, Valuable, Estimable, Small, Testable таски, которые помогают градировать нам нагрузку и понимать чего от нас хотят, так как ты постоянно будешь сталкиваться с кейсами: "я не понимаю куда мы движемся", "я хочу все и вся", "не ясно, что надо сделать" и т.д.

В AppSec, как и везде, часто прилетает «сделайте безопасную безопасность». Это не задачи, а реальная головная боль. I.N.V.E.S.T. помогает превратить боль в нормальные user‑story и технические задачи, то есть:

• понятные команде
• дающие измеримый эффект
• которые реально можно закрыть за спринт
• и проверить, что они сработали

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

• I — Independent

История должна жить отдельно: можно взять и сделать без половины департамента
Пример плохой: «Сделать безопасный логин, регистрацию, восстановление пароля и профили»
I.N.V.E.S.T.: «Добавить rate limiting на POST /login с логированием блокировок»

• N — Negotiable

История, как приглашение к разговору, где детали можно уточнить с командой до начала спринта
Если задача звучит как «строго по ГОСТу XXX, без вариантов» — это уже скорее политика, а не user story

• V — Valuable

Должно быть понятно, кому и какую ценность даёт история: пользователю, бизнесу, безопасности
Пример: «Включить ещё один сканер» — не ценность.
I.N.V.E.S.T.: «Сократить критические уязвимости в проде, добавив Quality Gate на уровне CI» - становится ценностью

• E — Estimable

Команда должна понимать объём: хотя бы порядок — день, три, спринт
Если история звучит как «внедрить DevSecOps», её сначала нужно дорезать до кусочков, которые можно оценить (например, «подключить SAST к проекту X») и если не провести ревью или анализ, а тебе говорят «посчитай что то там сам и предложи», - это совсем плохо

• S — Small

История должна помещаться в один спринт и, желательно, занимать не больше 25–50% спринта на команду
Всё, что звучит как «переписать модуль авторизации» — режем на отдельные шаги: логин, MFA, блокировки, аудит

• T — Testable

У истории должны быть чёткие критерии приёмки: как поймём, что она сделана - ранее писал про Win Conditions/ Fail Conditions
То есть, - «Сделать безопаснее» - не тестируется, а «при 5 неверных логинах аккаунт блокируется на 15 минут, событие уходит в SIEM» — тестируется

Как корректно подходить к задачам?

Берёшь любую хотелку и прогоняешь через INVEST:

• Независима ли она от всего остального?
• Можно ли её обсудить и переформулировать перед спринтом?
• Понятно ли, какую пользу она приносит?
• Команда может её оценить?
• Влезает ли она в один спринт?
• Можем ли мы чётко тестом/ мониторингом проверить результат?

Если хоть на один пункт ответ «нет» — история ещё сырая, и её лучше дорезать, прежде чем тянуть в спринт

Шаблон

## Заголовок

[AppSec] Кратко и конкретно: что делаем и где

## User story

Как <роль/ клиент> хочу <что именно> чтобы <какая измеримая польза/риск>

Примеры:
- Как владелец сервиса auth-service хочу ограничить число попыток логина чтобы снизить риск перебора паролей и захвата аккаунтов.
- Как AppSec-инженер хочу включить блокирующий Quality Gate по критическим уязвимостям чтобы не выпускать в прод новые критические дыры.

## Контекст (Define)

- Текущее поведение/ проблема:
  - Сейчас ...
- Затронутые системы/ сервисы:
  - auth-service, gateway, ...
- Риски/ инциденты/ мотивация:
  - Были X инцидентов/ найдено Y уязвимостей ...

## Критерии INVEST

- **Independent**
- **Valuable**
- **Estimable & Small**
- **Testable**

## Критерии приёмки (Testable)

Формат Given/ When/ Then или список

## Технические заметки (Negotiable)

- Предлагаемый подход (можно менять по итогам обсуждения):
- Ограничения и допущения:

## Метрики / контроль (Control)

- Что и как измеряем после внедрения:
- Где смотрим:

#pmi #reco #specialty #appsec #humanres #paper

Я тут побаловался с минцифры сертификатами ИТ-компетенций, решил попробовать пройти их тесты, которые так хвалят на hh и тд, в итоге: прикольно, но ничего особенного, пусть полежит тут 🙃

Думаю, что сделаю еще парочкку, для массы, также есть там прикольные вопросы конечно, но мало вообще встречаешь такое, как например git cherry-pick и то только для разрешение конфликтов при rebase через temp ветку 😅

#paper #appsec #devsecops #course

🛠 Hacktrick for Application Security

Салют,
Сегодня хочу поделиться с тобой очень объемным материалом, который залетит (как дети в школу) для твоей прокачки и понимание глубоких принципов работы безопасности - от сокета и TLS до namespaces, cgroups и секьюрных профилей ядра и т.д. Материал с описанием и деталями как ломают и как противодействовать на реальных техниках эскалации, а не только best practices из мануалов.

Что важно тебе сразу взять?

• В разделе Pentesting Methodology расписан весь цикл теста: от сбора активов и сканирования до эксплуатации и пост‑эксплуатации, с конкретными командами и тулзами
• Для Windows и Linux есть чек‑листы локальной привилегии: что смотреть в службах, правах, реестре, драйверах, файловой системе, чтобы быстро найти точку эскалации
• Отдельный раздел по Docker Security: как правильно настраивать engine, какие флаги и security‑опции использовать, как работать с сокетом, capabilities, seccomp/ AppArmor
• Есть практические страницы по Docker breakout / privilege escalation — сценарии, когда у тебя есть доступ к контейнеру или docker.sock, и ты шаг за шагом превращаешь это в root на хосте через mount’ы, привилегированные контейнеры и т.п.
• Для AWS/ GCP/ Azure есть отдельные гайды по перечислению ресурсов, поиску мисконфигов, уязвимых политикам и типовым сценариям атак в облаке
• Обучалки формата AWS Red Team Expert / GCP Red Team Expert
• Большой кусок посвящён специфике отдельных технологий: AD, SQL, веб‑фреймворки, криптопримитивы

То есть, сам HackTricks даёт не теоретическую, а операционную картинку атакующего мышления: «какие команды я запускаю, что именно проверяю, что делаю дальше, если нашёл X».

Из этого удобно собирать свои чек‑листы для ревью инфраструктуры: Docker, Windows, облака и т.д. — буквально адаптируешь под себя.

Смотри, вот пример такого чек листа под Docker Security Checklist (приметив)

**Цель:** быстро проверить, не превращён ли ваш Docker‑хост в лёгкую цель

---

## Docker Engine и daemon

- Не светить `docker.sock`  — только HTTPS + клиентские сертификаты
- Не поднимать `-H tcp://0.0.0.0:2375` без TLS
- Включить rootless‑режим и обновлять Docker/ host до актуальных патчей

***

## Образы и registry

- Использовать только официальные или свои базовые образы, не наследоваться от случайных `user/some-ubuntu-with-magic`
- В Dockerfile по возможности использовать **COPY вместо ADD**, чтобы не тянуть внешние URL и не распаковывать архивы
- Настроить регулярный пересбор образов, чтобы тянуть security‑патчи
- Подключить сканирование образов (docker scan / Trivy / Grype) — в CI и по расписанию по registry

***

## Секреты и конфиги

- Не класть токены/ ключи в image или в ENV, использовать секреты оркестратора (docker secrets/ k8s secrets/ vault)
- Проверять сохранённые образы/ слои на наличие секретов (git‑history, слои tar внутри image)

***

## Runtime‑ограничения

- Ограничить ресурсы контейнера (CPU, RAM, IO) через cgroups  
- Настроить seccomp/ AppArmor/ SELinux‑профили, сузив доступные syscalls и операции до минимума

***

## Capabilities

- Не использовать `--privileged` в проде: он даёт контейнеру почти полный набор прав ядра и сильно упрощает escape
- Базовый подход: `--cap-drop=ALL` и затем точечно `--cap-add` только тех возможностей, без которых сервис не работает (например, `NET_BIND_SERVICE` для портов 80/443)

> Capabilities позволяют вместо «полного root» выдавать контейнеру только необходимые возможности ядра; чем их меньше, тем сложнее атакующему выйти из контейнера

#appsec #devsecops #course #specialty #containersecurity #mast #dast

Салюты, нашел тут историю, которая показывает восприятие ИБ бизнесом, а именно человек оркестр 😅

#lol

🛠 Docker Level Security

Давай еще поговорим про Docker и посмотрим повнимательнее на namespaces, cgroups, chroot, capabilities, seccomp.

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

Поэтому мы разберем то, на что тебе стоит обратить внимание в первую очередь.

• FS: chroot и mount

Внутри контейнера процессы видят корень как результат mount-операций и chroot. Поэтому следует не монтировать чувствительные директории (/var/run/docker.sock, /etc, /var/lib/docker) внутрь рабочих контейнеров. Тем более для stateful сервисов использовать чётко выделенные volume.

# Смотрим mount-namespace контейнера

pid=$(docker inspect -f '{{.State.Pid}}' my-container)
lsns -t mnt -p "$pid"

• Namespaces: изоляция процессов, сети и хостнейма

Напомню, что контейнер — это набор пространств имён: PID, NET, MNT, UTS, USER. Они отвечают за то, какие процессы ты видишь, какие точки монтирования доступны и т.д. Поэтому никогда не используй --pid=host и --network=host в обычных сервисах, потому что это антипаттерн изоляции. Для отладки следует использовать nsenter, а не пробрасывать сервисы напрямую на хост.

# Сравниваем namespace контейнера с хостом

pid=$(docker inspect -f '{{.State.Pid}}' ns-demo)
lsns -p "$pid"

# Войти в namespace контейнера для отладки
nsenter -t "$pid" -n ip addr

• cgroups лимиты

Они контролируют, сколько CPU/ памяти может потреблять группа процессов. Docker создаёт группы под каждый контейнер автоматически, но лимиты нужно задавать ручками. Поэтому для всех боевых сервисов обязательно задавать лимиты --cpus и -m, иначе один runaway процесс кладёт всю ноду. В мониторинге следить за OOMKilled и CPU throttling и при превышении необходимо пересмотреть лимиты.

# Ограничить контейнер по ресурсам
docker run -d --name web \
  --cpus="1.0" \
  -m 512m --memory-reservation=256m \
  nginx:stable

# Смотреть потребление в реальном времени
docker stats web

• Capabilities

Docker по умолчанию урезает capabilities контейнера и выдает только часть привилегий ядра. Поэтому следует не использовать --privileged в проде ни при каких условиях, а также стартовая формула: --cap-drop=ALL и точечный --cap-add только того, без чего сервис реально не работает, как пример, - NET_BIND_SERVICE для портов 80/ 443.

# Посмотреть набор capabilities
docker run --rm -it alpine sh
apk add libcap && capsh --print | grep cap_

# Дропаем все, добавляем только нужное ручками
docker run --rm -it \
  --cap-drop=ALL \
  --cap-add=NET_BIND_SERVICE \
  -p 80:80 nginx:stable

• Seccomp и AppArmor

Даже когда злоумышленник внутри контейнера, - ядро может запретить опасные syscalls или операции с файлами через seccomp/ AppArmor. Docker применяет дефолтный профиль, но для чувствительных сервисов его нужно ужимать под конкретное приложение. Рекомендую включить логирование нарушений профиля, чтобы видеть попытки эскалирований и т.д. до того, как они станут эксплойтом.

# Запустить с кастомным профилем
docker run --rm -it \
  --security-opt seccomp=/opt/seccomp/web.json \
  alpine sh

# AppArmor
docker run --rm -it \
  --security-opt apparmor=docker-default \
  alpine sh

• Docker daemon и docker.sock

docker.sock это как root на хосте. Любой, у кого есть доступ к сокету, может запустить привилегированный контейнер и выйти на хост. Поэтому следует:
• не поднимать -H tcp://0.0.0.0:2375 без TLS и mTLS
• не монтировать /var/run/docker.sock в рабочие контейнеры
• для CI-раннеров использовать отдельный нод с отдельными правилами
• доступ к группам docker выдавать только с контролем Segregation-of-Duties

# Кто имеет доступ к сокету
ls -l /var/run/docker.sock
getent group docker

# Минимальный systemd-конфиг: только unix-сокет
ExecStart=/usr/bin/dockerd -H unix:///var/run/docker.sock

#appsec #devsecops #reco #specialty #containersecurity

оффтоп, на оценочку

#lol

Салюты,
Актуальное 🙃

#lol

🛠 SecScore как аналог Quality Gate

Давай сегодня посмотрим с тобой на готовое open-sourse решение, которое из коробки кастомится и просто можно переиспользовать в своих работах (почему бы и не да? если только соблюдать лицензию 🤔).

SecScore — open-source для оценки безопасности сборки путем использования принципов Quality Gate. По сути это коробочный аналог, который должен быть у всех встроен для оценки безопасности и рисков ИБ, но эта тула заточена под метрики: веса по критичности, жёсткие условия и фильтрация только новых дефектов. Я что то подобное, но более серьозное делал в РБ еще, принцип концепта я в карусель закинул, что бы ты мог посмотреть на логику работы.

Логика

• Score — каждой уязвимости присваивается вес, суммарный score сравнивается с порогом. Достигли порога тогда сборка падает
• Hard Fails — условия, при которых сборка падает безоговорочно, даже если общий score в норме, как пример:любой секрет в коде, любая Critical-уязвимость в авторизации или иные критерии которые поставишь ты для своего проекта
• Условия — можно настроить реакцию только на новые дефекты, поэтому тебе придется пилить напильником дополнительно условия исключений false [psitive/ negative сработок, тех долг контролировать через дополнительный механизм, у себя я стараюсь предлагать Jira Issue Workflow (ранее описывал это на схемке, когда трогали тему с QG тут)

Конфиг

score:
  threshold: 100

weights:
  critical: 50
  high: 20
  medium: 7
  low: 1

hard_fails:
  - severity: critical
    rule: "sql-injection"
  - severity: high
    rule: "hardcoded-secret"
  - type: secret
    severity: any
  - rule_id: "CWE-78"
    severity: critical

conditions:
  only_new: true

Пример - SecScore создаёт комментарий в PR с принятым решением и перечнем причин

name: Security Gate

on:
  pull_request:
    branches: [main]

jobs:
  secscore:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Run SAST (Semgrep → SARIF)
        run: |
          semgrep ci --sarif --output results.sarif

      - name: Run SecScore
        run: |
          secscore \
            --sarif results.sarif \
            --config secscore.yaml \
            --pr-comment \
            --github-token ${{ secrets.GITHUB_TOKEN }}

Как в итоге это работает?

• Набрали слишком много баллов, тогда мягкий порог по score
• Нашли что-то недопустимое, тогда жёсткий стоп без обсуждений (бизнес dont like it)
• Простые QG не учитывают совокупный риск и факторы
• Hard Fails фиксируют «красные линии» отдельно от числового порога
• Комфортно начинать с мягкого порога (threshold: 200) и Hard Fails только на самое критичное, ну только вменяемое и что реально аффектит проект, но для этого тебе надо ручками потриажить и построить механизм - тоже custom
• Постепенно снижается порог по мере закрытия долга
• Включить only_new: true при первом внедрении, чтобы не заблокировать весь пайплайн сразу

Пример набора условий

conditions:
  - metric: vulnerabilities_critical
    operator: GREATER_THAN
    value: 0  # ни одного Critical

  - metric: vulnerabilities_high
    operator: GREATER_THAN
    value: 5 # не больше 5 High

  - metric: coverage
    operator: LESS_THAN
    value: 80 # покрытие не ниже 80%

  - metric: duplicated_lines_density
    operator: GREATER_THAN
    value: 3 # дублирование не выше 3%

  - metric: security_hotspots_reviewed
    operator: LESS_THAN
    value: 100 # все hotspots проверены

Сноска

Quality Gate — это автоматическая проверка, через которую должен пройти код, прежде чем двинуться дальше по пайплайну. Не прошёл — сборка падает, деплой блокируется

#appsec #devsecop #reserch #toolchain #vulnmanagement #techsolution