Как стать автором
Обновить

Комментарии 4

А вам не приходила идея использовать Profiling API и на живом процессе собрать реальные данные попадающие в функции/методы, и смешав с data-flow анализом узнать куда могут попадать «зараженные данные». Да и вообще с реальными данными можно получить более качественный анализ и подсказки и утереть нос реактивным могзам *wink*.

Нет, в эту сторону не смотрели.
Можете немного подробнее раскрыть Вашу идею?


Имеете в виду собрать какую-то статистику, на основе которой расширить taint анализ (источники и sink'и) или динамически это мониторить и в динамике же отслеживать (тут уже динамический анализ получается)?

НЛО прилетело и опубликовало эту надпись здесь
Это конечно можно код ревью решить, но лучше делегировать анализатору, чтобы не тратить усилия ревьюеров там где это легко автоматизируется.

Очень хороший поинт. :)


Хорошим подспорьем может быть правило запретить прямое использование SqlCommand и ко. везде, кроме прямо указанных проектах. Т.е. если мы используем db layer проект, мы отслеживаем что никто потихоньку не вкорячит побыстренькому, типа потом поменяю.
Это кстати касается не только операций работы с базой, но и вообще чего угодно.

Если хочется запретить / отслеживать использование определённого API — почему бы и нет? Если говорить про C# — тот же Roslyn вполне предоставляет для этого все средства. Опустим BuildTools уровень (парсинг проектов), с этим отдельная история… Хотя сейчас у них стало вроде получше с этим.


Если же говорить про сам анализ — кажется, при желании вполне себе можно сделать самостоятельно.


На всякий случай упомяну здесь свою статью про Roslyn — вдруг кому пригодится во время экспериментов. :) Она старенькая, но основные концепции всё те же.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.