www.hakin9.org

hakin9 Nr 12/2007

52

Obrona

Z

apewnienie odpowiedniej jakości kodu,
czy to przy pomocy różnych metodologii
(np. Extreme Programming), okresowego

sprawdzania i analizy kodu (code reviews), czy
też kombinacji różnych podejść, jest procesem
kosztownym i długotrwałym. Jego automatyza-
cja i wplecenie w cykl życia aplikacji, pomimo
iż nie wyeliminuje do końca ingerencji człowie-
ka – a także samych błędów – zdecydowanie
usprawnia proces i zwiększa efektywność pra-
cy całego zespołu. Tu przychodzą nam z pomo-
cą narzędzia do statycznej analizy kodu, a wśród
nich aplikacja FxCop.

FxCop jest narzędziem do analizy kodu,

które sprawdza zgodność elementów kodu za-
rządzanego .NET z wytycznymi projektowymi
dla platformy .NET (Microsoft .NET Framework
Design Guidelines). Narzędzie wykorzystuje me-
chanizm refleksji, parsowanie MSIL oraz analizę
grafu wywołań do sprawdzenia elementów pod
kątem występowania ponad 200 często spotyka-
nych wad w następujących obszarach:

• projekt bibliotek,
• lokalizacja,
• konwencje nazewnictwa,
• wydajność,
• bezpieczeństwo.

FxCop dysponuje graficznym interfejsem użyt-
kownika, ale jest też narzędziem dostępnym
z wiersza polecenia. Zawiera także pakiet
SDK umożliwiający tworzenie niestandardowych
reguł.

Jakość tworzonego kodu

Kiedy mówimy o tworzeniu bezpiecznego opro-
gramowania, musimy zacząć od samych pod-
staw, czyli od jakości tego, co napisaliśmy. Ma
ona fundamentalne znaczenie w przypadku, gdy
nasza aplikacja jest kluczowa dla firmy. Spraw-
dzeniem jakości naszego kodu zajmuje się spe-
cjalna dziedzina inżynierii oprogramowania, nie-
mniej jednak jako programiści sami jesteśmy

FxCop – analiza kodu

w .NET

Artur Żarski

stopień trudności

Tworzenie oprogramowania jest bardzo złożonym procesem,

bardzo trudno jest napisać aplikację, która będzie pozbawiona

błędów, a co za tym idzie – bezpieczna. Ogromny nacisk

kładziony jest więc na to, aby oprogramowanie zawierało tych

błędów jak najmniej.

Z artykułu dowiesz się

• jak działa i czym jest narzędzie FxCop,
• czym jest analiza kodu.

Co powinieneś wiedzieć

• należy znać zagadnienia związane z programo-

waniem przy użyciu platformy .NET ,

• wiedzieć, jak poruszać się w środowisku Visual

Studio.

FxCop – analiza kodu w .NET

hakin9 Nr 12/2007

www.hakin9.org

53

w stanie określać reguły, którym pod-
lega tworzony kod aplikacji. Do tego
celu możemy wykorzystać mecha-
nizm statycznej analizy kodu. Okre-
ślenie statyczna analiza kodu to
specjalny etap kompilacji naszego
programu, w trakcie którego przy
pomocy odpowiednich reguł spraw-
dzane jest to, co napisaliśmy. Regu-
ły te opisują, co jest prawidłowe i jak
powinien wyglądać nasz kod źródło-
wy, aby był poprawny i bezpieczny
z naszego punktu widzenia.

FxCop w działaniu

No dobrze, jeśli już dowiedzieliśmy
się czegoś na temat jakości kodu
oraz jego statycznej analizy, to nie
pozostaje nam nic innego jak tylko
napisanie czegoś co pozwoli ana-
lizować i sprawdzać nasz kod. Jest
to wykonalne, ale bardzo skompliko-
wane do oprogramowania. Dlaczego
jest to takie trudne? Ponieważ bar-
dzo często zdarza się, że ten sam
problem może być opisany w różny
sposób. Z pomocą przychodzą nam
kody operacji języka pośredniego
(Intermediate Language). Ich zapis
po stronie systemu operacyjnego,
po kompilacji, jest bardziej przewi-
dywalny i bardziej jednoznaczny niż
sam kod źródłowy, nawet przy uży-
ciu różnych języków programowania
dostępnych w platformie .NET.

W taki właśnie sposób – przy

pomocy analizy kodu pośredniego
– działa narzędzie pod nazwą FxCop.

Reguły w FxCop

Jak już wcześniej wspominaliśmy,
analiza składni polega na sprawdze-
niu kodu według wcześniej określo-
nych reguł. Dokładnie ta sama zasa-

da działania dotyczy FxCop. Narzę-
dzie to zawiera standardowo wbudo-
wane pewne reguły określające, jak
powinien wyglądać nasz kod. Regu-
ły te są umieszczone w kilku grupach

Tabela 1.

Grupy reguł dla FxCop

Grupa

Zakres analizy

Design

Poprawność architektury bibliotek pod kątem zgodności z zasadami nakre-
ślonymi w dokumencie Design Guidelines for Class Library Developers

Globalization

Globalizacja, czyli gotowość aplikacji do lokalizacji

Interoperability

Współpraca z kodem niezarządzanym (głównie COM)

Maintainability

Konserwacja kodu

Naming

Zgodność z konwencjami nazewniczymi opisanymi w dokumencie Design
Guidelines for Class Library Developers

Performance

Wydajność kodu

Reliability

Niezawodność aplikacji oraz odporność na problemy, np. związane z ilością
użytej pamięci

Security

Bezpieczeństwo

Usage

Poprawne użycie .Net Framework

Listing 1.

Definicja reguły w pliku XML

<

Rules

>

<

Rule TypeName=

"RegulaPusteNazwy"

Category=

" Naming"

CheckId=

"Reg5000"

>

<

Name

>

Reguła używana, kiedy pojawiają się puste nazwy

<

/Name

>

<

Description

>

Tutaj nasz opis

<

/Description

>

<

Url

>

Link do opisu

<

/Url

>

<

Resolution

>

Sposób rozwiązania

<

/Resolution

>

<

Email

>

email do osoby odpowiedzialnej

<

/Email

>

<

MessageLevel Certainty=

"95"

>

Error

<

/MessageLevel

>

<

FixCategories

>

Breaking

<

/FixCategories

>

<

Owner

>

Informacje o właścicielu reguły

<

/Owner

>

<

/Rule

>

<

/Rules

>

Rysunek 1.

Okno Code Analysis w VisualStudio

Źródło: http://msdn2.microsoft.com/en-us/library/ee1hzekz(VS.80).aspx

hakin9 Nr 12/2007

www.hakin9.org

Obrona

54

funkcjonalnych. Tabela 1. zawiera
zestawienie grup wraz ze specyfika-
cją, jakiemu zakresowi analizy pod-
legają umieszczone reguły.

Sama reguła jest tylko jednym

z elementów całej analizy. Istotną
sprawą jest stwierdzenie, czy to
co dana reguła wykryje, jest waż-
ne, czy nie i jak to zdarzenie zakla-
syfikować. W związku z tym musi-
my określić jeszcze dwa parametry.
Są nimi poziom istotności oraz pew-
ność. Występują trzy główne czynni-
ki determinujące poziom istotności:

• widzialność znalezionego pro-

blemu,

• prawdopodobieństwo tego, czy

wykryty problem będzie miał ne-
gatywny skutek na całość apli-
kacji i jej zachowania,

• ryzyko powiązane z nie napra-

wieniem problemu.

Dodatkowo każda reguła musi cecho-
wać się jednym z pięciu poziomów
istotności. Poziomy te przedstawiają
się następująco:

• Critical Error (Błąd krytyczny) /

Error (Błąd) – wiadomości, któ-
rym nadano ten poziom, dotyczą
problemów, które mogą zagrozić
stabilności kodu,

• Critical Warning (Ostrzeżenie kry-

tyczne) / Warning (Ostrzeżenie)
– w tej grupie problemy zwykle
nie dotyczą stabilności aplikacji.
Niemniej jednak powinny zostać
dokładnie przeanalizowane pod
kątem optymalności kodu,

• Informational (Informacja) – sto-

sowany do wiadomości, które
dostarczają jedynie informacji
o przedmiocie analizy, nie iden-
tyfikują zaś potencjalnych proble-
mów z nim związanych.

Współczynnik pewności określa praw-
dopodobieństwo, z jakim problem zo-
stał poprawnie zidentyfikowany. Po-
dobnie, jak poziom istotności, jest to
wartość określana subiektywnie przez
autora reguły, jednak powinna ona za-
leżeć od algorytmu użytego do wykry-
cia problemu oraz cech specyficznych
dla problemu, które nie mogą zostać

zweryfikowane na podstawie staty-
cznej analizy. Współczynnik pew-
ności określany jest w procentach
(0-99%). Im wyższa wartość, tym
większe prawdopodobieństwo, że
dana reguła poprawnie identyfiku-
je problem.

Własne reguły

Bardzo dobrze, jeśli proces spraw-
dzania naszego oprogramowania jest
w pełni opisany dostarczonymi regu-
łami. Zdarzają się jednak sytuacje,
kiedy standardowe opcje nam nie wy-
starczają. W takim przypadku mamy
możliwość dopisania własnej reguły
i podpięcia jej do istniejącego zesta-
wu. Jak się do tego zabrać? W tym
celu pomocne są dwie biblioteki:
FxCopSdk.dll oraz Microsoft.Cci.dll.

Proces tworzenia nowej reguły

składa się z dwóch etapów. Pierw-
szy z nich to stworzenie definicji
reguły – określonej w pliku XML
– oraz napisanie kodu, który będzie
realizował sprawdzenie danej reguły.

Plik XML powinien wyglądać tak,

jak na Listingu 1. i powinien zawierać

informację o rodzaju reguły, jej naz-
wie, identyfikatorze oraz poziomie
pewności.

W drugim kroku tworzymy biblio-

tekę, do której dodajemy następują-
ce referencje:

using Microsoft.Cci;
using Microsoft.FxCop.Sdk;
using Microsoft.FxCop.Sdk.Introspect

ion;

oraz tworzymy klasę o nazwie takiej
jak nazwa reguły:

public class RegulaPusteNazwy :
BaseIntrospectionRule

Następnie musimy zaimplementować
obsługę sprawdzania danej reguły, nad-
pisując w tym celu metodę Check. Jej
parametrem może być moduł, para-
metr, zasób, etc. Pełna lista możliwych
parametrów znajduje się w Ramce.

Ostatnim krokiem jest kompilacja

biblioteki i umieszczenie jej w katalo-
gu z innymi regułami (FxCop\Rules),
a także przetestowanie jej.

Pełna lista możliwych parametrów

public virtual ProblemCollection Check(Member member);
public virtual ProblemCollection Check(Module module);
public virtual ProblemCollection Check(Parameter parameter);
public virtual ProblemCollection Check(Resource resource);
public virtual ProblemCollection Check(TypeNode type);
public virtual ProblemCollection Check(string namespaceName,
TypeNodeList types);

Rysunek 2.

Lista Ostrzezeń po analizie kodu

FxCop – analiza kodu w .NET

hakin9 Nr 12/2007

www.hakin9.org

55

FxCop w praktyce

Wiemy już, czym jest FxCop i jakie jest jego zastosowa-
nie. Zobaczmy teraz, w jaki sposób możemy praktycznie
wykorzystać to narzędzie i jak się do tego zabrać. Poniżej
chciałbym przedstawić sposób wykonania statycznej ana-
lizy kodu przy użyciu Visual Studio.

Aby rozpocząć pracę z FxCop i statyczną analizą

kodu, należy uruchomić właściwości projektu w Visual
Studio, a następnie z lewego menu wybrać opcję Co-
de Analysis. Otrzymamy okno takie, jak na Rysun-
ku 1. Następnie w tym oknie wybieramy opcję Enable
Code Analysis, która spowoduje włączenie analizy kodu.
W tym momencie możemy jeszcze raz wykonać zbudo-
wanie naszej aplikacji.

W trakcie kompilacji będziemy dostawać ostrzeżenia

(o ile się takie pojawią) dotyczące jakości utworzonego
kodu. Przykład takiej listy ostrzeżeń przedstawiony jest
na Rysunku 2. Jeśli przyjrzymy się temu obrazkowi, bę-
dziemy mogli dostrzec błędy o numerach zaczynających
się od liter CA – jak Code Analysis. W drugiej kolum-
nie zobaczyć można kolejną bardzo ważną informację,
mówiącą o kategorii, do której należy dana reguła, np.
Microsoft.Usage.

Dla przykładu linia 4 zawiera następujące informacje:
CA2210 : Microsoft.Design : Sign FxCop-Sample with

a strong name key.

Oznacza to, że nasz projekt nie jest podpisany, a co

za tym idzie – klient może mieć problem z instalacją lub
uruchomieniem wynikowej aplikacji, ponieważ system nie
będzie wiedział, czy można zaufać bibliotekom wcho-
dzącym w skład programu (lub samemu programowi).

Oczywiście nie ma potrzeby wykorzystania wszyst-

kich reguł. Jeśli celowo chcemy pominąć jakąś grupę re-
guł lub konkretny numer błędu (bo tego wymaga nasza
aplikacja), to w oknie, w którym uruchamialiśmy anali-
zę kodu, możemy wybierać interesujące nas reguły. Na
Rysunku 3. przedstawiony jest przykład wyłączenia ze
sprawdzania reguły mówiącej o tym, że nasza bibliote-
ka powinna mieć zadeklarowany minimalny stopień bez-
pieczeństwa.

Jeśli teraz ponownie przekompilujemy nasz projekt, to

zobaczymy, że ostrzeżenie o błędzie CA2209 nie będzie

Rysunek 3.

Wyłączenie jednej z reguł

hakin9 Nr 12/2007

www.hakin9.org

Obrona

56

już widoczne – pokazuje to Rysu-
nek 4. Oczywiście nie musimy się
ograniczać do włączania lub wyłą-
czania pojedynczych reguł. Mamy
również możliwość wyłączenia ze
sprawdzania całej ich grupy, tak jak
widać na Rysunku 5.

Jeśli dobrze zwrócimy uwagę

na opcję konfiguracji analizy kodu,
łatwo dostrzeżemy, że możliwe jest
przygotowanie takich ustawień, które
będą odpowiednie dla różnych konfi-
guracji. Co innego może być spraw-
dzane dla konfiguracji Debug, a co
innego dla konfiguracji Release.

Od czasu do czasu zdarza się,

że z jakiś powodów nie chcemy
pozwolić na kompilację programu,
jeśli pojawią się ostrzeżenia z anali-
zy kodu. W takiej sytuacji warto za-
mienić ostrzeżenie w błąd. Dzię-
ki temu, jeśli napotkamy na ta-
ki problem, to nie będziemy mogli
przejść nad nim do porządku dzien-
nego, tylko będziemy zmuszeni do
jego poprawy. Jak to wykonać?
Nic prostszego. Na liście z reguła-
mi po prawej stronie mamy wykrzyk-
nik symbolizujący ostrzeżenie. Jeśli
teraz klikniemy w niego i zmienimy
ostrzeżenie na błąd, to w momencie
napotkania na opisany regułą pro-
blem otrzymamy błąd. Taką sytuację
przedstawia Rysunek 6. Po kom-
pilacji przypadek spełnienia reguły
CA2100 będzie wykryty jako błąd, co
spowoduje, że będziemy musieli tak
poprawić składnię SQLa, aby nie ak-
ceptowała dowolnie wpisanego cią-
gu znaków. Pozwoli nam to na napi-
sanie bezpieczniejszej aplikacji.

Podsumowanie

Mamy do dyspozycji coraz więcej
narzędzi wspomagających tworze-
nie bezpieczniejszych aplikacji. Jed-
nym z nich jest FxCop. Narzędzie to
jest bardzo potężne i to nie tylko dzię-
ki wbudowaniu w nie standardowo

około dwustu reguł, ale również dla-
tego, że pozwala na rozbudowę tego
zestawu. Jeśli nasza firma korzysta
z własnych reguł poprawności ko-
du, to mamy możliwość dopisania ich
do już istniejących. Gdybyśmy chcie-
li dodać własny algorytm analizy,
także mamy taką możliwość. Pole-
cam zapoznać się z tym narzędziem,
a tworzenie bezpieczniejszych aplika-
cji stanie się łatwiejsze. l

Rysunek 5.

Wyłączenie ze sprawdzania całej grupy

Rysunek 6.

Zamiana ostrzeżenia na błąd

Rysunek 4.

Wynik kompilacji po wyłączeniu reguły

O autorze

Autor jest pracownikiem firmy Micro-
soft. Na co dzień zajmuje się m. in. two-
rzeniem rozwiązań w oparciu o SQL
Server w różnych aspektach – bazy
relacyjne, usługi integracyjne, usługi
analityczne. Jest certyfikowanym admi-
nistratorem baz danych (MCDBA).
Kontakt z autorem:
[e-mail]