Anleitung zur Quellcode-Vorschau · 0.1.0

Das Scan-Gate eines Projekts lesen und konfigurieren

Trenne abgeschlossene Analyse und Richtlinienentscheidung und ändere die vorgesehenen Projektschwellen ohne Quellzugriff oder Push-Schutz zu verändern.

Die API-Referenz ist auf Englisch.

Lies die Abdeckung vor der Gate-Entscheidung

Ein Scan berichtet, was während der Analyse geschah. Sein Gate bewertet, ob die anwendbaren Nachweise der Projektrichtlinie entsprechen. Lies beides in der Findings-Übersicht.

Anzeige Bedeutung für den nächsten Schritt
Vollständige Analyse und bestandenes Gate Der Scan erfüllt die aktive Richtlinie für aufgezeichneten Umfang und Nachweise. Prüfe, ob Quelle und Umfang beabsichtigt sind.
Vollständige Analyse und gescheitertes Gate Die Analyse ist fertig, aber mindestens eine Richtlinienbedingung scheitert. Prüfe Gründe und relevante Befunde.
Teilweise, fehlgeschlagene oder abgebrochene Analyse Nützliche Befunde können bestehen bleiben; fehlende Analyse wird jedoch kein vollständiger bestandener Nachweis. Behebe die Abdeckungslücke und scanne erneut.
Nicht konfiguriertes oder deaktiviertes Gate Keine aktive Projektrichtlinie belegt ein Bestehen. Damit lässt sich kein geschützter Push autorisieren.

Eine leere Befundliste reicht für keine dieser Schlussfolgerungen. Filter können Berichte verbergen, ein Scanner kann gescheitert sein oder der ausgewählte Scan kann nur eine Datei abdecken. Übersicht und Gate-Gründe erhalten diese Unterschiede.

Abgeschlossener Scan mit gescheitertem Gate, aktiven Befunden und getrenntem Schutzstatus.

Scanabschluss, Gate-Entscheidung und installierter Schutz sind getrennte Zustände. Prüfe die Befunde zum Verständnis des gescheiterten Gates.

Vollständiges Bild öffnen

Konfiguriere nur das vorgesehene Projekt

Öffne Projects, wähle das Projekt und suche Repository scan gate. Prüfe den Namen vor dem Bearbeiten. Das Formular bietet vier Einstellungen:

  • Evaluate this project’s gate aktiviert oder deaktiviert die Richtlinienbewertung dieses Projekts.
  • Maximum critical findings legt die erlaubte Zahl gezählter kritischer Berichte fest.
  • Maximum high findings legt die erlaubte Zahl gezählter hoher Berichte fest.
  • Block secrets in this project ergänzt die Bedingung für Geheimnisberichte.

Ein Maximum von 0 erlaubt keinen gezählten Befund dieses Schweregrads. 2 erlaubt zwei und scheitert bei einer höheren Zahl. -1 lässt den Schweregrad unbegrenzt. Das Formular akzeptiert Schwellenwerte bis 999.

Wähle Werte entsprechend der Prüfrichtlinie des Projekts und dann Save project gate. Speichern berechnet bestehende Scan-Gates dieses Projekts neu. Es ändert keine andere Projektrichtlinie, scannt keine Quellen, autorisiert kein Verzeichnis, bereitet keine Scannerdaten vor und installiert keinen Git-Hook.

Die Geheimnisbedingung gilt für Berichte, die durch Abgleich von Scanner, Regel und Meldung erkannt werden. Sie behauptet keine Erkennung jedes möglichen Geheimnisses. Prüfe die zugrunde liegenden Berichte bei einer verletzten Bedingung.

Trenne Entwurf und gespeicherte Richtlinie

Reset draft stellt die zuletzt geladenen gespeicherten Formularwerte wieder her. Reload policy liest die aktuelle Serverrichtlinie und erhält ungespeicherte Änderungen zum Vergleich und zur Prüfung. Beim Projektwechsel bleiben die Formulare ihrem jeweiligen Projekt zugeordnet.

Meldet das Speichern einen Konflikt oder kann die aktuelle Richtlinie nicht gelesen werden, lade neu und gleiche ab. Ein fehlgeschlagener Abruf ist keine leere Richtlinie. Prüfe bei unklarem Speicherergebnis zuerst den gespeicherten Zustand, bevor du erneut änderst.

Verstehe die Zählung

Das Gate zählt aktive Befunde, die weder unterdrückt noch ausgenommen sind. Open und Needs review bleiben gemäß Richtlinie zählbar. Non-blocking for gate und Accepted risk erhalten einen aktiven Bericht mit Gate-Ausnahme. Ignore, False positive und Fixed schließen ihn aus aktiven Gate-Zählungen aus.

Das sind begründete Prüfentscheidungen, beschrieben in der Lebenszyklusanleitung. Fixed verifiziert keine Quellreparatur. Ein neuer Scan liefert Nachweise über geänderten Code.

Geänderte Bewertungen können einen abgeschlossenen Scan die Richtlinie erfüllen lassen. Sie ergänzen keine fehlenden Scannernachweise in einem teilweisen oder fehlgeschlagenen Scan. Modellantwort und Konfidenz von Advisor gelten ebenfalls nicht als Richtlinienentscheidung.

Verbinde das Gate mit Push-Schutz

Ein Projekt-Gate blockiert Git nicht allein. Push-Schutz benötigt eine separate klonspezifische Freigabe und die ausdrückliche Anwendung des lokalen Hooks in VS Code.

Für einen Push mit Quellbäumen prüft der Schutz aktuelle, vollständige und bestandene Nachweise zur genauen ausgehenden Historie. Ein bestandener Dateiscan, früherer Arbeitsbereichsscan oder anderer Ref ersetzt sie nicht. Änderungen an Richtlinie, Bewertungen, Scannernachweisen oder ausgehenden Refs können eine neue Prüfung erfordern.

Ein reiner Lösch- oder No-op-Plan enthält keinen zu scannenden Quellbaum; Repository-Freigabe und aktuelle Richtlinie gelten dennoch. Der Schutzablauf behandelt diesen Fall getrennt von Pushes mit Quellen.

Lies Gate-Operationen für Projektrichtlinienanfragen, Konfigurationsoperationen für separate Laufzeitfunktionen und Scanarchitektur für den Weg der Nachweise zur Entscheidung.