Skip to content

ADR 013: Software Supply Chain Security and SBOMs

  • Status: Accepted
  • Type: Feature
  • Created: 2024-07-17
  • Related-ADRs: 006, 008, 010, 058 (reproducibility model)

Context and Goals

Supply chain transparency, traceability, and component-level security are prerequisites for platform integrity and reliability. Hop3 implements Software Bill of Materials (SBOMs) to provide a detailed inventory of software components and to anchor the other supply-chain practices described here.

Decision

Hop3 integrates SBOMs and supply-chain security practices throughout the development and delivery pipeline. Dependencies are made transparent, verifiable, and secure, and each release carries a compliance-ready CycloneDX SBOM. Any SBOM generator that produces valid CycloneDX output meets the requirement; Genealogos is a candidate tool but not a committed dependency.

Key Components

Software Supply Chain Security

  1. Dependency Management:

  2. Nix Package Management: Nix builds deterministically and manages dependencies explicitly: all software dependencies are defined, reproducible, and isolated.

  3. Dependency Auditing: Dependencies are audited for known vulnerabilities using automated tools (pip-audit via Nox), and security patches are kept up to date.

  4. Secure Development Practices:

  5. Code Reviews: Thorough code reviews and security audits are enforced for all changes to the codebase.

  6. Continuous Integration: Security checks are integrated into the CI pipeline to detect and address vulnerabilities early in the development process.

  7. REUSE-compliant licensing: Every source file carries a REUSE-compliant license header, enforced in CI.

  8. Software Bill of Materials (SBOMs):

  9. Generation: CycloneDX SBOMs are generated for software releases using supply-chain tooling declared in the project (ADR 004): cyclonedx-bom, spdx-tools, pip-audit, deptry, import-linter.

  10. Transparency and Compliance: SBOMs provide a detailed inventory of software components, including their versions, licenses, and known vulnerabilities, to support compliance with regulations such as the Cyber Resilience Act (CRA).

Implementation Strategy

  1. Integration of Nix:

  2. Hermetic Builds: every Nix-built application builds in a sealed sandbox with no network access, against hash-pinned inputs. Each ecosystem's dependency set is vendored by a fixed-output derivation from a committed lockfile before the build begins, so the package manager runs offline. The ADR 058 tiers distinguish provenance: Tier-1 apps are packaged by nixpkgs, Tier-2 built from source by Hop3, and Tier-3 wrap an upstream binary that is hash-pinned and not auditable.

  3. Content-addressed closures: Every Nix-built app has a content-addressed closure whose full dependency graph is inspectable via nix-store -qR, and update deltas are minimal: only changed store paths transfer.

  4. CI/CD Pipeline Enhancements:

  5. Security Scans: Automated security scans run in the CI pipeline to monitor for vulnerabilities and compliance issues.

  6. SBOM Inclusion: SBOMs are generated and included in the release pipeline so that each release carries a detailed inventory of all components.

Continuous Improvement

  1. Monitoring and Auditing:

  2. Regular Audits: Regular security audits and reviews of the software supply chain identify and mitigate risks.

  3. Performance Monitoring: The performance and security of the CI/CD pipeline are continuously monitored to ensure they meet the highest standards of software supply chain security.

  4. Community Engagement:

  5. Feedback Loop: A feedback loop with users and contributors continuously improves supply chain security practices based on real-world usage and feedback.

  6. Documentation and Training: Comprehensive documentation and training are provided to the community on best practices for supply chain security and the use of SBOMs.

Consequences

Benefits

  • Enhanced Security: Improves the security and integrity of the software supply chain by making all dependencies transparent and verifiable.
  • Compliance: Detailed SBOMs support compliance with industry standards and regulations such as the Cyber Resilience Act (CRA).
  • Transparency: Increases transparency and trust by providing a comprehensive inventory of software components and their security status.

Drawbacks

  • Implementation Effort: Requires dedicated effort to integrate and maintain SBOM generation and supply chain security practices.
  • Complexity: Adds complexity to the development and delivery pipeline; it needs tools and processes to manage that pipeline.

Risks

  • Security Threats: Ongoing risk of evolving security threats. Mitigation involves continuous monitoring, regular updates, and proactive security measures.
  • Toolchain Integration: Potential challenges in integrating SBOM generation tools with the existing CI/CD pipeline. Mitigation includes thorough testing and community support.

Future Work

  • Signature attestation (Sigstore / in-toto / cosign) for release artefacts and for the SBOM itself, likely required for Cyber Resilience Act compliance.
  • Reproducible-builds verification on a schedule. The rebuild check exists and covers all three tiers (ADR 058); a scheduler must run it without being asked (ADR 044).
  • Upstream source mirroring to insulate against PyPI / registry deletions.

Related ADRs: ADR 006: Nix Integration with Hop3, ADR 008: Template-Based Nix Expression Generation, ADR 010: Security and Resilience (Umbrella), ADR 058: Build Reproducibility Model