Guide de la version préliminaire · 0.1.0

Autoriser les sources et soumettre une analyse

Sélectionnez les sources exactes, préparez les analyseurs activés et distinguez un résultat complet d’une couverture limitée.

La référence de l’API est en anglais.

Donner un périmètre clair à chaque source

Partez du répertoire à examiner. L’ajouter à VS Code ou le choisir comme contexte de dépôt change l’appartenance à l’éditeur, pas les droits de l’analyseur.

Dans Projects, utilisez Authorize another source root si le répertoire sort des racines configurées en lecture seule. Vérifiez le chemin exact, choisissez Copy host command, puis exécutez cette commande depuis les sources du backend. L’outil réservé au propriétaire de l’hôte applique ce périmètre précis en préservant racines existantes et données d’installation. L’API ne possède pas de socket Docker.

Après application sur l’hôte, enregistrez le répertoire avec Add Project. N’autorisez pas /, une collection du répertoire personnel ou un vaste parent commun pour atteindre plusieurs dépôts indépendants. Un choix hors périmètre est refusé avant création d’un projet ou d’une analyse.

POSIX et Remote WSL utilisent des montages autorisés en lecture seule. Les chemins Windows natifs pris en charge utilisent des instantanés scellés et bornés. L’architecture d’analyse décrit ces transports et leurs vérifications communes d’identité des sources.

Lire Scan setup avant de soumettre le travail

Sélectionnez le projet et examinez Scan setup. Ses trois vérifications concernent services essentiels, accès aux sources et données des analyseurs. Chaque prérequis manquant possède une action de récupération. Le formulaire d’analyse normal devient disponible lorsque ces vérifications sont prêtes.

Une réponse de santé réussie établit que le service répond. Elle ne prouve ni le montage des sources choisies, ni la disponibilité de tous les outils activés, ni la couverture complète d’une analyse.

Préparer les analyseurs activés

Ouvrez Tools > Prepare all scanners une fois. Le parcours vérifie le catalogue examiné, télécharge bases ou règles nécessaires via le service de mise à jour sans accès aux sources, puis valide les entrées sélectionnées. Cette préparation ne lit pas les sources des projets.

Les outils externes remplissent des rôles complémentaires :

Lorsque Grype est activé, il dépend de l’inventaire Syft expurgé de la même analyse. Les outils heuristiques internes de repli sont identifiés séparément et ne remplacent pas la couverture des outils externes.

Suivez la préparation dans Jobs. Étape, composant, dernière activité et nombre d’octets décrivent du travail observé. Un indicateur indéterminé n’implique aucun pourcentage caché ni estimation de fin.

Les bases examinées modifiables et les contrôles téléchargés avertissent après sept jours et expirent après quatorze, à partir des horodatages définis dans les sources. Les arbres de règles examinés immuables suivent leur identité verrouillée. Retélécharger la même base expirée ne renouvelle pas son âge intrinsèque. Si Tools exige une mise à jour des sources, obtenez des sources examinées plus récentes, préservez l’installation et préparez à nouveau. Ne modifiez pas les horodatages et ne désactivez pas les contrôles de fraîcheur.

Choisir une couverture complète ou limitée

Complete coverage est le choix normal. L’admission échoue avant création d’une analyse ou d’un job si un analyseur activé n’est pas prêt.

Limited coverage est un repli explicite proposé si au moins un analyseur activé peut fonctionner. Examinez sous-ensemble prêt, outils omis et raisons, puis confirmez cette vérification préalable exacte. Le résultat reste partiel et son contrôle incomplet. Des changements ultérieurs de cycle de vie ne complètent pas la couverture omise.

Un analyseur doit produire une sortie native valide même sans constat. Une sortie absente, mal formée ou non fiable ne devient pas une analyse propre. Examinez avertissements et omissions autant que le nombre de constats.

Choisir le périmètre prévu

Utilisez les commandes du projet dans l’interface web pour une source enregistrée. Dans VS Code :

• Scan Workspace with Lomo CodeSecurity détermine un contexte de dépôt ouvert.
• Scan Workspace Folders… permet de choisir des racines, examiner les chemins exacts et confirmer un lot.
• Le bouton d’espace de travail dans Explorer analyse la racine déterminée ou ouvre le sélecteur multiracine.
• Cliquez droit sur un dossier ou un fichier pris en charge pour son périmètre exact.
• Rescan Exact Finding File confirme et analyse uniquement le fichier du constat.

Enregistrez d’abord les modifications. Les analyseurs lisent le contenu admis du disque ou de l’instantané, pas un tampon non enregistré. Un résultat limité à un fichier ou dossier ne représente pas tout le dépôt. L’arbre Findings indique ces périmètres et propose Open scan history pour les analyses antérieures.

La requête incremental_diff utilise actuellement toute la vue des sources. Les résultats enregistrent effective_mode=full et incremental-diff-fallback-full. Elle n’exécute pas les analyseurs uniquement sur les fichiers modifiés.

Analyser plusieurs dépôts sans fusionner les résultats

Pour plusieurs dépôts sous un parent ouvert, utilisez d’abord Choose repositories in this workspace…. La découverte se limite aux enfants directs ; une navigation explicite permet un dépôt plus profond. Le parent reste ouvert et chaque enfant sélectionné conserve son identité.

Scan Workspace Folders… présente l’autorisation des sources, permet d’omettre des racines et demande une confirmation finale. Chaque racine admise possède son projet, son analyse et son job. Le lot n’a pas de contrôle réussi commun.

Cancel arrête le travail annulable actuel du lot et laisse les racines suivantes non démarrées. Si l’observation d’un job admis devient incertaine, le résultat désigne ce job exact et les racines suivantes ne sont pas soumises. Lisez chaque résultat plutôt que d’interpréter la notification du lot comme un succès unique.

Interpréter le résultat terminal

Ouvrez l’analyse exacte lorsque son job est stabilisé. Vérifiez périmètre, état, couverture, avertissements, analyseurs omis et contrôle avant les constats.

• Une analyse terminée peut échouer au contrôle si des éléments bloquants subsistent.
• Une analyse partielle conserve des constats utiles mais manque d’éléments complets.
• Un travail échoué ou annulé peut conserver des constats enregistrés sans risque et des artefacts publiables.
• Zéro constat n’établit à lui seul aucun de ces états.

Transfert des sources et analyse ont des bornes distinctes. Un instantané admet au plus 5 000 fichiers ordinaires, 8 MiB par fichier transféré et 64 MiB de contenu décodé, avec une limite séparée de 112 MiB pour la requête encodée. L’analyse du code admissible est limitée à 1 MiB par fichier. Capturer un fichier plus grand ne prouve pas son analyse complète. Chemins dangereux, liens non pris en charge et identités modifiées sont refusés.

Poursuivez avec la revue des constats et l’interprétation des contrôles. Les clients API doivent conserver les identités exactes du job et de la commande ; consultez analyses, autorisation des sources et jobs.