Elysia Tools
Navigation mobile
Workflow Playbook
Figez l’inventaire d’une version Node.js, examinez un SBOM externe selon une politique approuvée et livrez les écarts, exceptions et preuves de validation.
Dossiers
Ce parcours aide les responsables Node.js à constituer un dossier de revue avant une publication précise. Réunissez l’artefact exact, la révision source, package.json, le verrouillage et le SBOM produit à l’extérieur. Consignez générateur, paramètres et inclusion éventuelle des dépendances de développement. Calculez une empreinte de chaque original et documentez le lien avec la compilation. Le verrouillage décrit une résolution ; regroupement, exclusions et dépendances optionnelles ou propres à une plateforme peuvent modifier le contenu livré. Sans lien vérifiable, la couverture reste incomplète.
Vérifiez l’autorisation avant d’envoyer des noms privés ou adresses internes. N’incluez jamais de jeton de registre. Les copies expurgées ont leurs propres empreintes et une correspondance contrôlée avec les originaux. Ce parcours n’installe rien, ne génère pas de SBOM, n’inspecte pas l’archive finale et ne recherche pas de vulnérabilités.
L’auditeur examine package.json et peut construire un arbre depuis package-lock.json de npm ou yarn.lock de Yarn v1. Un verrouillage pnpm ou Bun demande un lecteur externe. Le convertir pour satisfaire le formulaire ne prouve pas une couverture identique. Sans verrouillage exploitable, les résultats concernent les déclarations uniquement. Conservez origine, profondeur maximale et avertissements : un arbre vide après une erreur n’est pas une preuve d’absence de dépendances.
Ainsi, ^2.4.0 est une plage déclarée et 2.4.3 une version concrète. Réservez SemVer à cette dernière et documentez séparément références Git, espaces de travail et étiquettes. Le validateur JSON nécessite un schéma correspondant et un dialecte pris en charge. Une structure valide ne prouve ni exhaustivité ni exactitude des licences. L’auditeur de politique accepte SPDX 2.3 JSON et CycloneDX 1.5 JSON/XML. Les branches de validation et comparaison JSON ne couvrent pas XML : conservez-le et prévoyez les contrôles externes adaptés.
Enregistrez les réglages réels : profil, tolérance copyleft, listes d’autorisation et d’interdiction, traitement des licences inconnues. Un simple nom de profil peut devenir ambigu avec une nouvelle version. Gardez le rapport Markdown ou SARIF. Si les deux sont nécessaires, exécutez chaque format avec les mêmes entrées et réglages. Conservez l’expression de licence entière, y compris AND, OR et WITH, et faites examiner les textes et obligations applicables. Un fragment permissif ne représente pas toute l’expression.
Examinez chaque composant signalé et son chemin lorsqu’il existe. L’absence de chemin peut révéler un SBOM sans relations suffisantes, pas un composant sans effet. Comparez les JSON avec la référence approuvée, puis rapprochez identité, version et licence manuellement. Ordre des tableaux, identifiants générés et horodatages peuvent brouiller les différences ; l’outil n’assure pas un rapprochement sémantique des paquets. Expliquez ajouts, retraits et changements inattendus. Toute exception doit comporter responsable, justification, publication concernée, périmètre et échéance.
Tenez un registre Markdown distinct : identité de publication, empreintes artefact et SBOM, révision de politique, composant, version, expression exacte, chemin ou absence, preuve, décision et responsable. Il s’agit de champs recommandés, pas de données toutes promises par le rapport. Une pièce manquante reste en attente ou bloquante. Relancez les contrôles après modification d’entrée ou de politique et conservez les rapports précédents.
Le contrôle Markdown améliore la lisibilité, pas la justesse juridique. Pour un PDF facultatif, vérifiez tableaux, avertissements, identifiants et chemins longs ; gardez la source intégrale si la pagination masque une preuve. Archivez rapports bruts, fichiers locaux et empreintes finales : un lien temporaire ne constitue pas une archive. SARIF seul ne configure aucune barrière CI. Le parcours conteneur traite Dockerfile et environnement, celui des différences élargit les comparaisons et celui des signatures sert à vérifier l’auteur lorsque l’égalité des octets ne suffit pas.
Guide de workflow
Enregistrez empreintes, révision source et paramètres du générateur SBOM. Séparez dépendances déclarées et contenu réellement livré.
Auditez manifeste et verrouillage compatible, vérifiez les versions résolues puis le schéma JSON fourni. Conservez les avertissements et limites de lecture.
Analysez le SBOM externe avec les réglages enregistrés. Gardez Markdown ou SARIF et examinez expressions complètes, licences inconnues et chemins manquants.
Comparez les JSON actuel et approuvé, puis rapprochez manuellement les composants malgré le bruit des tableaux. Relancez après correction et datez les exceptions avec responsable et périmètre.
L’arbre facultatif lit package-lock.json de npm et yarn.lock de Yarn v1. Pour pnpm ou Bun, utilisez un lecteur externe et consignez la couverture manquante ; un arbre vide après erreur ne signifie pas absence de dépendances.
Validez le JSON avec votre schéma compatible puis comparez-le. L’auditeur accepte aussi le CycloneDX XML pris en charge ; sa validation et sa comparaison nécessitent une autre méthode, pas une conversion présumée fidèle.
Gardez les licences inconnues, sources manquantes et échecs ouverts jusqu’à revue nominative ou exception délimitée. Un succès automatique ne garantit ni conformité juridique ni absence de vulnérabilités.
Calculateurs, outils numériques, logique de dates, statistiques et finance
Contrôlez le registre Markdown et le PDF éventuel, notamment tableaux et chemins longs. Calculez les empreintes finales et archivez rapports, avertissements et décision.