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

The DevSecOps Security Checklist от sqreen (https://www.sqreen.com/). Каждый раздел содержит ссылки на соответствующую тематику.

Чеклистов много не бывает #checklist #dev #ops

"10 Steps Every CISO Should Take to Secure Next-Gen Software" Cindy Blake Те самые 10 шагов: 1) Инвестиция в сканирование зависимостей, безопасности контейнеров и облачной инфраструктуры. SAST, DAST к каждому новому участку кода 2) Пересмотр безопасности. Выравнивание метрик и управление рисками. Исправление текущих уязвимостей важнее обнаружения новых 3) Инструменты и процессы обязательно должны идти рука об руку. Начните с процесса, а затем примените инструменты, которые помогут вам достичь желаемого результата. 4) Идти вширь, а не вглубь. Проверять каждом изменение на наличие распространненных уязвимостей, а не на наличие наиболее "критических" 5) Объедините рабочий процесс, применяя непрерывное сканирование безопасности с итеративной разработкой 6) Проверка на наличие уязвимостей в момент коммита, чтобы разбить работу на более мелкие и эффективные циклы сканирования 7) Автоматизация, позволяющая безопасности сосредоточиться на исключениях. 8) Примите открытый исходный код. Согласуйте цели с разработчиками. Совместите тестирование безопасности с рабочим процессом разработчика. Стандартизируйте конвейеры, код и многое другое для получения согласованных, предсказуемых результатов. 9) Применять принципы Zero-Trust к приложениям и их инфраструктуре. 10) Защитите целостность процесса разработки и доставки программного обеспечения, обеспечив надлежащий контроль аудита и бесперебойную работу по всему SDLC. Подробности в файле следующим сообщением. #report #checklist #dev #ops

CSSLP - Certified Secure Software Lifecycle Profession (+ гайд для подготовки) Экзамен предназначен для профессиональных разработчиков и безопасников, ответственных за SDLC, и призван гарантировать высокий уровень технических навыков проектирования, разработки и внедрения методов обеспечения безопасности на каждом цикле ПО. Для сдачи экзамена необходимо иметь как минимум 4 года работы как специалиста по жизненному циклу разработки ПО, обладающего знаниями в одной из 8-и областей. Области (и это же вопросы экзамена): 1) Требования безопасной разработки (14% экзамена) 2) Безопасное проектирования ПО (16% экзамена) 3) Безопасное ннедрение и программирование ПО (16% экзамена) 4) Безопасное тестирование ПО (14% экзамена) 5) Управление жизненным циклом ПО (10% экзамена) 6) Разработка ПО, эксплуатирование и поддержание (9% экзамена) 7) Цепь поставок ПО (8% экзамена) 8) Концепции безопасной разработки (13% экзамена) 175 вопросов, 4 часа, 700/1000 - проходной, Цена 549$, 125$ для членов (ISC)2 Не настолько популярный в России как CISSP, CISA, CISM, но, в силу роста популярности DevSecOps, вопрос времени. https://www.isc2.org/Certifications/CSSLP #exam #dev #ops

Использование машинного обучения в статическом анализе исходного кода программ Среди инструментов: - DeepCode - Infer - Sapienz - SapFix - Embold - Source{d} - Clever-Commit + Нюансы обучения на большом количестве открытого исходного кода https://habr.com/ru/company/pvs-studio/blog/484208/ #tools #article #dev

У Kubernetes появилась собственная программа bug bounty Программа распространяется на основной код Kubernetes, хранящийся на GitHub, а также на проблемы связанные с непрерывной интеграцией, релизами и артефактами в документации. В частности, разработчиков интересуют дыры в безопасности, которые могут привести к кластерным атакам (включая эскалацию привилегий, баги аутентификации и удаленное выполнение кода в kubelet’ах или API сервере). Программа разместилась на платформе HackerOne. https://xakep.ru/2020/01/16/kubernetes-bug-bounty/ #k8s #news #ops

Про стандарты безопасной разработки ФСТЭК 01.11.19 прошло совещание во ФСТЭК касательно обсуждения безопасной разработки Выделен отдельный программный комитет ПК4 по безопасной разработке в составе ТК362. Обсуждался проект стандарта "Руководство по безопасной разработке". Стандарт предлагает рекомендации по внедрению требований и процессам ГОСТ 56939. Пока готова не вся линейка стандартов. Поэтому, чтобы соответствовать требованиям по безопасной разработке, требуется соблюдать описанный процесс, а белые пятна заполнять по своему усмотрению. Планируемые стандарты : 1. Руководство по безопасной разработке 2. Руководство по оценке безопасности разработки по 3. Руководство по статическому анализу 4. Руководство по динамическому анализу 5. Доверенный компилятор 6. Пересмотр ГОСТ 56939 Доверенный компилятор - рабочее название. Стандарт будет описывать рекомендации по настройке существующих компиляторов, а не выбор или создание какого-то отдельного компилятора. Система непрерывной интеграции (CI) хоть и не упомянается в ГОСТ 56939, но является его хребтом. Статический анализ и фаззинг должны быть подключены к CI конвееру При сертификации лаборатория проверяет соответствие требованиям уровня доверия. Тоесть не полное соответствие ГОСТ Все материалы с совещания: https://vk.com/secdevops?w=wall-190263496_16 #law #dev

"Seccomp в Kubernetes: 7 вещей, о которых надо знать с самого начала" Перевод статьи Paulo Gomes https://habr.com/ru/company/flant/blog/481114/ Seccomp - механизм безопасности ядра Linux, который позволяет ограничить набор доступных системных вызовов для приложений, в частсности для работы контейнеров. #k8s #article #ops

"Обороняем порт. Как защитить инфраструктуру на Docker минимальными силами" Иван Пискунов https://xakep.ru/2019/07/05/docker-security/ #article #Docker #ops