Dependency Inventory and SBOM

🌟 Objective

Guarantee that all applications have a complete, traceable and versioned inventory of the libraries and components used - known as an SBOM (Software Bill of Materials) - as a fundamental measure to:

Mitigate third-party and supply chain risks;
Accelerate the response to public vulnerabilities (e.g. CVE);
Support compliance with standards and regulatory requirements (e.g. NIS2, CRA, EO 14028);
Enable technical audits and impact analyses.

🧬 What an SBOM is

An SBOM is a structured file that describes all the software components of a system, including:

Package name and version
Origin (repository, supplier)
Licence
Hashes/signatures
Transitive dependencies
Relationships (e.g. runtime, dev, optional)

⚠️ An SBOM is not a lockfile - it is a formal, standardised artefact that security tools can process.

📘 Supported formats

Format	Description	Compatible tools
CycloneDX	Lightweight, extensible and widely supported format	Syft, Trivy, OWASP tools, GitHub, Snyk
SPDX	Normative format maintained by the Linux Foundation	SPDX tools, FOSSology, Black Duck
SWID	Used in regulated environments (e.g. fed. gov.)	Requires specialised tooling

🌟 Recommended by SbD-ToE: CycloneDX, in JSON or XML format, with support for multiple languages.

🛠️ How to generate SBOMs

Stack / Language	Typical command	Notes
Node.js	`syft . -o cyclonedx-json`	Includes `package.json` and transitive dependencies
Java/Maven	`cyclonedx-maven-plugin`	Output directly in the build (`target/`)
Python	`syft . -o cyclonedx-json`	Includes `requirements.txt`, `pipfile.lock`
Docker/Containers	`syft docker:imagem:tag -o cyclonedx-json`	Generates the SBOM of the complete image (base + app)
C# (.NET)	`cyclonedx-dotnet`	SBOM per `.csproj` project or `.sln`

💡 Suggestion: generate the SBOM automatically on every build as a versioned pipeline artefact.

📂 Where to store SBOMs

Dedicated directory in the repository: /.sbom/
CI/CD artefact associated with the build (e.g. Azure Artifacts, GitHub Releases)
SBOMs versioned in source control or external systems (Artifactory, Nexus, etc.)

🧬 Examples of fields in a CycloneDX SBOM

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "version": 1,
  "components": [
    {
      "type": "library",
      "name": "lodash",
      "version": "4.17.21",
      "purl": "pkg:npm/lodash@4.17.21",
      "hashes": [{ "alg": "SHA-256", "content": "..." }],
      "licenses": [{ "license": { "id": "MIT" } }]
    }
  ]
}

Each component may be linked to CVEs, licence and metadata that support traceability and validation.

✅ Good practices

Generate an SBOM in every production build
Include transitive dependencies, not only direct ones
Version and retain each SBOM alongside the corresponding artefact
Automate the comparison of SBOMs between versions (detect the introduction of risk)
Integrate the SBOM with SCA scanners and vulnerability management systems

📎 Cross-references

Document	Relationship with the SBOM
`02-analise-sca.md`	Uses the SBOM as input for vulnerability analysis
`04-integracao-ci-cd.md`	Integration of SBOM generation into the pipeline
`08-rastreabilidade-vulnerabilidades.md`	Mapping between findings and SBOM components

🔒 The SBOM is a technical and documentary prerequisite for effective risk detection, compliance with frameworks (SSDF, SLSA) and a swift response to security incidents.

🌟 Objective​

🧬 What an SBOM is​

📘 Supported formats​

🛠️ How to generate SBOMs​

📂 Where to store SBOMs​

🧬 Examples of fields in a CycloneDX SBOM​

✅ Good practices​

📎 Cross-references​