Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Collection de dépendances des langages de programmation

Le générateur Amazon Inspector SBOM prend en charge différents langages de programmation et frameworks, qui constituent un ensemble robuste et détaillé de dépendances. La génération d'une SBOM vous aide à comprendre la composition de votre logiciel, afin d'identifier les vulnérabilités et de garantir la conformité aux normes de sécurité. Le générateur SBOM d'Amazon Inspector prend en charge les langages de programmation et formats de fichiers suivants.

Passez à l'analyse des dépendances

go.mod/go.sum

Utilisez go.mod des go.sum fichiers et pour définir et verrouiller les dépendances dans les Go projets. Le générateur Amazon Inspector SBOM gère ces fichiers différemment en fonction de la version de la chaîne Go d'outils.

Exemple de fichier go.mod

Voici un exemple de go.mod fichier.

module example.com/project

go 1.17

require (
github.com/gin-gonic/gin v1.7.2
golang.org/x/crypto v0.0.0-20210616213533-5cf6c0f8e123
)
        

Exemple de fichier go.sum

Voici un exemple de go.sum fichier.

github.com/gin-gonic/gin v1.7.2 h1:VZ7DdRl0sghbA6lVGSkX+UXO2+J0aH7RbsNugG+FA8Q=
github.com/gin-gonic/gin v1.7.2/go.mod h1:ILZ1Ngh2f1pL1ASUj7gGk8lGFeNC8cRTaN2ZhsBNbXU=
golang.org/x/crypto v0.0.0-20210616213533-5cf6c0f8e123 h1:b6rCu+qHze+BUsmC3CZzH8aNu8LzPZTVsNTo64OypSc=
golang.org/x/crypto v0.0.0-20210616213533-5cf6c0f8e123/go.mod h1:K5Dkpb0Q4ewZW/EzWlQphgJcUMBCzoWrLfDOVzpTGVQ=
        

Binaires Go

Le générateur Amazon Inspector SBOM extrait les dépendances Go des fichiers binaires compilés pour garantir le code utilisé.

GOMODCACHE

Le générateur Amazon Inspector SBOM analyse le cache du Go module pour collecter des informations sur les dépendances installées. Ce cache stocke les modules téléchargés pour s'assurer que les mêmes versions sont utilisées dans les différentes versions.

Exemple de structure

Voici un exemple de GOMODCACHE structure.

~/go/pkg/mod/
├── github.com/gin-gonic/gin@v1.7.2
├── golang.org/x/crypto@v0.0.0-20210616213533-5cf6c0f8e123
        

Analyse des dépendances Java

Le générateur Amazon Inspector SBOM effectue une analyse des Java dépendances en analysant les Java applications et pom.xml les fichiers compilés. Lors de l'analyse d'applications compilées, le scanner génère des hachages SHA-1 pour vérifier l'intégrité, extrait pom.properties les fichiers intégrés et analyse les fichiers imbriqués. pom.xml

collection de hachage SHA-1 (pour les fichiers .jar, .war, .ear compilés)

Le générateur Amazon Inspector SBOM essaie de collecter les hachages SHA-1 pour tous .ear.jar, ainsi que les .war fichiers d'un projet afin de garantir l'intégrité et la traçabilité des artefacts compilés. Java

Exemple d'artefact

Voici un exemple d'artefact SHA-1.

{
  "bom-ref": "comp-52",
  "type": "library",
  "name": "jul-to-slf4j",
  "version": "2.0.6",
  "hashes": [
    {
      "alg": "SHA-1",
      "content": ""
    }
  ],
  "purl": "pkg:maven/jul-to-slf4j@2.0.6",
  "properties": [
    {
      "name": "amazon:inspector:sbom_generator:source_path",
      "value": "test-0.0.1-SNAPSHOT.jar/BOOT-INF/lib/jul-to-slf4j-2.0.6.jar"
    }
  ]
}
         

pom.properties

Le pom.properties fichier est utilisé dans les Maven projets pour stocker les métadonnées du projet, notamment les noms et les versions des packages. Le générateur Amazon Inspector SBOM analyse ce fichier pour collecter des informations sur le projet.

Exemple de fichier pom.properties

Voici un exemple de fichier pom.properties.

#Generated by Maven
#Tue Mar 16 15:44:02 UTC 2021

version=1.6.0
groupId=net.datafaker
artifactId=datafaker
        

À l'exclusion de l'analyse imbriquée pom.xml

Si vous souhaitez exclure l'analyse pom.xml syntaxique lors de l'analyse d'Javaapplications compilées, utilisez l'--skip-nested-pomxmlargument.

pom.xml

Le pom.xml fichier est le fichier de configuration de base pour les Maven projets. Il contient des informations sur les projets et leurs dépendances. Le générateur Amazon Inspector SBOM analyse les pom.xml fichiers pour collecter les dépendances, en analysant les fichiers autonomes dans les référentiels et les fichiers contenus dans les fichiers compilés. .jar

Étendue et Maven tags pris en charge

Les dépendances sont collectées avec les Maven étendues suivantes :

Les dépendances sont collectées avec la Maven balise suivante :<optional>true</optional>.

Exemple de pom.xml fichier avec une portée

Voici un exemple de pom.xml fichier doté d'une portée.

<dependency>
<groupId>jakarta.servlet</groupId>
<artifactId>jakarta.servlet-api</artifactId>
</version>6.0.0</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>8.0.28</version>
<scope>runtime</scope>
</dependency>
        

Exemple pom.xml de fichier sans portée

Voici un exemple de pom.xml fichier sans portée.

<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
<version>2.17.1</version>
</dependency>

<dependency>
<groupId>org.jenkins-ci.plugins</groupId>
<artifactId>plain-credentials</artifactId>
<version>183.va_de8f1dd5a_2b_</version>
</dependency>

<dependency>
<groupId>org.jenkins-ci.plugins</groupId>
<artifactId>jackson2-api</artifactId>
<version>2.15.2-350.v0c2f3f8fc595</version>
</dependency>
        

JavaScript analyse des dépendances

package.json

Le package.json fichier est un élément essentiel des Node.js projets. Il contient des métadonnées sur les packages installés. Le générateur SBOM d'Amazon Inspector analyse ce fichier pour identifier les noms et les versions des packages.

Exemple de fichier package.json

Voici un exemple de fichier package.json.

{
"name": "arrify",
"private": true,
"version": "2.0.1",
"description": "Convert a value to an array",
"license": "MIT",
"repository": "sindresorhus/arrify"
}
        

package-lock.json

Le package-lock.json fichier est automatiquement généré par npm pour verrouiller les versions exactes des dépendances installées pour un projet. Il garantit la cohérence des environnements en stockant les versions exactes de toutes les dépendances et de leurs sous-dépendances. Ce fichier permet de faire la distinction entre les dépendances classiques et les dépendances de développement.

Exemple de fichier package-lock.json

Voici un exemple de fichier package-lock.json.

"verror": {
"version": "1.10.0",
"resolved": "https://registry.npmjs.org/verror/-/verror-1.10.0.tgz",
"integrity": "sha1-OhBcoXBTr1XW4nDB+CiGguGNpAA=",
"requires": {
    "assert-plus": "^1.0.0",
    "core-util-is": "1.0.2",
    "extsprintf": "^1.2.0"
}
},
"wrappy": {
"version": "1.0.2",
"resolved": "https://registry.npmjs.org/wrappy/-/wrappy-1.0.2.tgz",
"integrity": "sha1-tSQ9jz7BqjXxNkYFvA0QNuMKtp8=",
"dev": true
},
"yallist": {
"version": "3.0.2",
"resolved": "https://registry.npmjs.org/yallist/-/yallist-3.0.2.tgz",
"integrity": "sha1-hFK0u36Dx8GI2AQcGoN8dz1ti7k="
}
        

npm-shrinkwrap.json

npmgénère automatiquement package-lock.json des npm-shrinkwrap.json fichiers pour verrouiller les versions exactes des dépendances installées pour un projet. Cela garantit la cohérence des environnements en stockant les versions exactes de toutes les dépendances et sous-dépendances. Les fichiers font la distinction entre les dépendances classiques et les dépendances de développement.

Exemple

Voici un exemple de fichier package-lock.json.

"verror": {
            "version": "1.10.0",
            "resolved": "https://registry.npmjs.org/verror/-/verror-1.10.0.tgz",
            "integrity": "sha1-OhBcoXBTr1XW4nDB+CiGguGNpAA=",
            "requires": {
                "assert-plus": "^1.0.0",
                "core-util-is": "1.0.2",
                "extsprintf": "^1.2.0"
            }
        },
        "wrappy": {
            "version": "1.0.2",
            "resolved": "https://registry.npmjs.org/wrappy/-/wrappy-1.0.2.tgz",
            "integrity": "sha1-tSQ9jz7BqjXxNkYFvA0QNuMKtp8=",
            "dev": true
        },
        "yallist": {
            "version": "3.0.2",
            "resolved": "https://registry.npmjs.org/yallist/-/yallist-3.0.2.tgz",
            "integrity": "sha1-hFK0u36Dx8GI2AQcGoN8dz1ti7k="
}

pnpm-yaml.lock

Le pnpm-lock.yaml fichier est généré par pnpm pour conserver un enregistrement des versions de dépendance installées. Il suit également les dépendances de développement séparément.

Exemple

Voici un exemple de fichier pnpm-lock.yaml.

lockfileVersion: 5.3
importers:
my-project:
dependencies:
  lodash: 4.17.21
devDependencies:
  jest: 26.6.3
specifiers:
  lodash: ^4.17.21
  jest: ^26.6.3
packages:
/lodash/4.17.21:
resolution:
  integrity: sha512-xyz
engines:
  node: '>=6'
dev: false
/jest/26.6.3:
resolution:
  integrity: sha512-xyz
dev: true
        

yarn.lock

Le générateur Amazon Inspector SBOM essaie de collecter les hachages SHA-1 pour .ear.jar, et les .war fichiers d'un projet afin de garantir l'intégrité et la traçabilité des artefacts compilés. Java

Exemple d'artefact SHA-1

Voici un exemple d'artefact SHA-1.

"@ampproject/remapping@npm:^2.2.0":
version: 2.2.0
resolution: "@ampproject/remapping@npm:2.2.0"
dependencies:
"@jridgewell/gen-mapping": ^0.1.0
"@jridgewell/trace-mapping": ^0.3.9
checksum: d74d170d06468913921d72430259424b7e4c826b5a7d39ff839a29d547efb97dc577caa8ba3fb5cf023624e9af9d09651afc3d4112a45e2050328abc9b3a2292
languageName: node
linkType: hard

"@babel/code-frame@npm:^7.0.0, @babel/code-frame@npm:^7.12.13, @babel/code-frame@npm:^7.18.6, @babel/code-frame@npm:^7.21.4":
version: 7.21.4
resolution: "@babel/code-frame@npm:7.21.4"
dependencies:
"@babel/highlight": ^7.18.6
checksum: e5390e6ec1ac58dcef01d4f18eaf1fd2f1325528661ff6d4a5de8979588b9f5a8e852a54a91b923846f7a5c681b217f0a45c2524eb9560553160cd963b7d592c
languageName: node
linkType: hard
        

Analyse des dépendances .NET

Packages.config

Le Packages.config fichier est un fichier XML utilisé par une ancienne version de Nuget pour gérer les dépendances du projet. Il répertorie tous les packages référencés par le projet, y compris les versions spécifiques.

Exemple

Voici un exemple de fichier Packages.config.

<?xml version="1.0" encoding="utf-8"? >
<packages>
<package id="FluentAssertions" version="5.4.1" targetFramework="net461" />
<package id="Newtonsoft.Json" version="11.0.2" targetFramework="net461" />
<package id="SpecFlow" version="2.4.0" targetFramework="net461" />
<package id="SpecRun.Runner" version="1.8.0" targetFramework="net461" />
<package id="SpecRun.SpecFlow" version="1.8.0" targetFramework="net461" />
<package id="SpecRun.SpecFlow.2-4-0" version="1.8.0" targetFramework="net461" />
<package id="System.ValueTuple" version="4.5.0" targetFramework="net461" />
</packages>
            

*.deps.json

Le *.deps.json fichier est généré par les .NET Core projets et contient des informations détaillées sur toutes les dépendances, notamment les chemins, les versions et les dépendances d'exécution. Ce fichier garantit que le moteur d'exécution dispose des informations nécessaires pour charger les versions correctes des dépendances.

Exemple de fichier .deps.json

Voici un exemple de fichier .deps.json.

{
"runtimeTarget": {
    "name": ".NETCoreApp,Version=v7.0",
    "signature": ""
},
"libraries": {
    "sample-Nuget/1.0.0": {
        "type": "project",
        "serviceable": false,
        "sha512": ""
    },
    "Microsoft.EntityFrameworkCore/7.0.5": {
        "type": "package",
        "serviceable": true,
        "sha512": "sha512-RXbRLHHWP2Z3pq8qcL5nQ6LPeoOyp8hasM5bd0Te8PiQi3RjWQR4tcbdY5XMqQ+oTO9wA8/RLhZRn/hnxlTDnQ==",
        "path": "microsoft.entityframeworkcore/7.0.5",
        "hashPath": "microsoft.entityframeworkcore.7.0.5.nupkg.sha512"
    },
}
        

packages.lock.json

Le packages.lock.json fichier est utilisé par les nouvelles versions de Nuget pour verrouiller les versions exactes des dépendances d'un .NET projet afin de garantir que les mêmes versions sont utilisées de manière cohérente dans différents environnements.

Exemple de fichier packages.lock.json

Voici un exemple de fichier packages.lock.json.

{
"version": 1,
"dependencies": {
"net7.0": {
  "Microsoft.EntityFrameworkCore": {
    "type": "Direct",
    "requested": "[7.0.5, )",
    "resolved": "7.0.5",
    "contentHash": "RXbRLHHWP2Z3pq8qcL5nQ6LPeoOyp8hasM5bd0Te8PiQi3RjWQR4tcbdY5XMqQ+oTO9wA8/RLhZRn/hnxlTDnQ==",
    "dependencies": {
      "Microsoft.EntityFrameworkCore.Abstractions": "7.0.5",
      "Microsoft.EntityFrameworkCore.Analyzers": "7.0.5",
      "Microsoft.Extensions.Caching.Memory": "7.0.0",
      "Microsoft.Extensions.DependencyInjection": "7.0.0",
      "Microsoft.Extensions.Logging": "7.0.0"
    }
  },
  "Newtonsoft.Json": {
    "type": "Direct",
    "requested": "[13.0.3, )",
    "resolved": "13.0.3",
    "contentHash": "HrC5BXdl00IP9zeV+0Z848QWPAoCr9P3bDEZguI+gkLcBKAOxix/tLEAAHC+UvDNPv4a2d18lOReHMOagPa+zQ=="
  },
  "Microsoft.Extensions.Primitives": {
    "type": "Transitive",
    "resolved": "7.0.0",
    "contentHash": "um1KU5kxcRp3CNuI8o/GrZtD4AIOXDk+RLsytjZ9QPok3ttLUelLKpilVPuaFT3TFjOhSibUAso0odbOaCDj3Q=="
  }
}
}
}
        

.csproj

Le .csproj fichier est écrit en XML et le fichier de projet pour les .NET projets. Il inclut des références aux Nuget packages, aux propriétés du projet et aux configurations de construction.

Exemple de fichier .csproj

Voici un exemple de fichier .csproj.

<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net7.0</TargetFramework>
<RootNamespace>sample_Nuget</RootNamespace>
<ImplicitUsings>enable</ImplicitUsings>
<Nullable>enable</Nullable>
<RestorePackagesWithLockFile>true</RestorePackagesWithLockFile>
</PropertyGroup>
<ItemGroup>
</ItemGroup>
<ItemGroup>
<PackageReference Include="Newtonsoft.Json" Version="13.0.3" />
<PackageReference Include="Microsoft.EntityFrameworkCore" Version="7.0.5" />
</ItemGroup>
</Project>
            

Exemple de fichier .csproj

Voici un exemple de fichier .csproj.

<PackageReference Include="ExamplePackage" Version="6.*" />
<PackageReferencePackageReference Include="ExamplePackage" Version="(4.1.3,)" />
<PackageReference Include="ExamplePackage" Version="(,5.0)" />
<PackageReference Include="ExamplePackage" Version="[1,3)" />
<PackageReference Include="ExamplePackage" Version="[1.3.2,1.5)" />
        

Analyse des dépendances PHP

composer.lock

Le composer.lock fichier est automatiquement généré lors de l'exécution des commandes d'installation ou de mise à jour du compositeur. Ce fichier garantit que les mêmes versions des dépendances sont installées dans tous les environnements. Cela fournit un processus de construction cohérent et fiable.

Exemple de fichier composer.lock

Voici un exemple de fichier composer.lock.

{
"packages": [
    {
        "name": "nesbot/carbon",
        "version": "2.53.1",
        // TRUNCATED
    },
    {
        "name": "symfony/deprecation-contracts",
        "version": "v3.2.1",
        // TRUNCATED
    },
    {
        "name": "symfony/polyfill-mbstring",
        "version": "v1.27.0",
        // TRUNCATED
    }
]
// TRUNCATED
}
        

/vendor/composer/installed.json

Le /vendor/composer/installed.json fichier se trouve dans le vendor/composer répertoire et fournit une liste complète de tous les packages installés et de toutes les versions de packages.

Exemple de fichier /vendor/composer/installed.json

Voici un exemple de fichier /vendor/composer/installed.json.

 
{
"packages": [
    {
        "name": "nesbot/carbon",
        "version": "2.53.1",
        // TRUNCATED
    },
    {
        "name": "symfony/deprecation-contracts",
        "version": "v3.2.1",
        // TRUNCATED
    },
    {
        "name": "symfony/polyfill-mbstring",
        "version": "v1.27.0",
        // TRUNCATED
    }
]
// TRUNCATED
}
        

Analyse des dépendances en Python

requirements.txt

Le requirements.txt fichier est un format largement utilisé dans les Python projets pour spécifier les dépendances des projets. Chaque ligne de ce fichier inclut un package avec ses contraintes de version. Le générateur Amazon Inspector SBOM analyse ce fichier pour identifier et cataloguer les dépendances avec précision.

Exemple de fichier requirements.txt

Voici un exemple de fichier requirements.txt.

flask==1.1.2
requests==2.24.0
numpy==1.18.5
foo~=1.2.0
# Comment about a dependency
scipy. # invalid 
    

Pipfile.lock

Pipenvest un outil qui offre le meilleur de tous les mondes de l'emballage (groupé, épinglé et non épinglé). Il Pipfile.lock verrouille les versions exactes des dépendances pour faciliter les constructions déterministes. Le générateur Amazon Inspector SBOM lit ce fichier pour répertorier les dépendances et leurs versions résolues.

Exemple de fichier Pipfile.lock

Voici un exemple de fichier Pipfile.lock.

{
"default": {
    "requests": {
        "version": "==2.24.0",
        "hashes": [
            "sha256:cc718bb187e53b8d"
        ]
    }
},
"develop": {
    "blinker": {
        "hashes": [
            "sha256:1779309f71bf239144b9399d06ae925637cf6634cf6bd131104184531bf67c01",
            "sha256:8f77b09d3bf7c795e969e9486f39c2c5e9c39d4ee07424be2bc594ece9642d83"
        ],
        "markers": "python_version >= '3.8'",
        "version": "==1.8.2"
    }
}
}
    

Poetry.lock

Poetryest un outil de gestion des dépendances et d'empaquetage pour Python. Le Poetry.lock fichier verrouille les versions exactes des dépendances afin de garantir la cohérence des environnements. Le générateur Amazon Inspector SBOM extrait des informations de dépendance détaillées à partir de ce fichier.

Exemple de fichier Poetry.lock

Voici un exemple de fichier Poetry.lock.

[[package]]
name = "flask"
version = "1.1.2"
description = "A simple framework for building complex web applications."
category = "main"
optional = false
python-versions = ">=3.5"
[[package]]
name = "requests"
version = "2.24.0"
description = "Python HTTP for Humans."
category = "main"
optional = false
python-versions = ">=3.5"
    

verrou UV

uvest un gestionnaire de Python paquets rapide écrit enRust. Le uv.lock fichier verrouille les versions exactes des dépendances afin de garantir la cohérence des environnements. Le générateur Amazon Inspector SBOM extrait des informations de dépendance détaillées à partir de ce fichier.

Exemple de fichier uv.lock

Voici un exemple de fichier uv.lock.

version = 1
requires-python = ">=3.12"

[[package]]
name = "flask"
version = "3.1.0"
source = { registry = "https://pypi.org/simple" }
dependencies = [
    { name = "blinker" },
    { name = "click" },
    { name = "itsdangerous" },
    { name = "jinja2" },
    { name = "markupsafe" },
    { name = "werkzeug" },
]

[[package]]
name = "pytest"
version = "8.3.4"
source = { registry = "https://pypi.org/simple" }
dependencies = [
    { name = "iniconfig" },
    { name = "packaging" },
    { name = "pluggy" },
]

[package.dev-dependencies]
dev = [
    { name = "pytest" },
]
        

Œuf/Roue

Pour les packages Python installés dans le monde entier, le générateur Amazon Inspector SBOM prend en charge l'analyse des fichiers de métadonnées trouvés dans les .egg-info/PKG-INFO répertoires et. .dist-info/METADATA Ces fichiers fournissent des métadonnées détaillées sur les packages installés.

Exemple de fichier PKG-INFO/METADATA

Voici un exemple de fichier PKG-INFO/METADATA.

Metadata-Version: 1.2
Name: Flask
Version: 1.1.2
Summary: A simple framework for building complex web applications.
Home-page: https://palletsprojects.com/p/flask/
    

Analyse des dépendances Ruby

Gemfile.lock

Le Gemfile.lock fichier verrouille les versions exactes de toutes les dépendances afin de garantir que les mêmes versions sont utilisées dans tous les environnements.

Exemple de fichier Gemfile.lock

Voici un exemple de fichier Gemfile.lock.

GEM
remote: https://rubygems.org/
specs:
ast (2.4.2)
awesome_print (1.9.2)
diff-lcs (1.5.0)
json (2.6.3)
parallel (1.22.1)
parser (3.2.2.0)
nokogiri (1.16.6-aarch64-linux)
        

.gemspec

Le .gemspec fichier est un RubyGem fichier contenant des métadonnées relatives à une gemme. Le générateur Amazon Inspector SBOM analyse ce fichier pour collecter des informations détaillées sur une gemme.

Exemple de fichier .gemspec

Voici un exemple de fichier .gemspec.

Gem::Specification.new do |s|
s.name        = "generategem"
s.version     = "2.0.0"
s.date        = "2020-06-12"
s.summary     = "generategem"
s.description = "A Gemspec Builder"
s.email       = "edersondeveloper@gmail.com"
s.files       = ["lib/generategem.rb"]
s.homepage    = "https://github.com/edersonferreira/generategem"
s.license     = "MIT"
s.executables = ["generategem"]
s.add_dependency('colorize', '~> 0.8.1')
end
        

# Not supported 

Gem::Specification.new do |s|
s.name        = &class1
s.version     = &foo.bar.version
        

Gemmes installées dans le monde entier

Le générateur Amazon Inspector SBOM prend en charge l'analyse des gemmes installées dans le monde entier, qui se trouvent dans des annuaires standard, tels que /usr/local/lib/ruby/gems/<ruby_version>/gems/ Amazon EC2/Amazon ECR et Lambda. ruby/gems/<ruby_version>/gems/ Cela permet de s'assurer que toutes les dépendances installées dans le monde entier sont identifiées et cataloguées.

Exemple de structure de répertoire

Voici un exemple de structure de répertoire.

. 
└── /usr/local/lib/ruby/3.5.0/gems/ 
├── actrivesupport-6.1.4 
├── concurrent-ruby-1.1.9 
└── i18n-1.8.10
        

Analyse des dépendances Rust

Cargo en ml

Le Cargo.toml fichier est le fichier manifeste des Rust projets.

Exemple de fichier Cargo.toml

Voici un exemple de fichier Cargo.toml.

[package]
name = "wait-timeout"
version = "0.2.0"
description = "A crate to wait on a child process with a timeout specified across Unix and\nWindows platforms.\n"
homepage = "https://github.com/alexcrichton/wait-timeout"
documentation = "https://docs.rs/wait-timeout"
readme = "README.md"
categories = ["os"]
license = "MIT/Apache-2.0"
repository = "https://github.com/alexcrichton/wait-timeout"
[target."cfg(unix)".dependencies.libc]
version = "0.2"
[badges.appveyor]
repository = "alexcrichton/wait-timeout"
        

Cargo.lock

Le Cargo.lock fichier verrouille les versions de dépendance pour s'assurer que les mêmes versions sont utilisées chaque fois qu'un projet est créé.

Exemple de fichier Cargo.lock

Voici un exemple de fichier Cargo.lock.

# This file is automatically @generated by Cargo.
# It is not intended for manual editing.
[[package]]
name = "adler32"
version = "1.0.3"
source = "registry+https://github.com/rust-lang/crates.io-index"

[[package]]
name = "aho-corasick"
version = "0.7.4"
source = "registry+https://github.com/rust-lang/crates.io-index"
        

Binaires Rust avec cargo-auditable

Le générateur Amazon Inspector SBOM collecte les dépendances à partir des Rust fichiers binaires créés avec la bibliothèque. cargo-auditable Cela fournit des informations de dépendance supplémentaires en permettant l'extraction des dépendances à partir de fichiers binaires compilés.

Artefacts non pris en charge

Cette section décrit les artefacts non pris en charge.

Java

Le générateur Amazon Inspector SBOM Generator prend uniquement en charge la détection des vulnérabilités pour les dépendances provenant du référentiel standard. Maven MavenLes référentiels privés ou personnalisés, tels que Red Hat Maven etJenkins, ne sont pas pris en charge. Pour une détection précise des vulnérabilités, assurez-vous que Java les dépendances sont extraites du Maven référentiel principal. Les dépendances provenant d'autres référentiels ne seront pas couvertes par les analyses de vulnérabilité.

JavaScript

bundles esbuild

Pour les bundles esbuild minifiés, le générateur SBOM d'Amazon Inspector ne prend pas en charge l'analyse des dépendances pour les projets utilisant. esbuild Les cartes sources générées par esbuild n'incluent pas suffisamment de métadonnées (noms et versions des dépendances) requises pour une Sbomgen génération précise. Pour des résultats fiables, scannez les fichiers du projet d'origine, tels que le node_modules/directory etpackage-lock.json, avant le processus de regroupement.

package.json

Le générateur Amazon Inspector SBOM ne prend pas en charge l'analyse des informations de dépendance dans le fichier package.json situé au niveau racine. Ce fichier indique uniquement les noms de packages et les plages de versions, mais n'inclut pas les versions de packages entièrement résolues. Pour des résultats de numérisation précis, utilisez package.json ou d'autres fichiers de verrouillage, tels que yarn.lock etpnpm.lock, qui incluent des versions résolues.

Dotnet

Lorsque vous utilisez des versions flottantes ou des plages de versionsPackageReference, il devient plus difficile de déterminer la version exacte du package utilisée dans un projet sans effectuer de résolution de package. Les versions flottantes et les plages de versions permettent aux développeurs de spécifier une plage de versions de package acceptables plutôt qu'une version fixe.

Binaires Go

Le générateur Amazon Inspector SBOM ne scanne pas Go les fichiers binaires créés avec des indicateurs de compilation configurés pour exclure l'ID de build. Ces indicateurs de compilation empêchent Amazon Inspector SBOM Generator de mapper avec précision le binaire à sa source d'origine. GoLes fichiers binaires peu clairs ne sont pas pris en charge en raison de l'impossibilité d'extraire les informations du package. Pour une analyse précise des dépendances, assurez-vous que Go les fichiers binaires sont créés avec les paramètres par défaut, y compris l'ID de version.

Binaires Rust

Le générateur Amazon Inspector SBOM analyse les Rust fichiers binaires uniquement s'ils sont créés à l'aide de la bibliothèque cargo-auditable. Rustles binaires n'utilisant pas cette bibliothèque ne disposent pas des métadonnées nécessaires pour une extraction précise des dépendances. Le générateur Amazon Inspector SBOM extrait la version compilée de la Rust chaîne d'outils à partir de la version Rust 1.7.3, mais uniquement pour les fichiers binaires d'un environnement. Linux Pour une analyse complète, créez des Rust fichiers binaires à l'Linuxaide de cargo-auditable.