Bezpieczeństwo wbudowane w sposób, w jaki Wasz zespół pisze i wydaje oprogramowanie — nie doklejone po audycie.
Każda kontrola działa w narzędziach, których zespół już używa.
Tak wygląda punkt wyjścia w wielu firmach, które dowożą szybko i podlegają regulacjom.
Bezpieczeństwo pojawia się na końcu: przed wydaniem, przed audytem albo po pytaniu klienta. Wtedy każda znaleziona rzecz jest droga, bo trzeba cofać gotową pracę. Zespół traktuje ją jako przeszkodę, nie jako część roboty.
Zakres ustalamy po diagnozie — zaczynamy od elementu, który najszybciej obniży Wasze ryzyko.
Wchodzimy tam, gdzie oprogramowanie faktycznie powstaje.
Zaczynamy od zobaczenia, jak Wasz zespół naprawdę pracuje — nie jak to wygląda na diagramie w dokumentacji. Dopiero wtedy ustalamy, w których punktach procesu kontrola bezpieczeństwa ma sens i nie zablokuje dowożenia. Mechanizmy wpinamy w narzędzia, których zespół już używa, i dostrajamy je tak długo, aż przestaną generować fałszywe alarmy — bo kontrola, której nikt nie czyta, jest gorsza niż jej brak. Na końcu przekazujemy proces zespołowi razem z dokumentacją, żeby utrzymał go bez nas.
Po każdym etapie zostaje u Was konkretny rezultat, a nie notatka ze spotkania.
Sprawdzamy, jak naprawdę powstaje u Was oprogramowanie — od pomysłu do wydania. Nie jak wygląda na diagramie.
RezultatMapa procesu z miejscami, w których powstaje ryzyko
Ustalamy, w których punktach procesu kontrola bezpieczeństwa ma sens i nie zablokuje pracy.
RezultatPlan kontroli ułożony od tego, co najszybciej obniży ryzyko
Wpinamy mechanizmy w istniejące narzędzia zespołu. Tak długo, aż przestają generować fałszywe alarmy.
RezultatDziałające kontrole w Waszych narzędziach, dostrojone do Waszego kodu
Zostawiamy proces, który zespół rozumie i utrzyma bez nas.
RezultatDokumentacja i zespół, który utrzyma proces samodzielnie
Wdrożenie kończy się działającą konfiguracją i dowodami, a nie raportem z listą zaleceń. Tak to wygląda na przykładzie.
# akcje przypięte do SHA, nie do tagu
permissions: { contents: read }
steps:
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
with: { persist-credentials: false }
- name: Sekrety w kodzie
run: gitleaks git --redact
- name: Podatne zależności
run: osv-scanner scan source -r .
- name: SBOM do każdego wydania
run: syft . -o cyclonedx-json=sbom.jsonKontrole uruchamiają się przy każdej zmianie, bez ręcznego pilnowania.
| Zagrożenie | Gdzie | Kontrola |
|---|---|---|
| Wyciek tokenu z procesu budowania | CI/CD | krótkotrwałe tokeny OIDC |
| Podmieniona zależność | budowanie | weryfikacja wersji i SBOM |
| Zmiana bez recenzji | repozytorium | ochrona gałęzi i wymagana recenzja |
Każde zagrożenie ma przypisaną kontrolę w konkretnym miejscu procesu.
main + historia scaleńDowody zbierają się na bieżąco, a nie pod presją terminu audytu.
Ilustracja. Zakres i narzędzia dobieramy po diagnozie. Dowody techniczne ułatwiają audyt, ale go nie zastępują.
Zakres ustalamy po rozmowie i diagnozie. Mniejsze wdrożenia zamykają się w kilku tygodniach, większe dzielimy na etapy, żeby efekt był widoczny po pierwszym.
Zwykle nie do całego. W większości przypadków wystarczy dostęp do konfiguracji procesu budowania i ustawień organizacji. Zakres ustalamy pisemnie przed startem.
Tak, ale nie na pełen etat. Potrzebujemy kontaktu z osobą, która zna system, i przeglądu naszych zmian. Reszta jest po naszej stronie.
Wpinamy się w to, co u Was działa. Wymiana narzędzia to najdroższy i najrzadziej potrzebny sposób poprawy bezpieczeństwa.
Nie. Pracujemy na standardach i narzędziach, które Wasz zespół zna albo szybko pozna — nie na autorskiej metodyce, którą rozumiemy wyłącznie my. Wszystko jest udokumentowane i przekazane.
Tak wpinamy kontrole, żeby działały w tle. Jeśli któraś zaczyna blokować pracę, dostrajamy ją albo zmieniamy jej miejsce w procesie.