Czasami w sposobie, w jaki ludzie rozumieją i przetwarzają język, może pojawić się mała pułapka. W szczególności czasami bierzemy znaczenie słowa lub frazy za pewnik. Rozumiem przez to, że używamy terminu oznaczającego daną rzecz, tylko po to, by ci, którzy nas słyszą, zrozumieli ten termin w zupełnie inny sposób.
Przynosi to efekt przeciwny do zamierzonego, gdy dzieje się to w codziennej komunikacji, ale może być niebezpieczne w kontekście dyscyplin mających wpływ na ryzyko, takich jak bezpieczeństwo cybernetyczne, zapewnienie bezpieczeństwa i zarządzanie. W takich sytuacjach może stwarzać ryzyko.
Poruszam ten temat, ponieważ często słyszymy o tzw sposoby zapewnienia „bezpiecznego kodowania” w organizacjach, które tworzą i utrzymują oprogramowanie w ramach swojej działalności, do użytku wewnętrznego lub zewnętrznego. To ważne, ponieważ szczerze mówiąc, większość firm należy obecnie do tej kategorii. Chociaż naturalne jest omawianie wyzwań związanych z oprogramowaniem w ten sposób, uważam, że sam termin „bezpieczne kodowanie” zakłada kontekst, który sprawia, że zamierzony stan końcowy faktycznie trudniej osiągnąć – przynajmniej w sensie dosłownym.
I nie mam na myśli tego tylko w sensie semantycznym. Na przykład twierdzę, że zrozumienie, dlaczego to stwierdzenie jest prawdziwe, ma rzeczywistą, namacalną, praktyczną wartość. Mówi o podstawowej przyczynie, dla której wiele organizacji zmaga się z zagrożeniami związanymi z aplikacjami i oprogramowaniem, i podkreśla praktyczne kroki, które organizacje mogą podjąć w celu poprawy. Mając to na uwadze, przyjrzyjmy się, jakie są rzeczywiste cele redukcji ryzyka związanego z oprogramowaniem i jak najlepiej je realizować, spełniając nasze wymagania dotyczące bezpiecznego i odpornego opracowywania i publikowania oprogramowania.
Bezpieczeństwo tworzenia oprogramowania a redukcja ryzyka
Pierwszą rzeczą do rozpakowania jest zamierzony stan końcowy tego, co rozumiemy przez „bezpieczne kodowanie”. Moim zdaniem istnieje kilka różnych, powiązanych ze sobą celów, które zwykle oznacza ten termin. Po pierwsze, przez „bezpieczeństwo” w tym kontekście ludzie zazwyczaj rozumieją dwie rzeczy:
- Stosowanie architektury aplikacji i wzorców projektowych, które sprzyjają zasadom ograniczania ryzyka (np. poufność, integralność i dostępność)
- Tworzenie oprogramowania odpornego na ataki (np. poprzez luki w zabezpieczeniach i błędne konfiguracje)
Obie te rzeczy są oczywiście niezwykle ważne. Poświęć trochę czasu na rozmowę z praktykami bezpieczeństwa aplikacji, a oni słusznie cię wyróżnią Barry’ego Boehma słynna praca o ekonomii znajdowania i naprawiania luk na wczesnym etapie procesu programowania. Słusznie wyjaśnią ci wartość narzędzi takich jak modelowanie zagrożeń aplikacji które można wykorzystać, aby zrozumieć, jakie i gdzie występują problemy związane z projektowaniem zabezpieczeń w oprogramowaniu. Pułapka polega na tym, że te rzeczy, choć ważne, nie stanowią całości tego, co mogłoby nas interesować, jeśli chodzi o zmniejszanie ryzyka w oprogramowaniu. Na przykład inne rzeczy, które mogą nas interesować przynajmniej w równym stopniu, mogą obejmować:
- Dojrzałość – zapewnienie, że procesy są dojrzałe, aby były odporne na odejście pracowników i aby wyniki były spójne
- Przezroczystość – zapewnienie przejrzystości w łańcuchu dostaw komponentów i bibliotek, na których z kolei opierają się nasze produkty (i możliwość zapewnienia tej przejrzystości klientom)
- Zgodność – upewnić się, że działamy zgodnie z różnymi licencjami (komercyjnymi i open source), których używamy do tworzenia naszego oprogramowania
- Prostota projektu – czy projekt jest łatwy do zrozumienia i oceny
I tak dalej. W rzeczywistości te rzeczy to tylko wierzchołek góry lodowej rozważań, które mogą i mają wpływ na ryzyko związane z oprogramowaniem w praktyce. Równie łatwo można uwzględnić takie elementy, jak: przydatność do określonego celu, rygor projektowy, wsparcie, zasięg testów, jakość kodu, czas wprowadzenia na rynek i wiele innych czynników, które mają wpływ na ryzyko związane z tym, jak projektujemy, rozwijamy, testujemy, wdrażamy, utrzymujemy, wsparcia, a ostatecznie wycofać z użytku nasze oprogramowanie.
Patrząc z tego punktu widzenia, pytanie, które powinniśmy zadać, wcale nie dotyczy „bezpieczeństwa”, ale raczej redukcji ryzyka (którego bezpieczeństwo jest podzbiorem, choć dużym i ważnym). interesariuszy, zawęża odpowiedzialność i zmienia dyskusję. Z drugiej strony skupienie się na ryzyku oznacza, że wszyscy – nawet ci daleko od świata programistów – mają do odegrania istotną rolę.
Cykl życia oprogramowania
Drugą rzeczą, na którą chciałbym zwrócić twoją uwagę, jest element „kodowania” frazy. Tak, kodowanie jest ważne. Ale podobnie jak „bezpieczeństwo”, to tylko część – choć duża – cyklu życia związanego z tworzeniem oprogramowania. Zastanów się, jak zwykle projektuje się oprogramowanie i ile różnych kroków obejmuje. Chociaż poszczególne cykle życia oprogramowania (SDLC) mogą opisywać je inaczej, na wysokim poziomie możesz mieć kroki – w każdym razie abstrakcyjne – podobne do następujących:
- Identyfikacja potrzeby
- Ideacja/Incepcja
- Zbieranie wymagań
- Projekt
- Rozwój
- Testowanie
- Zastosowanie
- Wsparcie
- Konserwacja
- Likwidacja
To wiele kroków. Zauważysz, że każdy z nich można dalej podzielić na niezliczone indywidualne podetapy. Na przykład krok taki jak „testowanie” może obejmować (w zależności od używanego SDLC, kontekstu itp.): testy jednostkowe, testy funkcjonalne, testy regresji, testy wydajności, testy bezpieczeństwa i dowolną liczbę innych pojedynczych elementów. Ile z nich obejmuje tylko „kodowanie”, a ile nie, ale mimo wszystko są one kluczowe dla zapewnienia niezawodnego produktu na końcu?
Innymi słowy, interesariusze zaangażowani na każdym etapie tego procesu mają mnóstwo możliwych sposobów wprowadzania lub łagodzenia ryzyka w zależności od procesów, które wykonują, ich szkolenia, świadomości i wielu innych czynników. Oznacza to, że program uwzględniający ryzyko, zaprojektowany w celu ograniczania, zarządzania i łagodzenia ryzyka związanego z oprogramowaniem, musi uwzględniać je wszystkie i, tam gdzie to możliwe, wspierać te działania, które sprzyjają redukowaniu ryzyka. Chodzi o to, że chociaż kodowanie jest prawdopodobnie najbardziej „widocznym” krokiem w procesie tworzenia i wydawania oprogramowania (przynajmniej wewnętrznie), nie jest to również jedyne miejsce, na którym powinniśmy się skupić.
Jak można się spodziewać, działania związane z zarządzaniem ryzykiem aplikacji — lub oprogramowania, w zależności od preferowanego języka — powinny obejmować cały cykl życia. W szerszym znaczeniu oznacza to dwie rzeczy: 1) całościowe zrozumienie i uwzględnienie całego cyklu życia oraz 2) rozszerzenie planowania na obszary poza rozwojem, które mimo wszystko mają znaczenie. Włącz i zastąp personel testowy, analityków biznesowych, kierowników projektów i produktów, zespoły wsparcia, dział sprzedaży, marketingu, HR i dział prawny — obejmij ich opieką nad bezpieczeństwem tego, co tworzysz.
Jak powiedziałem na początku, nie chodzi tylko o semantykę (chociaż przyznaję, że ująłem to w ten sposób, aby zilustrować tę kwestię). Chodzi raczej o zrozumienie, że na ryzyko mają wpływ całokształt procesów związanych z tworzeniem oprogramowania i to ryzyko znacznie wykracza poza to, na czym zwykle skupiamy się, patrząc na takie rzeczy, jak luki w zabezpieczeniach.
Dlaczego nie jest to tylko semantyka? Ponieważ mówi o czymś większym, co jest niezwykle ważne. W Cele i środkiAldous Huxley powiedział kiedyś, że „Cel nie może usprawiedliwiać środków z tego prostego i oczywistego powodu, że zastosowane środki determinują charakter osiągniętych celów.Chodziło mu o to, że sposób, w jaki coś robimy, w dużej mierze determinuje stan końcowy. Rozszerzając to na tworzenie oprogramowania, argumentuję, że zdezorganizowane, niedojrzałe i „niechlujne” procesy programistyczne nieuchronnie doprowadzą do powstania oprogramowania, które jest tandetnie zaprojektowane i gorzej wdrożone, niż miałoby to miejsce w przypadku bardziej solidnego i zdyscyplinowanego procesu. . To z kolei oznacza, że stawiamy sobie cele poza bezpieczeństwem i obejmujemy procesy wykraczające poza pisanie kodu.