View as presentation
→ Slide 1

Analiza kodu

→ Slide 2

Statyczna analiza kodu

  • Analiza statyczna kodu - analiza struktury kodu źródłowego lub kodu skompilowanego bez jego uruchomienia
  • może być wdrożona w potok ciągłej integracji, automatyczna weryfikacja jakości kodu
  • nie jest w stanie wyeliminować „ręcznej” inspekcji kodu („code review”)
  • kompilatory głownie analizują skłądnię ale również posiadają bogate funkcji analizy kodu
  • analiza w czasie pisania kodu, quick fix - schematy naprawy typowych wad kodu
↓ Slide 3

Czego dotyczy analiza statyczna

  • analiza poprawności składni
  • bezpieczeństwo: np. brak obsługi specyficznych danych wejściowych, detekcja backdoors, niebezpieczne i nieaktualne funkcje, wycieki pamięci, przepełnienie bufora, używanie niezainicjowanych zmiennych, SQL Injections, …
  • jakość i styl kodu: zgodność z dobrymi praktykami, zachowanie jednolitej konwencji nazewniczej w projekcie/organizacji, detekcja powtórzeń i nieużywanych fragmentów kodu
  • wydajność: sugestie zmian kodu w celu podniesienia szybkości działania
↓ Slide 4

SDL for Agile

Microsoft Security Development Lifecycle

Practice #10: Perform Static Analysis
Analiza statyczna w każdym sprincie

Źródło: http://www.microsoft.com/security/sdl/discover/sdlagile.aspx

↓ Slide 5

Metody analizy

  • analiza leksykograficzna - wyszukiwanie niebezpiecznych konstrukcji w kodzie źródłowym, zazwyczaj na podstawie zestawu reguł, różnych heurystyk i dopasowania do wzorców błędów
  • metryki kodu źródłowego - ocena jakości kodu źródłowego na podstawie danych statystycznych
  • metody formalne - oparte na matematycznej definicji zachowania programu
↓ Slide 6

Cechy

  • Szybkość działania - szybkie wykrywanie błędów, których naprawa jest prosta i mało kosztowna
    • nie wymagają uruchamiania programu
    • łatwe do zrównoleglenia
  • Łatwość użycia - proste we wdrożeniu w cykl wytwarzania oprogramowania
  • Automatyzacja - integracja z narzędziami continius integrations, serwery automatyzacji, IDE, kontrola wersji
  • Możliwości rozszerzania: własne reguły, wtyczki, …
  • Dużo darmowych narzędzi
↓ Slide 7

Wady

  • Wymagany dostęp do źródeł
  • Reguły wykrywają zazwyczaj proste błędy i nie są w stanie wyeliminować ręcznego sprawdzenia kodu
  • Dużo szumu, zbyt czułe - duże prawdopodobieństwo zaklasyfikowanie poprawnego fragmentu jako błędu (false positive)
  • Każde narzędzie zazwyczaj pokrywa pewien zakres testów. Dlatego warto korzystać z kilku różnych skanerów kodu.
↓ Slide 8

Dlaczego analizować kod?

Koszt naprawy błędu rosną im potniej błąd zostanie wykryty

benefits.jpg

Źródło: http://www.microsoft.com/security/sdl/about/benefits.aspx

  • zwiększenie wydajności i stabilności poprzez zasady oparte na dobrych praktykach,
  • unikniecie typowych błędów podczas programowania,
  • dostarczenie struktury do zarządzania standardami kodu.
  • wymuszenie zasad i standardów pisania kodu
  • zwiększanie bezpieczeństwa poprzez kolejny etap testowania
  • analizując sygnalizowane błędy można się sporo nauczyć na temat dobrych praktyk bezpiecznego programowania
↓ Slide 9

Narzędzia

Lint - UNIX V7 1979, historyczny program od którego nazwy często określa się narzędzia do analizy i szukania błedów

↓ Slide 10

Wielojęzykowe

↓ Slide 11

Ograniczenia

  • Jest wiele typów błędów, które ciężko jest wykryć, np. błędy związane są z konfiguracją lub logiką modelowanego problemu
  • Problemem są zależności, dodatkowe moduły, biblioteki, konteksty dodawane przez frameworki
  • Skomplikowane algorytmy i architektury bardzo ciężko jest analizować
// calculate the number of days
int days = hours / 23;
↓ Slide 12

Więcej informacji

→ Slide 13

Analiza kodu w Visual Studio

↓ Slide 14

Zmiany w kolejnych wersjach

  • VS 2013 - program FxCop
    dedykowane okno z wynikami analizy
  • VS 2015, 2017 - FxCop
    wyniki analizy w oknie Error List
  • VS 2019 - kompilator .NET + pakiety analizatorów
  • Build → Run Code Analysis
    Analyze → Run Code Analysis

VS 2013
VS 2015, 2017, 2019
↓ Slide 15

Analiza VS 2019

  • kompilator .NET Compiler Platform („Roslyn”)
  • dodatkowe analizatory w pakietach NuGet:
  • inne rozszerzenia, np.: Resharper
  • analiza kodu w czasie pisania kodu w edytorze
  • Quick Action - sugestie naprawy kodu
  • czyszczenie kodu
↓ Slide 16

Quick action

  • sugestie naprawy błędu, czasem kilka do wyboru
  • np. naprawa błędów składni (literówki), usuwanie nieużywanych zmiennych, transformacje kodu do innej postaci
  • typowe szybkie akcje naprawy

↓ Slide 17

Poziom defektu

Error (czerwony)
Warning (zielony)
Info (szary)
Hidden
None
Default
↓ Slide 18

Konfiguracja stylu

  • ustawienia edytora tekstu Tools → Options → Text Editor

↓ Slide 19

Plik konfiguracyjny

  • .editorconfig ustawienia analizy stylu w postaci pliku tekstowego
  • obecny w strukturze projektu nadpisuje domyślne ustawienia w zakresie folderu
↓ Slide 20

Czyszczenie kodu

  • automatyczne czyszczenie kodu w całym projekcie
  • tylko defekty, które nie niosą ryzyka uszkodzenia kodu

  • można konfigurować własne profile wybierając reguły, które mają być zaaplikowane

↓ Slide 21

Analizatory w pakietach NuGet

↓ Slide 22

Analizator FxCop

  • analizator C# działa na skompilowanym kodzie
  • ponad 200 defektów: aktualna lista reguł
    • konwencja nazewnicza (Naming)
    • konstrukcje kodu (Designe)
    • użycie, przepływ danych (Usage)
    • lokalizacja (Globalization)
    • wydajność (Performance)
    • czytelność kodu (Reliability)
    • bezpieczeństwo (Security)
    • utrzymanie kodu (Maintainability)
  • przykład: CA1051: Do not declare visible instance fields
↓ Slide 23

Analizator StyleCop

  • analizator kodu C#, działa na kodzie źródłowym
  • aktualna lista reguł
    • zasady robienia wcięć (SpecialRules),
    • poprawianie czytelności kodu (ReadabilityRules),
    • ujednolicanie kolejności elementów kodu (OrderingRules),
    • konwencje nazewnicze (NamingRules),
    • zasady dotyczące dokumentowania kodu (DocumentationRules), …
  • przykład: SA1119 Nadmiarowe nawiasy
int x = (5 + b);
↓ Slide 24

Konfiguracja

  • analizatory są dostępne w zasobach projektu
↓ Slide 25

Konfiguracja poziomu ostrzeżeń

  • zmiana poziomu ważności dla reguł możliwa jest z menu szybkiej akcji oraz z poziomu listy błędów
↓ Slide 26

Zastawy reguł

  • można tworzyć własne zestawy reguł (rule set)
    Solution Explorer → Analyzers → Open Active Rule Set
  • po zapisaniu zmian w projekcie pojawi się plik ruleset z naszymi ustawieniami
↓ Slide 27

Wyłączanie ostrzeżeń

  • ustawienie ważności serverity = None wyłącza ostrzeżenia danego typu
  • Suppress → In Source: w kodzie, w miejscu w którym występuje podatność
    #pragma warning disable CA1234
  • Suppress → In Supression File: w dodatkowym pliku określającym wyłączone reguły dla projektu porpzez atrybut SuppressMessage()

↓ Slide 28

Metryki kodu

  • Statystyki oceniające złożoność kodu oraz skalę trudności jego utrzymania i rozwoju
  • Analyse → Calculate Code Metrics
  • Maintainability Index - utrzymywalność kodu, wartość w zakresie 0-100, uwzględnia złożoność struktury kodu i ilość operacji w stosunku do liczby linii
    20-100 good , 10-19 moderately, 0-9 low

  • Cyclomatic Complexity - złożoność struktury kodu określona ilością różnych ścieżek wykonania. Program z dużą liczbą ścieżek wymaga wielu testów do pokrycia kodu i jest trudniejszy w utrzymaniu
  • Depth of Inheritance - głębokość dziedziczenia. Im wyższa wartość tym większe ryzyko, że zmiana w klasie bazowej uszkodzą działanie klas potomnych.
  • Class Coupling - uwikłanie klas, ilość unikatowych obiektów od których zależy badany fragment kodu (np. wartości zwracane, wywołania funkcji). Duża wartość wskazuje trudności z ponownym wykorzystaniem kodu, jego rozwijaniem oraz utrzymaniem
  • Lines of Source Code ilość linii kodu
  • Lines of Executable code - przybliżona ilość instrukcji wykonywalnych (VS2019)
↓ Slide 29

Więcej informacji