EJBCA PKI

кто работал со сканерами уязвимостей контейнеров типа trivy/anchore/clair,
как боретесь с false positive? сканы контейнеров с dotnet, которые от microsoft, дают очень много багов, связанных с библиотеками libc, утилитами tar, ssh. Но такие баги не влияют на безопасность контейнеров...

есть идеи, может кто победил?

а почему не влияют на ваш взгляд?
потому что уязвимость libc \ tar  можно  эксплуатировать _только_ через docker exec ?

не влияют с точки зрения целевой архитектуры, когда контейнер находится в оркестраторе и доступа к командной строке внутри контейнера нет.

как можно эксплуатировать tar, если крутится dotnet dll, и торчит один порт наружу?..

то есть по вашему нельзя в .Net Core приложении спровоцировать syscall EXEC через обработку какого нибудь хитрожопого PNG? ;)

ладно насчет false positive
в голову приходит только делать multistage контейнер
и вычищать все ненужное через COPY —from=dirty_stage
но я не знаю как современные сканеры к multistage относятся

то есть по вашему нельзя в .Net Core приложении спровоцировать syscall EXEC через обработку какого нибудь хитрожопого PNG

syscall из dotnet может быть вызван только из самого dotnet методом фаззинга (и то, не факт).
системные тулзы типа ssh или tar не вызываются. (хотя, совсем плохенькие джуны могут сделать, как это делается в python)

поэтому и встал вопрос, как избежать сработок...

multistage уже есть. то есть собрали, выкинули, закинули в отдельный контейнер для runtime. и вот в runtime уже есть сработки связанные с кучей дополнительных вещей (те же ssh, libjpg, tar)

погодите, а зачем вообще tar ssh в runtime образе?

спроси microsoft)

они делают свои сборки на debian

ну значит надо через COPY —from=runtime вытаскивать  .Net Core Runtime и связанных с ним библиотек, а все остальное нафиг

надо будет попробовать
спасибо за совет)

ну просто сканеры штука такая
есть уязвимая версия либы -> репорт
и в целом да, надо понять, какого фига

у меня просто  golang
и там весь продуктив
FROM stratch
COPY —from=builder ...

можно уйти в alpine-based (сложно в случае дотнета) или в distroless (не пробовал).
стоковый дебиан почти все сканеры раздражает.

вот пример distroless для dotnet: https://github.com/GoogleContainerTools/distroless/blob/master/examples/dotnet/Dockerfile

ребят Dockle и Trivy, дополняют как то друг друга? Или у них функционал и возможности одинаковые в целом и можно одной тулой обойтись

Мне в свое время понравился такой набор (Lynis) + (DockerBenchSecurity) + (Hadolint) + (Dockle) + (Trivy или Anchore). Dockle больше про безопасность образа, а не поиск проблем в зависимостях.

Коллеги девсекопсы, здравствуйте!
Вопрос уже обсуждал соседнем чате, хочу поинтересоваться, был ли у кого нибудь опыт проведения docker контейнеризации по требованиям 17-го приказа ФСТЭК по базовым мерам защиты ЗСВ?

Конкретно интересует ЗСВ.4 "Управление (фильтрация, маршрутизация, контроль соединения, однонаправленная передача) потоками информации между компонентами виртуальной инфраструктуры, а также по периметру виртуальной инфраструктуры", что можете посоветовать?)

А это разве не стандартная сетевая фильтрация?

Так то да, но:
- обеспечение доверенных канала, маршрута внутри виртуальной инфраструктуры между администратором, пользователем и средствами защиты информации (функциями безопасности);

- обеспечение подлинности сетевых соединений (сеансов взаимодействия) внутри виртуальной инфраструктуры, в том числе для защиты от подмены сетевых устройств и сервисов;

- обеспечение изоляции потоков данных, передаваемых и обрабатываемых компонентами виртуальной инфраструктуры (гипервизором, хостовой операционной системой) и сетевых потоков виртуальной вычислительной сети;

Для сего в государстве российском нужен сертификат...

Коллеги, подскажите пожалуйста, может кто сталкивался, начальство хочет нарисовать Threat model, в чем это лучше всего делать?