CounterProof

Znajdowanie staniało. Dowodzenie stało się trudne.

CounterProof to niezależna praktyka adwersaryjnego przeglądu nowoczesnych baz kodu — przede wszystkim kodu pisanego przez maszyny. Dostarczamy to jedno, czego nie da się wytworzyć wewnętrznie: niezależną, podpisaną ocenę bezpieczeństwa z gradacją dowodów, zbudowaną pod kątem kontroli regulatorów, nabywców, ubezpieczycieli i klientów korporacyjnych.

Kod napisany przez model i przejrzany przez ten sam model nie został przejrzany przez nikogo.

Porozmawiajcie z nami, zanim zrobi to termin →
01

Dlaczego tu jesteście

Nikt nie kupuje przeglądu kodu. Kupuje się to, co on otwiera.

Nie czytacie tego dlatego, że obudziliście się z pragnieniem oceny bezpieczeństwa. Coś żąda od was dowodów.

Regulator
Unijny Cyber Resilience Act wymaga od producentów „przeprowadzania skutecznych i regularnych testów i przeglądów bezpieczeństwa produktu z elementami cyfrowymi” (załącznik I część II pkt 3), a dokumentacja techniczna musi zawierać „sprawozdania z prób przeprowadzonych w celu weryfikacji zgodności” (załącznik VII pkt 6) — przechowywane co najmniej 10 lat po wprowadzeniu do obrotu lub przez okres wsparcia, jeżeli jest dłuższy (art. 13 ust. 13). Zgłaszanie aktywnie wykorzystywanych podatności i poważnych incydentów na mocy art. 14 zaczyna się 11 września 2026 r.; rozporządzenie stosuje się w pełni od 11 grudnia 2027 r. Większość produktów może się samooceniać — co nie jest ulgą, lecz ekspozycją: ciężar wytworzenia dokumentacji, która się obroni, spada w całości na was.
Nabywca lub inwestor
Techniczne due diligence to miejsce, gdzie bazy kodu wspierane przez AI są dziś przeceniane w dół. Niezależna ocena na stole zmienia tę rozmowę, zanim się zacznie.
Ubezpieczyciel cyber
Underwriterzy coraz częściej wyceniają różnicę między „testujemy wewnętrznie” a „niezależna strona przetestowała i podpisała”.
Klient korporacyjny
Ich kwestionariusz bezpieczeństwa nie ma pola „nasz model przejrzał własny wynik”.

Trzej z tych czterech nigdy nie przyjmą waszego słowa o waszym własnym kodzie — niezależność jest właściwością, którą kupują, i jedyną właściwością, której żaden zespół nie może dostarczyć o własnej pracy. Czwarty, regulator, często przyjmie waszą samoocenę — a potem rozliczy was z każdego dokumentu, który za nią stoi. Tak czy inaczej, dowody muszą się obronić. To właśnie wytwarzamy.

02

Co otrzymujecie

Produkt końcowy jest sednem.

Zlecenie wytwarza CounterProof Assessment pod trwałym identyfikatorem zlecenia (CPR-YYYY-NNN — to, co cytują wasi opiekunowie kodu, wasz nabywca albo wasze commity z poprawkami). Każde ustalenie jest albo potwierdzone względem waszego kodu źródłowego — dokładny plik i wiersz, ścieżka reprodukcji, klasyfikacja skutków — albo jawnie oznaczone jako jedynie uprawdopodobnione. Nic dopchanego, nic wygenerowanego przez skaner, nic, na czym nie można działać. Akta odnotowują także to, co sprawdziliśmy i czego nie znaleźliśmy: zapisany wynik negatywny jest tu produktem, a nie nieudanym zleceniem.

Każde ustalenie wskazuje szczebel dowodowy, który faktycznie osiągnęło — ślad w źródle, dowód kompilacji, test albo reprodukcja w działaniu — i nigdy nie sugeruje wyższego. Każde odwołanie ścieżka:wiersz jest maszynowo rozwiązywane względem dokładnie tej rewizji, którą przeglądaliśmy, zanim raport opuści nasze ręce. Możecie sprawdzić naszą pracę. To celowe.

Gdy ustalenie nie przetrwa weryfikacji — waszej, waszych opiekunów kodu albo naszego własnego ponownego badania — wycofujemy je na piśmie, z podaniem powodu, pod tym samym identyfikatorem zlecenia. Robimy to nieproszeni; druga strona nie musi o to występować. Dziennik wycofań nie jest przyznaniem się; jest mechanizmem.

Okaz — kształt ustalenia
CPR-2026-0NN · F-07 — duplicate credit on settlement retry severity: High (reachable in default build) evidence rung: reproduced — failing test, 2/2 runs, 3 clean controls source: gateway/src/settle.rs:412 @ rev a1b2c3d fix verified: rev e5f6a7b — finding closed in writing

Okaz ilustracyjny, niepochodzący ze zlecenia klienta; identyfikatory są wypełniaczami. Raporty wystawiamy po angielsku.

„Świadkowie są już darmowi. Edycja krytyczna nie jest.”

Dla organu
Zbudowana tak, by wejść do waszej dokumentacji technicznej jako sprawozdanie z prób w rodzaju przewidzianym w załączniku VII pkt 6, wspierające obowiązek testowania z części II pkt 3. Wspiera akta, które składacie; nie jest aktami i nie weryfikuje zgodności w całym załączniku I.
Dla zespołu due diligence
Z gradacją dowodów, odtwarzalna, o jasnym zakresie, z naszym nazwiskiem na ryzyku.
Dla waszych inżynierów
Dość krótka, by ją przeczytać, dość precyzyjna, by naprawić. Możemy zostać na czas poprawek i niezależnie zweryfikować każdą z nich względem ustalenia, którego dotyczy — zapisując, co zweryfikowaliśmy i przy której rewizji. Kończycie z aktami tego, co sprawdzono, a nie z listą uwag.

Rynek zaczął konkurować liczbą ustaleń, jakie narzędzie potrafi wygenerować — ale ustalenie to świadek, nie wyrok. Odwołanie plik:wiersz czytelnik może otworzyć i sprawdzić w minutę; goły „Krytyczny” — nie. W naszych aktach waga jest wynikiem szczebla dowodowego, nigdy wsadem do marketingu. Świadkowie są już darmowi. Edycja krytyczna nie jest. Ustalenie to nie wyrok →


A tak przebiega zlecenie

Cztery kroki. Znacie zakres, zanim zapłacicie, a akta zostają u was.

1 — Zakres
Rozmowa z samymi recenzentami — ludźmi, którzy wykonają pracę. Uzgadniamy, co wchodzi w zakres, a co nie, przypinamy dokładną rewizję poddawaną przeglądowi i przedstawiamy wam na piśmie ujawnienie grupowe — zanim ruszą jakiekolwiek pieniądze. Jeśli praca leży poza naszą domeną, mówimy to i odmawiamy.
2 — Przegląd
Zespół pracuje na przypiętej rewizji. Każde kandydackie ustalenie jest rozstrzygane względem źródła — potwierdzone, oznaczone jako jedynie uprawdopodobnione albo odrzucone — a kontrole, które wróciły czyste, zapisujemy obok tych, które czyste nie były.
3 — Raport
Otrzymujecie ocenę pod jej identyfikatorem zlecenia, wraz z omówieniem dla waszych inżynierów. Ustalenia, szczeble dowodowe, ścieżki reprodukcji, zapisane wyniki negatywne — dość krótko, by przeczytać, dość precyzyjnie, by działać.
4 — Akta
Możemy zostać na czas waszych poprawek i zweryfikować każdą z nich względem ustalenia, którego dotyczy, przy rewizji, która je zamknęła. Identyfikator, dziennik wycofań i ślad zamknięcia pozostają cytowalne — wobec zespołu bezpieczeństwa waszego klienta, waszego nabywcy albo organu — na warunkach przechowywania określonych w umowie zlecenia.

Pierwsze zlecenie nie musi obejmować wszystkiego, co wydajecie. Mały, dobrze dobrany zakres — jeden moduł, jedna granica zaufania — daje te same możliwe do obrony akta w rozmiarze, który potraficie ocenić, i może być pierwszym elementem dowodu z części II pkt 3, jaki producent składa.

03

Co naprawdę idzie źle

Płynność nie jest oznaką jakości. Jest trybem awarii.

Kiedy człowiek pisze linijkę kodu, wątpi w nią. Wie, że zgadywał — a ta wątpliwość jest zabezpieczeniem, bo to ona każe mu pójść i rzecz przetestować.

Model pisze tę samą linijkę płynnie, dokładnie tym głosem, którym pisze linijki poprawne. Dla czytającego płynność wygląda jak kompetencja. Młodszy inżynier podaje wam coś widocznie surowego i to sprawdzacie. Model podaje dwieście wypolerowanych linijek z pewnym uzasadnieniem każdej — i nie sprawdzacie.

Pułapką nie jest to, że modele mylą się częściej niż ludzie. Jest nią to, że ich błędne odpowiedzi przychodzą ubrane w ten sam głos co poprawne — nieodróżnialne z zewnątrz, bo są nieodróżnialne od wewnątrz.

Potem ten sam proces pisze test, który certyfikuje kod, i komentarz, który go objaśnia. Cała trójka się zgadza, bo cała trójka wyszła z jednego miejsca. Ta zgodność wygląda jak trzy niezależne potwierdzenia. Jest jednym.

„Ich błędne odpowiedzi przychodzą tym samym głosem co poprawne.”

Użyteczne pytanie nie brzmi więc, czy model potrafi napisać dobry kod — potrafi, z metodą wokół siebie. Brzmi ono: co właściwie mierzy wasz proces przeglądu, gdy wszystko, co bada, wyszło z tego samego źródła — kod, test, objaśnienie, a coraz częściej i narzędzie, które zbudowaliście do ich sprawdzania. Zrobione dobrze, wynik jest dobry. Zrobione źle — czyta się dokładnie tak samo.


A napastnik nie jest ograniczony do waszego recenzenta

Przegląd znajduje to, co potrafi znaleźć jego recenzent.

Przepuśćcie jeden model przez bazę kodu, a krótki raport powie wam coś wąskiego: ten model, w tej uprzęży, tego dnia, wydobył na powierzchnię to. Czego nie wydobył, nie ma w raporcie — i z konstrukcji być nie może.

Jak bardzo to się liczy, zależy od tego, jak mocno nakładają się martwe pola różnych recenzentów — czego dla przeglądu kodu nikt nie zmierzył. Badania nad skorelowanymi błędami między dostawcami wykazały istotne nakładanie się w testach wielokrotnego wyboru i w zadaniu selekcji CV; czy przenosi się to na wykrywanie podatności, nie zostało ustalone. Co pokazują: różni dostawcy nie są automatycznie od siebie niezależni.

Kilka rzeczy potrafi ograniczyć to, co pojedynczy przebieg przeoczył: dowód, zestaw testów, fuzzer, specjalista, zasiane defekty albo recenzent różny od pierwszego. Czego to nie ograniczy: czytania tego samego przebiegu z większą pewnością siebie.

Nie wykazaliśmy, że przegląd wielorecenzencki łapie więcej realnych defektów — eksperyment, który zaprojektowaliśmy, by to sprawdzić, wycofano przed uruchomieniem, i mówimy to publicznie. Węższa teza jest tą, za którą stoimy: czysty przebieg jednego recenzenta to wynik o ograniczonym zakresie, a czytanie go jako świadectwa czystości to wniosek, którego ten wynik nie unosi. Pełny wywód (po angielsku) →

Długi wywód spisaliśmy, łącznie z tym, gdzie leżą granice naszej własnej metody i czego nie wykazaliśmy: wprowadzenie prostym językiem oraz pełny artykuł za nim, opublikowany jako preprint pod doi:10.5281/zenodo.22030516 (CC BY 4.0), po angielsku. Nie przeszedł recenzji naukowej i mówi to wprost.

04

Dlaczego nie da się tego zrobić u siebie

Możecie uruchomić te same modele. Nie możecie być niezależni.

Przepuszczenie kilku modeli AI przez własny kod replikuje nasze narzędzia, a gubi właściwość, o którą chodzi. Wasz zespół wybiera, co recenzenci widzą, ustawia pytania i ocenia odpowiedzi — a każdy z tych wyborów wnosi wasze założenia prosto z powrotem do przeglądu. To nie jest brak dyscypliny; to struktura. Autor systemu nie może być jego własnym arbitrem.

Więc nawet nieskazitelny przegląd wewnętrzny pozostaje waszym słowem o waszym własnym kodzie. Tym, co oni kupują, jest strona trzecia gotowa się podpisać. Nie jesteśmy jednostką notyfikowaną i nie certyfikujemy zgodności; wytwarzamy niezależne dowody, które wspierają waszą ocenę i są zbudowane tak, by mogła je ponownie zbadać czyjakolwiek inna.

Metodzie jest obojętne, kto — albo co — napisał wasz kod. Kodowi pisanemu przez ludzi niezależności brakuje równie często. Kod pisany przez maszyny sprawia tylko, że tej luki nie da się już ignorować.

05

Ujawnienie, które się z tym wiąże

I tak byście to odkryli. Lepiej, żebyście usłyszeli to od nas.

CounterProof jest częścią grupy budującej infrastrukturę płatności i przechowywania aktywów cyfrowych. To tam wykuto tę metodę — i znaczy to, że jeśli budujecie na tych rynkach, nasza spółka powiązana może z wami sąsiadować albo z wami konkurować.

A zatem: przed każdym zleceniem mówimy wam na piśmie, co dokładnie grupa buduje i gdzie działa. Wy decydujecie, czy to akceptowalne — i decydujecie, zanim nam cokolwiek zapłacicie. Jeśli to nieakceptowalne, to uprawniona odpowiedź i wolimy ją usłyszeć na początku.

Co nasze roszczenie niezależności obejmuje, a czego nie — precyzyjnie: nie wydajemy żadnej oceny kodu napisanego przez CounterProof ani przez jakąkolwiek spółkę naszej grupy. Ta granica jest strukturalna. To stwierdzenie o tym, czyj kod przeglądamy, a nie roszczenie do braku interesów handlowych gdziekolwiek w pobliżu waszego sektora. Nasze są wymienione powyżej, a wy decydujecie, czy są akceptowalne, zanim nam cokolwiek zapłaciliście.

06

Kim jesteśmy

Trzy osoby, z nazwiska, w aktach.

Podpisana ocena znaczy, że widnieje na niej czyjeś nazwisko. Oto te osoby — i które nazwisko za co odpowiada.

Vincent Soons, CEO
Prowadzi badania bezpieczeństwa w CounterProof Research, z naciskiem na infrastrukturę Bitcoina: protokoły L2, systemy przechowywania i kod, który przesuwa prawdziwe pieniądze. Jego praca jest oparta na uprzężach testowych. Poziom dowodów jest podawany dla każdego twierdzenia, a to, co zgłasza jako odtworzone, zostało odtworzone deterministycznie na niezmodyfikowanym kodzie. W tle: kontrybutor upstream Fedimint, sfederowanego protokołu przechowywania Bitcoina — wkład publiczny, sprawdzalny dla każdego.
Luuk Soons, CSO
Aktywny w Bitcoinie i infrastrukturze zdrowego pieniądza od 2013 roku. Odpowiada za metodę, postawę regulacyjną i każdą decyzję o ujawnieniu — łącznie z tą powyżej.
Elenora Soons
Account manager i wasza osoba kontaktowa w sprawach zapytań — ta, która odpowiada, gdy do nas piszecie, ustawia ramy rozmowy i pilnuje, by papiery zlecenia się posuwały. Nie pisze ani nie podpisuje ocen; to niosą dwa nazwiska powyżej. info@counterproof.io · +356 7741 7951

Jesteśmy praktyką rodzinną — ojciec, syn i córka — a ława recenzencka liczy dwie osoby. Oba te fakty zespół due diligence odkryje sam, więc wolimy powiedzieć je tutaj: ława dwóch recenzentów bierze mniej zleceń niż firma, odmawia wszystkiego spoza swojej dziedziny i nie może ukryć słabego przebiegu za marką. To jest ta wymiana — i to jest powód, dla którego metoda jest spisana i zmechanizowana, zamiast być noszona w czyjejś głowie.

07

Notatki

Co czytamy — i co sprawdzamy.

Wszystkie notatki →

08

Porozmawiajcie z nami, zanim zrobi to termin.

Zapytania trafiają do Elenory Soons, account manager:

info@counterproof.io

+356 7741 7951

Obserwuj nas na LinkedIn Obserwuj nas na X