Как читать авторский курс и нормативные материалы
Это учебные материалы, а не заключение о соответствии конкретного продукта. Организационные модели курса отделяйте от терминов стандарта: ППК в опубликованном проекте — машиночитаемый перечень, а живой реестр его версий является практикой сопровождения. Термин OSA в разных материалах имеет разный охват. Статус и обязательность нормативного документа проверяются отдельно; проект КАПО опубликован как проект первой редакции.
Билет 11
Теоретический вопрос
Сравните динамическую и статическую линковку с точки зрения восстановления состава ПО. Почему динамическая зависимость (.so) видна и доказуема — через DT_NEEDED в ELF, readelf -d, ldd, — а статическая (.a) становится слепой зоной: компонент физически вшит в бинарь и исчезает из SBOM? Объясните, почему «сканер ничего не нашёл» для статически слинкованного бинаря — это не отсутствие зависимостей, а отсутствие доказательств.
Практический вопрос
Мини-кейс Дан один исполняемый файл. Нужно перечислить его сторонние компоненты. Снимите динамические зависимости и объясните, почему статически вшитая библиотека (например, своя сборка zlib через
.a) в этот список не попадёт и что нужно сделать, чтобы её зафиксировать.
readelf -d ./app | grep NEEDED # динамика: DT_NEEDED
ldd ./app # разрешённые .so
# для .a-вшитого кода ELF-анализ молчит — нужен build-scan/LIEFЧто должен показать ответ
- Источник факта: для динамики —
DT_NEEDED/readelf -d/ldd; для статики — build evidence на этапе сборки (после линковки следов нет). - Инструмент:
readelf,ldd, LIEF для программного анализа ELF; cdxgen + build-scan для статики. - Владелец решения: квалификация статической линковки как слепой зоны и постановка в worklist — за специалистом композиционного анализа.
- Нормативная опора: ГОСТ Р 56939-2024, NIST SP 800-218 SSDF (PS.3.2), BSI TR-03183-2 v2.1.0.
- Evidence: вывод
readelf -dкак occurrence; запись в реестре unresolved/слепых зон для статики.