Anleitung zur Quellcode-Vorschau · 0.1.0
Quellcode mit klaren Verträgen erweitern
Finde Scanner-, Nachweis-, Client- und Workflowgrenzen, die ein gezielter Beitrag erhalten muss.
Die API-Referenz ist auf Englisch.
Der Quellcode bietet sinnvolle Beitragsstellen: Scanneradapter und Regeln, normalisierte Nachweise, dauerhafte Abläufe, React-Weboberfläche und VS Code-Client. Dies sind geprüfte Implementierungsgrenzen. Es gibt kein Laufzeit-Plugin-SDK, beliebiges Programmregister oder allgemeine API-Schlüsselintegration.
Wähle einen begrenzten Beitrag
- Vertrag finden
Beginne mit öffentlichem Werkzeugregister, Adapterdispatch und normalisiertem Befundschema.
- Werkzeug- und Dateneingaben prüfen
Aktualisiere betroffene festgelegte Buildeingaben, Hinweise und Scannerdatenanforderungen.
- Begrenzten Adapter implementieren
Definiere genaue Argumente, Umgebung und Parsing. Erhalte Umfang, Ausgabegrenzen und Bereinigung bekannter Muster.
- Bereitschaft und Abdeckung verbinden
Mache fehlende Daten, nicht verfügbare Werkzeuge und begrenzte Analyse in Vorprüfung und Scan sichtbar.
- Geändertes Verhalten prüfen
Nutze kleine synthetische Fixtures und gezielte Prüfungen für Parsing, Fehlerwege, Bereitschaft und Ergebnissammlung.
- Gesamte Änderung prüfen
Verbinde Quelländerungen mit betroffenen UI- und API-Verträgen, bevor du einen Beitrag teilst.
| Bereich | Implementierungseinstieg | Zu erhaltender Vertrag |
|---|---|---|
| Scannerausführung | Register und native Adapter | Festgelegte Identität, eigene Konfiguration, begrenzte Ausführung und ehrliche Parser-/Abdeckungsergebnisse. |
| Regeln und Scannerdaten | Tool-Lock, Regel-Lock und Generationsvalidierung | Geprüfte Eingaben, Inhaltsidentität, Kompatibilität, Aktualität und atomare Aktivierung. |
| Befunde und Artefakte | Scannernormalisierung und Artefaktgrenze | Kanonischer Ort und Fingerprint, begrenzte Metadaten, Bereinigung und attestierte Veröffentlichung. |
| Dauerhafte Abläufe | Jobrepository und Workerausführung | Idempotenz, Lease-/Versuchsabsicherung, Fristen, Abbruch und wiederherstellbare Checkpoints. |
| Browserabläufe | React-Anwendung | Maßgebliche Ressourcenaktualisierung, erwartete Revisionen, hilfreiche Warte-/Fehlerzustände und Barrierefreiheit. |
| Editorabläufe | VS Code-Quellen | Aktive Capability-Generation, Workspace Trust, Quellidentität und ausdrückliche Hostaktionen. |
Eine kleine Regelfixture oder eng begrenzte Ablaufkorrektur ist ein sinnvoller erster Beitrag. Beschreibe das korrigierte Verhalten und die belegenden Nachweise. Eine breite Kategorie wie SAST-Unterstützung darf nicht als Versprechen für jede Sprache oder Schwäche dienen.
Ändere oder ergänze Scanner als abgestimmte Quelländerung
Das feste Register validiert Werkzeugversionen, Versionsbefehle, Argumente, Zusatzdurchläufe, Umgebungen und Ausgabeformate gegen den Lock. Eine Binärdatei im Image reicht deshalb nicht. Unbekannte Scanner-IDs werden bei Ausführung abgelehnt.
- Prüfe Upstreamquelle, Lizenz, Änderungen und genaue Build-/Download-Eingaben. Erhalte erforderliche Hinweise und binde die Image-Identität.
- Aktualisiere Katalog und Locks mit vorgesehenem Befehl, Ausgabeformat und erforderlichen Regeln oder Daten. Trenne Netzwerkvorbereitung von Quellausführung.
- Implementiere Adapter und Parser mit eigenen Kontrollen, endlicher Ausführung und Ausgabegrenzen, kanonischen Quellorten und ehrlichen Fehlern. Fehlerhafte Ausgabe darf nicht zu null Befunden werden.
- Integriere Bereitschaft und Quellabdeckung. Fehlende Voraussetzungen müssen vor Zulassung oder in unvollständigen Nachweisen sichtbar bleiben.
- Ergänze passende positive, befundfreie, fehlerhafte, übergroße, Timeout- und Quellkontrollfälle. Prüfe das native Werkzeug zusätzlich zu Parserfixtures.
- Prüfe normalisierte Befunde, Bereinigung, deterministische Fingerprints und den vollständigen Workerveröffentlichungsweg. Ein roher nativer Bericht ist nicht automatisch ein unterstütztes Artefakt.
Die aktuelle Scannerausführungsmatrix erklärt Adapterunterschiede. Trivy hat zwei Durchläufe; Grype hängt von Syft ab; Checkov steuert seine Konfigurationserkennung; Bearer nutzt einen veränderten Build. Jedes Upgrade braucht neue Nachweise für diese konkreten Verträge.
Erhalte Nachweisbedeutung bei neuen Abläufen
Ein neuer Status oder eine UI-Aktion kann mehr als ein Label verändern. Befunde haben eigene Revisionen und Bewertungen; Scans haben Abdeckung und Gate-Entscheidungen; Jobs haben Leases und Endzustände. Halte diese Bedeutungen getrennt.
Risikoannahme nimmt beispielsweise einen bestehenden Befund aus Gate-Zählungen heraus, ergänzt aber keine Scannerabdeckung. Fixed erfasst eine Prüfentscheidung und verifiziert keine geänderten Quellen. Ein abgeschlossener Arbeitsbaumscan autorisiert keinen geschützten Push, dessen frühere ausgehende Commits andere Bäume enthalten.
Clientänderungen sollen REST-Zustand nach Ereignissen, Resets und Mutationen abgleichen, statt Hinweise als vollständige Ressourcen zu behandeln. Veraltete Antworten dürfen keine neueren Entscheidungen überschreiben. Prüfe API-Revisionsvertrag und sichtbares Verhalten während Navigation, Wiederverbindung, Abbruch und Fehlern.
Halte Integrationen innerhalb vorhandener Berechtigungen
Controlclients verwenden Browsersitzungs-/CSRF-Regeln oder genaue erlaubte IDE-Capability-Scopes plus Eigentumsprüfungen jeder Route. Interne Scanner-, Updater- und Advisor-Protokolle sind keine unterstützten Integrations-APIs. Neue Routen dürfen nicht versehentlich jedem gekoppelten Editor Eigentümeraktionen oder breitere Quellmounts erlauben.
Advisor-Erweiterungen müssen die Offenlegungsgrenze erhalten. Eine entfernte Einzelbefundbestätigung bindet Ziel, Modell, Konfiguration, Einwilligung und Promptidentität; automatische scanweite Auswahl bleibt lokal. Der Connector spricht derzeit geprüfte Ollama-Routen. Andere Anbieter erfordern eine Quell- und Sicherheitsvertragsänderung, keinen undokumentierten Konfigurationstrick.
Nutze Quellberechtigungen und interne Dienste, um Aufrufer und Vertrauensgrenze vor einem Änderungsvorschlag zu bestimmen.
Berichte Nachweise nur auf ihrer belegten Ebene
Gezielte Unittests belegen ausgeführte Fälle. Native Scannerfixtures belegen das Verhalten genauer verwendeter Werkzeug-/Dateneingaben. Browserabläufe belegen beobachteten Clientworkflow. Image-Ausgangsprüfungen, Hosthookverhalten und Plattformabnahme benötigen eigene Beobachtungen. Nichts davon darf als vollständige Releasequalifikation umbenannt werden.
Das Repository enthält gezielte Tests für Jobeigentum, Ereignisse, Artefaktzulassung und quellverwaltete Scannerkontrollen. Ihre Existenz dient als Orientierung, nicht als Behauptung, sie seien für eine neue Änderung ausgeführt worden.
Folge Beitragsanleitung, Entwicklungsprüfungen und Releasegrenzen. Erfasse genaue Quellen und geprüfte Eingaben, beobachtetes Ergebnis und verbleibende Lücken.