Архивные и тестовые учётные записи: тихая дыра в продукте

Почему «забытый» аккаунт опаснее новой уязвимости — и как это связано с тем, что ваш AI уже написал в прод

Введение: проблема, у которой нет красивого CVE

Большинство команд хорошо знают, как защититься от SQL-инъекций и XSS. Значительно хуже — что делать с учётной записью QA-инженера, уволившегося полгода назад, или тестовым аккаунтом test_admin / password123, который кто-то создал под дедлайн и «временно» оставил в продакшне.

Архивные (orphaned) и тестовые учётные записи редко попадают в топы уязвимостей, потому что они не являются уязвимостью в техническом смысле. Это легитимные учётные данные, которые работают ровно так, как были задуманы — просто им давно не место в живом продукте. Именно поэтому они так опасны: не триггерят WAF, не светятся в SIEM-правилах на аномальный трафик, не попадают в отчёты SAST.

Для CTO, Tech Lead и AppSec-команды эта тема актуальна сразу в нескольких измерениях: безопасность продукта, соответствие регуляторным требованиям (GDPR, ФЗ-152, ISO 27001, PCI DSS), управление identity-жизненным циклом в CI/CD и, наконец, контроль изменений, которые AI-ассистенты сегодня генерируют с нарастающей скоростью.

Что такое архивные и тестовые учётные записи

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

Orphaned account (архивная, «осиротевшая» учётная запись) — активная учётная запись, у которой больше нет реального владельца. Классика: разработчик уволился, HR закрыл дело, но IT-команда так и не отозвала доступ к GitHub-организации, облачной консоли и production-базе. По определению BeyondTrust, такие учётные записи «сохраняют доступ к приложениям и системам без активного владельца» и позволяют атакующему двигаться по инфраструктуре незамеченным [9].

Stale account (устаревший аккаунт) — учётная запись, которая не использовалась более условного порога (обычно 90 дней). Может принадлежать живому сотруднику, который просто поменял роль, или быть полностью заброшенной. По данным Varonis, в среднем 26% всех аккаунтов в корпоративной среде относятся к категории stale; в некоторых организациях эта цифра доходит до 90% [4].

Test account (тестовый аккаунт) — учётная запись, созданная для нужд разработки или QA. Риск возникает, когда такие аккаунты попадают в продакшн-среду: с предсказуемыми паролями, расширенными правами («чтобы тестировать всё»), отключённым MFA и без срока действия.

Hardcoded credentials (захардкоженные учётные данные) — частный случай тестовых аккаунтов: пароли, токены или ключи, встроенные прямо в исходный код или конфигурационные файлы. В классификации MITRE это CWE-798 («Use of Hard-coded Credentials») — одна из наиболее стабильно воспроизводимых категорий уязвимостей [5].

Масштаб проблемы: цифры, которые неудобно игнорировать

Данные из нескольких независимых источников формируют устойчивую картину.

По частоте встречаемости. Согласно Varonis State of Data Security Report 2025, который охватывает анализ почти 10 миллиардов файлов в 1000 реальных корпоративных сред, 88% организаций имеют активные ghost-учётные записи [1]. В среднем в компании насчитывается около 15 000 таких аккаунтов с включённым доступом [2]. Исследование Orchid Security 2025 добавляет, что 44% организаций сообщают о более чем 1000 orphaned-аккаунтов; в финансовом секторе эта цифра — 64%, в здравоохранении — 79% [4].

По частоте эксплуатации. По данным того же Orchid Security, 27% облачных взломов в 2024 году были связаны с компрометацией неактивных учётных данных [3, 4]. Verizon DBIR 2024 зафиксировал, что злоупотребление учётными данными остаётся вектором атаки номер один [10]. Атаки через скомпрометированные учётные данные в среднем обнаруживаются через 292 дня — почти год — по данным IBM [2].

По стоимости. Средняя стоимость взлома через скомпрометированные учётные данные — 4,8 млн долларов [11]. При этом средняя стоимость любого breach в 2025 году составила 4,44 млн долларов — данные IBM [2, 11].

Для команд в России дополнительный контекст: по данным Infowatch, только за 2024 год произошло 9175 утечек, которые затронули 26,77 млрд записей [12]. Скомпрометированные или устаревшие учётные данные — один из ключевых векторов в этой статистике.

Почему проблема не исчезает сама по себе

Сложность lifecycle-управления

Современная разработка порождает сотни идентичностей: разработчики, QA-инженеры, контрагенты, CI-системы, боты, сервисные аккаунты, OAuth-приложения, SSH-ключи, PAT. Каждая система — GitHub, GitLab, AWS, GCP, Okta, Jira, Confluence, production-базы — ведёт собственный реестр пользователей. Когда разработчик уходит, HR фиксирует увольнение, но это событие далеко не всегда автоматически запускает deprovisioning во всех системах одновременно.

OWASP CI/CD Security Risks (CICD-SEC-2) прямо называет это «Inadequate Identity and Access Management» и выделяет stale identities — аккаунты сотрудников и систем, которые больше не нуждаются в доступе, но не были деактивированы — как одну из системообразующих проблем пайплайнов [8].

Тестовые среды — это недооценённый вектор

Тестовые среды традиционно считаются «менее критичными» и потому хуже защищены. На практике:

1. В тестовых средах часто используются реальные или близкие к реальным данные пользователей.
2. Тестовые учётные записи создаются с расширенными правами «для удобства отладки».
3. Тестовые среды реже мониторятся: аномальная активность остаётся невидимой.
4. После завершения проекта тестовые аккаунты не удаляются, а переносятся в продакшн как часть конфигурации [13].

Именно эту логику подчёркивает OWASP ASVS-тред: тестовые среды по умолчанию «имеют тестовые аккаунты и debug-функциональность», и использование в них продакшн-данных создаёт дополнительный риск экспозиции [13].

AI-ассистенты ускоряют проблему

Здесь появляется актуальный для 2025 года контекст. AI-инструменты — Copilot, Cursor, различные LLM-агенты — резко ускорили написание кода. Вместе с этим они ускорили и воспроизведение паттернов, которые считались «временными»: хардкодированные учётные данные в конфигах, дефолтные тестовые пароли в seed-данных, debug-аккаунты в миграциях.

Модель генерирует «рабочий» код быстро. Но «работает» не означает «безопасно для релиза» — особенно если в сгенерированном конфиге оказался тестовый пароль, скопированный из контекста запроса, или hardcoded токен из старого примера в обучающих данных. Дифы при этом читают не до конца: по данным исследований, служебный код, конфиги, миграции и internal tools просматриваются значительно небрежнее, чем бизнес-логика.

Реальные инциденты: от архивных аккаунтов до кода в продакшне

Colonial Pipeline (2021)

Атака на крупнейшую топливную инфраструктуру США начиналась через неактивный VPN-аккаунт без MFA. Учётная запись принадлежала уволившемуся сотруднику и оставалась активной. Инцидент повлёк остановку поставок и выкуп в 4,4 млн долларов [14].

SolarWinds Web Help Desk — CVE-2024-28987

В августе 2024 года Horizon3.ai обнаружили, что в Web Help Desk от SolarWinds захардкодены учётные данные разработчика (developer credentials), встроенные прямо в Java-класс. Используя эти данные, неаутентифицированный атакующий мог читать и изменять все тикеты в helpdesk — то есть фактически получал доступ к IT-переписке всей организации. CISA добавила CVE-2024-28987 в список Known Exploited Vulnerabilities [6, 7].

Cisco Smart Licensing Utility — CVE-2024-20439

Аналогичная ситуация: в Cisco CSLU обнаружился встроенный backdoor-аккаунт с административными привилегиями, позволявший удалённый доступ без аутентификации. SANS зафиксировал активную эксплуатацию цепочки уязвимостей в реальных атаках [15].

Manufacturing company + Akira ransomware (2025)

Производственная компания стала жертвой Akira через «ghost»-аккаунт стороннего вендора, который не был деактивирован после завершения контракта. Инцидент задокументирован в отчёте Barracuda Managed XDR [14].

Microsoft (январь 2024)

Команда безопасности Microsoft зафиксировала атаку, в которой использовались скомпрометированные учётные данные, включая временные и тестовые аккаунты в корпоративной системе электронной почты. Атакующие получили доступ к внутренним системам, репозиториям исходного кода и предприняли попытки горизонтального перемещения по сети [16].

Mercedes-Benz (январь 2024)

В публичном GitHub-репозитории обнаружен authentication token сотрудника Mercedes-Benz, который предоставлял неограниченный и немониторируемый доступ к внутреннему GitHub Enterprise Server с исходным кодом компании [17].

Как архивные аккаунты становятся точкой входа: механика атаки

Понимание атакерской механики помогает расставить приоритеты защиты.

Шаг 1 — Разведка. Атакующий ищет информацию об orphaned-аккаунтах через LinkedIn (кто уволился из компании), утечки в даркнете, публичные репозитории (захардкоженные токены, конфиги с тестовыми паролями), ответы API без авторизации.

Шаг 2 — Первоначальный доступ. Используется учётная запись с предсказуемым или утёкшим паролем, тестовый аккаунт с дефолтными данными или hardcoded-токен. Поскольку учётные данные легитимны, они не вызывают срабатывания типичных правил.

Шаг 3 — Горизонтальное перемещение. Orphaned-аккаунты часто имеют избыточные права — «временно» расширенные и никогда не отозванные. BeyondTrust описывает типичную схему: атакующий входит через низкоуровневый эксплойт или фишинг, а затем «натыкается» на orphaned-аккаунт с privileged access и использует его для эскалации [9].

Шаг 4 — Длительное присутствие. Поскольку активность orphaned-аккаунта никто не отслеживает, атака может оставаться незамеченной месяцами. Именно этим объясняется медианное время обнаружения в 292 дня.

В контексте CI/CD-пайплайнов механика аналогична, но масштаб потенциальных последствий шире: скомпрометированный developer-аккаунт даёт доступ к workflow-файлам, секретам в CI-среде и в конечном счёте к продакшну. Кампания GhostAction в сентябре 2025 года продемонстрировала это в промышленных масштабах: 327 пользователей GitHub, 817 репозиториев, 3325 украденных секретов [18].

Классификация рисков по типу учётных записей

Orphaned human accounts

Наиболее распространённый тип. Возникают при увольнениях, смене ролей, завершении контрактов. Особенно опасны в CI/CD-системах (GitHub, GitLab) и облачных консолях. Compliance-риск: прямое нарушение требований ISO 27001, NIS2, PCI DSS по deprovisioning [14].

Service accounts и programmatic identities

Сервисные аккаунты создаются под конкретные интеграции и задачи. После завершения проекта они часто остаются активными с широкими правами. OWASP CI/CD Risks отдельно выделяет local identities — аккаунты, не федерированные с централизованным IdP, — как сложные в управлении и аудите [8].

Test accounts в продакшне

Создаются под дедлайн, «временно» попадают в продакшн и остаются там навсегда. Характерные признаки: предсказуемые логины (test, admin, qa-user), слабые или отсутствующие пароли, расширенные права, отключённый MFA.

Hardcoded credentials в коде

Технически это не аккаунт, а встроенный «ключ». Но эффект тот же: любой, кто получает доступ к коду (через публичный репозиторий, утечку, supply chain атаку), автоматически получает и учётные данные для доступа к системе. CWE-798 стабильно входит в рейтинги наиболее опасных weakness'ов [5].

OWASP, стандарты и регуляторная картина

OWASP Top 10 CI/CD Security Risks — CICD-SEC-2

OWASP прямо называет «Inadequate Identity and Access Management» второй по значимости угрозой для CI/CD-пайплайнов. В числе конкретных риск-факторов: stale identities; local identities вне централизованного IdP; аккаунты с регистрацией на email вне домена организации [8].

OWASP WSTG — 4.3.3 Test Account Provisioning

Раздел WSTG, посвящённый тестированию процесса provisioning, прямо указывает, что «provisioning аккаунтов создаёт возможность для атакующего создать валидный аккаунт в обход надлежащих процессов идентификации и авторизации». Проверять следует: кто может создавать аккаунты, с какими правами, существуют ли проверки при deprovisioning [19].

OWASP Secure Coding Practices

Чек-лист OWASP Secure Coding Practices требует: изолировать dev-среды от production; использовать разные учётные данные для каждого уровня доверия; не хардкодить connection strings и не оставлять тестовые аккаунты в production-конфигах [20].

ISO 27001, NIS2, PCI DSS

Все три стандарта содержат требования к своевременному deprovisioning и принципу минимальных привилегий. Orphaned-аккаунты — прямой audit finding по этим требованиям. Для российских компаний: ФСТЭК прямо рекомендует «отключить (удалить) неиспользуемые учётные записи пользователей» как компенсирующую меру при обнаружении уязвимостей [21]. ФЗ-152 накладывает требования по защите персональных данных, которые хранятся в системах с потенциально скомпрометированным доступом [22].

Где архивные аккаунты живут в продукте: карта поверхности

Полезно систематизировать, где именно скапливаются проблемные учётные записи в типичной команде разработки:

1. Source control (GitHub/GitLab) — PAT уволившихся разработчиков, OAuth-приложения устаревших интеграций, SSH-ключи бывших контрагентов.
2. CI/CD-системы (Jenkins, GitHub Actions, CircleCI) — сервисные аккаунты под завершённые проекты, workflow-секреты без ротации, runner-аккаунты с избыточными правами [8, 23].
3. Облачные консоли (AWS, GCP, Azure) — IAM-пользователи, роли и access keys, связанные со старыми проектами или уволившимися сотрудниками.
4. Базы данных — отдельные user-аккаунты с production-правами, созданные для отладки или миграции.
5. SaaS-инструменты (Jira, Confluence, Slack, Notion) — аккаунты контрагентов, партнёров, бывших сотрудников.
6. Конфигурационные файлы в репозитории — hardcoded тестовые пароли в .env.example, seed-файлах, docker-compose.yml, миграциях.
7. Internal tools и admin-панели — часто наименее контролируемый слой: создаются быстро, документируются плохо, деактивируются редко.

Где проблема пересекается с AI-кодингом

Команды, которые активно используют AI-ассистентов, сталкиваются с несколькими специфическими рисками.

Паттерн воспроизведения. LLM обучены на огромных корпусах кода, включая примеры с хардкодированными учётными данными. Модель может воспроизвести паттерн password = "test123" в конфиге или сгенерировать seed-файл с дефолтными admin-аккаунтами — просто потому, что это наиболее частый паттерн в обучающих данных.

Скорость без ревью. AI резко увеличивает скорость генерации кода, но скорость ревью остаётся человеческой. В результате дифы читают поверхностно, конфиги просматривают по диагонали, миграции вообще принимают «на доверие». Hardcoded credential в миграции или служебном файле легко проскочит в прод.

Контекст из промпта. Если разработчик вставляет в промпт реальный конфиг или .env-файл «для контекста», модель может включить фрагменты с реальными данными в ответ — который потом окажется в коде [17].

Тестовые аккаунты в seed-данных. AI-сгенерированные seed-файлы и фикстуры нередко содержат тестовые аккаунты с предсказуемыми паролями. Если такой файл попадает в продакшн-миграцию — проблема.

Именно здесь логично применить дополнительный слой контроля до merge и релиза. HighVibe анализирует конкретные изменения в коде, конфигурационных файлах и служебных файлах — именно там, где тестовые учётные данные и debug-настройки чаще всего ускользают от внимания при ревью. Инструмент не заменяет SAST или SCA, но помогает заметить риск до того, как он попал в прод.

Практика: чек-лист контроля учётных записей

До написания кода

• Зафиксировать политику именования тестовых аккаунтов (отдельный домен, отдельный префикс).
• Определить срок жизни тестовых аккаунтов — и автоматизировать их удаление.
• Убедиться, что seed-файлы и фикстуры не содержат реальных или production-подобных паролей.

При ревью PR / перед merge

• Проверить, нет ли хардкодированных учётных данных в новых файлах конфигурации, docker-compose, .env, миграциях.
• Убедиться, что новые сервисные аккаунты создаются с минимально необходимыми правами и документируются.
• Проверить, не добавляет ли PR новые тестовые аккаунты в production-конфиги.
• Проверить, нет ли «временных» admin-аккаунтов под конкретную фичу или дедлайн.

Перед релизом

• Убедиться, что тестовые аккаунты не попадают в production-миграции.
• Проверить, что все временные access keys и токены, выданные для тестирования, отозваны.
• Убедиться, что конфиги разных окружений используют разные учётные данные [20].

Регулярный аудит (operational)

• Проводить инвентаризацию учётных записей во всех системах с частотой не реже раза в квартал.
• Сопоставлять активные аккаунты с актуальным HR-реестром: уволившиеся, изменившие роль, завершившие контракт.
• Для CI/CD-систем: отдельно ревьюить PAT, SSH-ключи, OAuth-приложения, сервисные аккаунты.
• Установить автоматическое уведомление при появлении аккаунта, неактивного более 90 дней [10, 24].

Технические контроли

• Принцип минимальных привилегий (least privilege) — для каждой учётной записи, включая сервисные.
• MFA для всех человеческих учётных записей с доступом к CI/CD и облачным консолям [9, 10].
• Автоматическая ротация секретов и токенов.
• Federated identity: все аккаунты должны быть федерированы с централизованным IdP (Okta, Entra ID, Google Workspace) — это позволяет деактивировать доступ в одной точке [8].
• Just-In-Time (JIT) provisioning: вместо постоянного доступа — временный, выданный по запросу и автоматически отзываемый.

Ошибки и антипаттерны

«Тестовый аккаунт — не настоящий аккаунт». Разработчики искренне считают, что test_user / qwerty в staging — не проблема. Но staging нередко использует реальные данные или имеет сетевую доступность до production.

«Мы заберём его после релиза». Классика. После релиза начинается следующий спринт, тестовый аккаунт остаётся на годы.

«Это только для внутреннего использования». Разработчик публикует в публичный репозиторий конфиг с тестовым токеном, думая, что его «никто не найдёт». Роботы-сканеры ищут такие паттерны непрерывно [17].

«HR сообщит нам об увольнении». Отсутствие автоматизированной интеграции HR → IdP → deprovisioning приводит к тому, что уволившиеся разработчики сохраняют доступ неделями и месяцами.

«SAST найдёт хардкодированные пароли». Найдёт — если правило настроено и ложные срабатывания не заставили команду его отключить. Но SAST не знает о том, кто уволился вчера, и не проверяет, отозваны ли временные токены, выданные два месяца назад.

Тренды и то, что будет усиливаться

Несколько направлений, которые будут усиливать риски в ближайшие 12–24 месяца:

1. Рост non-human identities. AI-агенты и автоматические системы создают собственные identities в инфраструктуре. Управление их жизненным циклом — в основном нерешённая задача. Orchid Security State of Identity Security 2025 фиксирует: в почти половине корпоративных сред хотя бы один authentication flow обходит стандартные IdP [4].

1. Ускорение AI-кодинга без опережающего роста контроля. Темп генерации кода растёт быстрее, чем темп его ревью. Hardcoded credentials и тестовые аккаунты будут всё чаще попадать в PR — не по злому умыслу, а как артефакт скорости.

1. M&A как множитель orphaned-аккаунтов. При слияниях и поглощениях обнаруживаются тысячи устаревших аккаунтов и токенов из объединяемых организаций [14].

1. Ужесточение регуляторных требований. В России с 2025 года действуют обновлённые нормы ФЗ-152 с более строгими сроками уведомления РКН об утечках (24 часа) [22]. NIS2 в Европе устанавливает жёсткие требования к управлению доступом.

Заключение: что делать прямо сейчас

Архивные и тестовые учётные записи — это не нишевая проблема для IAM-команды. Это риск, который живёт в каждом PR, в каждом конфиге, который генерирует AI, и в каждом уволившемся разработчике, чей доступ ещё не отозван.

Практический вывод для команды:

1. Начать с инвентаризации: выгрузить список всех аккаунтов во всех системах и сопоставить с актуальным HR-реестром.
2. Установить автоматизированный deprovisioning — хотя бы для critical-систем (GitHub, облачные консоли, production-базы).
3. Добавить проверку hardcoded credentials и тестовых аккаунтов в процесс ревью PR — как обязательный чек-пойнт, а не «когда есть время».
4. Обеспечить контроль до merge и релиза: дополнительный слой, который видит конкретное изменение в конфиге или миграции и сигнализирует до того, как оно попало в прод.

«Работает» — не значит «безопасно для релиза». Особенно если за рычагами стоит AI, а ревью прочитали по диагонали.

Источники

[1] Varonis — "State of Data Security Report 2025" — https://info.varonis.com/en/state-of-data-security-2025

[2] Varonis — "Data Breach Statistics & Trends [updated 2025]" — https://www.varonis.com/blog/data-breach-statistics

[3] Trustle — "Orphaned Accounts: The High Cost of Ghost Access in the Cloud" — https://www.trustle.com/post/orphaned-accounts

[4] Orchid Security — "The Fastest Way into Your Org: Orphan & Local Accounts" — https://www.orchid.security/reports/orphan-local-accounts

[5] MITRE CWE — "CWE-798: Use of Hard-coded Credentials" — https://www.cvedetails.com/cwe-details/798/Use-of-Hard-coded-Credentials.html

[6] Field Effect — "SolarWinds patches actively exploited hardcoded credentials vulnerability (CVE-2024-28987)" — https://fieldeffect.com/blog/solarwinds-patches-exploited-hardcoded-credentials-vulnerability

[7] Horizon3.ai — "CVE-2024-28987: SolarWinds Web Help Desk Hardcoded Credential Vulnerability Deep-Dive" — https://horizon3.ai/attack-research/disclosures/cve-2024-28987-solarwinds-web-help-desk-hardcoded-credential-vulnerability-deep-dive/

[8] OWASP — "CICD-SEC-2: Inadequate Identity and Access Management" — https://owasp.org/www-project-top-10-ci-cd-security-risks/CICD-SEC-02-Inadequate-Identity-And-Access-Management

[9] BeyondTrust — "Orphaned Account Definition" — https://www.beyondtrust.com/resources/glossary/orphaned-accounts

[10] RoboMQ / Hire2Retire — "Orphaned Accounts: Identify, Eliminate & Stay Compliant" — https://www.robomq.io/blog/orphaned-accounts-identity-governance/

[11] DeepStrike — "Compromised Credential Statistics 2025" — https://deepstrike.io/blog/compromised-credential-statistics-2025

[12] АСТГУ — "Информационные технологии и безопасность (по данным Infowatch 2024)" — https://astu.org/Uploads/files/izdatelstvo/75-%D1%8F%20%D1%81%D1%82%D1%83%D0%B4%D0%B5%D0%BD%D1%87%D0%B5%D1%81%D0%BA%D0%B0%D1%8F%20%D0%BA%D0%BE%D0%BD%D1%84%D0%B5%D1%80%D0%B5%D0%BD%D1%86%D0%B8%D1%8F%20%D1%83%D1%87%D0%B5%D0%BD%D1%8C%D1%88%D0%B5%D0%BD%D0%BD%D1%8B%D0%B9%202.pdf

[13] OWASP ASVS — "Production data in test environment (Issue #851)" — https://github.com/OWASP/ASVS/issues/851

[14] The Hacker News — "The Hidden Risk of Orphan Accounts" — https://thehackernews.com/2026/01/the-hidden-risk-of-orphan-accounts.html

[15] Medium / ML4Den — "Cybersecurity News Review — Week 12 (2025)" — https://medium.com/ml4den/cybersecurity-news-review-week-12-2025-f15da578c304

[16] Stitchflow — "Risks of Inactive User Accounts and How to Mitigate Them" — https://www.stitchflow.com/blog/risks-of-inactive-user-accounts

[17] Codacy — "Managing the Risks of Hard-Coded Secrets" — https://blog.codacy.com/hard-coded-secrets

[18] Elastic Security Labs — "CI/CD pipeline abuse: the problem no one is watching" — https://www.elastic.co/security-labs/detecting-cicd-pipeline-abuse-with-llm-augmented-analysis

[19] OWASP WSTG — "4.3.3 Test Account Provisioning Process" — https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/03-Identity_Management_Testing/03-Test_Account_Provisioning_Process

[20] OWASP — "Secure Coding Practices - Quick Reference Guide" — https://owasp.org/www-project-secure-coding-practices-quick-reference-guide/stable-en/02-checklist/05-checklist

[21] ФСТЭК — "Бюллетень информационной безопасности от 14.08.2025" — https://shkola2alejsk-r22.gosweb.gosuslugi.ru/netcat_files/userfiles/Byulleten_1.pdf

[22] Kontур — "Обработка персональных данных в 2025: риски и штрафы" — https://kontur.ru/market/spravka/31263-personalnye_dannye_klientov_v_sisteme_loyalnosti

[23] Packetlabs — "The OWASP Top 10 CI/CD Security Risks to Harden DevSecOps" — https://www.packetlabs.net/posts/owasp-top-10-ci-cd-security-risks/

[24] SecurEnds — "How to Detect and Eliminate Orphaned Accounts Before They Become a Threat" — https://www.securends.com/blog/orphaned-accounts/