Anleitung zur Quellcode-Vorschau · 0.1.0
Scannerausführung und Vorbereitung
Verfolge festgelegte Werkzeuge, Quellabdeckung und validierte Datengenerationen bis zu normalisierten Befunden.
Die API-Referenz ist auf Englisch.
Ein Scan verbindet autorisierte Quellansicht, aktivierte Werkzeuge, validierte Scannerdaten und ein ausdrückliches Abdeckungsergebnis. Der Werkzeugkatalog wird im Quellcode gepflegt. Er entdeckt keine beliebigen Programme, lädt keine fehlende Datenbank während eines Scans und verspricht keine aktuelle Upstreamversion.
Lass den angeforderten Umfang vor dem Start zu
Die API prüft bei Scanerstellung die aktuelle Vorprüfungsrevision. Ist ein aktiviertes Werkzeug blockiert, wird ein vollständiger Scan vor Scan- oder Joberstellung abgelehnt. Ein ausdrücklich bestätigter begrenzter Scan benötigt mindestens ein bereites aktiviertes Werkzeug. Er erfasst ausgelassene Werkzeuge samt Gründen, bleibt teilweise und kann das Gate nicht bestehen.
Standardscans verwenden keine KI. Ein angeforderter scanweiter Advisor-Durchlauf nutzt den separat autorisierten lokalen Anbieterweg und verändert nicht die Scannerprüfung. Siehe Advisor-Anleitung.
incremental_diff führt derzeit alle aktivierten Scanner gegen die vollständige Quellansicht aus. Die Übersicht speichert effective_mode=full, keine Anzahl geänderter Dateien und incremental-diff-fallback-full. Die Implementierung behauptet kein inkrementelles Ergebnis von Werkzeugen ohne gemeinsamen vollständigen Änderungsdateivertrag. Scanzulassung und Ausführungsersatz definieren diese Entscheidungen.
Verfolge den nativen Ausführungspfad
- Quellen wählen und autorisieren
Halte Repository-, Datei- oder Ordnerumfang ausdrücklich fest. POSIX und Remote WSL nutzen enge schreibgeschützte Mounts; unterstützte native Windows-Pfade verwenden begrenzte versiegelte Momentaufnahmen.
- Scannervorprüfung lesen
Prüfe Bereitschaft, Datenaktualität und vorgesehenen Umfang vor Arbeitszulassung.
- Einen Scanbefehl zulassen
Die API prüft Clientberechtigung und Anfragesemantik und speichert dann Befehls- und Jobidentität.
- Zugelassene Quellen analysieren
Der Worker ruft den Scanner mit validierten Offlinedaten auf. Angefordertes incremental_diff fällt derzeit auf vollständige Quellanalyse zurück.
- Begrenzte Ergebnisse sammeln
Scanneradapter normalisieren und bereinigen bekannte sensible Muster. Der Worker validiert Seiten vor Befundspeicherung.
- Erst Abdeckung, dann Gate lesen
Nur anwendbare vollständige Nachweise erreichen die Richtlinienentscheidung. Ein abgeschlossener Scan kann wegen verbleibender blockierender Befunde scheitern.
Werkzeuge laufen nacheinander in eigenen Prozessgruppen mit endlichen Ausführungsgrenzen. Syft läuft vor Grype; Grype liest die bereinigte SBOM desselben Scans. Grype ohne Syft erzeugt unvollständige Nachweise.
Jeder Adapter liefert bei Bedarf eigene Konfiguration, eingeschränkte Umgebung und private temporäre Pfade. Geparste native Ausgabe wird vor Normalisierung geprüft. Fehlende Pflichtausgabe, fehlerhafte Datensätze, ungültige Orte und Analysefehler dürfen nicht stillschweigend als sauberer Scan gelten. Adapter entfernen Rohberichte nach Verarbeitung; rohe SARIF, JSONV2, JSONL und stderr sind keine Downloadartefakte.
Die Matrix beschreibt den festgelegten Ausführungsvertrag. Befehlsfragmente erklären Adapter und sind keine eigenständigen Befehle, die CodeSecurity-Autorisierung, Datenprüfung und Ressourcenkontrollen reproduzieren.
| Werkzeug und Quelle | Version | Tatsächliche Ausführung und Eingabe | Native Ausgabe und Vorbereitung |
|---|---|---|---|
| Trivy | 0.73.0 |
fs prüft Schwachstellen, Geheimnisse und Fehlkonfiguration. Ein zweiter bibliotheksbezogener rootfs-Durchlauf deckt paketierte Abhängigkeiten einschließlich Java-Archiven ab. Eigene Konfiguration und Ignore-Dateien; Updates, Telemetrie und Versionsprüfungen aus. |
SARIF aus beiden Durchläufen; validierte Trivy-Datenbank, Java-Datenbank und Checks. |
| Gitleaks | 8.30.1 |
dir scannt erfasste Quellen mit eigener Standardregelkonfiguration. Inline-gitleaks:allow wird ignoriert; .gitleaksignore im Wurzelverzeichnis führt zur Ablehnung. |
SARIF; festgelegte Binärdatei und native Erkennungsregeln. Verzeichnisscan, kein Gitleaks-Git-Historienmodus. |
| OpenGrep | 1.27.0 |
scan verwendet den validierten geprüften Einstieg rules.yml. Der native Kern ist im Image; Versionsprüfungen und Metriken sind deaktiviert. |
SARIF; verifizierte geprüfte Regelgeneration erforderlich. |
| Bearer | 2.1.0+lomo.1 |
scan nutzt eigene Konfiguration und externes geprüftes Regelverzeichnis; Standardregeln, Versionsprüfung und Telemetrie sind aus. |
JSONV2; geprüfte Bearer-Regeln und Buildidentität der veränderten Binärdatei. Analysefehler machen Nachweise unvollständig. |
| Grype | 0.117.0 |
sbom: liest die bereinigte Syft-Ausgabe dieses Scans und erfasst das Repository nicht erneut. Automatische Anwendungs- und Datenbankupdates sind aus. |
SARIF; geprüfte Grype-Datenbank und Syft-Abhängigkeit desselben Scans. |
| Checkov | 3.3.10 |
Verzeichnisscan mit Kubernetes-, Dockerfile- und Terraform-Frameworks, eigener Konfiguration, deaktivierten Downloads und Soft-Fail-Berichten. .checkov.yaml oder .checkov.yml in der Wurzel führt zur Ablehnung. |
SARIF; festgelegte Image-Eingaben. Das verbundene Verzeichnisargument vermeidet den Zielkonfigurations-Erkennungspfad dieser Version. |
| TruffleHog | 3.96.0 |
filesystem nutzt --no-update --no-verification. Erkannte Zugangsdaten werden nicht bei externen Anbietern getestet. |
JSONL; festgelegte Binärdatei und native Detektoren. |
| Syft | 1.51.0 |
dir: inventarisiert erfasste Quellen; Anwendungsupdateprüfung aus. |
CycloneDX JSON, bereinigt vor Grype-Nutzung und Veröffentlichung als zugelassene SBOM. |
Werkzeugregister, tatsächliche Adapterzweige und Tool-Lock liefern vollständige Argumente und Identitäten. Optionale secrets-lite, sast-lite und iac-lite beginnen deaktiviert und haben ausdrücklich begrenzte Abdeckung.
Berücksichtige Quell- und Parsergrenzen
Quellerfassung erlaubt höchstens 5.000 Dateien, 8 MiB je regulärer Datei und 64 MiB Quellinhalt insgesamt. Geeignete Textanalyse hat eine separate Dateigrenze von 1 MiB. Erfassung einer großen Codedatei bedeutet keine vollständige Analyse.
Der Quellabdeckungsbeleg erfasst geeignete Dateien und Auslassungen wie Anzahlüberschreitung, übergroße Inhalte, binäre oder ungültige UTF-8-Eingaben, unlesbare Dateien und nicht unterstützte Typen. Native Berichtsverarbeitung hat eine Eingabegrenze von 64 MiB. Stdout und stderr teilen begrenzten temporären Containerspeicher, haben aber noch keine eigenen Streaminglimits.
Normalisierte Befunde enthalten Scanner, Regel, Schweregrad, Quellort, Meldung, Ausschnitt, Fingerprint und begrenzte Metadaten. Genaue Duplikate können zusammengeführt werden; unterschiedliche kanonische Befunde mit gleichem Fingerprint werden abgelehnt. Befunde werden vor Transport deterministisch sortiert. Die Übersicht erhält Werkzeugfehler, Quellabdeckung, angeforderten/wirksamen Modus und Scannerdatenidentität.
Vollständige Nachweise bedeuten Verarbeitung geeigneter Eingaben und unterstützter nativer Berichte ohne gemeldete Auslassungen. Nicht jede Sprachkonstruktion, Abhängigkeit oder Schwäche ist damit abgedeckt; eine gemeldete riskante API muss nicht ausnutzbar sein. Ein befundfreier Scan kann teilweise bleiben, ein vollständiger an Richtlinien scheitern. Abdeckung und Kanonisierung speisen die Nachweisveröffentlichungsgrenze.
Bereite Daten außerhalb der Quellausführung vor
Der separate Updater hat Netzwerkzugriff auf geprüfte Datenquellen und beschreibbaren Cache, aber keinen Projektquellmount. Er stellt einen Kandidaten privat bereit, validiert festgelegte Identitäten und Inhalte, versiegelt eine vollständige Generation und wählt sie atomar aus. Ein teilweise heruntergeladenes Verzeichnis ist keine aktive Cache-Generation.
- Vorbereitung und Aktualität lesen
Katalogbeobachtungen, installierte Daten, Scannergesundheit und Ablauf beschreiben unterschiedliche Dinge.
- Geprüfte Komponenten abrufen
Der Updater ohne Quellzugriff lädt nur ausgewählte geprüfte Datenkomponenten herunter.
- Bereitstellen und validieren
Komponentenidentität und Inhalt werden geprüft, bevor die Kandidatengeneration wählbar ist.
- Vollständige Generation auswählen
Aktivierung schaltet auf validierte Daten um. Veraltete Beobachtungen oder unterbrochene Veröffentlichung müssen abgeglichen werden.
- Mit schreibgeschützten Daten scannen
Laufzeitscanner lesen die aktive Generation. Abgelaufene gebündelte Definitionen verlangen aktualisierte geprüfte Quellen und Vorbereitung.
Zur Laufzeit bestimmt der Scanner Bereitschaft und Komponentenpfade aus einer validierten Generation. Er darf Werkzeuge nicht gegen eine Zeigerrevision genehmigen und Daten einer anderen lesen. Aktive und vorherige Generationsprüfung sind getrennt: Eine schlechte Vorgängergeneration kann Rollback blockieren, ohne die geprüfte aktive Generation ungültig zu machen.
| Bereitschaftseingabe | Aktualitätsregel dieser Revision |
|---|---|
| Trivy-OS- und Java-Datenbanken | UpdatedAt des Herausgebers; Warnung nach sieben Tagen, Ablauf nach vierzehn. |
| Grype-Datenbank | Festgelegter intrinsischer Buildzeitstempel; Warnung nach sieben Tagen, Ablauf nach vierzehn. |
| Trivy-Checks | Verifizierter Erwerbszeitstempel; Warnung nach sieben Tagen, Ablauf nach vierzehn. |
| Geprüfte OpenGrep- und Bearer-Regeln | Unveränderliche geprüfte Identität ohne erfundenen Zeitablauf. |
Unveränderte Locks neu zu bauen oder dieselbe Datenbank erneut herunterzuladen erneuert keinen intrinsischen Zeitstempel. Daten mit Warnung bleiben nutzbar, können aber neuere Schwachstellen auslassen. Abgelaufene Daten brauchen ein geprüftes Quell-/Lockupdate. Rollback prüft ebenfalls Identität, Kompatibilität und Aktualität; Abbruch macht bereits aktivierte Generationen nicht rückgängig.
Dienstgesundheit, abgeschlossener Download und Ready to Scan sind verschiedene Ergebnisse. Quellseitige Offlineflags und Netzwerktopologie benötigen außerdem tatsächliche Image-Ausgangsprüfung vor Aussagen über einen bestimmten Build. Siehe Generationsaktivierung, Laufzeitprüfung und Operatorvorbereitung.
Erhalte Upstreamlizenzen bei den Werkzeugen
Die Tabelle nennt Kennungen im geprüften Lock und verlinkt festgelegte Upstreamtexte. Sie ist ein Quellinventar, keine vollständige Prüfung von Weiterverteilungs- oder Abhängigkeitslizenzen.
| Tool | Erfasste Lizenz und Upstreamtext |
|---|---|
| Trivy | Apache-2.0 |
| Gitleaks | MIT |
| OpenGrep | LGPL-2.1-or-later im Lock |
| Bearer | Elastic-2.0 |
| Grype | Apache-2.0 |
| Checkov | Apache-2.0 |
| TruffleHog | AGPL-3.0-or-later |
| Syft | Apache-2.0 |
Lomos Apache-2.0-Lizenz ersetzt diese Bedingungen nicht. Der Lizenzindex bewahrt einen ungeklärten Unterschied zwischen OpenGreps Lockausdruck und COPYRIGHT-Wortlaut. Bearer enthält Änderungshinweis sowie Quellrezept und Patch; es ist nicht mit einer unveränderten Upstreambinärdatei austauschbar. Prüfe Hinweise, Änderungen, eingebettete Abhängigkeiten, Regeln und Daten für die vorgesehene Verteilung.