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

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

qmake и legacy Qt

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

qmake — сборочная система старых Qt-проектов (.pro-файлы). Она прячет зависимости лучше, чем любая другая система в этом модуле: строка QT += network sql подтягивает целые библиотеки (libQt5Network, libQt5Sql) без единого упоминания версии, а LIBS += -lfoo — это просто сырые флаги линковщика. Ни версии, ни источника в .pro-файле нет в принципе. Какая версия Qt реально слинкуется, определяет не проект, а тот qmake, что стоит на сборочной машине: qmake -query QT_VERSION.

Для SCA это критично сразу по двум причинам. Во-первых, Qt — крупная библиотека с собственной историей CVE, и «невидимая» версия означает невидимую поверхность уязвимостей. Во-вторых, legacy Qt — это часто Qt 4 или ранние Qt 5, у которых истёк срок поддержки; такой компонент рискован сам по себе, независимо от конкретных CVE.

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

.pro-файл декларирует модули, но не версии:

QT += core gui network          # тянет libQt5Core/Gui/Network транзитивно, без версии
greaterThan(QT_MAJOR_VERSION, 4): QT += widgets
LIBS += -L/opt/lib -lcrypto     # сырые флаги: ни имени пакета, ни версии
INCLUDEPATH += /opt/include

Версию знает хост, а не проект

qmake -query QT_VERSION        # 5.15.2  — фактическая версия на этой машине
qmake -query QT_INSTALL_LIBS   # где лежат libQt5*.so
ldd ./app | grep -i qt         # что реально слинковано в артефакт

Один и тот же .pro на двух машинах с разными Qt даст бинари с разной версией Qt и разным набором CVE. Источник истины — ldd готового артефакта плюс qmake -query, а не .pro.

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

Слепая зона двойная. Первая — QT += ... не несёт версии, поэтому генератор SBOM по исходникам в лучшем случае запишет «зависит от Qt» без координаты. Вторая — LIBS += -l... вообще не парсится большинством анализаторов как зависимость: это выглядит как произвольная опция. Плюс legacy-риск: Qt 4 и Qt 5.x за пределами LTS не получают исправлений, и это нужно отмечать явно.

EOL важнее, чем кажется Зафиксируйте major.minor Qt (qmake -query QT_VERSION) и сверьтесь со статусом поддержки ветки. Qt 4 и не-LTS ветки Qt 5 — кандидаты в риск-реестр независимо от наличия конкретных CVE: для них исправлений не выпускают.

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

  1. Снимите qmake -query QT_VERSION и QT_INSTALL_LIBS на сборочной машине — это фактическая версия Qt.
  2. Распарсите .pro: соберите модули из QT += ... и сырые библиотеки из LIBS += -l... — последние легко теряются.
  3. Прогоните ldd по артефакту и смаппьте libQt5*.so/прочие .so на пакеты дистрибутива (dpkg -S).
  4. Проверьте мажор Qt и статус поддержки ветки; EOL-версии Qt вносите в риск-реестр явно.
  5. Сырые -l-зависимости, по которым нет координаты, отправьте в worklist ручной доразметки.
  6. Если проект мигрируем — рассмотрите перевод на CMake (Qt 6 уже на CMake), это сразу делает зависимости видимее для анализа.

Связь