Wdrożenie bezpiecznego SDLC, DevSecOps i CI/CD w Twoim IT
Układamy i wdrażamy w działach IT bezpieczny cykl wytwarzania oprogramowania: od zarządzania zmianą i wydaniami po CI/CD i bezpieczeństwo wbudowane w codzienną pracę zespołów. Zaczynamy od bezpłatnej konsultacji i warsztatu. Potem co miesiąc dostarczamy kolejny element roadmapy, którą ustalamy razem z Tobą.
- 01Wymaganie
- 02Zmiana
- 03Testy
- 04Wdrożenie
Bezpieczny przepływ od wymagania do produkcji
Procesy są, ale nie działają jako system
Przebieg kluczowych procesów zależy od kilku osób
Tylko one wiedzą, co wchodzi na produkcję i w jakiej kolejności. Gdy są na urlopie, okno wdrożeniowe robi się nerwowe.
Bezpieczeństwo przychodzi na końcu
Skan albo test penetracyjny tuż przed wdrożeniem. Wynik dostajesz wtedy, gdy na poprawki nie ma już czasu.
Audytor pyta o dowód
Procedura jest w dokumencie. Trudniej pokazać, że zespoły naprawdę tak pracują: kto zatwierdził zmianę, czym ją przetestowano, kiedy trafiła na produkcję.
Wiesz, co poprawić, ale brakuje czasu
Widzisz, co nie działa w wytwarzaniu, ale brakuje czasu, specjalistów lub ustalonego kierunku zmian.
Co wdrażamy: proces, automatyzacja i bezpieczeństwo w jednym przepływie
Bezpieczny SDLC (SSDLC) to sposób pracy, w którym wymaganie, zmiana, test, wydanie i wdrożenie tworzą jeden przepływ, a bezpieczeństwo jest jego częścią od pierwszego kroku. Zaczynamy od procesu i ludzi. Narzędzia dobieramy i łączymy na końcu, najczęściej te, które już masz.
Inicjowanie projektów i ścieżka developmentu
Ustalamy, jak praca w ogóle trafia do zespołów: jak dekomponować projekt, jak zlecać zmiany i kiedy zadanie jest gotowe do realizacji.
- start projektu: cele, zakres, role i punkty decyzyjne
- dekompozycja od projektu, przez elementy, po zadania zmieniające kod
- typy zadań odzwierciedlające proces, z jasnym zlecającym i realizującym
- zasady zlecania zmian: kto może zlecić, co musi zawierać zgłoszenie
- wycena i planowanie prac developerskich
- kryteria gotowości do realizacji i definicja ukończenia
Zarządzanie zmianą i wydaniami
Ustalamy, jak zmiana przechodzi od zgłoszenia do produkcji: kto ją akceptuje, co musi być sprawdzone przed kolejnym środowiskiem i jak planowane są okna wdrożeniowe.
- jednolity proces zmiany od zgłoszenia do zamknięcia, z rejestrem zmian
- źródło, zakres i ryzyko zmiany opisane przed startem
- akceptacje zebrane przed uruchomieniem, rozdzielone role zgłaszającego, zatwierdzającego i wdrażającego
- wydania planowane w powtarzalnych oknach, z zakresem i release notes
- bramka go/no-go przed produkcją
- rezerwacja środowisk i wykrywanie konfliktów między wydaniami
- rejestr wersji: co jest na którym środowisku i po co powstało
Repozytorium kodu i współpraca zespołów
Łączymy zgłoszenie zmiany z kodem, który ją realizuje. Porządkujemy pracę w repozytoriach tak, żeby kilka zespołów mogło pracować równolegle bez chaosu.
- kod zawsze powiązany z zadaniem: gałęzie, commity i pull requesty
- strategia gałęzi: do czego służą, jak są chronione, kiedy usuwane
- code review i ścieżka akceptacji zależna od ryzyka komponentu
- role i uprawnienia do repozytoriów, ochrona gałęzi głównych
- oznaczanie zależności, gdy zmiana obejmuje kilka komponentów
- konwencje nazewnictwa, wersjonowania i opisu zmian
CI/CD i automatyzacja wdrożeń
Budujemy i porządkujemy pipeline’y na Twojej platformie. Od CI/CD dla pojedynczego produktu po platformę DevOps dla całej organizacji.
- pipeline’y budowania, testowania i wdrażania (GitLab, Jenkins, Bitbucket i inne)
- repozytorium artefaktów z kontrolowanym dostępem
- bramki jakości w buildzie przed publikacją artefaktu
- pełny ślad: artefakt, build, commit, gałąź i zadanie
- automatyczne powoływanie środowisk testowych
- rejestr wdrożeń uzupełniany automatycznie z pipeline’u
- infrastruktura i pipeline’y jako kod
Zarządzanie testami i automatyzacja
Testy przestają być osobnym światem na końcu projektu. Układamy je jako proces z jednym źródłem scenariuszy, jednym miejscem zlecania i jednym miejscem na wyniki, niezależnie od tego, czy test jest manualny, automatyczny czy biznesowy.
- repozytorium scenariuszy jako jedno źródło prawdy, z zestawami i ponownym użyciem scenariuszy
- cykl życia scenariusza: od zidentyfikowania, przez kwalifikację do automatyzacji i regresję, po wycofanie
- klasyfikacja scenariuszy do automatyzacji i standard pisania automatów
- plany testów dobierane do zakresu i ryzyka zmiany, z uwzględnieniem systemów zależnych
- obsługa różnych typów testów: przedwdrożeniowych, powdrożeniowych, bezpieczeństwa, wydajnościowych, funkcjonalnych i regresyjnych
- zlecanie testów manualnych i automatycznych z jednego miejsca
- orkiestracja automatów: uruchamianie na żądanie lub wg harmonogramu, na właściwych środowiskach, z wynikami wracającymi do zarządzania testami
- kod testów wersjonowany, przeglądany i zabezpieczony jak kod produkcyjny, z sekretami z centralnego magazynu
- testy manualne według scenariuszy, z przypisaniem wykonawców i rejestracją wyników
- testy akceptacyjne z biznesem (UAT) w tym samym procesie co pozostałe testy
- obsługa defektów w pełnym cyklu życia: klasyfikacja, planowanie poprawek, powiązanie ze scenariuszem i wydaniem
- potwierdzenie przetestowania systemu lub komponentu w CMDB
- miary testów: pokrycie, wyniki i cykliczne przeglądy luk w pokryciu
DevSecOps: bezpieczeństwo w środku procesu
„S” w SSDLC to więcej niż skaner. Bezpieczeństwo, które spowalnia pracę, zespoły zaczynają omijać. Wbudowujemy je więc w kroki, które i tak wykonujesz.
- klasyfikacja ryzyka zmiany, od której zależy ścieżka akceptacji i zakres testów
- testy bezpieczeństwa w pipeline, z wynikami trafiającymi do zespołu, nie do szuflady
- obsługa podatności: rejestr, priorytet wg krytyczności systemu, termin naprawy
- sekrety wyłącznie w centralnym magazynie, skanowanie kodu pod kątem sekretów
- dostępy wg ról na wszystkich środowiskach, z regularnymi przeglądami
- ochrona integralności: kto zbudował, kto zaakceptował, kto wdrożył
Środowiska i CMDB
CMDB traktujemy jako fundament. Bez aktualnej wiedzy o systemach i ich zależnościach trudno ocenić wpływ zmiany, dobrać zakres testów i pokazać audytorowi, co się zmieniło.
- rozdzielenie środowisk i zasady pracy na danych testowych
- CMDB: rejestr systemów, komponentów, instancji i ich zależności
- zadania i zmiany wskazują obiekty z CMDB zamiast opisów tekstowych
- powiązanie zmian i wdrożeń z elementami CMDB oraz ocena wpływu zmiany
Zaczynamy od procesu, nie od narzędzia
SSDLC obejmuje u nas cztery warstwy organizacji: cele biznesu, zarządzanie IT, codzienną pracę zespołów i narzędzia. Wdrożenie, które zaczyna się od narzędzia, kończy się zwykle drogim pipeline’em obok starego sposobu pracy. Najpierw ustalamy więc, co chcesz osiągnąć i jak ma to wpłynąć na resztę organizacji. Potem standaryzujemy, implementujemy i automatyzujemy.
Tu zapadają decyzje o kierunku, które porządkują pracę niższych warstw.
Wspólne zasady i role, które spinają pracę zespołów w jedną całość.
Codzienna realizacja w zespołach, gdzie zasady zamieniają się w konkretny przepływ pracy.
Narzędzia, które wspierają zasady i dają dowód, że bezpieczeństwo działa.
Od pierwszej rozmowy do pierwszych efektów
Nie musisz przychodzić z gotową specyfikacją. Wystarczy, że wiesz, że chcesz zacząć. Resztę ustalimy razem, krok po kroku.
- zgłaszasz potrzebę, a my wskazujemy inicjatywę z roadmapy
- każdą inicjatywę wyceniamy i przedstawiamy do Twojej akceptacji
- priorytety zmieniasz co miesiąc, bez aneksów
- co miesiąc pokazujemy wynik i raportujemy wykorzystanie puli
- zakres, termin i cenę ustalamy przed startem
- realizujemy uzgodniony zakres
- kończymy odbiorem rezultatu
Jak wygląda miesiąc współpracy
Większość naszych klientów pracuje z nami w ramach miesięcznej puli. Rezerwujemy specjalistów, którzy są dla Ciebie dostępni w określonym wymiarze co miesiąc. My zapewniamy ludzi z właściwymi kompetencjami i dostarczamy kolejne elementy roadmapy.
Zasady, które warto znać
Zgodność, która wynika z procesu
Dobrze ułożony SSDLC sprawia, że gotowość na regulacje jest efektem codziennej pracy, a nie osobnym projektem.
Audytor pyta nie o procedurę w szufladzie, lecz o to, czy proces realnie działa. To umiemy pokazać.
Od wymogu do dowodu
Każdy wymóg regulacji ma u nas konkretny artefakt, który pokazujesz audytorowi.
Najczęściej pomagamy, gdy…
Wydania są nerwowe
Chcesz wiedzieć, co wchodzi na produkcję, kiedy i kto to zatwierdził.
CI/CD działa w jednym zespole, a potrzebny jest standard
Każdy zespół wdraża po swojemu. Chcesz jednego sposobu, który da się utrzymać.
Podlegasz uKSC, NIS2 lub DORA
Masz wymagania wobec wytwarzania oprogramowania i potrzebujesz wykonawcy, który przełoży je na codzienną pracę zespołów.
Wiesz, co poprawić, ale nie masz kiedy
Widzisz konkretne problemy w wytwarzaniu. Potrzebujesz zespołu, który zajmie się tym co miesiąc, bez rekrutacji.
Pracujemy tak z bankami, ubezpieczycielami i logistyką
W rezultacie projektu zapewniono możliwość sterowania zawartością wydania, a także automatycznego tworzenia i uzupełniania paczek. Mamy pełną kontrolę nad wdrożeniem.
…obsługę ponad 160 procesów deploymentowych, co doprowadziło do obsługi w „ścieżce automatycznej” ponad 40% wszystkich wdrożeń na środowiskach testowych i produkcyjnych.
…wzrost wydajności oraz stabilności systemów, a także skrócenie czasu time-to-market.
Porozmawiaj z osobą, która zna temat
Agata umówi Cię z konsultantem, który prowadził podobne wdrożenie.
Więcej o naszym podejściu
Szkolenie SSDLC dla kadry zarządzającej IT
Warsztaty dla kierowników i dyrektorów IT o bezpiecznym cyklu wytwarzania oprogramowania.
Dowiedz się więcej →Model SSDLC w czterech warstwach
Nasz autorski model: od celów biznesu, przez zarządzanie IT, po narzędzia.
Zobacz na stronie głównej →Czy firma objęta uKSC, NIS2 lub DORA może przenieść Atlassiana do chmury?
Artykuł o wymaganiach regulacyjnych w kontekście migracji do Atlassian Cloud.
Czytaj artykuł →Najczęściej zadawane pytania
Czym jest bezpieczny SDLC (SSDLC)?
Czym różni się DevSecOps od SSDLC?
Od czego zacząć?
Jak wygląda współpraca w ramach puli?
Co się dzieje z niewykorzystanymi dniami?
Na jak długo się wiążę?
Czy mogę zlecić pojedynczy projekt?
Ile to kosztuje?
Z jakimi narzędziami pracujecie?
Czy uKSC i NIS2 wymagają bezpiecznego SDLC?
Czy przejmiecie też utrzymanie naszych systemów?
Zacznij od rozmowy o swoim SDLC
Godzina z konsultantem, bez zobowiązań. Opowiesz, jak dziś powstaje i trafia na produkcję Twoje oprogramowanie. Powiemy, od czego byśmy zaczęli.

