Амазон релизит расширение для VSCode

Ключевые возможности
• Test your code locally with step-through debugging in a Lambda-like environment.
• Deploy your applications to the AWS Region of your choice.
• Invoke your Lambda functions locally or remotely.
• Specify function configurations such as an event payload and environment variables.

https://aws.amazon.com/ru/blogs/developer/announcing-aws-toolkit-for-visual-studio-code/

#tools #vscode #dev

TL;DR for developer documentation - a ridiculous collection of cheatsheets
#dev #tips #man
https://github.com/rstacruz/cheatsheets

DevSecOps: принципы работы и сравнение SCA. Часть первая

Рад объявить о том, что мы запустили блог на Хабре и серию статей по DevSecOps на русском языке. Первая статья - "Принципы работы и сравнение SCA". В этой статье я рассказываю, что такое Software Composition Analysis, как он работает, при чем здесь BOM и что это такое, какие фолзы выдают SCA и как их выявлять, а также табличка с функциональным сравнением. Вся статья построена вокруг двух самых известных open source решений Dependency Check, Dependency Track и коммерческего решения Nexus IQ.

https://habr.com/ru/company/swordfish_security/blog/516660/

В следующих частях планируем написать о встраивании SCA в CI/CD, сравнении результатов различных DAST и многое другое.

#sca #tools #dev

CloudSecDocs

Один из крутых инженеров Marco Lancini, за активностью которого слежу, релизнул cloudsecdocs.com. Это большая Интернет-энциклопедия по безопасности облаков.

Вот что уже можно почитать:
- Secure SDLC: сканеры, работа с секретами, compliance as code, лабы, моделирование угроз, метрики, логирование
- Docker и Kubernetes, что это, какие компоненты, как деплоить и работать с этим
- Моделирование угроз для Docker и Kubernetes
- Опиcание RBAC
- Описание важных компонентов с точки зрения безопасности k8s
- Атаки и пентест на контейнеры
- Компоненты AWS и Azure, а также их защита
- Угрозы и методология тестирования облаков

#aws #gcp #azure #dev #ops #k8s #docker

Threat Modelling & Supply-Chain (Part 3: Security Controls)

В прошлых постах [1,2] мы определили угрозы, которые, как нам кажется, более или менее полно покрывают перечень действий, определенных нами в рамках процессов над активами.

Следующее, что нам нужно сделать - определить меры безопасности (security controls). Здесь два варианта - начать указывать их на каждом процессе или потоке данных в рамках схемы, либо выписать отдельной табличкой напротив каждой нашей угрозы (чтобы убедиться, что мы закрываемся от всего, что сами для себя определили). Говоря более предметно, давайте вернемся к supply chain атакам. В частности возьмем за основу упоминаемый ранее фреймворк SLSA и рассмотрим угрозу компрометации CI/CD системы.

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

Вот примеры реализации hardening'а для разных решений CI/CD систем:
- Security Practices in GitLab
- Managing Security of Jenkins
- Securing Jenkins CI Systems
- Security hardening for GitHub Actions
- TeamCity Security Notes (лучше всего на мой взгляд сделано здесь)
- CircleCI Security

К мерам защиты CI/CD может относиться ролевая модель, отсутствие анонимной аутентификации, обязательная интеграция с identity-провайдером, запрет на доступ в Интернет для сборки, требование к изолированности агентов от агентов развертывания и обязательному логированию с последующей отправкой в SIEM-систему. Конечный список требований зависит исключительно от возможностей вашей CI/CD системы.

Рассматривая компрометацию системы хранения кода (Gitlab/Bitbucket) и артефактов (Nexus Repo, Artifactory) формируем требования безопасности по аналогии из тех же доменов.

Если мы говорим про supply chain атаки, то помимо компрометации самих систем, участвующих в процессе разработки, отдельное внимание надо уделить угрозе нарушения целостности перемещаемых активов, а именно коду и артефактов. Здесь я советую снова обратиться к SLSA-фреймворку.

Примеры угроз, реализуемых внутренним нарушителем:
- Публикация вредоносного кода в релизную ветку от имени скомпрометированной УЗ разработчика
- Указание в системе сборки кода из чужой системы хранения кода
- Указание в системе развертывания артефакта из чужой системы хранения артефактов
- Загрузка в Artifactory артефакта не прошедшего систему сборки

Обратите внимание, что при отсутствии проверки целостности и прохождения дополнительной аутентификации между системами сборки, хранения кода и артефактов нам необязательно получать полный доступ над системами. Например, достаточно указать неверные входные значения (сторонний git-репозиторий) в качестве параметров сборки, либо опубликовать артефакт в Artifactory вручную через CLI минуя security-проверки в рамках централизованного процесса сборки. Ещё один пример - изменить скрипт развёртывания так, чтобы установить вредоносный дистрибутив в прод вместо проверенного security-сканерами.

В помощь сюда приходят проекты вроде Notary или Sigstore. Кто-то реализует это посредством подписи SBOM на всех этапах разработки, кто-то ограничивается тэгированием артефактов без возможности перезаписи разработчиком. Неплохим требованием безопасности будет обязательный merge-approval для всех бизнесовых репозиториев, чтобы избежать нарушения целостности master/release ветки при компрометации УЗ разработчика.

#dev #ops #threatmodeling

Cloud Native Security

Свежая книга по cloud native безопасности (kubernetes, aws) с упоминанием некоторых DevSecOps-подходов (есть даже про "deprecation of PSP"). В основном все строится на практической составляющей с вводом-выводом на консоль и примерами интеграций конкретных инструментов.

#literature #dev #ops #k8s #aws

Introduction to OWASP Top 10 2021

OWASP выпустили драфт документа OWASP Top 10 2021!

Из нового, что отсутствовало в последнем Top 10 2017:
- A04:2021-Insecure Design
- A08:2021-Software and Data Integrity Failures
- A10:2021-Server-Side Request Forgery

Также по списку поднялись уязвимости класса A06:2021 – Vulnerable and Outdated Components, что автоматически повышает перспективы инструментов SCA.

В начале этого года Wallarm также представили свою версию Top10, основанную на анализе базы данных Vulners.

#web #dev