GitLab 13.9 уже доступен — с улучшениями DevSecOps, панелью оповещений безопасности для обработки приоритетных уведомлений, режимом обслуживания для постоянной поддержки распределённых команд, улучшенной видимостью, включая расширенную поддержку метрик DORA, а также продвинутыми возможностями автоматизации, которые помогут вам поставлять более качественные продукты быстрее. Это лишь некоторые из более чем 60 новых фич и улучшений в этом релизе.

Приветствую, братцы!

Задача получения актуальной информации и совета опытных коллег сегодня актуальна как никогда. С одной стороны, сложно превзойти крупнейшие ИТ-сообщества в Slack. С другой стороны, важно иметь контакт с коллегами в нашей стране, в своем городе. Телеграм за последние годы стал крупнейшей площадкой для русскоязычного ИТ-сообщества, присоединяйтесь, не отставайте :)

Nginx — это веб-сервер, на котором работает треть всех сайтов в мире. Но если забыть или проигнорировать некоторые ошибки в настройках, можно стать отличной мишенью для злоумышленников. Detectify Crowdsource подготовил список наиболее часто встречающихся ошибок, делающих сайт уязвимым для атак.

Nginx — один из наиболее часто используемых веб-серверов в Интернете, поскольку он модульный, отзывчивый под нагрузкой и может масштабироваться на минимальном железе. Компания Detectify регулярно сканирует Nginx на предмет неправильных настроек и уязвимостей, из-за которых могут пострадать пользователи. Найденные уязвимости потом внедряются в качестве теста безопасности в сканер веб-приложений.

Мы проанализировали почти 50 000 уникальных файлов конфигурации Nginx, загруженных с GitHub с помощью Google BigQuery. С помощью собранных данных нам удалось выяснить,  какие ошибки в конфигурациях встречаются чаще всего.

Краткий экскурс в AWS Lambda

Что это?

Зачем ее использовать?

• Деньги. Вы платите только за то время, когда сервис работает.
• Скорость. Сама по себе лямбда поднимается и работает очень быстро.
• Удобство. Лямбда имеет много возможностей по интеграции с сервисами AWS.
• Производительность. Параллельно может выполняться, в зависимости от региона максимально от 1000 до 3000 экземпляров. И при желании, этот лимит можно поднять, написав в поддержку.

У этого подхода есть и свои минусы, вы не можете управлять операционной системой на который выполняется код, не можете контролировать ЦП, память и ресурсы. Всем этим занимается AWS.

Все что вы можете, это выбрать язык, из поддерживаемых AWS Lambda.

Что могёт?

В продолжение предыдущей статьи про инструменты деплоя в Kubernetes, хочу рассказать вам про то как можно использовать Jsonnet для упрощения описания джоб в вашем .gitlab-ci.yml

Дано

Есть монорепа, в которой:

• 10 Dockerfiles
• 30 описанных деплоев
• 3 окружения: devel, staging и production

Задача

Настроить пайплайн:

• Сборка Docker-образов должна производиться по добавлении git-тэга с версией.
• Каждая операция деплоя должна выполняться при пуше в ветку окружения и только по изменении файлов в конкретной директории
• В каждом окружении установлен свой gitlab-runner с отдельным тэгом, который выполняет деплой только в своём окружении.
• Не все приложения должны быть задеплоены в каждое из окружений, мы должны описать пайплайн так, чтобы иметь возможность делать исключения.
• Некоторые деплойменты используют git submodule и должны запускаться с установленной переменной GIT_SUBMODULE_STRATEGY=normal

Описать это всё может показаться настоящим адом, но мы не отчаиваемся и вооружившись Jsonnet сделаем это легко и непринуждённо.

Привет, Хабр!

В своей работе наша компания очень часто имеет дело с различными инструментами статического анализа кода (SAST). Из коробки они все работают средне. Конечно, всё зависит от проекта и используемых в нём технологий, а также, насколько хорошо эти технологии покрываются правилами анализа. На мой взгляд, одним из самых главных критериев при выборе инструмента SAST является возможность настраивать его под особенности своих приложений, а именно писать и изменять правила анализа или, как их чаще называют, Custom Queries.

Мы чаще всего используем Checkmarx - очень интересный и мощный анализатор кода. В этой статье я расскажу про свой опыт написания правил анализа для него.

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

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

• Docker-контейнеры минимальны: один или несколько работающих процессов, только необходимое программное обеспечение. Это снижает вероятность пострадать от уязвимостей в ПО.

  
  

• Docker-контейнеры выполняют специфическую задачу. Заранее известно, что должно выполняться в контейнере, определены пути к директориям, открытые порты, конфигурации демонов, точки монтирования и т. д. В таких условиях проще обнаружить какие-либо связанные с безопасностью аномалии. Этот принцип организации систем идет рука об руку с микросервисной архитектурой, позволяя значительно уменьшить поверхность атаки.

  
  

• Docker-контейнеры изолированы как от хоста, так и от других контейнеров. Этого удается добиться благодаря способности ядра Linux изолировать ресурсы с помощью cgroups и namespaces. Но есть серьезная проблема — ядро приходится делить между хостом и контейнерами (мы еще вернемся к этой теме чуть позже).

  
  
• Docker-контейнеры воспроизводимы. Благодаря их декларативной системе сборки любой администратор может легко выяснить, из чего и как был сделан контейнер. Крайне маловероятно, что у вас в итоге окажется неизвестно кем настроенная legacy-система, которую никому не хочется конфигурировать заново. Знакомо, не правда ли? ;)

Однако в основанных на Docker системах есть и слабые места. В этой статье мы как раз о них и поговорим, рассмотрев 7 проблем безопасности Docker.

1. Необходимые меры внутри операционной системы хоста при работе с Docker'ом;
2. Инструкции, относящиеся к файлу конфигурации сборки и созданию контейнеров;
3. Инструменты для безопасности, которые могут интегрироваться со специфическими функциями Docker Enterprise.

Это первая статья из серии переводов стандарта Application Security Verification Standard 4.0, который был разработан OWASP в 2019 году. Стандарт состоит из 14 групп требований для программного обеспечения. Первая группа (V1) содержит в себе требования к архитектуре и моделированию угроз для основных функций ПО, таких как, аутентификация, управления сеансами, контроль доступа и др. Последующие группы расширяют список требований для каждой из функций.

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

Всем привет! В прошлом посте мы начали рассматривать важный вопрос о безопасности в npm и поговорили о том, какие меры использует сама компания для выявления и предотвращения угроз. В этот раз я хочу поговорить об инструментах и подходах, доступных лично вам, и которые я настоятельно рекомендую внедрить в свою практику всем разработчикам.

Всем привет! В предыдущих постах мы подробно поговорили про выбор зависимостей и использование lock-файлов в npm, однако я только вскользь касался вопросов безопасности. Пришло время исправить этот недочет: этот и следующий посты будут полностью посвящены безопасности в npm! И для начала мы рассмотрим, как безопасность обеспечивается на уровне инфраструктуры npm и экосистемы в целом.