Kontrola nad tym, z czego powstaje Wasze oprogramowanie — i dowód, że paczka u klienta pochodzi z Waszego procesu.
Klient sprawdza pochodzenie paczki sam, bez proszenia Was o oświadczenie.
Tak wygląda punkt wyjścia w wielu firmach, które dowożą szybko i podlegają regulacjom.
Większość Waszego produktu to cudzy kod. Nie trzeba atakować Was bezpośrednio — wystarczy biblioteka albo narzędzie, z którego korzystacie. Jeden zainfekowany element trafia do wszystkich, którzy go pobiorą, razem z aktualizacją.
Zakres ustalamy po diagnozie — zaczynamy od elementu, który najszybciej obniży Wasze ryzyko.
Wiecie, z czego zbudowany jest Wasz produkt.
Spis składników generujemy automatycznie przy każdym wydaniu, nie ręcznie raz do roku — dzięki temu pytanie „czy używacie tej biblioteki" przestaje być projektem na tydzień. Artefakty podpisujemy, żeby klient mógł samodzielnie zweryfikować, że dostał to, co wyszło z Waszego procesu. Nowe zależności przechodzą sprawdzenie, zanim wejdą do projektu, bo najtańszy moment na odrzucenie ryzykownej biblioteki jest przed jej dodaniem. Całość układamy tak, żeby domykała techniczną warstwę wymagań CRA.
Po każdym etapie zostaje u Was konkretny rezultat, a nie notatka ze spotkania.
SBOM generowany automatycznie przy każdym wydaniu, nie raz do roku ręcznie.
RezultatSBOM generowany automatycznie przy każdym wydaniu
Klient może zweryfikować, że dostał to, co wyszło z Waszego procesu.
RezultatPodpisane artefakty, które klient zweryfikuje sam
Nowa biblioteka przechodzi sprawdzenie, zanim wejdzie do projektu.
RezultatReguły przyjmowania nowych zależności, wpięte w recenzję zmian
Dokumentacja techniczna i zdolność odpowiedzi na zgłoszenie podatności.
RezultatDokumentacja techniczna i procedura zgłaszania podatności pod CRA
Wdrożenie kończy się działającą konfiguracją i dowodami, a nie raportem z listą zaleceń. Tak to wygląda na przykładzie.
# podpis bez długożyjących kluczy
cosign sign registry.example.com/api@sha256:4f3c…
# weryfikacja po stronie klienta
cosign verify \
--certificate-identity-regexp '^https://github.com/firma/' \
--certificate-oidc-issuer \
https://token.actions.githubusercontent.com \
registry.example.com/api@sha256:4f3c…Klient wie, że dostał dokładnie to, co wyszło z Waszego procesu.
| Składnik | Wersja | Licencja |
|---|---|---|
| openssl | 3.0.15 | Apache-2.0 |
| zlib | 1.3.1 | Zlib |
| log4j-core | 2.24.1 | Apache-2.0 |
Pytanie „czy używacie tej biblioteki” to jedno wyszukiwanie.
Szablony i role są ustalone, zanim przyjdzie pierwsze zgłoszenie.
Ilustracja. Zakres i narzędzia dobieramy po diagnozie. Pokrywamy warstwę techniczną; pełna zgodność z CRA wymaga też działań organizacyjnych i prawnych.
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.