1807
Чат для обсуждения DevSecOps и постов канала @sec_devops Вакансии: @appsec_job Услуги: https://radcop.online/
А так - докер - ни рыба, ни мясо, промежуточный этап. Который можно просто выкинуть
Читать полностью…
А если нет спецов по кубам, с докерами только работают?
Читать полностью…
Решение по ссылке не нужно
Читать полностью…
SLSA provenance и кое-что еще
Так как канал исторически носит название "DevSecOps", самое время вспомнить то, что было активно обсуждаемым в 2021 году — SLSA. Недавно мы наткнулись на репозиторий s3cme — тестовое приложение на Go, в котором реализованы следующие лучшие практики:
- Сканирование с помощью Trivy
- Сканирование с помощью CodeSQL
- Сборка и публикация образа с использованием ko (включает генерацию SBOM)
- Сканирование уязвимостей образа с использованием trivy с параметром проверки максимальной серьезности
- Подпись образа и аттестация с использованием cosign
- Генерация происхождения (provenance) SLSA с помощью slsa-framework/slsa-github-generator
- Проверка происхождения SLSA с использованием slsa-framework/slsa-verifier и CUE политики через cosign.
Напомним, что такое provenance. Всякий раз, когда образ публикуется в реестр, к этому образу прикрепляется аттестация в виде файла SLSA provenance (v0.2). Это позволяет отследить этот образ вплоть до его исходного кода в репозитории (включая GitHub Actions, которые использовались для его создания). Способность обеспечивать такую проверяемую прослеживаемость называется как раз происхождением (provenance). Делать это наибходимо с той целью, чтобы убедиться, что конечный доставляемый артефакт нигде не изменился по пути прохождения цепочки поставок, включая CI/CD. Отследить это можно либо вручную с помощью cosign, либо сразу в кластере с помощью sigstore admission controller.
Вот ссылка на наш старый пост с описанием фреймворка SLSA с действующими ссылками. Сейчас, спустя три года, можно с уверенностью сказать, что сообщество обогатилось конкретной реализацией некогда абстрактной теории, предложенной Google (к вопросу вечного холивара теоретиков и практиков - по-настоящему хорошо работает только синтез 😊 ).
А вот, например, автор из GitHub рассказывают про фичу GitHub по аттестации артефактов, которая упрощает подписание кода для программного обеспечения, созданного в GitHub Actions, и помогает достичь соответствия уровню 2 SLSA. Provenance включает информацию о происхождении, такую как данные о репозитории, инструкции по сборке и SHA исходного кода, делая процесс "голеньким и прозрачненьким".
А как вы решаете эти задачи, и дошли ли до их решения в своих пайпах?
#slsa #supplychain #devsecops
Можно, но только через UI, см. https://youtu.be/ozOP8N89s6o?si=szPE8MHA3ZdNo4Gy
После создания кнопкой можно экспортнуть в yaml/json. Так же через API можно экспортировать в json.
Но вот создать изначально в yaml нельзя.
А разве в Azure DevOps нельзя собрать CD?
Читать полностью…
Не, суть не про лучшее, а в какой системе вообще нельзя через yaml
Читать полностью…
Тимсити помнится мне таким обладает
Читать полностью…
Удаленная занятость.
Доход от ПЯТСОТ ДОЛЛАРОВ в неделю.
несколько часов в день с хорошим доходом.
от восемнадцати лет.
Если интересно ставь «+» в личные сообщения
ну т.е. речь про некую внешнюю проверку? А то по тексту - у меня было ощущение, что API-сервис сам как-то должен был это понять
Читать полностью…
С точки зрения бизнеса это может быть чувствительно, нужно конечно сначала оценить где есть tls ниже 1.2, собрать логи и посмотреть сколько таких подключений вообще и важны ли они. Но много быть не должно. А вот если 1.2 тоже запрещено и можно только последнюю версию тогда да, это проблема)
Читать полностью…
если ты суппортишь старые версии - есть атаки на даунгрейд протокола
Читать полностью…
мне казалось супортить предыдущие версии тлс все таки обязательно?
ну т.е. я не могу же посылать всех клиентов которые не обновились нахер?)
ну, qualys ssl labs делают именно такое - подключаются к условному вебсерверу по всем возможным протоколам и шифрам (так как согласованный протокол и шифр = подмножество того, что умеет И СЕРВЕР, и КЛИЕНТ) и дают отчет
Читать полностью…
Коллеги, в статье с рекомендациями по проектированию безопасности API
Обеспечение безопасности должно включать следующие шаги:
— Проверка того, что трафик поступает через туннель TLS и использует последнюю версию протокола
— Туннель TLS использует безопасный набор шифров, цифровых подписей и хеш-функций. Это требование зависит от технологии и потребует тщательного выбора наиболее безопасных параметров, поддерживаемых сервером и всеми клиентами, которым необходимо будет подключиться к API.
У вас парадигма работы неверная. Почему все считают, что раз поехали в докер - все классно, все все осилят. Нет. Либо надо идти до конца (кубер и Номад), либо сидеть дальше на виртуалках с классическими механизмами (понятными)
Читать полностью…
Используй кубернетес с нормальными средствами мониторинга - falco, tetragon и cni вроде cilium
Читать полностью…
Кто-нибудь в курсе - капа CAP_NET_ADMIN в контейнерах насколько прям плохая идея? Пока из угроз увидел (если атакующий смог получить шелл в контейтере):
— прослушивание трафика в неразборчивом режиме (собрать инфу о локалке)
— подмена IP-адреса контейнера: если есть ACL по IP - можно его обойти (т.е. выдача нового адреса в дополнение к старому - иначе есть шанс потерять удалённый доступ к контейнеру, не добившись профита, конфликт одинаковых IP-адресов не рассматриваем)
— банальный DoS (изменение IP адреса приведёт к недоступности сервисов на контейнере)
Ещё тут инфа есть (https://0xn3va.gitbook.io/cheat-sheets/container/escaping/excessive-capabilities#cap_net_admin). Но, мне кажется, она устарела и уже не стоит внимания
Капа нужна для этого решения по повышению защиты микросервисов. Собственно, вопрос с этим и связан: раз требуется капа CAP_NET_ADMIN - то если её изначально не было и нужно её добавлять для внедрения этой защиты - не страдает ли безопасность от этого? Можно ли понять: в каких ситуациях будет больше плюсов от такого решения, а когда - больше минусов?
Deployment не используем, не знаю(
Читать полностью…
Там же вроде можно нативно deployment в ресурсы azure упаковать в yaml, разве нет?
Читать полностью…
Или, наоборот, можно через ui без хранения в yaml, а только лишь с хранением конвейера в UI виде
Читать полностью…
Так через ямл лучше всего
Читать полностью…
Привет! В каких системах CI/CD конвейеры CI или/и CD разрабатываются в UI, а не через yaml/json? Знаю в Azure Pipelines конвейеры CD могут быть созданы только через UI, а конвейеры CI могут быть созданы как через YAML так и через UI. Интересуют есть ли другие подобные системы
Читать полностью…
Апи сервису обычно пофиг, он за реверс прокси
Читать полностью…
Если ты имеешь возможность юридическую ограничения предоставления услуг по безопасности - это делать нужно.
Читать полностью…
не 1.1 это ваще треш же уже
Читать полностью…
через старые версии можно задосить, 1.2+ лучше держать
Читать полностью…
ты же про TLS терминацию на самом сервере? То есть там условный NGINX и ты можешь в явном виде разрешить только высокие (новые) версии протокола и сильные шифры и при подключении по слабому шифру - давать отлуп клиенту и записывать аудит
Читать полностью…
https://overthewire.org/wargames/
Читать полностью…