Możecie wziąć jeden albo wszystkie. Razem układają się w ścieżkę od projektowania po utrzymanie.
Uczymy zespół znajdować słabe punkty na etapie projektu, zanim powstanie pierwsza linia kodu. Pracujemy metodą STRIDE na diagramie Waszego realnego systemu.
Jak wpiąć kontrole bezpieczeństwa w proces budowania tak, żeby działały w tle i nie wkurzały zespołu. Konfigurujemy je razem, na Waszym pipelinie.
Praktyczne warsztaty dla programistów. Nie wykład o podatnościach, tylko przegląd Waszego kodu i wspólne szukanie realnych błędów — z naprawą na miejscu.
Wyznaczamy i przygotowujemy osoby, które w każdym zespole odpowiadają za bezpieczeństwo na co dzień — tak, żeby nie było ono niczyje. Program działa także wtedy, gdy nas już nie ma.
Warsztat dla ośmiu osób to inna praca niż dla trzydziestu. Zakres i formę ustalamy po rozmowie — od pojedynczej sesji po program dla wielu zespołów.
Jedna sesja, jeden temat, jeden zespół. Najczęstszy punkt wejścia.
Kilka powiązanych warsztatów rozłożonych w czasie, z zadaniami między sesjami.
Uruchomienie sieci opiekunów bezpieczeństwa w organizacji wielozespołowej.
Każdy warsztat przygotowujemy pod Wasz system — to zwykle kilka dni pracy przed samą sesją. Nie prowadzimy szkoleń z gotowego slajdu. Szkolenia zdalne i stacjonarne traktujemy tak samo; przy stacjonarnych dochodzą koszty dojazdu.
Po warsztacie zespół potrafi zastosować to, czego się nauczył, bez naszej obecności. To jest jedyny sensowny miernik skuteczności szkolenia — nie ankieta satysfakcji.
Diagramy zagrożeń, konfiguracje, notatki z warsztatu i lista znalezionych problemów. Nie wysyłamy prezentacji w PDF — zostawiamy artefakty, których da się użyć.
Warsztat na Waszym kodzie zwykle kończy się listą konkretnych rzeczy do naprawienia — znalezionych przez zespół, nie przez nas. To zmienia podejście trwalej niż jakikolwiek wykład.
Bezpieczeństwo wbudowane w sposób, w jaki Wasz zespół pisze i wydaje oprogramowanie — nie doklej…
Zobacz obszar →Zasady korzystania z narzędzi AI w zespole developerskim — żeby przyspieszenie pracy nie odbywał…
Zobacz obszar →Kontrola nad tym, z czego powstaje Wasze oprogramowanie — i dowód, że paczka u klienta pochodzi …
Zobacz obszar →Domyślnie dla zespołów inżynierskich: programistów, architektów, testerów, DevOps. Prowadzimy też krótsze sesje dla kierownictwa technicznego, jeśli potrzebujecie wspólnego języka między zarządem a zespołem — ale to inna rozmowa i inny materiał.
Do dwunastu osób. Powyżej tego warsztat przestaje być warsztatem i zamienia się w wykład — a wykład nie zmienia sposobu pracy. Przy większych zespołach dzielimy grupę na kilka sesji.
Nie musicie. Bez dostępu warsztat będzie oparty na dokumentacji i rozmowie z zespołem — nadal wartościowy, ale mniej konkretny. Zakres dostępów zawsze ustalamy pisemnie przed startem.
Czasem wystarczy. Jeśli zespół ma kompetencje i czas, sam wdroży to, czego się nauczył — i tak jest najlepiej. Wdrożenie ma sens wtedy, gdy zespół wie, co robić, ale nie ma kiedy. Powiemy Wam wprost, który to przypadek.
Zwykle od dwóch do trzech tygodni od rozmowy do warsztatu. Ten czas idzie na poznanie Waszego systemu i przygotowanie materiału — bez tego warsztat byłby standardowy, a standardowy nie działa.
Wystawiamy zaświadczenie o ukończeniu warsztatu. Nie jest to certyfikat branżowy typu OSCP czy CISSP i nie udajemy, że nim jest — takich uprawnień nie mamy i nikt na naszym miejscu ich nie ma.