Q:

How can I mark a CA [SuppressMessage] as "blessed"?

Try as I might to keep [SuppressMessage]s to a minimum in the codebase, new ones continue to get introduced.  I would like some way to say in the code "I've reviewed this [SuppressMessage] and it is 'acceptable'".
One thought was to create my own My.CodeAnalysis.SuppressMessageAttribute class which inherits from System.Diagnostics.CodeAnalysis.SuppressMessageAttribute, but that class is sealed.
I'm sure I could cobble together something with a comment near the attribute and a post-processing step, but I'd like to stick to what is available "in the box" with Visual Studio 2010.

A:

Even if the attribute weren't sealed, a subclassing approach would not work since the code analysis engine screens for exact SuppressMessageAttribute instances.  As current versions are written, the engine would completely ignore subclass instances.
Personally, I use the following approach for management of suppressions:

All "permanent" suppressions must
have a Justification property that
explains the reason for the
suppression.
Where possible, permanent
suppressions must be placed in the
target code file.  Otherwise, they
must be placed at the top of the
GlobalSuppressions file.
Temporary suppressions must all be
placed below a "Temporary
suppressions" header comment in the
GlobalSuppressions file, and they
should not be assigned a
justification.
All permanent suppressions are
subject to code review, in exactly
the same manner as the code itself. 
I use difference detection to flag
code for review, so I can see which
suppressions have been added or
changed just as easily as I can see
which code has been modified.
Temporary suppressions must all be removed by a pre-defined phase of the project.  After this point has passed, a rule that detects missing Justification properties is enabled.

If this sort of thing wouldn't work for you, another approach would be to use stand-alone FxCop to annotate your suppressed violations.  Unfortunately, these annotations would reside outside your code base, but maybe that would suit you better if you want to prevent developers from "blessing" their own suppressions.

