Guida alla versione preliminare · 0.1.0

Job persistenti e pubblicazione delle evidenze

Comprendi proprietà dei lease, validazione dei risultati, commit prima dell’acknowledgement e revisioni dei rilievi.

Il riferimento API è in inglese.

Il database è responsabile del lavoro accettato. Una pagina può ricaricarsi, un editor disconnettersi e un worker perdere il lease senza rendere il browser il registro dell’accaduto. Stato persistente del job, trasporto dello scanner ed evidenze pubblicate restano separati.

Identifica un comando prima di eseguirlo

Il repository dei job lega una chiave d’idempotenza a client e tipo di job. Ripetere lo stesso comando restituisce quello esistente; riusare l’identità per un altro genera conflitto. Il job ha anche identità stabile di esecuzione esterna, documenti limitati di payload e checkpoint e una revisione.

Gli stati sono queued, leased, running, cancelling, completed, failed e cancelled. Un invio riuscito significa lavoro accettato, non scanner eseguito o evidenza completa.

claim_next_job richiede PostgreSQL. Blocca righe idonee senza attendere quella scelta da un altro worker e gestisce lease scaduti e candidati al recupero. Le modifiche verificano sotto lock ID, worker, tentativo, stato ammesso e lease valido. Gli heartbeat rinnovano quella proprietà esatta. Un ex proprietario non può completare un job perché ne possedeva prima il lease.

Un errore ritentabile riporta il job in coda solo entro limiti di tentativi e budget. Ritentare non estende indefinitamente la preparazione. Consulta repository e modello dei job.

Pubblica evidenze prima di consentire la pulizia

Lo scanner sigilla un risultato normalizzato ed espone manifest e pagine limitate. Il worker non scambia la disponibilità per pubblicazione persistente.

1. Valida il manifest e lega esecuzione, digest di richiesta e risultato, digest del manifest artefatti e provenienza nel checkpoint persistente.
2. Avvia una transazione PostgreSQL, blocca la scansione padre e rifiuta la pubblicazione se contiene già rilievi o indici di artefatti. Recupera ogni pagina limitata e valida identità, cursore, ordinali, conteggi dei byte, hash, valori canonici, ordine e fingerprint unici. Oscura i dati sensibili e inserisci i rilievi ammessi di quella pagina senza eseguire il commit.
3. Confronta lo stream completo e il riepilogo con il manifest. Ammetti gli artefatti attestati esatti, aggiorna le revisioni e registra scanner_persisted=true nella stessa transazione.
4. Accerta il commit prima di inviare ACK per l’esatto legame di esecuzione, richiesta e risultato.
5. Lascia che lo scanner rimuova il risultato temporaneo, poi continua la finalizzazione di scansione e gate. Un risultato persistente con pulizia da riconciliare resta distinto da evidenza non pubblicata.

È un confine di inserimento unico. Un nuovo tentativo deve recuperare il checkpoint confermato, non sostituire rilievi cancellando la revisione dell’operatore. Il codice rifiuta conflitti con scan_evidence_conflict. La transazione di persistenza governa la regola.

Se la transazione viene annullata, le inserzioni parziali non diventano autorevoli. Se l’esito è incerto, il worker riconcilia lo stato persistente prima della pulizia. Dopo la persistenza di scanner_persisted=true, il recupero è solo ACK e non rilegge e reinserisce la raccolta. Un 404 scanner può valere come già pulito solo in questo recupero già persistito. Il recupero dell’acknowledgement delimita l’eccezione.

Limita il trasporto temporaneo separatamente dallo storage

Lo spool temporaneo è tmpfs privato, non archivio persistente, artefatto scaricabile o backup. Risultati senza ACK non sono espulsi solo per liberare uno slot finale; la pressione di capacità può rifiutare nuovo lavoro. Il limite temporale vale comunque. Riavviare perde registro locale e segreto dei cursori e rimuove file vecchi riconosciuti dello spool.

I cursori legano processo, esecuzione, richiesta, risultato e posizione successiva. Non si riusano per un altro risultato. Il registro delle esecuzioni implementa il trasporto temporaneo.

Conserva evidenze utili senza pubblicare report grezzi

I rilievi conservano identità normalizzata di scanner e regola, gravità, posizione, messaggio, snippet, fingerprint e metadati limitati. I dati sensibili vengono oscurati prima della pubblicazione e dell’inserimento nel database. L’oscuramento riconosce pattern e strutture sensibili note; non garantisce la rimozione di ogni possibile segreto.

Il confine degli artefatti ammette SBOM Syft CycloneDX JSON sanitizzati e limitati. Valida il percorso dedicato senza seguire link, lega provenienza da grezzo a sanitizzato e indicizza l’identità risultante. Il download controlla dimensioni e digest contro l’indice e copia byte verificati in storage di risposta limitato. Stdout, stderr, SARIF, JSONV2 e JSONL grezzi non sono artefatti pubblicati.

Leggi oscuramento dei dati sensibili dello scanner e ammissione e download artefatti. Riducono l’esposizione; non rendono sicura l’esecuzione di codice ostile arbitrario.

Continua il ciclo di vita dopo la pubblicazione

I nuovi rilievi iniziano open, non soppressi né esenti dal gate, a revisione uno. Le sette decisioni sono open, needs_review, gate_exempt, accepted_risk, ignore, false_positive e fixed. Sono stati selezionabili, non un flusso lineare obbligatorio.

open e needs_review partecipano ai conteggi. gate_exempt e accepted_risk restano non soppressi ma non contano per il gate. ignore, false_positive e fixed sopprimono il rilievo. Le cinque esclusioni richiedono un motivo non vuoto. Ogni modifica verifica la revisione attesa, aggiorna metadati di revisione e rinnova riepilogo e valutazione del gate.

Marcare fixed non esamina un file modificato. Una nuova scansione produce nuova evidenza e apre i suoi rilievi. Scanner e fingerprint coincidenti tra scansioni del progetto supportano la cronologia delle occorrenze, senza ereditare decisioni vecchie. Eliminare rimuove la riga ed è un’azione separata con controlli di revisione e job attivi.

Pagine e dettagli sono legati alle revisioni della raccolta per evitare sovrascritture silenziose da viste obsolete. I campi Advisor sono distinti dal ciclo di vita. Il consiglio non sopprime, accetta rischio o cambia il gate automaticamente. Consulta modifica del ciclo di vita e flusso dei rilievi.

Tratta annullamento e recupero come esiti osservabili

La richiesta d’annullamento viene persistita e può vincere la corsa con il completamento. Gli esiti finali restano finali. Le operazioni cache rifiutano l’annullamento durante commit o attivazione, oltre il confine protetto. Annullare non ritira generazioni attivate o dati Advisor consegnati.

Job completato, scansione completa e gate superato sono risultati diversi. Solo evidenze complete raggiungono la valutazione normale; le decisioni non riparano copertura mancante. L’implementazione del gate conserva la distinzione.

I job persistenti permettono la riconciliazione dopo interruzioni. Non stabiliscono qualifica completa di recupero da crash o disastri. L’helper backup attuale è sperimentale, non atomico e disabilitato senza consenso esplicito per test sacrificabili. Segui la guida al recupero e conserva identità esatte nel valutare un errore.