The Power of 10/pl: what changed
Revision 0 to 1. Removed lines have a minus sign; added lines have a plus sign.
Title: The Power of 10/pl
| Old | New | Line | |
|---|---|---|---|
| 1 | + | *Nieskończone pętle lub wycieki pamięci w oprogramowaniu rakiety startowej lub bezzałogowej sondy kosmicznej mogą spowodować utratę misji. Przyjęcie przez sterownik respiratora wartości domyślnej dla braku odczytu pomiaru może doprowadzić do śmierci ciężko chorego pacjenta. Dwa wypadki Boeinga 737 MAX z dużą liczbą ofiar śmiertelnych były wynikiem działania oprogramowania ślepo ufającego wynikom pojedynczego czujnika, który dostarczał nieprawidłowe dane*. | |
| 2 | + | ||
| 3 | + | [[Secure programming/pl|Bezpieczne programowanie]] ma kluczowe znaczenie dla każdego projektu. Dotyczy to zwłaszcza zastosowań w niektórych dziedzinach, takich jak medycyna, wojsko, przemysł i lotnictwo. Z tego powodu Narodowa Agencja Aeronautyki i Przestrzeni Kosmicznej (NASA) zdefiniowała zbiór zasad o nazwie **The Power of 10** (Potęga 10) podsumowujących podstawowe zasady poprawy bezpieczeństwa kodu. | |
| 4 | + | ||
| 5 | + | Język [[Pascal]] wprowadza już pewne podstawowe środki poprawy bezpieczeństwa od podstaw, w tym silne typowanie i zachęcanie do bezpiecznych struktur kontrolnych. Warto jednak pamiętać o kilku dodatkowych zasadach, zwłaszcza na początku nowego projektu. Oczywiście możliwe jest również wdrożenie tych zasad na późniejszych etapach. | |
| 6 | + | ||
| 7 | + | Zasady The Power of 10 (Zasady Potęgi 10) zostały zdefiniowane w 2006 roku przez Gerarda J. Holzmanna w Laboratorium Niezawodnego Oprogramowania JPL\|NASA/JPL. Ich główną intencją jest wyeliminowanie pewnych praktyk kodowania C, które utrudniają przeglądanie lub analizę statyczną kodu. Zasady te zostały włączone do standardów kodowania wielu instytucji. | |
| 8 | + | ||
| 9 | + | ## Zasady | |
| 10 | + | ||
| 11 | + | Dziesięć zasad to: | |
| 12 | + | ||
| 13 | + | 1. Unikaj złożonych konstrukcji przepływu, takich jak [[Goto|goto]], bezpośrednich lub pośrednich, jak [[Recursion|rekurencja (rekursja)]]. | |
| 14 | + | 2. Wszystkie pętle muszą mieć ustaloną górną granicę, aby zapobiec niekontrolowanemu kodowi. | |
| 15 | + | 3. Unikaj alokacji pamięci sterty po inicjalizacji. | |
| 16 | + | 4. Ogranicz wielkość [[Procedure|procedury]], [[Function|funkcji]] i [[Method|metody]] do jednej drukowanej strony. Zazwyczaj oznacza to nie więcej niż około 60 linii kodu na blok. | |
| 17 | + | 5. Użyj co najmniej dwóch asercji w czasie wykonywania na funkcję. | |
| 18 | + | 6. Ogranicz zakres danych do najmniejszego możliwego. Dlatego też, lokalne [[Variable|zmienne]] powinny być preferowane nad zmiennymi globalnymi. | |
| 19 | + | 7. Sprawdź zwracaną wartość wszystkich funkcji lub zwróć [[Nil|nil]] lub [[NaN]], aby wskazać, że zwracana wartość jest bezużyteczna. Dodatkowo każda wywoływana funkcja musi sprawdzać poprawność wszystkich rzeczywistych parametrów dostarczonych przez kod ją wywołujący. | |
| 20 | + | 8. Używaj [[Compiler directive|dyrektyw kompilatora]] lub [[IDE directives|dyrektyw IDE]] oszczędnie. Jeśli to możliwe, powinny być ograniczone do sekcji [[Interface|interface]] w [[Unit|module]]. | |
| 21 | + | 9. Ogranicz użycie [[Pointer|wskaźników]] do pojedynczego pobrania danych i unikaj używania wskaźników do funkcji. | |
| 22 | + | 10. Kompiluj z aktywnymi wszystkimi możliwymi ostrzeżeniami; wszystkie ostrzeżenia należy następnie rozwiązać przed wydaniem oprogramowania. | |
| 23 | + | ||
| 24 | + | ### Unikaj złożonych konstrukcji przepływu, takich jak goto i bezpośrednia lub pośrednia rekurencja | |
| 25 | + | ||
| 26 | + | Chociaż konstrukcja **goto** jest dostępna w Pascalu, nie zaleca się jej używania, ponieważ utrudnia ona odczytanie kodu, a jeszcze trudniej jest przewidzieć jego zachowanie. Podobne rozważania dotyczą **exit**. | |
| 27 | + | ||
| 28 | + | Jeśli to możliwe, należy unikać nawet konstrukcji z rekurencją. W wielu przypadkach pętle **for**, **while** i **repeat**... **until** wykonują tę samą pracę całkiem dobrze. | |
| 29 | + | ||
| 30 | + | ### Wszystkie pętle muszą mieć ustaloną górną granicę, aby zapobiec niekontrolowanej ucieczce kodu | |
| 31 | + | ||
| 32 | + | Ta zasada jest bardzo podobna do pierwszej. Stałe granice pomagają uniknąć używania struktur kontrolnych, takich jak **goto** lub **exit**. | |
| 33 | + | ||
| 34 | + | ### Unikaj alokacji pamięci sterty po inicjalizacji | |
| 35 | + | ||
| 36 | + | Niedopasowane pary alokacji i usuwanie bloków pamięci w stercie są częstym źródłem awarii lub wycieków zasobów. Dodatkowo, ta technika zwykle wymaga użycia wskaźników lub uchwytów i dlatego powinna być unikana w miarę możliwości (patrz reguła \#9). | |
| 37 | + | ||
| 38 | + | ### Ograniczenie procedur, funkcji i metod do pojedynczej drukowanej strony. Zazwyczaj oznacza to nie więcej niż około 60 linii kodu na blok | |
| 39 | + | ||
| 40 | + | Krótsze bloki kodu mają trzy zalety: | |
| 41 | + | ||
| 42 | + | - Łatwiej je zrozumieć. | |
| 43 | + | - Są mniej podatne na przeładowanie. | |
| 44 | + | - W wielu przypadkach skracanie bloków zapobiega duplikowaniu kodu. | |
| 45 | + | ||
| 46 | + | ### Użyj co najmniej dwóch asercji środowiska wykonawczego na funkcję | |
| 47 | + | ||
| 48 | + | Asercje są rodzajem automatycznego pasa bezpieczeństwa dla twojego kodu. To rodzaj testu, który zwraca prawdę lub fałsz w wyniku wykonania bloku kodu programu. Ich efekt jest podobny do przestrzegania zasady \#7. | |
| 49 | + | ||
| 50 | + | ### Ogranicz zakres danych do najmniejszego możliwego. Dlatego zmienne lokalne powinny być preferowane nad zmiennymi globalnymi | |
| 51 | + | ||
| 52 | + | Zmienne globalne mogą zostać przypadkowo zmienione przez błędy w dowolnym miejscu kodu. To niebezpieczeństwo można znacznie zmniejszyć, ograniczając ich zakres do kontekstu lokalnego. Podobnie deklarowanie pól w klasach jako chronionych lub prywatnych może pomóc w poprawie bezpieczeństwa. | |
| 53 | + | ||
| 54 | + | ### Sprawdź zwracaną wartość wszystkich funkcji lub zwracaj nil lub NaN, aby wskazać, że zwracana wartość jest bezużyteczna. Dodatkowo każda wywoływana funkcja musi sprawdzać poprawność wszystkich rzeczywistych parametrów dostarczonych przez kod ją wywołujący | |
| 55 | + | ||
| 56 | + | Nie ufaj ślepo istniejącemu kodowi, nawet jeśli został napisany przez Ciebie. Zawsze dobrze jest sprawdzić wartości pod kątem wiarygodności. Odwrotnie, sprawdzanie w witrynie funkcji wywołującej może być obsługiwane przez jawne wskazywanie nieprawidłowych wyników. | |
| 57 | + | ||
| 58 | + | ### Używaj dyrektyw kompilatora lub dyrektyw IDE oszczędnie. Jeśli to możliwe, powinny być ograniczone do sekcji interface modułu | |
| 59 | + | ||
| 60 | + | Dyrektywy i warunki dodają osobną warstwę do twojego kodu, która jest zgodna z rodzajem logiki, która różni się od głównego algorytmu. Może to być głównym źródłem nieprzewidywalności. Podobne rozważania mogą dotyczyć również używania makr. | |
| 61 | + | ||
| 62 | + | ### Ogranicz użycie wskaźników do pojedynczego pobrania danych i unikaj używania wskaźników do funkcji | |
| 63 | + | ||
| 64 | + | Arytmetyka wskaźników jest złożona i często myląca. Brak równowagi między przydzielaniem a zwalnianiem pamięci może powodować awarie i wycieki. Dodatkowo, podobnie jak zmienne globalne, bloki pamięci, do których odwołuje się wskaźnik, są podatne na przypadkowe uszkodzenie przez błędy w dowolnym miejscu kodu. | |
| 65 | + | ||
| 66 | + | ### Kompiluj z aktywnymi wszystkimi możliwymi ostrzeżeniami; wszystkie ostrzeżenia należy następnie rozwiązać przed wydaniem oprogramowania | |
| 67 | + | ||
| 68 | + | Jeśli używasz FPC z wiersza poleceń, to w generowaniu cennych informacji pomocne mogą być szczególnie opcje -B, -C i -g. W Lazarusie może to być [[Turn warnings and hints on or off|określone]] w oknie dialogowym opcji na poziomie globalnym. Dodatkowo istnieje możliwość kontrolowania tego zachowania za pomocą makr IDE na poziomie lokalnym. To oczywiście wyjątek od reguły nr 8. | |
| 69 | + | ||
| 70 | + | ## Zobacz także | |
| 71 | + | ||
| 72 | + | - [[The Power of Proper Planning and Practices|Siła właściwego planowania i praktyk]] | |
| 73 | + | - [[Secure programming/pl|Bezpieczne programowanie]] | |
| 74 | + | ||
| 75 | + | ## Przykłady | |
| 76 | + | ||
| 77 | + | - 4 czerwca 1996 r. rakieta startowa o dużym udźwigu *Ariane 5* uległa awarii podczas swojego dziewiczego lotu z powodu przepełnienia liczby całkowitej i nieobsłużonego wyjątku. Spowodowało to fiasko misji badawczej w zakresie magnetosfery *Cluster* i stratę ponad 370 milionów dolarów. Można było tego uniknąć, przestrzegając zasady nr 7 (i prawdopodobnie nr 10). | |
| 78 | + | - W latach 1985-1987 trzech pacjentów zostało zabitych, a trzech dodatkowych osób zostało poważnie rannych, kiedy sterowana komputerowo maszyna do radioterapii *Therac-25* dostarczyła ogromne dawki promieniowania. Przyczyny obejmowały ponowne użycie słabo poznanego kodu dla starszego modelu maszyny oraz arytmetyczne przepełnienie zmiennej flagi. Reguły \#4, \#5 i \#7 zapobiegłyby temu. | |
| 79 | + | ||
| 80 | + | ## Referencje | |
| 81 | + | ||
| 82 | + | 1. GJ Holzmann: [Potęga 10: Zasady opracowywania kodeksu krytycznego dla bezpieczeństwa](http://web.eecs.umich.edu/~imarkov/10rules.pdf) DOI: [10.1002/9781119174240.ch10](https://doi.org/10.1002/9781119174240.ch10) | |
| 83 | + | 2. R Giorato: [Potęga 10 — zasady kodowania NASA](https://medium.com/better-programming/the-power-of-10-nasas-rules-for-coding-43ae1764f73d). Medium, 2 października 2019 r. | |
| 84 | + | ||
| 85 | + | --- | |
| 86 | + | *From the Free Pascal wiki, page "The Power of 10/pl", as it stood on 2022-10-02 after a change by Slawek, out of the wiki's dump of 2024-05-26. Copyright stays with the author who wrote it, according to the old wiki's [[Licensing]] page. If you have concerns about this material, [message the admin](/wiki-contact).* | |
| 87 | + | Category: Coding guidelines | |
| 88 | + | Category: FPC | |
| 89 | + | Category: Software security |