Главная проблема: сканирование контейнеров всё ещё завышает риск#
Команды container security хорошо знают эту проблему. Scanner выдаёт длинный список CVE внутри image. Часть приходит из base image. Часть — из application dependencies. Часть присутствует в package database, но недостижима, не exploitable в этой сборке или уже mitigated тем, как был собран image.
Пост в Docker Blog описывает новую интеграцию между Docker Hardened Images и Black Duck, которая пытается убрать этот шум. Заявленная цель узкая, но полезная: автоматически определять Docker Hardened Images во время сканирования Black Duck, импортировать предоставленные Docker VEX statements и подавлять уязвимости base image, которые Docker помечает как “not_affected”.
Это важно, потому что vulnerability management часто ломается на стыке ответственности infrastructure и application. Developers получают alerts по packages, которые они не выбирали. Security teams тратят время, доказывая, что найденная CVE не применима. Auditors всё равно хотят видеть понятную запись: почему что-то было принято, проигнорировано или исправлено.
Docker и Black Duck позиционируют эту интеграцию как способ сделать такое разделение явным. Findings в base layer можно оценивать с учётом Docker exploitability statements. Findings в application layer по-прежнему остаются ответственностью customer.
Что, по словам Docker и Black Duck, делает интеграция#
По данным Docker, Black Duck может автоматически определять Docker Hardened Images во время сканирования без ручной разметки tags. После распознавания DHI base image Black Duck может использовать Docker VEX data вместе с Black Duck Security Advisories, чтобы решить, какие findings следует считать actionable.
VEX означает Vulnerability Exploitability eXchange. На практике это позволяет supplier указать, затрагивает ли известная vulnerability конкретный product или artifact. Ключевой status в описании Docker — “not_affected”. Если Docker утверждает, что vulnerability в hardened base image не affected из-за процесса сборки или hardening image, Black Duck может использовать это statement, чтобы suppress или ignore alert согласно policy.
В посте также сказано, что Black Duck объединяет Docker VEX data со своей advisory intelligence. Docker описывает Black Duck Security Advisories как источник exploitability context и remediation guidance, иногда ещё до обновления записей в National Vulnerability Database. Это vendor claim, но направление понятно: интеграция не просто читает package manifests и сопоставляет CVE. Она пытается привязать findings к exploitability и ownership.
Операционное обещание простое:
- автоматически определять DHI base images;
- отличать findings hardened base layer от findings customer application layer;
- использовать Docker VEX statements для suppress alerts по base image со статусом “not affected”;
- оставлять application-layer vulnerabilities видимыми для обычного policy enforcement;
- поддерживать SBOM, audit и compliance workflows за счёт более понятного vulnerability status.
Это не значит, что vulnerabilities исчезают. Это значит, что scanner получает больше контекста, чтобы решить, какие из них действительно требуют действий.
Почему binary analysis — часть этой истории#
В посте Docker сказано, что интеграция DHI использует Black Duck Binary Analysis, или BDBA, для проверки compiled assets внутри containers. Идея в том, что binary matching может определять components по fingerprint, даже когда package metadata отсутствует, удалена или изменена.
Это важно для hardened images. Minimal и hardened containers часто удаляют или меняют metadata, чтобы уменьшить attack surface или размер image. Traditional scanners, которые сильно зависят от package manager databases, в таких случаях могут терять видимость или выдавать менее точные matches. Binary analysis должен проверять, что реально присутствует в shipped container, а не только то, что, согласно manifest, должно там быть.
Есть одна деталь исходника, с которой стоит быть аккуратнее. В посте Docker сказано, что основная BDBA integration для DHI была выпущена 14 апреля 2026 года. В более позднем разделе говорится, что BDBA “launching March 31st”. Исходный материал не объясняет расхождение этих дат. Безопасное прочтение такое: Docker описывает недавно выпущенную или поэтапно запускаемую поддержку BDBA, но точный milestone timing из собранного текста не до конца ясен.
Docker также сообщает, что Black Duck планирует расширить поддержку DHI identification и verification на свою Software Composition Analysis platform. Эта часть описана как upcoming. Если её реализуют, она свяжет DHI intelligence с source-side dependency management и даст более широкий SBOM view по всему software development lifecycle.
Пока читателям стоит отделять то, что заявлено как доступное, от roadmap. Automatic DHI identification и VEX-based handling — непосредственный фокус поста. Более широкая унификация SCA представлена как будущая поддержка.
Практическая ценность: более чистые границы triage#
Самая полезная часть интеграции — не в брендинге, а в границе triage.
У container image есть слои. Base image обычно сопровождает supplier или platform team. Application layers чаще всего принадлежат product team. Когда scanner сводит эти слои в один список, ответственность размывается. Developer может получить задачу исправить CVE в hardened base image, который он не контролирует. Security team тратит время на исключения по findings, которые поставщик base image уже пометил как not affected.
Предлагаемый Docker workflow снижает это трение. Если уязвимость относится к DHI base image и есть Docker VEX statement со статусом not affected, Black Duck может по policy подавить такой finding. Если уязвимость найдена в custom application layer и превышает risk threshold, Black Duck может запускать рабочие действия, например Jira tickets или email alerts.
Bottom line#
Интеграция Docker и Black Duck — практичная попытка уменьшить CVE noise в контейнерной безопасности.
Если всё работает так, как описано, команды получают более честный процесс: меньше общих alerts, более чёткое ownership между base и application слоями и лучшее обоснование, почему finding требует действия или нет.