Zgodność z DORA dla programistów: co ląduje w pull request

Dla kogo jest ten przewodnik (i dla kogo nie)

Jesteś odbiorcą, jeśli Twój kod obsługuje podmiot finansowy objęty DORA lub jeśli Twój produkt jest usługą ICT, z której korzystają te podmioty w produkcji (niezależnie od tego, czy jesteś wyznaczonym krytycznym dostawcą usług ICT podlegającym bezpośredniemu nadzorowi, czy dostawcą związanym głównie poprzez umowy z klientami). Zakres i wyznaczenie zgodnie z rozporządzeniem to kwestie prawne i klasyfikacji podmiotów, a nie coś, co decyduje recenzja kodu. Jeśli Twój zespół ds. zgodności lub prawny poinformował Cię, że DORA ma zastosowanie (bezpośrednio lub na podstawie umowy), ten przewodnik dotyczy inżynierskiej części tego obowiązku. Jeśli nie jesteś pewien, czy jesteś objęty zakresem, przerwij tutaj i zapytaj ich: zła odpowiedź to albo niedoinwestowanie w rzeczywisty obowiązek, albo nadmierne dostosowywanie się do rozporządzenia, które nie ma zastosowania.

Nie jest to zamiennik dla ram zarządzania ryzykiem ICT, programu testów odporności, procesu raportowania incydentów, rejestru podmiotów trzecich ani kluczowych postanowień umownych z dostawcami usług ICT. heygrc nie realizuje żadnych z tych zadań. Został zaprojektowany, aby ujawnić moment, w którym zmiana w pull request osłabia lub wprowadza kontrolę istotną dla odporności, którą te programy zakładają, że nadal istnieje.

Artykuły, które faktycznie pojawiają się w diff

Większość DORA nigdy nie pojawi się jako linia kodu aplikacji. To, co zwykle ląduje w pull request, skupia się w krótkiej liście artykułów. Art. 9 (ochrona i zapobieganie): zmiana osłabia kontrolę dostępu, szyfrowanie, segmentację sieci lub inną miarę, która utrzymuje izolację krytycznej funkcji ICT. Art. 10 (wykrywanie): usuwanie lub wyłączanie logowania, alertów lub wykrywania anomalii, na których podmiot polega, aby szybko zauważyć problem ICT. Art. 11 (reagowanie i odzyskiwanie): usuwanie jako czyszczenie ponownych prób, wyłączników obwodu, awaryjnych przełączeń, limitów czasu lub ścieżek odzysku, które utrzymywały krytyczną funkcję przy życiu podczas zakłóceń. Art. 12 (kopie zapasowe i przywracanie): zmniejszenie zakresu kopii zapasowych, częstotliwości lub narzędzi do przywracania, albo nowy krytyczny magazyn danych wprowadzany bez ścieżki kopii zapasowej. Artykuły 17 do 19 (zarządzanie incydentami związanymi z ICT, ich klasyfikacja i raportowanie): zmiana usuwa identyfikowanie, śledzenie, logowanie lub rejestrowanie incydentów związanych z ICT (Art. 17) lub usuwa pola i sygnały, od których zależy proces klasyfikacji (Art. 18) i ścieżka raportowania poważnych incydentów (Art. 19). Art. 28 (ogólne zasady dotyczące ryzyka związanego z podmiotami trzecimi w zakresie ICT), w tym rejestr informacji zgodnie z Art. 28(3): nowa umowa dotycząca usługi ICT jest podłączana do produkcji bez zarejestrowania w rejestrze, który powinien obejmować wszystkie takie umowy. Art. 30 (kluczowe postanowienia umowne): umowa jest traktowana jako "kolejny klient SaaS" bez odniesienia do rozdziału dotyczącego postanowień umownych dla usług ICT, co jest oddzielnym obowiązkiem od rejestru Art. 28 i prac związanych z zarządzaniem.

Powyższe opisy to podsumowania w prostym języku dla inżynierów, a nie tekst rozporządzenia. Szczegółowa analiza ram DORA pod adresem /frameworks/dora omawia artykuły dotyczące odporności wraz z kształtami zmian, które je naruszają. Strony dotyczące kontroli w kodzie dla Art. 9 (ochrona i zapobieganie) i Art. 11 (reagowanie i odzyskiwanie) pokazują praktyczne diffy dla spłaszczonej segmentacji i usuniętego wyłącznika obwodu. Ten przewodnik koncentruje się na grupie artykułów, która najczęściej zaskakuje inżynierów produktowych: Art. 28 i Art. 30, gdy wygodne wywołanie SaaS staje się zależnością ICT w produkcji.

Przykład praktyczny: czysty klient, który staje się niezarejestrowanym podmiotem trzecim w zakresie ICT

Zespół ds. płatności chce szybszych decyzji dotyczących oszustw. Programista otwiera pull request, który zastępuje wolną ścieżkę reguł wewnętrznych typowanym klientem HTTP do nowego zewnętrznego interfejsu API "FraudScore". Klient ma limity czasu, ponowne próby z wycofaniem, strukturalne mapowanie błędów i flagę funkcji. Testy obejmują ścieżkę pomyślną i błędy 5xx. Komentarze w recenzji dotyczą głównie budżetów opóźnień i tego, czy flaga jest domyślnie włączona czy wyłączona. Nic w diff nie wygląda na błędne z punktu widzenia oprogramowania: to poprawnie zintegrowany kod.

To, czego PR nie zawiera, to żadna aktualizacja rejestru informacji dotyczących umów z dostawcami usług ICT (Art. 28(3)) ani żadne odniesienie do kluczowych postanowień umownych z Art. 30, które mają zastosowanie do umów dotyczących usług ICT (Art. 30(1) i (2)). Żaden z tych elementów nie czeka na decyzję, czy wywołanie jest "krytyczne". Ponadto, jeśli ta sprawdzenie oszustw znajduje się na ścieżce autoryzacji płatności, umowa może obsługiwać krytyczną lub ważną funkcję, co może wiązać się z dodatkowymi obowiązkami, w tym wymaganiami dotyczącymi strategii wyjścia z Art. 28 i oceny ryzyka koncentracji z Art. 29 oraz rozszerzonymi postanowieniami umownymi z Art. 30(3). Wprowadzenie klienta do produkcji, a następnie dodanie wpisu do rejestru "później" to sposób, w jaki zależność produkcyjna staje się niewidoczna dla programu, który powinien śledzić każdą umowę dotyczącą usług ICT.

To właśnie taki kształt recenzja świadoma zgodności ma na celu wykryć: nie "czy klient HTTP jest poprawny", ale "czy ta zmiana wprowadziła lub wymieniła usługę podmiotu trzeciego w zakresie ICT, której umowa zgodnie z Art. 28(3) powinna znaleźć się w rejestrze". Znalezisko, które powołuje się na Art. 28 / Art. 28(3) (oraz Art. 30, jeśli luką są postanowienia umowne), nie zatwierdza dostawcy, nie projektuje umowy, nie klasyfikuje krytyczności ani nie decyduje o ryzyku koncentracji. Sprawia, że obowiązek związany z podmiotem trzecim staje się widoczny, zanim autor zamknie PR, dzięki czemu kroki związane z rejestrem, klasyfikacją i umową mogą postępować razem z kodem, a nie tygodnie po tym, jak ruch produkcyjny zależy od nowego dostawcy.

Na co zwrócić uwagę podczas recenzji, nie stając się prawnikiem DORA

Gdy zmiana dodaje lub wymienia zewnętrzną zależność, która będzie działać w produkcji dla funkcji finansowej, zadaj trzy pytania inżynierskie: czy umowa dotycząca tej usługi ICT jest już zarejestrowana w naszym rejestrze informacji (Art. 28(3)), w tym jak usługa jest klasyfikowana i czy obsługuje krytyczną lub ważną funkcję; czy awaria tego wywołania pogarsza usługę finansową na tyle, że mogą mieć zastosowanie prace związane z krytycznością i planem awaryjnym; oraz czy ten sam PR (lub powiązana zmiana) aktualizuje wewnętrzną listę kontrolną lub zgłoszenie, którego używa Twój zespół ds. ryzyka, gdy nowa umowa dotycząca ICT ląduje, w tym prace związane z postanowieniami umownymi z Art. 30, jeśli tak śledzi to Twoja organizacja. Jeśli odpowiedź dotycząca rejestru brzmi "nie" lub "nieznane", funkcja jest niekompletna z punktu widzenia DORA dotyczącego podmiotów trzecich, nawet jeśli jest kompletna jako kod. Krytyczność decyduje o tym, ile dodatkowej pracy należy wykonać; nie decyduje o tym, czy umowa powinna znaleźć się w rejestrze.

W przypadku zabezpieczeń odporności, które już posiadasz, sygnał jest inny: PR, którego podsumowanie brzmi "czyszczenie", "usunięcie martwego kodu" lub "zmniejszenie kosztów", który usuwa ponowne próby, awaryjne przełączenia, kopie zapasowe, reguły izolacji lub haki wykrywania na krytycznej ścieżce. Zapytaj, czy system nadal spełnia właściwość odporności, którą zapewniało to zabezpieczenie. Art. 9, 10, 11, 12 oraz grupa artykułów dotyczących zarządzania incydentami (Artykuły 17 do 19) to typowe powołania, gdy odpowiedź brzmi "nie". Nie musisz cytować rozporządzenia. Musisz nazwać właściwość i odmówić scalania, dopóki ktoś nie przejmie odpowiedzialności za przywrócenie zabezpieczenia lub udokumentowanie zaakceptowanej zmiany poprzez rzeczywisty proces zmian.

Rola heygrc i granica uczciwości

heygrc został zaprojektowany, aby analizować każdy pull request w oparciu o wybrane przez Ciebie ramy, w tym DORA, jeśli jest włączone, i identyfikować artykuł, którego dotyczy zmiana (np. Art. 28(3) w przypadku nowej umowy dotyczącej usługi ICT brakującej w rejestrze, Art. 11 w przypadku usuniętej ścieżki odzysku). Znalezisko to komentarz w recenzji z dołączonym artykułem, dzięki czemu autor i recenzent mogą podjąć decyzję z pełną wiedzą. Nie certyfikuje zgodności z DORA, nie zastępuje ram ryzyka ICT, nie przeprowadza testów odporności, nie składa raportów o incydentach, nie utrzymuje rejestru podmiotów trzecich ani nie projektuje postanowień umownych z Art. 30. Te obowiązki pozostają po stronie ludzi i organizacji. Zielona recenzja heygrc nie jest zatwierdzeniem przez organ nadzoru; to wcześniejszy, oparty na artykułach sygnał, że zmiana wpłynęła na coś, co te programy uważają za istotne.

Jeśli Twój zespół już używa narzędzia do recenzji błędów lub jakości na tym samym pull request, zachowaj je. Te narzędzia sprawdzają, czy kod jest poprawny i bezpieczny. Pytania dotyczące DORA dotyczą odporności operacyjnej i obowiązków związanych z podmiotami trzecimi w zakresie ICT. Klient FraudScore opisany powyżej może być czysty, typowany i dobrze przetestowany, a mimo to pozostawić Art. 28(3) nierozwiązany. Uruchom obie warstwy; żadna nie zastępuje drugiej.