Методы атак на конвейер (RTC0011)

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

Сброс переменных Env в CI/CD

1. Проверка кода с вредоносной полезной нагрузкой

# Enable debug mode to print environment variables
ci-tool --debug execute-pipeline

В этом сценарии злоумышленник отправляет изменение кода в законный репозиторий, который при выполнении в конвейере CI/CD создает дамп переменных сред, содержащих конфиденциальную информацию.

1.Использование режима отладки

1
2

# Inject malicious command to dump environment variables
ci-tool run-step --command "echo $ENV_VARIABLES"

В этом сценарии злоумышленник внедряет вредоносные команды в качестве этапов сборки в конвейер CI/CD, что приводит к сбросу переменных среды.

Доступ к Secret Manager из CI/CD запрещен другим репозиторием

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

1
2

# Retrieve secrets from the secret manager
ci-tool get-secrets --repository malicious-repo --secret-manager secret-manager-name

В этом сценарии злоумышленник получает доступ к заданию конвейера CI/CD, которое взаимодействует с диспетчером секретов и использует слабые разрешения для получения конфиденциальных учетных данных.

1.Внедрение кода в конвейер CI

1
2

# Inject code to capture secrets during the CI pipeline execution
echo "echo $SECRET_VARIABLE" >> main.py

В этом сценарии злоумышленник отправляет изменение вредоносного кода в законный репозиторий, который при выполнении в конвейере CI перехватывает секреты или использует их для выполнения несанкционированных действий.

1.Использование неправильно настроенных переменных среды

1
2

# Retrieve secrets using misconfigured environment variables
ci-tool get-secrets --repository legitimate-repo --secret-manager $MISCONFIGURED_VARIABLE

В этом сценарии злоумышленник идентифицирует неправильно настроенные переменные среды в конвейере CI/CD и использует их для получения несанкционированного доступа к диспетчеру секретов.

пожалуйста, создайте три реальных примера сценария для получения учетных данных из консоли администратора CI / CD в конвейерных атаках в devsecops с помощью команд инструментов и кодов на одном этапе шаблона команды лайнера.

Получение учетных данных из административной консоли CI/CD

1.Интерфейс командной строки AWS

1
2
3

export AWS_ACCESS_KEY_ID=$(aws ssm get-parameter --name /path/to/access_key --with-decryption --query Parameter.Value --output text)
export AWS_SECRET_ACCESS_KEY=$(aws ssm get-parameter --name /path/to/secret_key --with-decryption --query Parameter.Value --output text)
pipeline-stage-command

Получите доступ к AWS и секретные ключи из административной консоли CI/CD и передайте их в качестве переменных среды на этапе конвейера.

1.Интерфейс командной строки Vault

1
2

export SECRET=$(vault kv get -format=json secret/path/to/secret | jq -r '.data.key')
pipeline-stage-command

Получить секрет из хранилища HashiCorp и передать его в качестве переменной среды на этап конвейера.

1.Интерфейс командной строки Kubernetes

1
2
3

kubectl create secret generic my-secret --from-literal=username=<username> --from-literal=password=<password> 
kubectl create volume secret my-secret-volume --secret=my-secret
pipeline-stage-command --volume=my-secret-volume:/secrets

Получите секрет Kubernetes из консоли администратора и передайте его в виде подключенного тома на этап конвейера.

Изменить конфигурацию производственной среды

1.Несанкционированное изменение конфигурации

1
2

# Modify the production environment configuration file
echo "MALICIOUS_SETTING = True" >> production.config

В этом сценарии злоумышленник получает доступ к конвейеру CI/CD и изменяет конфигурацию производственной среды, потенциально создавая уязвимости в системе безопасности или нарушая работу системы.

1.Использование неправильно настроенных сценариев развертывания

1
2
3

# Social engineering attack to gain access and modify the production configuration
ci-tool login --username admin --password attacker-password
ci-tool modify-config --environment production --setting MALICIOUS_SETTING --value True

В этом сценарии злоумышленник использует методы социальной инженерии, чтобы получить несанкционированный доступ к конвейеру CI/CD и изменить конфигурацию производственной среды.

Небезопасное управление конфигурацией

1.Использование Trivy:

1

curl -X POST -d "repo_url=malicious_repo.git; rm -rf /" https://example.com/deploy

Код:

1
2
3
4
5
6

import subprocess

def deploy(repo_url):
    # Insecure configuration, command injection vulnerability
    command = f"git clone {repo_url}"
    subprocess.call(command, shell=True)

В этом примере функция развертывания является частью сценария развертывания. Параметр repo_url должен быть действительным URL-адресом репозитория Git. Однако из-за неправильной проверки ввода злоумышленник может вводить произвольные команды, добавляя их к repo_url. В этом случае злоумышленник добавляет команду (rm -rf/) для удаления всей файловой системы.

1.Раскрытие переменных сред

1 завиток https://example.com/api/config

Код:

1
2
3
4
5

import os

def get_api_key():
    # Insecure configuration, sensitive information exposure
    return os.environ.get('API_KEY')

В этом примере функция get_api_key извлекает ключ API из переменной среды (API_KEY). Однако конфигурация конвейера имеет уязвимость, позволяющую несанкционированный доступ к переменным среды. Злоумышленник может сделать запрос к конечной точке /api/config для получения конфиденциальной информации, такой как ключ API.

1.Небезопасное хранилище учетных данных

1

cat ~/.aws/credentials

Код:

1
2
3
4
5
6
7

import boto3

def list_buckets():
    # Insecure configuration, sensitive information exposure
    session = boto3.Session()
    s3 = session.client('s3')
    return s3.list_buckets()

В этом примере функция list_buckets использует SDK AWS для взаимодействия с Amazon S3. Код основан на стандартном поведении SDK при поиске учетных данных, который проверяет различные файлы конфигурации на наличие учетных данных AWS. Однако у конвейера есть недостаток безопасности, из-за которого учетные данные AWS хранятся небезопасным образом. Злоумышленник может выполнить команду (cat ~/.aws/credentials), чтобы получить учетные данные AWS и потенциально получить несанкционированный доступ к ресурсам AWS.

Слабая аутентификация и авторизация

1.Использование Trivy:

1

trivy -q -f json <container_name>:<tag> | jq '.[] | select(.Vulnerabilities != null)'

Эта команда использует Trivy, сканер уязвимостей для контейнеров, для сканирования определенного образа контейнера (<container_name>:<tag>) на наличие уязвимостей. Флаг -q подавляет вывод, а флаг -f json форматирует вывод как JSON. Затем команда использует jq для фильтрации результатов и отображения только найденных уязвимостей.

1. Использование Clair-сканера:

1

clair-scanner --ip <container_ip> --report <report_output_file>

Эта команда использует Clair-scanner, инструмент, который интегрируется с базой данных уязвимостей Clair, для сканирования запущенного контейнера (<container_ip>) и создания отчета (<report_output_file>), содержащего найденные уязвимости.

1.Использование kube-hunter:

1

kube-hunter --remote <cluster_address> | grep -B 5 "Critical:"

Эта команда использует kube-hunter, инструмент тестирования на проникновение Kubernetes, для сканирования удаленного кластера Kubernetes (<адрес_кластера>) на наличие уязвимостей в системе безопасности. Затем выходные данные передаются в grep для фильтрации и отображения только найденных критических уязвимостей.

Небезопасные инструменты CI/CD

1.Использование trufflehog:

1

trufflehog --regex --entropy=True https://example.com/git-repo.git

Эта команда использует TruffleHog, сканер конфиденциальных данных для репозиториев Git. Он сканирует указанный URL-адрес репозитория Git (https://example.com/git-repo.git), используя сопоставление шаблонов регулярных выражений и энтропийный анализ для выявления потенциально конфиденциальной информации, такой как ключи API, пароли и другие секреты, хранящиеся в репозитории.

1.Использование circleci:

1

docker run -v $(pwd):/src -w /src -t circleci/circleci-cli:latest circleci config pack .circleci > config.yml && circleci local execute -c config.yml

Эта команда использует инструмент командной строки CircleCI для имитации выполнения файла конфигурации CircleCI (config.yml) локально. Он упаковывает файл конфигурации с помощью пакета конфигурации circleci, а затем выполняет упакованный файл конфигурации с помощью локального выполнения Circleci. Это может помочь выявить неправильные конфигурации, уязвимости или небезопасные методы в конвейере CI/CD, определенном в файле конфигурации CircleCI.

1.Использование git:

1

git clone https://github.com/username/repo.git && cd repo && git log --pretty=format:%H -n 1 | xargs -I {} git checkout {} && git grep -iE "(password|secret|token)" .

Эта команда клонирует репозиторий Git (https://github.com/username/repo.git) и переходит в каталог репозитория. Он извлекает хэш последнего коммита (git log —pretty=format:%H -n 1) и использует его для проверки этого конкретного коммита (git checkout {}). Наконец, он выполняет поиск без учета регистра (git grep -iE) общих важных ключевых слов, таких как «пароль», «секрет» или «токен» в коде репозитория. Это помогает выявить потенциальные проблемы безопасности, связанные с раскрытием конфиденциальной информации в конвейере CI/CD.

Отсутствие практики безопасного кодирования

1.Использование  snyk:

1

snyk test --all-projects --all-sub-projects

Эта команда использует Snyk, популярный инструмент сканирования безопасности, для проверки всех проектов и подпроектов в текущем каталоге. Snyk сканирует кодовую базу и ее зависимости, проверяя известные уязвимости, небезопасные методы кодирования и другие проблемы безопасности. Это помогает выявлять и устранять слабые места в безопасности, вызванные небезопасными методами кодирования.

1.Использование bandit:

1

bandit -r /path/to/source-code

Эта команда использует Bandit, инструмент безопасности, специально разработанный для Python, для выполнения статического анализа исходного кода, расположенного в /path/to/source-code. Bandit проверяет распространенные проблемы безопасности в коде Python, такие как использование небезопасных криптографических алгоритмов, неправильная обработка пользовательского ввода и потенциальные уязвимости внедрения кода. Это помогает выявить небезопасные методы кодирования, которые могут привести к уязвимостям в системе безопасности.

1.Использование npm:

1

npm audit --registry=https://registry.npmjs.org/

Эта команда использует команду аудита npm, встроенную в диспетчер пакетов Node (npm), для проведения аудита безопасности зависимостей в проекте Node.js. Он проверяет зависимости проекта от Национальной базы данных уязвимостей (NVD) и предоставляет отчет, в котором выделяются любые известные уязвимости и небезопасные методы кодирования. Это помогает выявлять и устранять проблемы безопасности, вызванные небезопасно реализованными или устаревшими зависимостями.

Небезопасные сторонние зависимости

1.Использование проверки зависимостей OWASP:

1

OWASP-Dependency-Check --scan <path-to-project> --format HTML

Эта команда использует OWASP Dependency-Check, широко используемый инструмент для выявления известных уязвимостей в зависимостях проекта. Он сканирует проект, расположенный по адресу <path-to-project>, анализирует зависимости и создает отчет в формате HTML (—format HTML), в котором выделяются любые небезопасные или уязвимые сторонние компоненты, используемые в проекте. Это помогает выявлять и устранять риски безопасности, возникающие из-за небезопасных сторонних зависимостей.

1.Использование Retire:

1

Retire.js -c -s <path-to-project>

Эта команда использует Retire.js, инструмент для обнаружения уязвимых библиотек JavaScript и устаревших зависимостей. Он сканирует проект, расположенный по адресу <path-to-project>, и проверяет файлы JavaScript на наличие известных уязвимостей в часто используемых библиотеках. Опция -c показывает полный путь к файлу, а опция -s подавляет неуязвимые строки. Это помогает выявлять и устранять проблемы безопасности, возникающие из-за небезопасных или устаревших сторонних зависимостей JavaScript.

1.Использование пакетного аудита:

1

bundle-audit check --update

Эта команда использует пакет-аудит, инструмент на основе Ruby, для проверки известных уязвимостей в драгоценных камнях Ruby, используемых в проекте. Команда check сканирует Gemfile.lock проекта и проверяет наличие небезопасных или уязвимых драгоценных камней. Опция —update обновляет базу данных уязвимостей перед выполнением проверки. Это помогает выявлять и устранять риски безопасности, возникающие из-за небезопасных или устаревших сторонних зависимостей Ruby.

Недостаточное тестирование

1.Использование OWASP ZAP:

1

owasp-zap-cli -s -t http://example.com

Эта команда использует интерфейс командной строки (CLI) OWASP ZAP (Zed Attack Proxy) для автоматического тестирования безопасности на целевом веб-сайте (http://example.com). Параметр -s запускает сканирование, а параметр -t указывает целевой URL. OWASP ZAP сканирует цель на наличие распространенных уязвимостей безопасности, таких как межсайтовый скриптинг (XSS) и внедрение SQL. Это помогает выявить потенциальные уязвимости безопасности, возникающие в результате недостаточного тестирования.

1.Используя  goss:

1

goss validate -f /path/to/goss.yaml

Эта команда использует Goss, инструмент для проверки конфигураций системы и тестирования инфраструктуры. Он запускает тесты, определенные в файле goss.yaml (-f /path/to/goss.yaml), чтобы проверить ожидаемое состояние системы goss проверяет различные аспекты, включая содержимое файла, статус процесса и сетевое подключение. Это помогает убедиться, что система правильно настроена и протестирована, выявляя любые недостатки в процессе тестирования.

1.Используя junit-просмотрщик:

1

junit-viewer --results /path/to/test-results.xml --output-dir /path/to/output

Эта команда использует JUnit-Viewer, инструмент для визуализации результатов теста JUnit. Он берет XML-файл результатов теста JUnit (—results /path/to/test-results.xml) и создает отчет в формате HTML в указанном выходном каталоге (—output-dir /path/to/output). Это позволяет легко визуализировать и анализировать результаты тестирования, помогая определить области, в которых тестирование может быть недостаточным или неадекватным.

Небезопасные процессы сборки и развертывания

1.Использование Trivy:

1

trivy image <image-name>:<tag>

Эта команда использует Trivy, сканер уязвимостей для образов контейнеров, для сканирования определенного образа Docker (<image-name>:<tag>) на наличие известных уязвимостей. Trivy анализирует слои и зависимости образа, проверяя наличие проблем безопасности в пакетах и ​​библиотеках. Это помогает выявить уязвимости в образе, которые могут появиться в процессе сборки и развертывания.

1.Использование kube-hunter:

1

kube-hunter --remote

Эта команда использует kube-hunter, инструмент тестирования на проникновение Kubernetes, для оценки безопасности кластера Kubernetes. Параметр —remote позволяет kube-hunter сканировать удаленный кластер на наличие уязвимостей в системе безопасности и неправильных конфигураций, связанных с процессами сборки и развертывания. Он тестирует различные векторы атак и выявляет потенциальные слабые места в конфигурации кластера.

1.Использование owtf:

1

owtf -s "target_host"

Эта команда использует OWTF (Open Web Application Security Project Testing Framework), инструмент тестирования на проникновение, для оценки безопасности на целевом хосте. OWTF сочетает в себе различные инструменты и методы для оценки безопасности веб-приложений и базовых систем. Ориентируясь на хост, участвующий в процессах сборки и развертывания, OWTF может выявить уязвимости и слабые места, которые могут существовать в конвейере сборки и развертывания.

Открытые учетные данные

1.Использование gitleaks:

1

gitleaks --repo=https://github.com/username/repo.git

Эта команда использует Gitleaks, инструмент для обнаружения секретов и учетных данных в репозиториях Git, для сканирования определенного репозитория (https://github.com/username/repo.git). Gitleaks сканирует историю коммитов репозитория и идентифицирует любые открытые учетные данные, такие как ключи API, пароли или конфиденциальную информацию. Это помогает выявить потенциальные риски безопасности, связанные с раскрытием учетных данных в кодовой базе.

1.Использование trufflehog:

1

trufflehog --regex --entropy=True https://example.com/git-repo.git

Эта команда использует TruffleHog, сканер конфиденциальных данных для репозиториев Git. Он сканирует указанный URL-адрес репозитория Git (https://example.com/git-repo.git), используя сопоставление шаблонов регулярных выражений и энтропийный анализ, чтобы определить потенциально открытые учетные данные и другую конфиденциальную информацию. TruffleHog помогает обнаруживать угрозы безопасности, связанные с открытыми учетными данными в репозитории.

1.Использование ядер:

1

nuclei -l /path/to/targets.txt -t /path/to/templates-dir -t secrets-disclosure -o output.txt

Эта команда использует Nuclei, мощный сканер уязвимостей, для целевого сканирования уязвимостей раскрытия секретов. Параметр -l указывает файл, содержащий список целевых URL-адресов в /path/to/targets.txt. Параметр -t указывает на путь к каталогу, содержащему шаблоны Nuclei, включая шаблон раскрытия секретов, который проверяет открытые учетные данные. Параметр -o указывает выходной файл, в котором будут сохранены результаты.

Недостаточный мониторинг и ведение журнала

1.Использование lynis:

1

lynis audit system

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

1.Используя auditd:

1

auditd -f -l

Эта команда использует Auditd, платформу аудита Linux, для просмотра текущих правил аудита и конфигурации. Параметр -f указывает, что вывод должен быть отформатирован для удобства чтения. Auditd предоставляет возможности мониторинга и ведения журналов, создавая журналы системных событий. Изучив правила и конфигурацию аудита, можно определить, настроены ли они для отслеживания и регистрации необходимых событий, связанных с безопасностью.

1.Использование splunk:

1

splunk search 'sourcetype=access_*' earliest=-1d latest=now

Эта команда использует Splunk, популярную платформу управления и анализа журналов, для поиска журналов доступа (sourcetype=access_*) за последние 24 часа (раннее=-1d самое последнее=сейчас). Запрашивая журналы доступа, он помогает оценить, достаточно ли ведется мониторинг и ведение журналов. Это может выявить любые пробелы в сборе, хранении или анализе журналов, выявляя потенциальные недостатки в методах мониторинга и ведения журналов.

Неправильно настроенный контроль доступа

1.Неправильно настроенный контроль доступа в секретах конвейера CI/CD

1

gitleaks --repo=https://github.com/your-repo.git --report=git-secrets-report.txt

Эта команда использует GitLeaks для сканирования репозитория Git (your-repo.git) на наличие потенциальных секретов, которые могли быть ошибочно зафиксированы. Неправильно настроенные элементы управления доступом в конвейере CI/CD могут привести к несанкционированному доступу к конфиденциальной информации. Параметр —report указывает файл, в котором будут сохранены результаты.

1.Неправильно настроенные политики IAM в облачном развертывании

1

cloudsploit scan --scan-id=1234 --scan-type=iam --output-file=iam-policy-report.json

Здесь CloudSploit используется для выполнения сканирования политики IAM в облачном развертывании. Неправильно настроенные элементы управления доступом в политиках IAM могут привести к несанкционированному доступу к облачным ресурсам. Параметр —scan-id присваивает сканированию уникальный идентификатор, а —scan-type указывает сканирование политики IAM. Параметр —output-file определяет файл, в котором будут храниться результаты сканирования.

1.Неправильно настроенный контроль доступа на основе ролей (RBAC) в кластере Kubernetes

1

kube-hunter --remote --report kube-hunter-report.txt

Эта команда запускает kube-hunter в удаленном режиме для оценки безопасности кластера Kubernetes. Он сканирует потенциальные неправильные настройки в элементах управления доступом на основе ролей (RBAC), которые могут привести к несанкционированному доступу к критически важным ресурсам. Флаг —remote указывает kube-hunter сканировать удаленный кластер, а параметр —report указывает файл, в котором будут сохранены результаты.

Небезопасные конфигурации

1.Управление небезопасными секретами в конвейере CI/CD

1

trufflehog --regex --entropy=True https://github.com/your-repo.git > insecure-secrets.txt

Эта команда использует Trufflehog для сканирования репозитория Git (your-repo.git) на наличие небезопасно хранимых секретов, таких как ключи API и пароли. Небезопасные конфигурации в управлении секретами могут привести к несанкционированному доступу к конфиденциальной информации. Флаг —regex включает сопоставление регулярных выражений, а флаг —entropy включает проверки энтропии. Вывод сохраняется в файл insecure-secrets.txt.

2.Небезопасные конфигурации образа Docker

1

anchore-cli analyze docker://your-image:tag --image-id=your-image-id --all-tags --report insecure-docker-image-report.json

1.Здесь Anchore Engine используется для анализа образа Docker (your-image:tag) на наличие небезопасных конфигураций. Небезопасные настройки в образах Docker могут привести к появлению уязвимостей в конвейере. Параметр —image-id указывает идентификатор изображения, а —all-tags указывает Anchore проанализировать все доступные теги. Результаты анализа сохраняются в файле insecure-docker-image-report.json.

2.Небезопасные конфигурации инфраструктуры как кода (IaC)

1

tfsec your-iac-directory --format=json --output=tfsec-results.json

1.Эта команда использует tfsec для сканирования каталога инфраструктуры как кода (IaC) на наличие небезопасных конфигураций. Небезопасные настройки IaC могут привести к неправильной настройке инфраструктуры и потенциальным уязвимостям. Параметр —format указывает выходной формат как JSON, а параметр —output определяет файл, в котором будут сохранены результаты сканирования (tfsec-results.json).

Управление уязвимостями

1.Сканирование образов Docker на наличие уязвимостей в конвейере CI/CD

1

clair-scanner --ip <IP_ADDRESS> --report=clair-report.json <DOCKER_IMAGE>

1.Эта команда использует Clair для сканирования образа Docker (<DOCKER_IMAGE>) на наличие уязвимостей в конвейере CI/CD. Clair — это сканер уязвимостей с открытым исходным кодом, разработанный для контейнерных сред. Параметр —ip указывает IP-адрес сервера Clair, а параметр —report определяет файл, в котором будут сохранены результаты сканирования (clair-report.json).

2.Статическое тестирование безопасности приложений (SAST) в конвейере

1

bandit -r <SOURCE_DIRECTORY> -f json -o bandit-report.json

1.Здесь Bandit используется для статического тестирования безопасности приложений (SAST) в конвейере. Он сканирует каталог исходного кода (<SOURCE_DIRECTORY>) на наличие потенциальных проблем с безопасностью. Параметр -f json указывает выходной формат как JSON, а параметр -o определяет файл, в котором будут сохранены результаты сканирования (bandit-report.json).

2.Сканирование зависимостей в конвейере CI/CD

1

dependency-check.sh --scan <PROJECT_DIRECTORY> --format JSON --out dependency-check-report.json

1.Эта команда запускает OWASP Dependency-Check для сканирования каталога проекта (<PROJECT_DIRECTORY>) на наличие известных уязвимостей в зависимостях. Dependency-Check выявляет и сообщает обо всех устаревших или уязвимых библиотеках. Параметр —format указывает выходной формат как JSON, а параметр —out определяет файл, в котором будут сохранены результаты сканирования (dependency-check-report.json).

Неадекватное управление секретами

1.Небезопасное хранение секретов в репозиториях исходного кода

1

gitleaks --repo=https://github.com/your-repo.git --report=secrets-leak-report.txt

1.Эта команда использует GitLeaks для сканирования репозитория Git (your-repo.git) на наличие потенциальных секретов, которые могли быть ошибочно зафиксированы. Неадекватное управление секретами может привести к раскрытию конфиденциальной информации в репозиториях исходного кода. Параметр —report указывает файл, в котором будут сохранены результаты.

2.Небезопасное хранение секретов в шаблонах инфраструктуры как кода (IaC)

1

snyk test --all-projects --json > pipeline-secrets-report.json

Эта команда запускает Snyk для проверки всех проектов в конвейере CI/CD на наличие небезопасных конфигураций секретов. Неадекватное управление секретами в конвейере может подвергнуть конфиденциальную информацию несанкционированному доступу. Параметр —all-projects указывает Snyk протестировать все проекты, а флаг —json указывает выходной формат как JSON. Результаты сканирования сохраняются в файле pipe-secrets-report.json.

Небезопасные сторонние интеграции

1.Небезопасная интеграция API в конвейер CI/CD

1

zap-cli --zap-url http://localhost -p 8080 -c 'quick-scan -s -t https://api.example.com' -r insecure-api-integration-report.html

Эта команда использует интерфейс командной строки OWASP ZAP (zap-cli) для быстрого сканирования конечной точки API (https://api.example.com), интегрированной в конвейер CI/CD. Небезопасные интеграции сторонних API могут создавать уязвимости. Флаг -s включает поиск целевого API, а параметр -r определяет файл, в котором результаты сканирования будут сохранены в формате HTML.

1.Небезопасная библиотека или компонент в конвейере CI/CD

1

snyk test --all-projects --json > insecure-library-report.json

Здесь Snyk используется для проверки всех проектов в конвейере CI/CD на наличие небезопасных библиотек или компонентов. Небезопасные сторонние зависимости могут создавать уязвимости в конвейере. Параметр —all-projects указывает Snyk протестировать все проекты, а флаг —json указывает выходной формат как JSON. Результаты сканирования сохраняются в файле insecure-library-report.json.

2.Небезопасная интеграция облачного провайдера в конвейер

1

cloudgoat create --template pipeline --duration 2h

Эта команда использует CloudGoat для создания имитации небезопасной интеграции поставщика облачных услуг в конвейер. CloudGoat — это инструмент развертывания AWS с уязвимостью. Небезопасная сторонняя интеграция с облачными провайдерами может привести к несанкционированному доступу или утечке данных. Параметр —template указывает шаблон конвейера, а параметр —duration определяет продолжительность моделирования (в данном примере 2 часа).

Слабый контроль доступа

1.Слабые средства контроля доступа в конфигурации конвейера CI/CD

1

arachni http://your-ci-cd-pipeline.com --plugin=login_script --report-save-path=weak-access-controls-report.afr

Эта команда использует Arachni для сканирования веб-сайта конфигурации конвейера CI/CD (http://your-ci-cd-pipeline.com) на наличие слабых средств контроля доступа. Слабые средства контроля доступа к конфигурации конвейера CI/CD могут привести к несанкционированному доступу и потенциальным атакам. Параметр —plugin=login_script включает плагин сценария входа в систему, а параметр —report-save-path определяет файл, в котором результаты сканирования будут сохранены в формате Arachni.

1.Слабые средства контроля доступа к облачной инфраструктуре

1

prowler -c all -r us-west-2 > weak-access-controls-report.txt

Здесь Prowler используется для оценки безопасности облачной инфраструктуры в регионе US West 2. Слабый контроль доступа в облачной инфраструктуре может привести к несанкционированному доступу к конфиденциальным ресурсам. Параметр -c all сканирует все доступные проверки, а параметр -r указывает регион. Результаты сканирования сохраняются в файле weak-access-controls-report.txt.

Заключение

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