Guide de la version préliminaire · 0.1.0
Exécution et préparation des analyseurs
Suivez outils figés, couverture des sources et générations validées jusqu’aux constats normalisés.
La référence de l’API est en anglais.
Une analyse combine vue autorisée des sources, outils activés, données validées et résultat explicite de couverture. Le catalogue est organisé dans les sources. Il ne découvre pas d’exécutables arbitraires, ne télécharge pas une base manquante pendant l’analyse et ne promet pas la dernière version amont.
Admettre la couverture demandée avant le démarrage
L’API vérifie la révision actuelle des prérequis lors de la création. Une analyse complète est refusée avant création d’analyse ou de job si un outil activé est bloqué. Une analyse limitée explicitement confirmée exige au moins un outil activé prêt. Elle enregistre omissions et raisons, reste partielle et ne peut réussir le contrôle.
Les analyses par défaut n’utilisent pas d’IA. Une passe Advisor demandée pour toute l’analyse utilise le parcours fournisseur local séparément autorisé ; elle ne change pas les vérifications des analyseurs. Voir Advisor.
incremental_diff exécute actuellement tous les outils activés sur la vue complète. Le résumé enregistre effective_mode=full, aucun compte de fichiers modifiés et incremental-diff-fallback-full. L’implémentation ne revendique pas un résultat incrémental d’outils sans contrat complet commun sur les fichiers modifiés. Admission et repli d’exécution définissent ces choix.
Suivre l’exécution native
- Choisir et autoriser les sources
Gardez explicite le périmètre dépôt, fichier ou dossier. POSIX et Remote WSL utilisent des montages précis en lecture seule ; Windows natif pris en charge utilise des instantanés scellés bornés.
- Examiner les prérequis
Lisez disponibilité, fraîcheur et périmètre prévu avant admission.
- Admettre une commande d’analyse
L’API vérifie droits et sémantique, puis conserve les identités de commande et de job.
- Analyser les sources admises
Le worker invoque l’analyseur avec des données hors ligne validées. incremental_diff revient actuellement à une analyse de toute la vue source.
- Collecter des résultats bornés
Les adaptateurs normalisent et expurgent les motifs sensibles connus. Le worker valide les pages avant conservation.
- Lire la couverture puis le contrôle
Seuls les éléments complets applicables atteignent la décision de politique. Une analyse terminée peut encore échouer à cause de constats bloquants.
Les outils s’exécutent séquentiellement dans des groupes de processus maîtrisés avec des limites finies. Syft précède Grype, qui lit la SBOM expurgée de la même analyse. Activer Grype sans Syft produit des éléments incomplets.
Chaque adaptateur fournit configuration maîtrisée, environnement restreint et chemins temporaires privés si nécessaire. La sortie native parsée est vérifiée avant normalisation. Sortie obligatoire absente, enregistrements mal formés, emplacements invalides ou erreurs d’analyse ne deviennent pas silencieusement un résultat propre. L’adaptateur retire les rapports bruts après traitement ; SARIF, JSONV2, JSONL et stderr bruts ne sont pas téléchargeables.
La matrice décrit le contrat figé. Les fragments expliquent l’adaptateur ; ce ne sont pas des commandes autonomes reproduisant autorisation, validation des données et limites de ressources de CodeSecurity.
| Outil et sources | Version | Exécution réelle et entrée | Sortie native et préparation |
|---|---|---|---|
| Trivy | 0.73.0 |
fs examine vulnérabilités, secrets et mauvaises configurations. Une seconde passe rootfs limitée aux bibliothèques couvre les dépendances empaquetées, dont les archives Java. Configuration et fichiers d’exclusion maîtrisés ; mises à jour, télémétrie et vérification de version désactivées. |
SARIF des deux passes ; bases Trivy et Java et contrôles validés. |
| Gitleaks | 8.30.1 |
dir analyse les sources capturées avec configuration maîtrisée des règles par défaut. Les suppressions gitleaks:allow sont ignorées ; un .gitleaksignore à la racine entraîne un refus. |
SARIF ; binaire figé et détecteurs natifs. Analyse de répertoire, pas mode historique Git de Gitleaks. |
| OpenGrep | 1.27.0 |
scan utilise l’entrée rules.yml examinée et validée. Le noyau natif est dans l’image ; vérifications de version et métriques désactivées. |
SARIF ; génération de règles examinées vérifiée requise. |
| Bearer | 2.1.0+lomo.1 |
scan utilise configuration maîtrisée et répertoire externe de règles examinées ; règles par défaut, contrôle de version et télémétrie désactivés. |
JSONV2 ; règles Bearer vérifiées et identité du build modifié. Les erreurs rendent les éléments incomplets. |
| Grype | 0.117.0 |
sbom: lit la sortie Syft expurgée de cette analyse sans recapturer le dépôt. Mises à jour automatiques de l’application et de la base désactivées. |
SARIF ; base Grype vérifiée et dépendance Syft de la même analyse. |
| Checkov | 3.3.10 |
Analyse de répertoire avec frameworks Kubernetes, Dockerfile et Terraform, configuration maîtrisée, téléchargements désactivés et signalement soft-fail. .checkov.yaml ou .checkov.yml à la racine entraîne un refus. |
SARIF ; entrées d’image figées. L’argument de répertoire joint évite la découverte de configuration cible de cette version. |
| TruffleHog | 3.96.0 |
filesystem utilise --no-update --no-verification. Les secrets détectés ne sont pas testés auprès de fournisseurs externes. |
JSONL ; binaire figé et détecteurs natifs. |
| Syft | 1.51.0 |
dir: inventorie les sources capturées ; contrôle de mise à jour de l’application désactivé. |
CycloneDX JSON, expurgé avant Grype et publication comme SBOM admise. |
Le registre, les branches réelles des adaptateurs et le verrou donnent tous les arguments et identités. Les contrôles facultatifs secrets-lite, sast-lite et iac-lite commencent désactivés avec une couverture explicitement limitée.
Tenir compte des limites de sources et de parsing
La capture admet au plus 5 000 fichiers, 8 MiB par fichier ordinaire et 64 MiB au total. L’analyse du texte admissible a une borne séparée de 1 MiB par fichier. Capturer un grand fichier de code ne signifie pas l’analyser entièrement.
Le reçu de couverture enregistre fichiers admissibles et omissions : dépassement de nombre, taille excessive, binaire ou UTF-8 invalide, fichiers illisibles et types non pris en charge. Le traitement des rapports natifs accepte au plus 64 MiB. Stdout et stderr partagent un stockage temporaire de conteneur borné, sans limites de streaming individuelles à ce jour.
Les constats normalisés portent analyseur, règle, gravité, emplacement, message, extrait, empreinte et métadonnées bornées. Les doublons exacts peuvent être fusionnés ; deux constats canoniques différents avec la même empreinte sont refusés. L’ordre est déterministe avant transport. Le résumé conserve erreurs d’outils, couverture, modes demandé/effectif et identité des données.
Des éléments complets signifient traitement des entrées admissibles et rapports pris en charge sans omission déclarée. Cela ne couvre pas chaque construction de langage, dépendance ou faiblesse, et ne prouve pas l’exploitabilité d’une API risquée. Une analyse sans constat peut rester partielle ; une analyse complète peut échouer à la politique. Couverture et canonicalisation alimentent la frontière de publication.
Préparer les données hors exécution sur les sources
- Lire préparation et fraîcheur
Observations du catalogue, données installées, santé et expiration décrivent des choses différentes.
- Récupérer les composants examinés
Le service sans accès aux sources télécharge seulement les composants sélectionnés et examinés.
- Préparer et valider
Identité et contenu sont vérifiés avant sélection de la génération candidate.
- Choisir une génération complète
L’activation sélectionne les données validées. Observation périmée ou publication interrompue exigent réconciliation.
- Analyser avec des données en lecture seule
Les analyseurs lisent la génération active. Des définitions fournies expirées exigent des sources examinées renouvelées et une préparation.
Le service séparé de mise à jour accède au réseau des sources examinées et écrit le cache, sans montage de projet. Il prépare un candidat privé, valide identités verrouillées et contenu, scelle une génération complète puis la sélectionne atomiquement. Un répertoire partiellement téléchargé n’est pas une génération active.
À l’exécution, l’analyseur détermine disponibilité et chemins depuis une seule génération validée. Il ne doit pas approuver les outils contre une révision de pointeur puis lire une autre. Vérifications active et précédente sont séparées : une précédente génération invalide peut bloquer le rollback sans invalider l’active vérifiée.
| Entrée de disponibilité | Règle de fraîcheur de cette révision |
|---|---|
| Bases Trivy OS et Java | UpdatedAt de l’éditeur ; avertissement après sept jours, expiration après quatorze. |
| Base Grype | Horodatage intrinsèque verrouillé du build ; avertissement après sept jours, expiration après quatorze. |
| Contrôles Trivy | Horodatage d’acquisition vérifié ; avertissement après sept jours, expiration après quatorze. |
| Règles OpenGrep et Bearer examinées | Identité examinée immuable, sans expiration temporelle inventée. |
Recompiler des verrous inchangés ou retélécharger la même base ne renouvelle pas un horodatage intrinsèque. Les données sous avertissement restent utilisables mais peuvent omettre des vulnérabilités récentes. L’expiration exige une mise à jour examinée des sources/verrous. Le rollback vérifie aussi identité, compatibilité et fraîcheur ; annuler ne défait pas une génération déjà activée.
Santé du service, téléchargement terminé et Ready to Scan sont des résultats distincts. Drapeaux hors ligne et topologie réseau exigent aussi une vérification réelle des sorties réseau de l’image avant toute affirmation sur un build. Voir activation, vérification d’exécution et préparation opérateur.
Conserver les licences amont avec les outils
La table reprend les identifiants du verrou examiné et les textes amont figés. C’est un inventaire de sources, pas une revue complète des licences de redistribution ou de dépendances.
| Outil | Licence enregistrée et texte amont |
|---|---|
| Trivy | Apache-2.0 |
| Gitleaks | MIT |
| OpenGrep | LGPL-2.1-or-later dans le verrou |
| Bearer | Elastic-2.0 |
| Grype | Apache-2.0 |
| Checkov | Apache-2.0 |
| TruffleHog | AGPL-3.0-or-later |
| Syft | Apache-2.0 |
La licence Apache-2.0 de Lomo ne remplace pas ces conditions. L’index des licences conserve une distinction non résolue entre l’expression du verrou OpenGrep et son texte COPYRIGHT. Bearer comprend une notice de modification ainsi que recette source et correctif ; il n’est pas interchangeable avec un binaire amont non modifié. Examinez notices, modifications, dépendances embarquées, règles et données pour la distribution prévue.