Есть код:

public static class MyBox
{
    public static void StopDlg(string msg)
    {
        MessageBox.Show(ForegroundWindow,
            msg,
            "Уведомление...",
            MessageBoxButtons.OK,
            MessageBoxIcon.Stop
            );
    }

    private static Control ForegroundWindow
    {
        get
        {
            return Control.FromHandle(System.Diagnostics.Process.GetCurrentProcess().MainWindowHandle);
        }
    }
}

После проверки (Run Code Analysis в 10-й студии) получаем ругательство:

CA2122 : Microsoft.Security : 'MyBox.ForegroundWindow.get()' calls into 'Process.MainWindowHandle.get()' which has a LinkDemand.
By making this call, 'Process.MainWindowHandle.get()' is indirectly exposed to user code.
Review the following call stack that might expose a way to circumvent security protection:
->'MyBox.ForegroundWindow.get()'
->'MyBox.ForegroundWindow.get()'
->'MyBox.StopDlg(string)'

Поясните плиз, в чём дыра в безопасности? Свойство ForegroundWindow приватное, его никто посторонний вызвать не может (кроме как через рефлексию). Класс статический, наследников быть не может.
И почему оно в стеке показало вызов свойства два раза? Как такое может быть?

Здравствуйте, Кондраций, Вы писали:

К>Поясните плиз, в чём дыра в безопасности?

Почему сразу дыра? Так, недостаток просто. <termNazi>И не в безопасности, а в защищенности </termNazi>

Класс System.Diagnostics.Process помечен атрибутом PermissionSet(SecurityAction.LinkDemand, Name="FullTrust"). Это означает, что при вызове любого его метода будет осуществляться проверка того, что _непосредственный_ вызывающий метод (в твоем случае — это MyBox.ForegroundWindow.get() имеет неограниченные разрешения. Посольку для самого MyBox.ForegroundWindow.get() PermissionSet не определен, это создает ситуацию, при которой появляется возможность косвенного вызова метода MainWindowHandle в обход установленной политики. Более подробно: http://msdn.microsoft.com/ru-ru/library/ms182303.aspx

К>Свойство ForegroundWindow приватное, его никто посторонний вызвать не может (кроме как через рефлексию). Класс статический, наследников быть не может.

А это не имеет значения. Весь набор правил защищенности FxCop построен таким образом, чтобы указывать на недостатки (потенциальные места возникновения уязвимостей), а не на уязвимости. Первоначальные условия для нарушения CAS созданы -> Недостаток -> Сообщение от FxCop.

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Почему сразу дыра? Так, недостаток просто. <termNazi>И не в безопасности, а в защищенности </termNazi>

нужно ли устранять подобные "недостатки", или вообще обращать на них внимание?

Здравствуйте, Философ, Вы писали:

Ф>Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>Почему сразу дыра? Так, недостаток просто. <termNazi>И не в безопасности, а в защищенности </termNazi>

Ф>нужно ли устранять подобные "недостатки", или вообще обращать на них внимание?
Я так понял, что смотря по ситуации. В моём случай защищаемая информация (handle окна) не выходит наружу моего кода — значит всё нормально и игнорировать.

Здравствуйте, Философ, Вы писали:
Ф>Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>Почему сразу дыра? Так, недостаток просто. <termNazi>И не в безопасности, а в защищенности </termNazi>
Ф>нужно ли устранять подобные "недостатки", или вообще обращать на них внимание?

Обращать внимание — обязательно. Устранять — по ситуации. Пока недостаток не встретится с угрозой, он не станет уязвимостью. В данном примере угрозы нет, но устранение недостатка займет столько же строчек кода, сколько подавление варнинга от FxCop (при условии, что весь код рассчитан на работу с полными привилегиями). Так почему бы не устранить и забыть о нем?