Комментарии 4
А вам не приходила идея использовать Profiling API и на живом процессе собрать реальные данные попадающие в функции/методы, и смешав с data-flow анализом узнать куда могут попадать «зараженные данные». Да и вообще с реальными данными можно получить более качественный анализ и подсказки и утереть нос реактивным могзам *wink*.
НЛО прилетело и опубликовало эту надпись здесь
Это конечно можно код ревью решить, но лучше делегировать анализатору, чтобы не тратить усилия ревьюеров там где это легко автоматизируется.
Очень хороший поинт. :)
Хорошим подспорьем может быть правило запретить прямое использование SqlCommand и ко. везде, кроме прямо указанных проектах. Т.е. если мы используем db layer проект, мы отслеживаем что никто потихоньку не вкорячит побыстренькому, типа потом поменяю.
Это кстати касается не только операций работы с базой, но и вообще чего угодно.
Если хочется запретить / отслеживать использование определённого API — почему бы и нет? Если говорить про C# — тот же Roslyn вполне предоставляет для этого все средства. Опустим BuildTools уровень (парсинг проектов), с этим отдельная история… Хотя сейчас у них стало вроде получше с этим.
Если же говорить про сам анализ — кажется, при желании вполне себе можно сделать самостоятельно.
На всякий случай упомяну здесь свою статью про Roslyn — вдруг кому пригодится во время экспериментов. :) Она старенькая, но основные концепции всё те же.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
OWASP, уязвимости и taint анализ в PVS-Studio C#. Смешать, но не взбалтывать