Pull to refresh

Comments 4

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

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


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

UFO just landed and posted this here
Это конечно можно код ревью решить, но лучше делегировать анализатору, чтобы не тратить усилия ревьюеров там где это легко автоматизируется.

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


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

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


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


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

Sign up to leave a comment.