Глоссарий AI‑кодинга для инженерного руководителя

PR review, diff‑based review, SCA, SBOM, KEV, provenance, OIDC, attestations, risk acceptance — восемь понятий, без которых сегодня не обойтись на code review и в разговоре с AppSec-командой.

PR Review (Pull Request Review)

Процесс проверки изменений кода до их слияния в основную ветку. Разработчик создаёт pull request — предложение добавить набор коммитов — и один или несколько рецензентов проверяют корректность, безопасность и соответствие стандартам команды.

Ключевая точка контроля в современном workflow. Именно здесь обнаруживается большинство проблем, которые дорого исправлять после merge. По данным исследования CodeRabbit (декабрь 2025), AI-ассистированный код привносит предсказуемые и измеримые слабости — логические ошибки, проблемы корректности и безопасности — которые команде нужно активно отлавливать на этом этапе [1].

Практическая суть: PR review не гарантирует безопасность. Работающий PR — не обязательно безопасный PR. Рецензент часто не дочитывает диф до конца, не замечает новую зависимость в lock-файле, пропускает изменения в конфигах и CI/CD-файлах.

Diff-Based Review

Подход к код-ревью, при котором анализируется только разность (diff) между текущим и предыдущим состоянием кода — то есть именно те строки, которые изменились в конкретном PR.

Это стандартный режим работы большинства AI-инструментов ревью. GitHub Copilot Code Review, достигший миллиона пользователей за месяц после GA в апреле 2025, работает именно в diff-based режиме: он видит только изменённые строки и не анализирует, как правка влияет на остальные части системы [2]. Как следствие, инструмент может пропустить изменение, которое "маленькое в PR", но ломает дюжины зависимых сервисов [3].

Практическая суть: diff-based review — это скорость, но не глубина. Если правка затрагивает shared-контракты, публичные API или конфигурацию, одного диффа недостаточно. Нужен либо инструмент с пониманием всей кодовой базы, либо явный чек-лист для таких кейсов.

SCA (Software Composition Analysis)

Автоматизированный процесс сканирования зависимостей приложения — open-source библиотек, пакетов, транзитивных зависимостей — с целью выявления известных уязвимостей, устаревших компонентов и проблем с лицензиями [4].

SCA работает, сканируя манифесты пакетов (package.json, pom.xml, requirements.txt), lock-файлы и бинарники, затем сверяя найденные компоненты с базами уязвимостей — NVD, GitHub Security Advisories и другими [5]. Типичный результат — список CVE с CVSS-оценками и рекомендации по обновлению.

Важный нюанс: большинство уязвимостей находятся не в прямых зависимостях, а в транзитивных — тех, которые ваши пакеты подтягивают сами. Именно поэтому ручное отслеживание давно не работает: современные приложения на 80–90% состоят из стороннего кода [6].

SCA — не замена SAST (который анализирует ваш собственный код) и DAST (динамическое тестирование), а отдельный слой, закрывающий риски в коде, который вы не писали сами [7].

SBOM (Software Bill of Materials)

Машиночитаемый реестр всех компонентов, библиотек и зависимостей, из которых собран программный продукт. По аналогии с составом продуктов питания на упаковке — только для ПО [8].

EO 14028 (США, 2021) определяет SBOM как "формальную запись, содержащую детали и отношения цепочки поставок для различных компонентов, используемых при сборке программного обеспечения" [9]. Стандартные форматы: SPDX, CycloneDX, SWID [10].

SBOM — это выходной артефакт SCA. Инструмент SCA сканирует кодовую базу и генерирует SBOM; SBOM затем используется для мониторинга уязвимостей, лицензионного комплаенса и ответа на инциденты. Один и тот же SBOM нужно обновлять с каждым релизом — он не статичен [11].

Регуляторный контекст: EU Cyber Resilience Act (CRA), вступивший в силу в декабре 2024, требует SBOM для производителей программных продуктов. Полные требования по SBOM вступают в силу с декабря 2027 [12].

KEV (Known Exploited Vulnerabilities)

Публичный каталог CISA (США), содержащий CVE, которые подтверждённо эксплуатируются в реальных атаках прямо сейчас [13].

KEV — бинарный сигнал: уязвимость либо попала в каталог (подтверждена эксплуатация в дикой природе), либо нет. Это принципиальное отличие от CVSS (оценка severity) и EPSS (вероятность эксплуатации): KEV говорит о факте, а не вероятности [14].

Практическое значение: если ваш SBOM содержит компонент с CVE из KEV, это не теоретический риск — это активно используемый вектор атаки. Федеральные агентства США обязаны устранять KEV-уязвимости в установленные сроки по BOD 22-01. Для всех остальных организаций CISA настоятельно рекомендует то же самое [15].

Для инженерного руководителя KEV — приоритет номер один при patch-менеджменте. Не "самый высокий CVSS", а "есть ли в KEV".

Provenance (Происхождение артефакта)

Криптографически верифицируемая запись о том, кем, когда, из каких исходников и в каком CI/CD-процессе был собран программный артефакт [16].

Provenance отвечает на вопрос: "Как именно был собран этот бинарник / образ / пакет?" Это не просто метаданные — это подписанное доказательство цепочки сборки. Стандарт SLSA (Supply chain Levels for Software Artifacts) использует in-toto attestation format для provenance. Генерация provenance без подписи даёт только SLSA Level 1; подписание повышает уровень [17].

Практическая ценность: после атаки XZ Utils (2024), где злоумышленник скомпрометировал процесс сборки, а не исходный код, provenance стал обязательным элементом supply chain security. Npm и PyPI уже требуют Sigstore-подписанных provenance для публикации пакетов [18].

OIDC (OpenID Connect) в контексте CI/CD

Протокол федерации идентичности, позволяющий CI/CD-пайплайну доказать свою идентичность внешним сервисам (реестрам, signing-инфраструктуре, облачным провайдерам) без передачи долгоживущих секретов [19].

В контексте supply chain: GitHub Actions получает короткоживущий OIDC-токен, привязанный к конкретному workflow, репозиторию и ветке. Этот токен используется для аутентификации в Sigstore (Fulcio), который выдаёт краткосрочный signing-сертификат. В результате можно подписывать артефакты без хранения private keys в секретах репозитория [20].

Для чего это важно руководителю: традиционные CI/CD-пайплайны переполнены долгоживущими секретами — registry credentials, signing keys, service account tokens. Каждый из них — потенциальный вектор компрометации. OIDC-федерация убирает целый класс этих рисков [21].

Attestations (Аттестации)

Подписанные machine-verifiable заявления о свойствах артефакта. Аттестация — это "Я (конкретный CI/CD workflow) утверждаю, что этот артефакт обладает следующими свойствами и был собран вот так" [22].

Аттестации бывают разные по типу: provenance (как собран), SBOM (из чего состоит), vulnerability scan results (что найдено сканером), policy compliance (соответствие политике). Технически — это подписанный документ в формате DSSE или in-toto envelope, прикреплённый к digest артефакта. Cosign (часть Sigstore) — де-факто стандарт для создания и верификации аттестаций в экосистеме контейнеров и пакетов [23].

GitHub Artifact Attestations (GA с 2024) позволяют командам генерировать и проверять SLSA provenance прямо из GitHub Actions [18].

Практическое значение: аттестации — это способ получить верифицируемые ответы на вопросы "Что именно задеплоено?" и "Можно ли этому доверять?" без звонков в команду сборки.

Risk Acceptance (Принятие риска)

Осознанное задокументированное решение оставить известную уязвимость или риск без немедленного исправления — потому что стоимость исправления превышает потенциальный ущерб, или риск находится в пределах допустимого порога организации [24].

Risk acceptance — это не игнорирование риска. Это один из четырёх стандартных стратегий управления риском: избегание, снижение, передача (например, страхование) и принятие [25]. NIST и ISO 27001 предусматривают risk acceptance как легитимный исход оценки рисков [26].

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

Критически важно в контексте KEV: risk acceptance для уязвимости, которая уже попала в KEV, — это исключительная ситуация, требующая компенсирующих мер и письменного утверждения на уровне руководства. "Примем риск" без документирования — это не risk acceptance, это долг безопасности без учёта.

Как эти понятия связаны между собой

Типичный путь изменения через современный security-контроль выглядит так:

1. Разработчик создаёт PR с новой зависимостью.
2. SCA-инструмент в CI находит CVE в транзитивной зависимости.
3. Команда проверяет, есть ли CVE в KEV-каталоге (приоритет).
4. Diff-based PR review видит изменение в lock-файле, но не анализирует downstream-эффект.
5. После merge CI собирает артефакт, генерирует SBOM и provenance-аттестацию, подписанную через Sigstore с OIDC-токеном.
6. Если CVE остаётся в продакшене — команда оформляет risk acceptance с временным горизонтом и владельцем решения.

Инструменты вроде HighVibe работают именно на пересечении этих этапов: анализируют конкретное изменение в PR, проверяют новые и обновлённые зависимости, учитывают KEV и контекст релиза — и дают короткий ответ команде до merge, а не после.

Источники

[1] Help Net Security — "AI code looks fine until the review starts" — https://www.helpnetsecurity.com/2025/12/23/coderabbit-ai-assisted-pull-requests-report/

[2] DEV Community — "The Best AI Code Review Tools of 2026" — https://dev.to/heraldofsolace/the-best-ai-code-review-tools-of-2026-2mb3

[3] Qodo — "8 Best AI Code Review Tools That Catch Real Bugs in 2026" — https://www.qodo.ai/blog/best-ai-code-review-tools-2026/

[4] Black Duck — "What is Software Composition Analysis (SCA)?" — https://www.blackduck.com/glossary/what-is-software-composition-analysis.html

[5] SentinelOne — "What Is Software Composition Analysis (SCA)?" — https://www.sentinelone.com/cybersecurity-101/cybersecurity/software-composition-analysis-sca/

[6] Sonar — "Software Composition Analysis (SCA) Definition & Guide" — https://www.sonarsource.com/resources/library/software-composition-analysis/

[7] Chainguard — "What is Software Composition Analysis (SCA)" — https://www.chainguard.dev/supply-chain-security-101/what-is-software-composition-analysis-sca

[8] NIST CSRC Glossary — "Software Bill of Materials" — https://csrc.nist.gov/glossary/term/software_bill_of_materials

[9] NIST — "Software Security in Supply Chains: Software Bill of Materials (SBOM)" — https://www.nist.gov/itl/executive-order-14028-improving-nations-cybersecurity/software-security-supply-chains-software-1

[10] CISA — "Software Bill of Materials (SBOM)" — https://www.cisa.gov/sbom

[11] IBM — "Updated SBOM guidance: A new era for software transparency?" — https://www.ibm.com/think/insights/updated-sbom-guidance-2024

[12] FOSSA — "The Comprehensive Guide to SBOM Compliance Requirements" — https://fossa.com/learn/sbom-compliance-requirements/

[13] CISA — "Known Exploited Vulnerabilities Catalog" — https://www.cisa.gov/known-exploited-vulnerabilities-catalog

[14] Picus Security — "What Is Known Exploited Vulnerabilities Catalog (KEV)?" — https://www.picussecurity.com/resource/blog/what-is-kev-known-exploited-vulnerabilities-catalog

[15] CISA — "Reducing the Significant Risk of Known Exploited Vulnerabilities" — https://www.cisa.gov/known-exploited-vulnerabilities

[16] Nine Lives Zero Trust — "Secure Your Container Supply Chain: SBOM, Signing & Attestation with GitHub Actions" — https://nineliveszerotrust.com/blog/container-sbom-signing-attestation/

[17] Cycode — "Securing Artifacts: Keyless Signing with Sigstore and CI/MON" — https://cycode.com/blog/securing-artifacts-keyless-signing-with-sigstore-and-ci-mon/

[18] Sbomify — "What Is Sigstore? Keyless Signing for the Software Supply Chain" — https://sbomify.com/2024/08/12/what-is-sigstore/

[19] arXiv — "Establishing Workload Identity for Zero Trust CI/CD" — https://arxiv.org/pdf/2504.14760

[20] Legit Security — "SLSA Provenance Part 3: Adoption Challenges" — https://www.legitsecurity.com/blog/slsa-provenance-blog-series-part3-challenges-of-adopting-slsa-provenance

[21] GitLab Docs — "Use Sigstore for keyless signing and verification" — https://docs.gitlab.com/ci/yaml/signing_examples/

[22] Sigstore Blog — "cosign Verification of npm Provenance, GitHub Artifact Attestations" — https://blog.sigstore.dev/cosign-verify-bundles/

[23] Legit Security — "SLSA Provenance Part 3" (см. выше) — https://www.legitsecurity.com/blog/slsa-provenance-blog-series-part3-challenges-of-adopting-slsa-provenance

[24] ISMS.online — "Risk Acceptance" — https://www.isms.online/glossary/risk-acceptance/

[25] RSI Security — "What is Risk Acceptance in Cyber Security?" — https://blog.rsisecurity.com/what-is-risk-acceptance-in-cyber-security/

[26] Sprinto — "Risk Acceptance in Risk Management: Understanding, Strategies & Best Practices" — https://sprinto.com/blog/risk-acceptance/