Docker в опасности, или как искать уязвимости в образах контейнеров

Всем привет!

Меня зовут Роман, я — DevOps-инженер компании Nixys. Продолжаем тему безопасности и рисков. В предыдущей статье говорилось о безопасном подходе к эксплуатации облачных инфраструктур, в этой — расскажу про безопасность docker-образов: какие уязвимости бывают, как их искать в энтих самых docker-образах (спойлер: использовать сканеры уязвимостей, обзор прилагается) и что с ними делать.

Прежде чем начать, приглашаю вас подписаться на наш блог Хабр, TG-канал DevOps FM и познакомиться с YouTube — мы всегда рады новым друзьям 🙂

Введение

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

Оценил удобство и бизнес. Docker обеспечил уровень абстракции, который позволил упаковывать и развертывать приложения одинаково в различных средах, будь то личная машина разработчика или виртуальная машина в облаке – это сократило time-to-market. А ещё — Docker облегчил масштабирование и позволил сократить затраты на инфраструктуру, т.к. появилась возможность запускать несколько контейнеров (приложений) без вреда друг для друга на одном хосте.

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

Часть 1. Какие уязвимости бывают, какие риски они несут?

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

• OS Vulnerabilities – уязвимости базового образа и системных пакетов, включённых в этот образ;
• Dependencies – уязвимости в сторонних зависимостях;
• Software Vulnerabilities – уязвимости непосредственно в коде приложений, которые запускаются в контейнерах;
• Dockerfile – небезопасные инструкции для сборки образа.

Использование уязвимого docker-образа может представлять значительные риски для безопасности и стабильности IT-инфраструктуры и приложений организации:

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

Чтобы не быть голословным, приведу реальный пример из практики (конечно, опуская некоторые подробности).

1. Злоумышленники, воспользовавшись уязвимостью в Microsoft Exchange Server, добыли из почтового ящика пароль от административной панели bitrix для dev-сайта, который был переслан обычным plain-text,. Делать так, конечно же, не надо. Устанавливайте пароль на архив с паролями и отправляйте его по другому каналу.
   

2. В административной панели bitrix есть инструмент «командная php-строка», с помощью которой можно выполнять любой php-код. Воспользовавшись этим и задействовав внешний VPS сервер для получения reverse shell, был получен доступ к системе внутри контейнера.
3. После чего злоумышленники провели атаку на повышение привилегий, использовав уязвимость cve-2022-0847 в ядре linux (уязвимы версии, начиная с 5.8 и до 5.16.11, 5.15.25, и 5.10.102), и получили root-доступ в контейнере. Подробнее про данную уязвимость можно почитать тут, тут и тут.
4. В контейнере были запущены apache и php, требовавшие определенные capabilities для работы, в частности, cap_dac_read_search и cap_dac_override. Использовав их для выхода из контейнера, злоумышленники сумели получить доступ к диску хоста. Подробнее об этом эксплойте можно узнать тут и тут.
5. На хост-машине хранились бэкапы prod-сайта, включая хеши административных учетных записей в формате md5.salt, далее был произведен оффлайн брут, и повтор пунктов 2-5 в prod-окружении…
6. ???
7. ПРОФИТ!!!

К счастью, «злоумышленниками» оказались пентестеры… Будьте внимательны к хранимым sensitive-данным!

Часть 2. Где хранится информация об известных уязвимостях?

Существует несколько типов баз уязвимостей:

• официальная база уязвимостей CVE (Common Vulnerabilities and Exposures) – это база данных, которая содержит записи об известных уязвимостях в различных программных продуктах. Она поддерживается организацией MITRE Corporation и является стандартом отрасли;
• базы уязвимостей от производителей – многие производители программного обеспечения поддерживают свои базы уязвимостей, в которых содержатся информация об уязвимостях, найденных в их продуктах. Например, Microsoft имеет базу уязвимостей Microsoft Security Response Center (MSRC), а Oracle – базу уязвимостей Oracle Critical Patch Update;
• базы уязвимостей от сторонних организаций – существуют сторонние организации, которые поддерживают свои базы уязвимостей. Они часто специализируются на конкретных областях, таких как безопасность мобильных устройств или безопасность Интернета вещей (National Vulnerability Database (NVD), SecurityFocus, Secunia и др).

Наиболее популярные базы: CVE, NVD, Exploit-DB, OSVDB (Open Source Vulnerability Database), SecurityFocus и др.

Существует также система оценки серьезности уязвимостей – CVSS (Common Vulnerability Scoring System), которая используется в различных сканерах.

Часть 3. Так как же искать в своих docker-образах эти ваши уязвимости?

Конечно же превратить всех своих сотрудников в пентестеров использовать инструменты, которые называются сканеры уязвимостей!

Такие сканеры помогают выявить уязвимости и предоставляют рекомендации по их устранению, что может сэкономить тонны времени и сил. В нашей компании в качестве хранилища образов мы как правило используем Harbor, который с помощью адаптеров умеет работать с некоторыми сканерами, краткий обзор которых представлен ниже. Это добавляет удобства в построении пайплайнов. К тому же, он умеет выгружать отчет с уязвимостями в универсальном формате (CSV).

Я сразу исключу из обзора следующие инструменты:

• CSP (Aqua) – enterprise платформа (кому интересно, могут запросить триальную версию);
• Sysdig Secure – такая же ситуация, только еще и доступ из РФ запрещен;
• TensorSecurity и ArksecScanner – два китайских сканера с довольно скудной документацией – набор манифестов и команды для деплоя в k8s-кластер, репозитории в Github не поддерживаются – последние коммиты в январе 21 года и апреле 22 года, 5 и 9 звезд соответственно…

Остается четыре сканера. Давайте посмотрим, насколько сложно их настроить и развернуть, а также на результаты сканирования одних и тех же образов. Предварительный сетап – Harbor 2.8.0 c самоподписанным сертификатом (данное уточнение необходимо, потому что у большинства сканеров/адаптеров в таком случае нужно включать опцию работы без валидации сертификата).

Clair

Данный сканер был дефолтным для Harbor до версии 2.1 и его можно было установить флагом –with-clair. Сейчас актуальная версия Harbor 2.8, так что давайте рассмотрим деплой сканера отдельно от самого регистри.

Также есть один существенный нюанс – адаптер совместим только с устаревшим Clair v2, с v4 (актуальным) работать не будет из-за изменений API.

Чтобы не изобретать велосипед, я использовал образы clair-photon и clair-adapter-photon от goharbor. После развертывания нужно подождать какое-то время (примерно 1 ч, может меньше), пока полностью подтянется база уязвимостей.

version: '2.3' services:   clair:     container_name: clair     image: goharbor/clair-photon:v1.10.17     restart: always     cap_drop:       - ALL     cap_add:       - DAC_OVERRIDE       - SETGID       - SETUID     dns_search: .     volumes:       - type: bind         source: ./clair-config.yaml         target: /etc/clair/config.yaml     networks:       - clair   clair-adapter:     container_name: clair-adapter     image: goharbor/clair-adapter-photon:v1.10.17     restart: always     cap_drop:       - ALL     cap_add:       - DAC_OVERRIDE       - SETGID       - SETUID     dns_search: .     depends_on:       - clair     env_file:       ./clair-adapter-env     networks:       - clair networks:   clair:     external:       name: harbor_harbor 

clair:   database:     type: pgsql     options:       source: postgresql://postgres:root123@postgresql:5432/postgres?sslmode=disable       cachesize: 16384   api:     port: 6060     healthport: 6061     timeout: 300s   updater:     interval: 12h 

SCANNER_LOG_LEVEL=info SCANNER_CLAIR_URL=http://clair:6060 SCANNER_CLAIR_DATABASE_URL=postgresql://postgres:root123@postgresql:5432/postgres?sslmode=disable SCANNER_STORE_REDIS_URL=redis://redis:6379/4?idle_timeout_seconds=30 SCANNER_TLS_INSECURE_SKIP_VERIFY=True 

Anchore

С начала 2023 Anchore Engine перестал поддерживаться, вместо него предлагается использовать Syft и Grype, однако т.к. последняя версия еще относительно свежа, а для новых инструментов еще нет адаптеров для Harbor, из обзора убирать не буду.

version: '2.3' volumes:   anchore-db-volume:     external: false services:   api:     image: anchore/anchore-engine:v1.0.0     depends_on:       - db       - catalog     ports:       - "8228:8228"     logging:       driver: "json-file"       options:         max-size: 100m     environment:       - ANCHORE_ENDPOINT_HOSTNAME=api       - ANCHORE_ADMIN_PASSWORD=foobar       - ANCHORE_DB_HOST=db       - ANCHORE_DB_PASSWORD=mysecretpassword     command: ["anchore-manager", "service", "start", "apiext"]     networks:       - anchore   catalog:     image: anchore/anchore-engine:v1.0.0     depends_on:       - db     logging:       driver: "json-file"       options:         max-size: 100m     expose:       - 8228     environment:       - ANCHORE_ENDPOINT_HOSTNAME=catalog       - ANCHORE_ADMIN_PASSWORD=foobar       - ANCHORE_DB_HOST=db       - ANCHORE_DB_PASSWORD=mysecretpassword     command: ["anchore-manager", "service", "start", "catalog"]     networks:       - anchore   queue:     image: anchore/anchore-engine:v1.0.0     depends_on:       - db       - catalog     expose:       - 8228     logging:       driver: "json-file"       options:         max-size: 100m     environment:       - ANCHORE_ENDPOINT_HOSTNAME=queue       - ANCHORE_ADMIN_PASSWORD=foobar       - ANCHORE_DB_HOST=db       - ANCHORE_DB_PASSWORD=mysecretpassword     command: ["anchore-manager", "service", "start", "simplequeue"]     networks:       - anchore   policy-engine:     image: anchore/anchore-engine:v1.0.0     depends_on:       - db       - catalog     expose:       - 8228     logging:       driver: "json-file"       options:         max-size: 100m     environment:       - ANCHORE_ENDPOINT_HOSTNAME=policy-engine       - ANCHORE_ADMIN_PASSWORD=foobar       - ANCHORE_DB_HOST=db       - ANCHORE_DB_PASSWORD=mysecretpassword       - ANCHORE_VULNERABILITIES_PROVIDER=grype     command: ["anchore-manager", "service", "start", "policy_engine"]     networks:       - anchore   analyzer:     image: anchore/anchore-engine:v1.0.0     depends_on:       - db       - catalog     expose:       - 8228     logging:       driver: "json-file"       options:         max-size: 100m     environment:       - ANCHORE_ENDPOINT_HOSTNAME=analyzer       - ANCHORE_ADMIN_PASSWORD=foobar       - ANCHORE_DB_HOST=db       - ANCHORE_DB_PASSWORD=mysecretpassword     volumes:       - /analysis_scratch     command: ["anchore-manager", "service", "start", "analyzer"]     networks:       - anchore   db:     image: "postgres:9 "     volumes:       - anchore-db-volume:/var/lib/postgresql/data     environment:       - POSTGRES_PASSWORD=mysecretpassword     expose:       - 5432     logging:       driver: "json-file"       options:         max-size: 100m     healthcheck:       test: ["CMD-SHELL", "pg_isready -U postgres"]     networks:       - anchore   adapter:     image: "anchore/harbor-scanner-adapter:1.0.1"     restart: always     cap_drop:       - ALL     dns_search: .     environment:       - SCANNER_ADAPTER_LISTEN_ADDR=:8081       - ANCHORE_ENDPOINT=http://api:8228       - SCANNER_ADAPTER_LOG_LEVEL=info       - ANCHORE_USERNAME=admin       - ANCHORE_PASSWORD=foobar       - SCANNER_ADAPTER_APIKEY=agL5JFIDhM8Z4n5       - ANCHORE_CLIENT_TIMEOUT_SECONDS=180       - ANCHORE_FILTER_VENDOR_IGNORED=false       - SCANNER_ADAPTER_FULL_VULN_DESCRIPTIONS=true       - SCANNER_ADAPTER_REGISTRY_TLS_VERIFY=false       - SCANNER_ADAPTER_REGISTRY_VALIDATE_CREDS=false     networks:       - anchore networks:   anchore:     external:       name: harbor_harbor 

Trivy

Trivy является дефолтным сканером для Harbor с версии 2.2 и по текущую, его можно установить флагом –with-trivy, для наглядности опишу здесь отдельным компоузом.

version: '2.3' services:   trivy-adapter:     container_name: trivy-adapter     image: goharbor/trivy-adapter-photon:v2.8.1     restart: always     volumes:       - type: bind         source: ./trivy         target: /home/scanner/.cache/trivy       - type: bind         source: ./reports         target: /home/scanner/.cache/reports     env_file:       ./env     networks:       - trivy networks:   trivy:     external:       name: harbor_harbor 

SCANNER_LOG_LEVEL=info SCANNER_REDIS_URL=redis://redis:6379/5?idle_timeout_seconds=30 SCANNER_STORE_REDIS_URL=redis://redis:6379/5?idle_timeout_seconds=30 SCANNER_STORE_REDIS_NAMESPACE=harbor.scanner.trivy:store SCANNER_JOB_QUEUE_REDIS_URL=redis://redis:6379/5?idle_timeout_seconds=30 SCANNER_JOB_QUEUE_REDIS_NAMESPACE=harbor.scanner.trivy:job-queue SCANNER_TRIVY_CACHE_DIR=/home/scanner/.cache/trivy SCANNER_TRIVY_REPORTS_DIR=/home/scanner/.cache/reports SCANNER_TRIVY_VULN_TYPE=os,library SCANNER_TRIVY_SEVERITY=UNKNOWN,LOW,MEDIUM,HIGH,CRITICAL SCANNER_TRIVY_IGNORE_UNFIXED=False SCANNER_TRIVY_SKIP_UPDATE=False SCANNER_TRIVY_OFFLINE_SCAN=True SCANNER_TRIVY_SECURITY_CHECKS=vuln SCANNER_TRIVY_INSECURE=True SCANNER_TRIVY_TIMEOUT=5m0s 

DoSec

Китайский сканер, есть enterprise-версия. Качаем архив, распаковываем, запускаем установочный скрипт.

version: '2.3' services:   dosec-db-hb:     container_name: dosec-db-hb     image: hub.dosec.cn/library/dosec-db-hb:2022-07-07T16.56.50V2.0-20220706     restart: always     ports:       - "5432:5432"     networks:       - dosec   dosec-scannerapp:     container_name: dosec-scannerapp     depends_on:       - dosec-db-hb     image: hub.dosec.cn/library/dosec-scannerapp:2022-07-19T17.59.23V1.0.1_prod     ports:       - "8899:8899"     restart: always     networks:       - dosec     volumes:       - /var/log/dosec-scanner:/dosec/log   dosec-scanner-hb:     container_name: dosec-scanner-hb     depends_on:       - dosec-db-hb       - dosec-scannerapp     image: hub.dosec.cn/library/dosec-scanner-hb:2022-07-19T13.04.06V1.3_release     command: ["-update_cve"]     restart: always     networks:       - dosec     volumes:       - /var/log/dosec-scanner:/dosec/log networks:   dosec:     external:       name: harbor_harbor 

Теперь давайте сравним результаты их работы. В качестве подопытных образов будут использоваться ubuntu:focal, debian:stable-slim, и один кастомный (с заведомо большим количеством уязвимостей) образ на базе php:7.4.27-apache-buster.

ubuntu:focal

debian:stable-slim

php:7.4.27-apache-buster

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

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

trivy image postgres:9

в ответ вернется табличка с кратким summary, найденными уязвимостями, их описанием и версией, где они были устранены (картинка кликабельна):

Особенности Trivy:

• хорошая документация с примерами;
• интеграции с популярными сервисами (Harbor, Gitlab, Github, k8s (trivy-operator) etc.);
• компактная база, которая обновляется при каждом запуске;
• есть summary, удобный вывод. Если пакет установлен из репозитория, можно выводить отчет в разных предустановленных форматах (html, xml или кастомных);
• может сканировать локальные образы и проекты;
• умеет в сканирование образов в приватных репозиториях и в сканирование кода приложений в git-репозиториях;
• находит уязвимости двух типов – проблемы сборок ОС и проблемы в зависимостях (по lock-файлам);
• умеет опционально показывать только те CVE, для которых были фиксы, а также скрывать CVE, добавленные в локальный whitelist (.trivyignore);
• вывод осуществляется как на экран, так и в json, при этом есть возможность фильтрации уязвимостей по критичности.

Часть 4. Как можно использовать сканирование в CI/CD пайплайнах?

Если говорить об использовании сканера Trivy, то еще одним его плюсом является наличие готовых workflow шаблонов для GitHub Actions, GitLab CI, Bitbucket Pipelines и др. Можно ознакомиться с ними в документации.

Я же здесь приведу пару сценариев из практики с использованием GitLab, Harbor и любого совместимого с ним сканера.

1. Запуск сканирования, если поменялся какой-нибудь pom.xml, и образ запушился в Harbor. Джоба должна падать, а пайп прерываться (или нет — в таком случае измените allow_failure на true), если появились CVE определенного уровня, например critical и high.
   
   scan job

   scan-image:   stage: scan   image: debian:stable-slim   script:     - apt update && apt install curl jq -y     - "curl -X 'POST' 'https://'${REGISTRY_USER}':'${REGISTRY_PASS}'@'${REGISTRY_URL}'/api/v2.0/projects/'${PROJECT_NAME}'/repositories/'${REPO}'/artifacts/'${TAG}'/scan' -H 'accept: application/json' -H 'Content-Type: application/json'"     - sleep 90     - "curl -X 'GET' 'https://'${REGISTRY_USER}':'${REGISTRY_PASS}'@'${REGISTRY_URL}'/api/v2.0/projects/'${PROJECT_NAME}'/repositories/'${REPO}'/artifacts/'${TAG}'?page=1&page_size=10&with_tag=true&with_label=false&with_scan_overview=true&with_signature=false&with_immutable_status=false' -H 'accept: application/json' -H 'X-Accept-Vulnerabilities: application/vnd.security.vulnerability.report; version=1.1, application/vnd.scanner.adapter.vuln.report.harbor+json; version=1.0' > report.json"     - export CRIT_VULN=$(jq '.scan_overview."application/vnd.security.vulnerability.report; version=1.1".summary.summary.Critical' ./report.json)     - export HIGH_VULN=$(jq '.scan_overview."application/vnd.security.vulnerability.report; version=1.1".summary.summary.High' ./report.json)     - |-         export EXPORT_BODY_DATA=$(cat << EOF          [{"tags":"${TAG}","repositories":"${REPO}","projects":[${PROJECT_ID}]}]         EOF         )     - "curl -X 'POST' 'https://'${REGISTRY_USER}':'${REGISTRY_PASS}'@'${REGISTRY_URL}'/api/v2.0/export/cve' -H 'accept: application/json' -H 'X-Scan-Data-Type: application/vnd.security.vulnerability.report; version=1.1' -H 'Content-Type: application/json' -d "${EXPORT_BODY_DATA}" -o export_job_id.json"     - sleep 15     - export JOB_ID=$(jq '.id' ./export_job_id.json)     - curl -X 'GET' "https://'${REGISTRY_USER}':'${REGISTRY_PASS}'@'${REGISTRY_URL}'/api/v2.0/export/cve/download/${JOB_ID}?format=CSV" -H 'accept: application/json' -o report.csv     - if [[ $CRIT_VULN -ne 0 || $HIGH_VULN -ne 0 ]]; then echo "Образ имеет $CRIT_VULN уязвимостей уровня critical и $HIGH_VULN уровня high. Проверьте отчет, скачав его как артефакт пайплайна."; exit 1; fi   artifacts:     when: on_failure     paths:     - ./report.json     - ./report.csv     expire_in: 1 day   only:     changes:       - "**/pom.xml"   allow_failure: false 

2. Ежемесячный запуск сканирования и алерт в Телеграм (использовался alertmanager). Таким образом, когда зависимости не менялись, но в базах появилась новая CVE, нам сообщит об этом алерт.
   
   scheduled scan job

   scheduled-scan:   stage: scan   image: debian:stable-slim   script:     - apt update && apt install curl jq -y     - "curl -s -X 'POST' 'https://'${REGISTRY_USER}':'${REGISTRY_PASS}'@'${REGISTRY_URL}'/api/v2.0/projects/'${PROJECT_NAME}'/repositories/'${REPO}'/artifacts/latest/scan' -H 'accept: application/json' -H 'Content-Type: application/json'"     - sleep 90     - "curl -s -X 'GET' 'https://'${REGISTRY_USER}':'${REGISTRY_PASS}'@'${REGISTRY_URL}'/api/v2.0/projects/'${PROJECT_NAME}'/repositories/'${REPO}'/artifacts/latest?page=1&page_size=10&with_tag=true&with_label=false&with_scan_overview=true&with_signature=false&with_immutable_status=false' -H 'accept: application/json' -H 'X-Accept-Vulnerabilities: application/vnd.security.vulnerability.report; version=1.1, application/vnd.scanner.adapter.vuln.report.harbor+json; version=1.0' -o report.json"     - export CRIT_VULN=$(jq '.scan_overview."application/vnd.security.vulnerability.report; version=1.1".summary.summary.Critical' ./report.json)     - export HIGH_VULN=$(jq '.scan_overview."application/vnd.security.vulnerability.report; version=1.1".summary.summary.High' ./report.json)     - |-         export BODY_DATA=$(cat << EOF          [{"endsAt":"$(date +"%Y-%m-%dT%T" -d '+10 minutes' -u)","annotations":{"summary":"${PROJECT_NAME}/${REPO}:latest image has $HIGH_VULN high and $CRIT_VULN critical vulnerabilities","description":"Check Harbor: https://${REGISTRY_URL}/harbor/projects/${PROJECT_ID}/repositories/${REPO}"},"labels":{"alertname":"HarborScanResults"}}]         EOF         )     - echo $BODY_DATA     - |-         export EXPORT_BODY_DATA=$(cat << EOF          [{"tags":"latest","repositories":"${REPO}","projects":[${PROJECT_ID}]}]         EOF         )     - "curl -X 'POST' 'https://'${REGISTRY_USER}':'${REGISTRY_PASS}'@'${REGISTRY_URL}'/api/v2.0/export/cve' -H 'accept: application/json' -H 'X-Scan-Data-Type: application/vnd.security.vulnerability.report; version=1.1' -H 'Content-Type: application/json' -d "${EXPORT_BODY_DATA}" -o export_job_id.json"     - sleep 15     - export JOB_ID=$(jq '.id' ./export_job_id.json)     - curl -X 'GET' "https://'${REGISTRY_USER}':'${REGISTRY_PASS}'@'${REGISTRY_URL}'/api/v2.0/export/cve/download/${JOB_ID}?format=CSV" -H 'accept: application/json' -o report.csv     - |-       if [[ $CRIT_VULN -ne 0 || $HIGH_VULN -ne 0 ]]; then        echo "Image ${PROJECT_NAME}/${REPO}:latest has vulnerabilities, sending alert..." &&        curl -X 'POST' --anyauth --user ${BASIC_AITH_USER}:${BASIC_AUTH_PASS}  "https://'${ALERTMANAGER_URL}'/alertmanager/api/v2/alerts" -H 'accept: application/json' -H 'Content-Type: application/json' -d "${BODY_DATA}";        fi   only:     variables:       - $HARBOR_SCAN == "true"   artifacts:     paths:     - ./report.json     - ./report.csv     expire_in: 3 days 

   В остальных джобах необходимо будет задать условие:

   except:   variables:     - $HARBOR_SCAN == "true" 

   чтобы запускалась только запланированное сканирование.

   Далее в проекте GitLab в разделе «CI/CD –> Schedules» просто указываем время запуска, нужную ветку и задаем переменную HARBOR_SCAN=true.

Часть 5. Мы просканировали и у нас все красное нашли несколько уязвимостей, что делать?

В целом vulnerability management это отдельная тема, и в рамках текущей статьи раскрываться не будет. Однако упомяну функции, которые должны выполняться в рамках организованного вами управления уязвимостями:

• непосредственно сканирование на уязвимости с использованием автоматизированных инструментов;
• выявление уязвимостей — анализ результатов сканирования и уведомление о них;
• определение приоритетов уязвимостей — выявление систем и уровней среды, на которые влияет каждая уязвимость, а также предоставление информации о ее серьезности, влиянии и основных причинах;
• рекомендации по устранению — предоставление руководства и инструкций по устранению уязвимости;
• исправление уязвимостей;
• экранирование уязвимостей — в случаях, когда сложно или невозможно устранить уязвимость в ее источнике, некоторые решения (например, Aqua vShields) обеспечивают виртуальное исправление или экранирование, предотвратив само использование уязвимости. К примеру, если уязвимость основана на доступе к определенному файлу, то будет предложен план смягчения последствий, который включает прекращение любого доступа к этому файлу, а затем аудит соответствующих событий.

Часть этих функций берут на себя сканеры, но далеко не всегда предоставленная ими информация достаточна для устранения проблем. Для более основательного подхода к менеджменту уязвимостей существует много комплексных платформенных решений, как платных, так и опенсорсных (DefectDojo, Archery, Faraday).

Заключение

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

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

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

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

Спасибо за прочтение, делитесь мыслями в комментариях)