Здравствуйте, Ночной Смотрящий, Вы писали:

EP>>Для того чтобы знать что конкретно требуется тщательно проверять и не разрешать лишнего — нужен fine-grained контроль за отдельными функциями
НС>CLR это позволяет. На сборки навешивается только общая политика, так что не программистом задается, а администратором. А разметка кода вполне опускается до уровня конкретных методов.

Какие keyword'ы поискать по теме?

НС>>>Я ж говорю, изобретаешь CLR.
EP>>Ок, как определить используется ли в вызываемом методе операции, которые могут привести к переполнению целых?
НС>Есть соотвествующие метки контекста.

Метки кто расставляет?

EP>> Или, например, возможен ли вылет исключения?
НС>Тут все совсем просто — вылет исключения возможен всегда. Только какое это имеет отношение к безопасности? CLR не С++, неперехваченное исключение память не портит.

С исключениями как раз в C#/Java проблем больше, using'и/try-with-resources это полумера, с транзитивностью распространения is-a-resource никак не помогает. Тема уже не раз обсуждалась.
Но суть в другом — если код не готов к исключению, то оно может поломать инварианты, грубо говоря прервать транзакцию на пол пути. Обвешивать избыточными try/using'ами — тоже не всегда оправданно. Более того, откатить "транзакцию" до приемлемого состояния даже не всегда возможно. Поэтому иногда приходится требовать чтобы некоторые операции не кидали исключений.
Опять таки, в Haskell'е есть монада Exceptional: не заметить что вызываемый код может "выкинуть" исключение — никак нельзя. И это форсится языком — у функции которая "кидает" исключение просто другая сигнатура, и использовать таким же образом как обычную уже не получится.
А к безопасности это имеет самое прямое отношение — большинство проблем с безопасностью происходят от нарушения предусловий/инвариантов, пусть и не всегда явных.