unabhängiges adversarielles Code-Review
CounterProof ist eine unabhängige adversarielle Review-Praxis für moderne Codebasen — allen voran maschinengeschriebenen Code. Wir liefern das eine, das Sie intern nicht erzeugen können: eine unabhängige, signierte, evidenzgestufte Sicherheitsbewertung, gebaut für die Prüfung durch Regulatoren, Käufer, Versicherer und Unternehmenskunden.
Code, den ein Modell geschrieben und dasselbe Modell geprüft hat, wurde von niemandem geprüft.
Sprechen Sie mit uns, bevor die Frist es tut →Niemand kauft ein Code-Review. Man kauft, was es aufschließt.
Sie lesen das hier nicht, weil Sie mit dem Wunsch nach einer Sicherheitsbewertung aufgewacht sind. Irgendetwas verlangt von Ihnen Belege.
Drei dieser vier akzeptieren nie Ihr eigenes Wort über Ihren eigenen Code — Unabhängigkeit ist die Eigenschaft, die sie kaufen, und sie ist die eine Eigenschaft, die kein Team für die eigene Arbeit liefern kann. Der vierte, der Regulator, nimmt Ihre Selbstbewertung oft an — und hält Sie dann an jeder Aufzeichnung dahinter fest. So oder so muss der Beleg halten. Das ist, was wir erzeugen.
Wo Review im Schwachstellenmanagement ansetzt, Stufe für Stufe →
Das Lieferergebnis ist der Punkt.
Ein Engagement erzeugt ein CounterProof Assessment unter einer persistenten Engagement-Kennung (CPR-YYYY-NNN — das, was Ihre Maintainer, Ihr Käufer oder Ihre Fix-Commits zitieren). Jeder Befund wird entweder gegen Ihre Quelle bestätigt — exakte Datei und Zeile, Reproduktionspfad, Wirkungsklassifizierung — oder ausdrücklich als nur plausibel eingestuft. Nichts aufgepolstert, nichts scannergeneriert, nichts, worauf Sie nicht reagieren können. Die Akte hält auch fest, was wir geprüft und nicht gefunden haben: ein dokumentiertes Negativ ist hier ein Lieferergebnis, kein gescheitertes Engagement.
Jeder Befund nennt die Evidenzstufe, die er tatsächlich erreicht hat — Quellnachverfolgung, Kompilierbeweis, Test oder Live-Reproduktion und, für jede probabilistische Aussage, eine Rate mit Intervall und aufbewahrten Einzelprotokollen — und impliziert nie eine höhere. Jede Pfad:Zeile-Zitation wird maschinell gegen die exakte Revision aufgelöst, die wir geprüft haben, bevor der Bericht unsere Hände verlässt. Sie können unsere Arbeit nachprüfen. Das ist Absicht.
Wir sitzen dort, wo aus einem Befund eine Entscheidung wird, die später jemand rechtfertigen muss — Adjudikation, Abschluss und die unterschriebene Akte —, nicht im Wettlauf der Scanner um Kandidaten. Der Fund ist das Nebenprodukt eines Engagements; die Akte ist das Produkt.
Wenn ein Befund der Prüfung nicht standhält — Ihrer, der Ihrer Maintainer oder unserer eigenen Nachprüfung — ziehen wir ihn schriftlich zurück, mit Begründung, unter derselben Engagement-Kennung. Wir tun das unaufgefordert; die Gegenseite muss nicht darum bitten. Das Rücknahmeprotokoll ist kein Eingeständnis; es ist der Mechanismus.
Musterstück — die Form eines BefundsIllustratives Beispiel, nicht aus einem Kundenauftrag; Kennungen sind Platzhalter. Berichte werden auf Englisch ausgestellt.
„Zeugen gibt es jetzt umsonst. Die kritische Edition nicht.“
Der Markt hat begonnen, darüber zu konkurrieren, wie viele Befunde ein Werkzeug erzeugen kann — aber ein Befund ist ein Zeuge, kein Urteil. Eine Datei:Zeile-Zitation kann ein Leser öffnen und in einer Minute prüfen; ein bloßes „Kritisch“ nicht. In unseren Akten ist der Schweregrad ein Ergebnis der Evidenzstufe, nie eine Eingabe für das Marketing. Zeugen gibt es jetzt umsonst. Die kritische Edition nicht. Ein Befund ist kein Urteil →
Vier Schritte. Sie kennen den Umfang, bevor Sie zahlen, und behalten die Akte danach.
Ein erstes Engagement muss nicht alles umfassen, was Sie ausliefern. Ein kleiner, gut gewählter Umfang — ein Modul, eine Vertrauensgrenze — erzeugt dieselbe verteidigungsfähige Akte in einer Größe, die Sie bewerten können, und er kann das erste Stück Nachweis nach Teil II Nummer 3 sein, das ein Hersteller einreicht.
Flüssigkeit ist kein Qualitätsmerkmal. Sie ist der Fehlermodus.
Wenn ein Mensch eine Zeile Code schreibt, zweifelt er an ihr. Er weiß, dass er geraten hat — und dieser Zweifel ist eine Sicherheitsvorkehrung, denn er ist es, der ihn die Sache testen lässt.
Ein Modell schreibt dieselbe Zeile flüssig, in genau der Stimme, die es für die korrekten Zeilen benutzt. Für den Lesenden liest sich Flüssigkeit wie Kompetenz. Ein Junior-Ingenieur reicht Ihnen etwas sichtbar Grobes, und Sie prüfen es. Ein Modell reicht Ihnen zweihundert polierte Zeilen mit einer selbstbewussten Begründung für jede — und Sie tun es nicht.
Die Falle ist nicht, dass Modelle öfter falsch liegen als Menschen. Sie ist, dass ihre falschen Antworten in derselben Stimme ankommen wie ihre richtigen — von außen nicht zu unterscheiden, weil sie von innen nicht zu unterscheiden sind.
Dann schreibt derselbe Prozess den Test, der den Code zertifiziert, und den Kommentar, der ihn erklärt. Alle drei stimmen überein, weil alle drei aus einer Quelle kamen. Diese Übereinstimmung liest sich wie drei unabhängige Bestätigungen. Sie ist eine.
„Ihre falschen Antworten kommen in derselben Stimme an wie ihre richtigen.“
Die nützliche Frage ist also nicht, ob ein Modell guten Code schreiben kann — es kann, mit einer Methode darum herum. Sie ist, was Ihr Review-Prozess tatsächlich misst, wenn alles, was er inspiziert, aus derselben Quelle kam: der Code, der Test, die Erklärung und zunehmend das Werkzeug, das Sie zu ihrer Prüfung gebaut haben. Richtig gemacht, ist das Ergebnis gut. Falsch gemacht, liest es sich exakt gleich.
Ein Review findet, was sein Prüfer finden kann.
Lassen Sie ein Modell über eine Codebasis laufen, und ein kurzer Bericht sagt Ihnen etwas Enges: Dieses Modell, in diesem Harnisch, an diesem Tag, hat dieses zutage gefördert. Was es nicht zutage gefördert hat, steht nicht im Bericht — und kann es konstruktionsbedingt nicht.
Wie sehr das zählt, hängt davon ab, wie weit sich die blinden Flecken verschiedener Prüfer überlappen — was für Code-Review niemand gemessen hat. Forschung zu korrelierten Fehlern in Modellpopulationen, die verschiedene Anbieter umfassen, fand erhebliche Überlappung bei Multiple-Choice-Benchmarks und einer Lebenslauf-Screening-Aufgabe; ob sich das auf das Finden von Schwachstellen überträgt, ist nicht belegt. Was sie zeigt: Verschiedene Anbieter sind nicht automatisch unabhängig voneinander.
Mehrere Dinge können eingrenzen, was ein einzelner Durchlauf verpasst hat: ein Beweis, eine Testsuite, ein Fuzzer, ein Spezialist, eingesäte Defekte oder ein Prüfer, der sich vom ersten unterscheidet. Was es nicht eingrenzen kann: denselben Durchlauf mit mehr Zuversicht zu lesen.
Wir haben nicht gezeigt, dass Multi-Prüfer-Review mehr echte Defekte fängt — das Experiment, das wir dafür entworfen hatten, wurde eingestellt, bevor es lief, und wir sagen das öffentlich. Der engere Punkt ist der, hinter dem wir stehen: ein sauberer Durchlauf eines Prüfers ist ein abgegrenztes Ergebnis, und ihn als Sauberkeitszertifikat zu lesen, ist eine Folgerung, die dieses Ergebnis nicht trägt. Das vollständige Argument (auf Englisch) →
Wir haben das lange Argument niedergeschrieben, einschließlich dessen, wo die Grenzen unserer eigenen Methode liegen und was wir nicht demonstriert haben: eine Einführung in klarer Sprache und das vollständige Papier dahinter, veröffentlicht als Preprint unter doi:10.5281/zenodo.22030516 (CC BY 4.0), auf Englisch. Es ist nicht peer-reviewed, und es sagt das auch.
Sie könnten dieselben Modelle laufen lassen. Unabhängig sein können Sie nicht.
Mehrere KI-Modelle über den eigenen Code laufen zu lassen, repliziert unser Werkzeug und verliert die Eigenschaft, auf die es ankommt. Ihr Team wählt, was die Prüfer sehen, rahmt die Fragen und beurteilt die Antworten — und jede dieser Entscheidungen trägt Ihre Annahmen geradewegs zurück ins Review. Das ist kein Disziplinversagen; es ist strukturell. Der Autor eines Systems kann nicht sein eigener Schiedsrichter sein.
Selbst ein makelloses internes Review bleibt also Ihr eigenes Wort über Ihren eigenen Code. Was sie kaufen, ist ein Dritter, der zu unterschreiben bereit ist. Wir sind keine notifizierte Stelle und zertifizieren keine Konformität; wir erzeugen den unabhängigen Beleg, der Ihre Bewertung stützt und so strukturiert ist, dass ihn jede andere nachprüfen kann.
Der Methode ist gleichgültig, wer — oder was — Ihren Code geschrieben hat. Unabhängigkeit fehlt menschengeschriebenem Code genauso oft. Maschinengeschriebener Code macht die Lücke nur unmöglich zu ignorieren.
Sie würden es ohnehin herausfinden. Besser, Sie hören es von uns.
CounterProof ist Teil einer Gruppe, die Zahlungs- und Digital-Asset-Verwahrungsinfrastruktur baut. Dort wurde diese Methode geschmiedet — und es bedeutet: Wenn Sie in diesen Märkten bauen, kann unser verbundenes Unternehmen an Sie angrenzen oder mit Ihnen konkurrieren.
Also: Vor jedem Engagement sagen wir Ihnen schriftlich, was genau die Gruppe baut und wo sie operiert. Sie entscheiden, ob das akzeptabel ist — und Sie entscheiden es, bevor Sie uns irgendetwas bezahlt haben. Ist es nicht akzeptabel, ist das eine legitime Antwort, und wir hören sie lieber am Anfang.
Was unser Unabhängigkeitsanspruch abdeckt und was nicht, präzise: Wir erstellen keine Bewertung von Code, der von CounterProof oder einem Unternehmen unserer Gruppe verfasst wurde. Diese Grenze ist strukturell. Sie ist eine Aussage darüber, wessen Code wir prüfen — nicht der Anspruch, nirgends in der Nähe Ihres Sektors kommerzielle Interessen zu haben. Unsere sind oben benannt, und Sie entscheiden, ob das akzeptabel ist, bevor Sie uns irgendetwas bezahlt haben.
Drei Personen, benannt, aktenkundig.
Eine signierte Bewertung heißt: Jemandes Name steht darauf. Das sind die Personen — und welcher Name was trägt.
Wir sind eine Familienpraxis — Vater, Sohn und Tochter — und die Prüferbank besteht aus zwei Personen. Beides sind Fakten, die ein Due-Diligence-Team von selbst herausfindet, also sagen wir sie lieber hier: Eine Bank aus zwei Prüfern nimmt weniger Engagements an als ein Haus, lehnt alles außerhalb ihrer Domäne ab und kann einen schwachen Durchlauf nicht hinter einer Marke verstecken. Das ist der Tausch, und er ist der Grund, warum die Methode niedergeschrieben und mechanisiert ist, statt in jemandes Kopf getragen zu werden.
Was wir lesen und was wir prüfen.
Modelle anderer Anbieter haben geholfen, die Trainingsdaten von Kolibri-1 zu schreiben, auszuwählen und zu beurteilen. Die EU-Zusammenfassung nennt sieben Namen; der technische Bericht erklärt die verschiedenen Rollen. Die Angaben zeigen, wie ein für souveränen und spezialisierten Einsatz gebautes Modell beim Training auf Modelle anderer Anbieter zurückgreifen kann. Welche Verhaltensweisen dabei übernommen wurden, falls überhaupt, belegen sie nicht.
Die Konfiguration, die unter zwölf Agenten-Konfigurationen am häufigsten funktionierenden Code erzeugte, tat dies in 57 % der Aufgaben; nur in 11,8 % funktionierte ihr Code und bestand zugleich den Sicherheitstest. Den Agenten auf das Risiko hinzuweisen, half ein wenig. Die Studie konnte auf jede Schwachstelle testen, weil sie bereits gefunden und behoben worden war und der Fix einen Sicherheitstest mitbrachte. Der neue Code Ihres Agenten hat noch keinen solchen Test.
Die Verordnung erwähnt Krypto-Wallets nirgends. Sie gilt für Produkte mit digitalen Elementen. Ab Dezember 2027 verlangt sie außerdem, die Sicherheit des Produkts regelmäßig und wirksam zu testen und zu überprüfen. Nach unserer Lesart berührt diese Pflicht die Frage, ob ein Hersteller eine Schwachstelle vor einem Angreifer findet. Diese Notiz erläutert den Anwendungsbereich, die Meldefristen und die Rolle eines unabhängigen Reviews.
Sprechen Sie mit uns, bevor die Frist es tut.
Informationsanfragen gehen an Elenora Soons, Account-Managerin: