Arbeitsumgebung für technische Due Diligence
Ein Investor möchte den Code eines Zielunternehmens prüfen. Das Unternehmen verbindet seine eigenen Repositories und entscheidet selbst, was geteilt wird. Die Arbeitsumgebung bewertet, was sie erhält, belegt jede Aussage mit Dateien und nennt zu jedem Abschnitt des Berichts das Modell, das ihn erstellt hat.
- BrancheInvestment Due Diligence
- Art der ArbeitEigenes Produkt
- StatusIn aktiver Entwicklung
Was es tut
Ein Investor muss wissen, was er kauft, bevor das Geld fließt. Diese Arbeitsumgebung beantwortet diese Frage mit einem bewerteten, belegten Bericht über den Code des Zielunternehmens, statt mit einer Zusammenfassung, der man glauben muss.
Der Ablauf hat zwei Seiten. Der Investor eröffnet die Prüfung und verschickt eine Einladung; das Zielunternehmen verbindet sein eigenes Konto und wählt genau aus, welche Repositories in die Prüfung eingehen. Analysiert wird nur, was das Unternehmen übergeben hat.
Eine Prüfung, die ihre Arbeit nicht zeigen konnte
Technische Prüfungen kommen meist als Ergebnis an. Wer sie liest, kann sie weder nachprüfen noch sehen, was nie betrachtet wurde.
Ergebnisse ohne Belege
Eine schriftliche Prüfung nennt den Code riskant oder solide. Der Leser kann dieses Urteil nicht bis zu einer Datei zurückverfolgen und nicht erkennen, ob der Prüfer diesen Teil des Codes überhaupt geöffnet hat.
Zugang, bevor Vertrauen besteht
Vom Zielunternehmen wird erwartet, dass es seinen Quellcode früh im Prozess am Stück herausgibt, ohne Mitsprache darüber, was geteilt wird, und ohne Nachweis, wohin er ging.
Lücken, die wie ein sauberes Ergebnis aussehen
Wenn eine Prüfung nicht abschließt, mittelt ein Bericht gern um die Lücke herum. Fehlende Belege und ein gutes Ergebnis sehen auf der Seite gleich aus.
Eine Arbeitsumgebung, gebaut um das, was sie belegen kann
Was wir entworfen und gebaut haben, als vier Fähigkeiten, die im erzeugten Bericht sichtbar sind.
Repository-Zugang mit Einwilligung
Der Investor eröffnet die Prüfung und verschickt eine Einladung. Das Zielunternehmen verbindet sein eigenes Konto und wählt, welche Repositories in die Prüfung eingehen. Zugang wird gegeben, nicht verlangt.
- Einladung und Übergabe zwischen zwei Seiten
- Das Unternehmen wählt, was geteilt wird
- Arbeitskopien werden nach dem Lauf gelöscht
Eine gestufte Analyse-Pipeline
Die Prüfung läuft als Folge von Stufen. Jede schreibt ihr eigenes Ergebnis, sodass eine fehlgeschlagene Stufe den Bericht schwächt, statt den Lauf zu beenden.
- Indexierung, adversariale Sicherheitsanalyse, Verifikation
- Ablaufkartierung, Prüfung von Abhängigkeiten und hinterlegten Zugangsdaten
- Änderungshistorie, Architektur, technische Schulden, Bericht
Bewertungen mit angehängten Belegen
Der Code wird nach Komplexität, Testabdeckung, Abhängigkeiten, Architektur, Duplizierung, Sicherheitslage, Wartbarkeit und technischen Schulden bewertet, jeweils mit den Messwerten hinter der Note.
- Befunde tragen Datei- und Zeilenangabe
- Sicherheitsbefunde tragen einen reproduzierbaren Nachweis
- Technische Schulden nach veröffentlichtem Kostenmodell, Formel sichtbar
Ehrlichkeit im Bericht angelegt
Der Bericht ist so gebaut, dass er nachprüfbar ist. Seine Bereitschaftsliste kennt drei Zustände statt zwei: bestanden, nicht bestanden und unzureichende Belege.
- Ein unvollständiger Lauf vergibt keine Gesamtnote
- Ausbleibende Befunde gelten als unzureichender Beleg, nicht als sauberes Ergebnis
- Die Verifikation behandelt einen Kommentar im Code als Behauptung, nicht als Beleg
Wo die Arbeit stattfand und wer sie gemacht hat
Statt einer Teileliste vier Dinge, die für einen Lauf gelten.
Jeder Abschnitt nennt das Modell, das ihn geschrieben hat
Der Bericht enthält eine Herkunftstabelle: Stufe, Anbieter, Modell und Endpunkt. Die letzte Spalte zeigt den Unterschied zwischen Arbeit auf der lokalen Maschine und Arbeit, die das Haus verlassen hat.
Jede Stufe kann auf ein anderes Modell festgelegt werden
Sensible Analysen bleiben auf einem Modell auf eigener Hardware, während Routinedurchläufe anderswo laufen. Die Wahl fällt pro Stufe, nicht einmal pro Installation.
Es läuft auch ganz ohne Anbieterkonto
Eine lokale Modellumgebung braucht keine Zugangsdaten, und die Arbeitsumgebung kann Repositories auf der eigenen Festplatte prüfen, erreichbar nur von dieser Maschine.
Was Sie als sensibel markieren, erreicht kein Modell
Dateien, die auf Ihre eigenen Pfadregeln passen, werden aussortiert, bevor irgendetwas gesendet wird. Hinterlegte Zugangsdaten liegen verschlüsselt, und Endpunkte im Bericht werden von allem Geheimen befreit.
Was sich an einer Prüfung ändert
Die Veränderung ist qualitativ, und genau das veröffentlichen wir. Auf dieser Seite steht keine Zahl aus einem Lauf, den wir nicht zeigen können.
Nachvollziehbar
Jedes Ergebnis
Eine Note lässt sich bis zu den Dateien und Zeilen zurückverfolgen, die sie erzeugt haben, und der Leser sieht, welches Modell den Abschnitt geschrieben hat.
Ihre Hardware
Wo die Analyse läuft
Jede Stufe kann auf ein Modell auf der eigenen Maschine festgelegt werden, sodass sensibler Code sie für die Prüfung nicht verlassen muss.
Nichts gemittelt
Fehlende Belege
Eine Lücke wird als Lücke berichtet. Ist die Abdeckung unvollständig, vergibt der Bericht keine Gesamtnote, statt eine zu geben, die die Belege nicht tragen.
Prüfen Sie eine technische Investition?
Wir bauen Diligence-Werkzeuge, die ihre Belege zeigen und dort laufen, wo Sie sie brauchen. Sagen Sie uns, was Sie bewerten.
Sprechen Sie mit uns