Пиков / КАПО
Библиотека
Как читать авторский курс и нормативные материалы

Это учебные материалы, а не заключение о соответствии конкретного продукта. Организационные модели курса отделяйте от терминов стандарта: ППК в опубликованном проекте — машиночитаемый перечень, а живой реестр его версий является практикой сопровождения. Термин OSA в разных материалах имеет разный охват. Статус и обязательность нормативного документа проверяются отдельно; проект КАПО опубликован как проект первой редакции.

копипаста кода

Почему это важно для SCA/OSA

Композиционный анализ построен вокруг компонентов: библиотека, пакет, артефакт со своей версией и координатами. Но в C/C++ заимствование часто происходит на уровне фрагмента, а не библиотеки: разработчик скопировал функцию хеширования из Stack Overflow, реализацию CRC из чужого проекта, парсер из примера к статье. Такой код не библиотека — у него нет ни имени пакета, ни версии, ни записи в графе зависимостей. Ни один SCA-сканер, идущий по манифестам и линковке, его не обнаружит, потому что обнаруживать в его модели нечего.

Между тем риск реален: скопированный фрагмент мог прийти из уязвимой версии (классика — копипаста уязвимого парсера или функции с переполнением буфера), а лицензия источника — оказаться copyleft или несовместимой. Уязвимость и лицензионное обязательство «приезжают» вместе с кодом, но в SBOM их нет.

Как это проявляется

Скопированный фрагмент неотличим от собственного кода по структуре проекта — он просто функция в .c-файле. Найти его можно только содержательным сравнением, а не анализом зависимостей:

# Маркеры копипасты: чужой стиль, оставленные комментарии и копирайты внутри своего кода
grep -rnE 'Copyright|SPDX-License-Identifier|Permission is hereby|stackoverflow\.com|gist\.github' src/

# Дубликаты внутри проекта (clone detection) — например, через PMD CPD
pmd cpd --minimum-tokens 100 --language cpp --files src/ --format text

# Точная функция могла прийти из известной библиотеки — поиск характерных констант/строк
grep -rn '0xEDB88320' src/   # табличная константа CRC32 — почти всегда копипаста

В отличие от vendoring (где скопирован целый файл/библиотека), копипаста — это десятки строк внутри вашего файла, и её не вычистить простым исключением каталога third_party/.

Слепая зона или приём

Слепая зона — snippet-level reuse невидим для компонентного SCA. Граф зависимостей пуст, линковка чистая, манифестов нет — формально «свой код». Поэтому уязвимость или лицензия источника не попадают ни в анализ CVE, ни в юридический workflow. Спасает только переход с компонентного уровня на уровень фрагментов: clone/snippet detection (CPD/PMD, а в коммерческих SCA — «snippet matching» против базы open source).

SCA по зависимостям копипасту не ловит Если у компонента нет имени и версии, сканеру уязвимостей не на что мэтчить CVE, а лицензионному анализатору — не на что вешать обязательство. Copy-paste из уязвимого источника проходит все стандартные SCA-проверки как «first-party», то есть как чистый. Для этого класса нужен отдельный инструмент уровня кода, а не уровня зависимостей.

Что делать на проекте

  1. Прогоните проект через clone detection (например, pmd cpd) и зафиксируйте крупные дубликаты — кандидаты на внешнее происхождение.
  2. Ищите оставленные маркеры происхождения: копирайты, SPDX-теги, URL источников, характерные комментарии внутри собственных файлов.
  3. Для критичной функциональности (крипто, парсинг недоверенного ввода, сериализация) выясняйте источник фрагмента и его лицензию вручную.
  4. Найденный заимствованный фрагмент с известным происхождением оформляйте как компонент в SBOM с пометкой «snippet» и ссылкой на источник; неустановленное — в unresolved libraries.
  5. По возможности замените копипасту на нормальную зависимость с версией — так компонент станет видимым для SCA.
  6. Введите ревью-правило: внешний код входит в проект только как объявленная зависимость или явно задокументированный фрагмент с лицензией.

Связь