Хостинг Беларусь Хостинг Беларусь
Хостинг Беларусь Хостинг Беларусь

Блог / Статьи

Полезная информация для вашего хостинга

  2. Главная
  3. Блог
  4. Полное руководство по защите при создании Docker-образов
Полное руководство по защите при создании Docker-образов

Полное руководство по защите при создании Docker-образов

Блог

Каждый контейнер Docker строится на основе образа, который служит фундаментом для всех последующих развертываний. Если злоумышленник получит возможность модифицировать процесс создания образа или изменить Dockerfile, это может привести к серьезным последствиям: 

  • внедрение вредоносного кода, который активируется в рабочей среде и распространится на всю инфраструктуру;
  • доступ к конфиденциальной информации сборки;
  • получение данных о сетевой архитектуре, доступной из среды сборки;
  • атаки на хост-систему, где выполняется сборка. 

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

Рассмотрим рекомендации по безопасной сборке на примере инструкций Dockerfile. 

Выбор компактного базового образа Для запуска контейнера можно использовать готовый публичный образ или создать собственный на его основе. Рассмотрим второй вариант. При работе с Docker обычно создается персональный образ согласно инструкциям Dockerfile, где подробно описан каждый шаг. 

Контейнерный образ состоит из двух ключевых элементов: корневой файловой системы и параметров конфигурации. Иными словами, он включает базовый образ и команды, модифицирующие файловую систему (ADD, COPY, RUN) и определяющие настройки (USER, PORT, ENV). 

Первая директива Dockerfile - FROM, указывающая базовый образ для нового. Выбор этого образа существенно влияет на конечный результат, особенно на его объем. Если проект не требует стандартных системных библиотек или утилит, лучше отказаться от полноценной ОС в качестве базы. 

Меньший базовый образ содержит меньше лишнего кода, что снижает риск атак. Желательно выбирать минимальный базовый образ, содержащий только приложение и необходимые дополнительные пакеты. 

Компактные образы также быстрее передаются по сети. Например, образ Alpine занимает 5,6 МБ, тогда как Ubuntu - 72,8 МБ. Проиллюстрируем это сравнение. 

  1. Создадим простой Dockerfile с одной инструкцией и соберем образ на базе Python:  
FROM python $ docker build . -f python -t python

 Проверим размер полученного образа:  

$ docker images --format "{{.Repository}}: {{.Size}}" | grep python python: 925MB

 Теперь создадим образ на базе легковесного Alpine с установкой необходимого для Python ПО: 

FROM alpine
 
RUN apk add --update-cache RUN apk add python3 RUN apk add python3-dev RUN apk add py-pip RUN apk add build-base RUN pip install virtualenv

очистка кэша 

RUN rm -rf /var/cache/apk/*

  Сравним размеры полученных образов: 

$ docker images --format "{{.Repository}}: {{.Size}}" alpine-python: 392MB

  Образ на базе Alpine вдвое легче! Хотя образ Python более удобен благодаря предустановленным библиотекам и пакетам разработчика, готовы ли вы контролировать все его содержимое и устранять уязвимости? Чем больше объем, тем выше риск.

Оптимизация инструкций в Dockerfile для повышения безопасности 

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

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

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

Основные рекомендации по оптимизации: 

Использование фиксированных версий: При отсутствии указания конкретной версии используется тег latest: FROM node = FROM node:latest 

Это может привести к непредсказуемому поведению контейнера из-за возможных различий между версиями. Рекомендуется использовать точные версии: FROM node:17.0.1 

Расположение инструкций Команды, редко подвергающиеся изменениям, следует размещать выше в Dockerfile. Система сборки обрабатывает инструкции последовательно сверху вниз, поэтому более стабильные команды с большей вероятностью будут взяты из кэша. 

Оптимизация кэширования и объединение команд Команды RUN, COPY и FROM создают новые слои, занимающие место на диске. Их можно оптимизировать путем объединения. Например, вместо: 

FROM alpine:3.19
 
RUN apk cache clean RUN apk update RUN apk add python3
 Лучше использовать: FROM alpine:3.19  
RUN apk update && apk add --no-cache python3 && apk cache clean

  Это обеспечивает:

  • Получение актуальных версий пакетов
  • Уменьшение объема занимаемой памяти
  • Сокращение количества слоев 

Пример структуры слоев после оптимизации: 

 "RootFS": { "Type": "layers", "Layers": [ "sha256:d4fc045c9e3a848011de66f34b81f052d4f2c15a17bb196d637e526349601820", "sha256:b31d2d0c4fa1bdf747c1f5c767bbe3b56ece3aedf13ee159a9fb2313a7148561" ] }

 Такая оптимизация не только улучшает производительность, но и снижает риски безопасности за счет использования актуальных версий пакетов и уменьшения поверхности атаки.

Оптимизация Dockerfile: от чистки кэша до безопасного выполнения

Управление кэшем и минимизация размера образа

Очистка кэша пакетного менеджера — важный шаг для освобождения дискового пространства. Рассмотрим пример: 

FROM alpine:3.19

RUN apk cache clean && \
    apk update && \
    apk add python3 && \
    rm -rf /var/cache/apk/

При этом важно удалять временные файлы в той же инструкции, где они создаются. Если сделать это в следующей команде, файлы останутся в предыдущем слое и продолжат занимать место на диске.

Использование мультистейдж-сборки

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

Пример: 

# Сборочный этап
FROM golang:1.20 AS builder
WORKDIR /app
COPY . .
RUN go build -o myapp .

# Финальный этап
FROM alpine:3.19
COPY --from=builder /app/myapp /usr/local/bin/myapp
CMD ["myapp"]

 Таким образом, мы получаем два временных образа и один финальный, который содержит только необходимые файлы. Это значительно ускоряет загрузку и повышает безопасность.

Предпочтение COPY перед ADD

Команда COPY рекурсивно копирует локальные файлы в контейнер, предоставляя базовую функциональность. Команда ADD, помимо этого, может автоматически распаковывать архивы, что может быть опасным. Например, злоумышленник может заменить архив, чтобы запустить вредоносный код внутри контейнера (например, через ZIP bomb).

Поэтому рекомендуется использовать COPY вместо ADD, если не требуется специальная функциональность последней.

Избегайте выполнения контейнеров от имени root

По умолчанию контейнеры Docker запускаются от имени суперпользователя (root). Однако это создает дополнительные риски безопасности. Например:

  • Для открытия портов с номерами меньше 1024 требуются привилегии CAP_NET_BIND_SERVICE. В контейнере это можно обойти, настроив проброс портов.
  • Установка ПО через пакетные менеджеры во время выполнения контейнера — плохая практика. Лучше выполнять такие операции во время сборки образа.

Рекомендуется создавать отдельного пользователя и группу для выполнения контейнера с минимально необходимыми привилегиями. Пример: 

# Создание группы и пользователя
RUN groupadd -r tom && useradd -g tom tom

# Назначение прав и владельцев
RUN chown -R tom:tom /my-app

# Переключение на нового пользователя
USER tom

Таким образом, контейнер будет выполняться без прав root, что снижает риск эксплуатации уязвимостей.

docker2

Безопасная работа с Docker-образами: от управления пользователями до защиты данных

Использование встроенных пользователей в базовых образах

Некоторые базовые образы уже содержат предопределенных пользователей, которые могут быть использованы для повышения безопасности. Например, образ Node.js предоставляет пользователя node, который работает без прав root. Однако не все образы следуют этой практике. Рассмотрим пример работы с образом MariaDB.

  1. Скачивание и запуск контейнера : Согласно официальной документации, скачаем образ и запустим контейнер:

    # docker pull mariadb
Using default tag: latest
latest: Pulling from library/mariadb
...
Status: Downloaded newer image for mariadb:latest
docker.io/library/mariadb:latest

# docker run -p 127.0.0.1:3306:3306 --name mariadb -e MARIADB_ROOT_PASSWORD=superpass -d mariadb
d617a77532919cfb16a68bb4607607192cb61fdb45473a80319ea1a5f3ad51a1

     

 2. Проверка пользователя внутри контейнера : Войдем в контейнер в интерактивном режиме и проверим текущего пользователя:

# docker exec -ti mariadb sh
# whoami
root
# cd /root/
# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
24: eth0@if25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default
    link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0

Как видно, контейнер запустился с правами root. Пользователь имеет доступ к корневому каталогу (/root) и может просматривать сетевые интерфейсы.

  1. Ограничение прав root : Попробуем удалить сетевой интерфейс:

    # ip link delete eth0
RTNETLINK answers: Operation not permitted

     

 Несмотря на то, что контейнер запущен под root, операция удаления интерфейса запрещена. Это демонстрирует, что права root внутри контейнера ограничены.

Защита чувствительной информации

Чувствительные данные, такие как ключи SSH или токены, никогда не должны быть "захардкожены" в Dockerfile. Они будут закэшированы и могут стать доступными другим пользователям. Рекомендуется:

  • Хранить секреты за пределами Dockerfile.
    • Сканировать операционную систему контейнера.
    • Анализировать библиотеки и их зависимости.
    • Поддерживать языки программирования, используемые в образах.спользовать автоматизированные инструменты для поиска утечек секретов.

       

      Использование надежных источников

      При необходимости использования сторонних образов важно соблюдать следующие правила:

       
      1. Проверка обновлений : Убедитесь, что образ регулярно обновляется.
      2. Сканирование на уязвимости : Проверьте, был ли образ протестирован на наличие уязвимостей.
      3. Доверие автору : Убедитесь, что образ официальный и его автор заслуживает доверия.
      4. Подпись образа : Проверьте, является ли образ подписанным.
      5. Контрольные суммы : Убедитесь, что контрольные суммы образа совпадают.
       

      Рекомендуется использовать образы только из надежных источников, таких как Docker Hub или GitLab Container Registry. Однако даже в этих случаях следует сканировать образы на наличие уязвимостей.

      Подписание и проверка образов

      Для защиты от использования неподписанных образов можно включить Docker Content Trust:

      export DOCKER_CONTENT_TRUST=1

       Эта команда блокирует использование неподписанных образов. Для подписания своих образов используйте инструмент Docker Notary.

      Использование статического анализа для повышения безопасности Docker-образов

      Почему важно сканировать образы

      Даже если ваш Dockerfile выглядит идеально, а функциональные тесты проходят успешно, это не гарантирует отсутствие уязвимостей. Использование сторонних библиотек и пакетов неизбежно увеличивает количество потенциальных угроз. Уязвимость в одном компоненте Dockerfile распространится на все контейнеры, созданные на его основе.

      Чтобы минимизировать риски, необходимо внедрить сканирование образов на наличие уязвимостей. Этот процесс должен быть:

      • Постоянным : проводиться после каждого изменения.
      • Автоматизированным : интегрироваться в CI/CD-пайплайн.
      • Превентивным : включать автоматическое сканирование новых образов в реестре.

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

      Кроме того, современные инструменты способны анализировать не только содержимое Dockerfile, но и метаданные образов, выявляя ошибки в конфигурации контейнеров.

      Пример сканирования уязвимостей

      Одна из основных причин уязвимостей — использование устаревших версий программного обеспечения. Регулярное обновление и исправление ПО помогает устранить известные проблемы. Для сканирования используется информация из открытых баз данных уязвимостей, таких как Common Vulnerability and Exposure (CVE) . Каждой уязвимости присваивается уникальный идентификатор (например, CVE-2023-52136), который позволяет отслеживать её статус и доступные исправления.

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

      Сканирование с помощью Docker Snyk

      Встроенный в Docker сканер, основанный на Snyk, позволяет анализировать содержимое и зависимости проекта, сравнивая их с базой данных уязвимостей. Пример вывода команды docker scan:

      $ docker scan ubuntu

Testing ubuntu...

✗ Low severity vulnerability found in shadow/passwd
  Description: Time-of-check Time-of-use (TOCTOU)
  Info: https://snyk.io/vuln/SNYK-UBUNTU2004-SHADOW-577863
  Introduced through: shadow/passwd@1:4.8.1-1ubuntu5.20.04.1, Адрес электронной почты защищен от спам-ботов. Для просмотра адреса в браузере должен быть включен Javascript.
  From: shadow/passwd@1:4.8.1-1ubuntu5.20.04.1
  From: Адрес электронной почты защищен от спам-ботов. Для просмотра адреса в браузере должен быть включен Javascript. > shadow/passwd@1:4.8.1-1ubuntu5.20.04.1
  ...

✗ Low severity vulnerability found in pcre3/libpcre3
  Description: Uncontrolled Recursion
  Info: https://snyk.io/vuln/SNYK-UBUNTU2004-PCRE3-580031
  Introduced through: pcre3/libpcre3@2:8.39-12build1, Адрес электронной почты защищен от спам-ботов. Для просмотра адреса в браузере должен быть включен Javascript.
  From: pcre3/libpcre3@2:8.39-12build1
  From: Адрес электронной почты защищен от спам-ботов. Для просмотра адреса в браузере должен быть включен Javascript. > pcre3/libpcre3@2:8.39-12build1
  ...

Organization:   my-org
Package manager: deb
Project name:   docker-image|ubuntu
Docker image:   ubuntu
Platform:       linux/amd64
Base image:     ubuntu:20.04
Licenses:       enabled

Tested 93 dependencies for known issues, found 18 issues.

Base Image        Vulnerabilities  Severity
ubuntu:20.04      18               0 critical, 0 high, 3 medium, 15 low

Recommendations for base image upgrade:

Major upgrades
Base Image                Vulnerabilities  Severity
ubuntu:impish-20211015    12               0 critical, 0 high, 2 medium, 10 low

       

      Рекомендации по использованию сканирования

      1. Интеграция в CI/CD :

        • Настройте автоматическое сканирование образов на каждом этапе сборки.
        • Блокируйте развертывание образов с критическими уязвимостями.

      2. Регулярное обновление базовых образов :

        • Используйте рекомендации сканера для выбора более безопасных версий базовых образов.
        • Например, замена ubuntu:20.04 на ubuntu:impish-20211015 может снизить количество уязвимостей.

      3. Отслеживание CVE :

        • Подпишитесь на уведомления о новых уязвимостях через базы данных, такие как CVE или VULDB.
        • Регулярно проверяйте статус уже выявленных проблем.

      4. Минимизация зависимостей :

        • Удаляйте ненужные пакеты и зависимости из финального образа.
        • Используйте мультистейдж-сборку для исключения build-зависимостей.

      Использование современных инструментов для сканирования Docker-образов

      Разнообразие решений для анализа уязвимостей

      Существует множество инструментов для сканирования Docker-образов, включая как open-source решения, так и enterprise-продукты. Для выбора подходящего инструмента рекомендуется изучить актуальный топ-10 решений, учитывая их функциональность и поддержку технологий, используемых в вашем проекте.

      Идеальное решение должно:

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

    Пример использования Trivy

    Одним из популярных инструментов является Trivy — простой в использовании сканер с богатой документацией и широкими возможностями интеграции. Рассмотрим его применение на примере официального образа WordPress.

    # trivy image --scanners vuln --severity CRITICAL wordpress
...
wordpress (debian 12.4)

Total: 3 (CRITICAL: 3)

┌────────────┬────────────────┬──────────┬──────────────┬───────────────────┬───────────────┬────────────────────────────────────────────────────────┐
│  Library   │ Vulnerability  │ Severity │	Status	│ Installed Version │ Fixed Version │                     	Title                      	│
├────────────┼────────────────┼──────────┼──────────────┼───────────────────┼───────────────┼────────────────────────────────────────────────────────┤
│ libaom3	│ CVE-2023-6879  │ CRITICAL │ affected 	│ 3.6.0-1       	│           	│ aom: heap-buffer-overflow on frame size change     	│
│        	│            	│      	│          	│               	│           	│ https://avd.aquasec.com/nvd/cve-2023-6879          	│
├────────────┼────────────────┤      	├──────────────┼───────────────────┼───────────────┼────────────────────────────────────────────────────────┤
│ zlib1g 	│ CVE-2023-45853 │      	│ will_not_fix │ 1:1.2.13.dfsg-1   │           	│ zlib: integer overflow and resultant heap-based buffer │
│        	│            	│      	│          	│               	│           	│ overflow in zipOpenNewFileInZip4_6                 	│
│        	│            	│      	│          	│               	│           	│ https://avd.aquasec.com/nvd/cve-2023-45853         	│
├────────────┤            	│      	│          	│               	├───────────────┤                                                    	│
│ zlib1g-dev │            	│      	│          	│               	│           	│                                                    	│
└────────────┴────────────────┴──────────┴──────────────┴───────────────────┴───────────────┴────────────────────────────────────────────────────────┘

    В отчете показаны только критические уязвимости для краткости, но на практике могут быть обнаружены десятки проблем разной степени серьезности. Использование такого образа в enterprise-среде крайне рискованно.

    Действия после сканирования

    После выявления уязвимостей необходимо предпринять следующие шаги:

    1. Обновление базового образа :

      • Если уязвимости связаны с базовым образом, проверьте наличие более новых версий.
      • Обновите инструкцию FROM в Dockerfile и пересоберите образ.

    2. Обновление пакетов :

      • Если проблемы вызваны конкретными пакетами или библиотеками, обновите их до исправленных версий.
      • Внесите изменения в Dockerfile, добавив команды для установки обновлений. Например:
    RUN apt-get update && apt-get upgrade -y

    1. Удаление ненужных зависимостей :

      • Убедитесь, что в финальном образе отсутствуют лишние пакеты, которые могут увеличивать поверхность атаки.

    2. Мультистейдж-сборка :

      • Используйте мультистейдж-сборку для исключения build-зависимостей из финального образа.

    3. Регулярное повторное сканирование :

      • Настройте автоматическое сканирование образов в CI/CD-пайплайне.
      • Регулярно проверяйте новые версии базовых образов и зависимостей.

        Расширенные возможности сканеров Docker-образов

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

        Сканирование ошибок конфигурации

        Неправильно настроенные параметры контейнера могут стать причиной серьезных уязвимостей. Например:

        • Открытые порты.
        • Неправильные права доступа к файлам.
        • Использование учетных данных по умолчанию.
        • Отсутствие минимальных привилегий для пользователей.
         

        Инструмент Trivy может анализировать конфигурационные файлы Docker, Kubernetes, Terraform и других технологий, выявляя такие проблемы. Также поддерживается создание собственных политик для проверки.

        Пример сканирования на наличие ошибок конфигурации:

        # trivy image --scanners misconfig --severity HIGH,CRITICAL myapp
2024-02-15T13:19:26.131+0300    INFO    Misconfiguration scanning is enabled
2024-02-15T13:19:26.294+0300    INFO    Detected config files: 6

go/pkg/mod/github.com/!nerzal/gocloak/v13@v13.1.0/Dockerfile (dockerfile)

Tests: 19 (SUCCESSES: 18, FAILURES: 1, EXCEPTIONS: 0)
Failures: 1 (HIGH: 1, CRITICAL: 0)

HIGH: Specify at least 1 USER command in Dockerfile with non-root user as argument
══════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════
Running containers with 'root' user can lead to a container escape situation. It is a best practice to run containers as non-root users, which can be done by adding a 'USER' statement to the Dockerfile.

See https://avd.aquasec.com/misconfig/ds002

        В отчете видно, что контейнер запускается с правами root, что является серьезной уязвимостью. Рекомендуется добавить в Dockerfile команду USER для использования непривилегированного пользователя.

        Сканирование на наличие секретов

        Секреты — это чувствительная информация, такая как пароли, ключи API или данные аутентификации. Если они случайно попадают в образ, это может привести к серьезным утечкам данных.

         docker3

        Пример сканирования на наличие секретов с помощью Trivy :

        # trivy image --scanners secret --severity HIGH,CRITICAL myapp
2024-02-15T13:55:39.125+0300    INFO    Secret scanning is enabled
/go/pkg/mod/github.com/lib/Адрес электронной почты защищен от спам-ботов. Для просмотра адреса в браузере должен быть включен Javascript..7/certs/server.key (secrets)

Total: 1 (HIGH: 1, CRITICAL: 0)

HIGH: AsymmetricPrivateKey (private-key)
══════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════
Asymmetric Private Key
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
 /go/pkg/mod/github.com/lib/Адрес электронной почты защищен от спам-ботов. Для просмотра адреса в браузере должен быть включен Javascript..7/certs/server.key:1 (added by 'RUN /bin/sh -c go mod download && go bui')
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
   1 [ --BEGIN PRIVATE KEY--*******************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************--END PRIVATE KEY--
   2

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

         

        Сканирование на наличие вредоносного ПО

        Некоторые образы могут содержать вредоносное программное обеспечение, такое как трояны, вирусы или программы-вымогатели. Для выявления таких угроз рекомендуется использовать специализированные сервисы, например, Container Scan от Kaspersky . 

        Использование линтеров

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

        • Обнаружения нежелательных паттернов.
        • Выявления ненадежных функций.
        • Предотвращения типичных проблем безопасности, таких как XSS, SQL-инъекции или некорректная обработка ввода-вывода.
        • Приведения кода к единым стандартам.
         

        Для анализа Dockerfile существует специальный линтер Hadolint , который можно интегрировать в IDE или CI/CD-пайплайн. Он анализирует файл в реальном времени и выдает предупреждения о несоответствиях лучшим практикам. 

        Пример работы Hadolint :

        $ hadolint Dockerfile
Line 10: DL3002 Warning: Last USER should not be root
Line 15: DL3008 Warning: Pin versions in apt-get install

        Эти предупреждения помогают улучшить безопасность и надежность образа. 

        Заключение

        Современные сканеры и линтеры предоставляют широкие возможности для обеспечения безопасности Docker-образов:

        1. Сканирование конфигураций : Выявление ошибок в настройках контейнеров.
        2. Поиск секретов : Обнаружение чувствительной информации в образах.
        3. Обнаружение вредоносного ПО : Защита от вирусов и троянов.
        4. Анализ кода : Использование линтеров для предотвращения уязвимостей на ранних этапах.
         

        Интеграция этих инструментов в процессы разработки и CI/CD позволяет минимизировать риски и создавать надежные, безопасные Docker-образы, готовые к использованию в рабочей среде.Создание безопасных Docker-образов особенно важно для проектов на хостинге для Python, которые часто разворачиваются на хостингах с поддержкой контейнеризации. Используя рекомендации из статьи — такие как минимизация базового образа, мультистейдж-сборка и сканирование на уязвимости — вы сможете подготовить оптимизированный и защищенный образ для размещения Python-приложений. Это не только повысит производительность, но и обеспечит надежную изоляцию приложения на хостинге, защищая как данные, так и инфраструктуру от потенциальных атак.