Supply Chain
Summary
PDF p.231Software supply chain vulnerabilities are risks introduced during the development, distribution, and maintenance of software products. These vulnerabilities can arise from service providers, hardware suppliers, and software providers, affecting the entire lifecycle from coding to deployment.
In plain words
Supplementary — not from your PDFSupply chain risk comes from everyone who contributes to your software: service providers (development platforms, contractors), hardware suppliers (tampered hardware, firmware flaws, bad drivers) and software providers (vulnerable third-party libraries). A software bill of materials (SBOM) lists every component, so when a new vulnerability is announced you can quickly see whether you're affected. Tools such as OWASP Dependency-Check and Dependency-Track, and formats such as SPDX and CycloneDX, support this.
Detailed explanation
PDF p.231-
Service Providers
- Role: Offer development, testing, and deployment platforms or contribute to the software's codebase.
- Risks: Inadequate security measures, unsecured communication.
-
Hardware Suppliers
- Role: Provide the hardware on which software runs or interacts.
- Risks: Compromised hardware, preinstalled firmware vulnerabilities, physical tampering, unreliable drivers.
- Example: Hardware with known vulnerabilities or susceptible to tampering.
-
Software Providers
- Role: Makers of libraries, frameworks, and third-party components.
- Risks: Vulnerabilities in third-party components, outdated software.
-
Software Bill of Materials (SBOM)
- Definition: Comprehensive inventory of all components in a software product.
- Purpose: Provide transparency and visibility into the software supply chain.
- Benefits: Identify potential vulnerabilities, track component origins, support rapid response to vulnerabilities.
-
Dependency Analysis and SBOM Tools
- OWASP Dependency-Check: Identifies project dependencies and known vulnerabilities.
- Comprehensive SBOM Tools: OWASP Dependency-Track, SPDX, CycloneDX for detailed SBOMs.
Important terms
taken from the text above- Software Bill of Materials (SBOM)
- Comprehensive inventory of all components in a software product.
- OWASP Dependency-Check
- Identifies project dependencies and known vulnerabilities.
- Comprehensive SBOM Tools
- OWASP Dependency-Track, SPDX, CycloneDX for detailed SBOMs.
Examples & real-world scenarios
Supplementary — not from your PDF- Running Dependency-Check in a build pipeline.
- Asking a vendor for an SBOM in CycloneDX format.
- Searching SBOMs to find every app that uses a newly vulnerable library.
Scenario
A critical flaw is announced in a popular logging library. Teams with SBOMs identify affected apps within an hour; teams without spend days searching code.
Common mistakes
Supplementary — not from your PDF- Assuming open-source libraries are someone else's security problem.
- Treating an SBOM as a one-time document instead of updating it with each release.
Practical skills
Supplementary — not from your PDF- Generate and read an SBOM for a small project of your own.
What I should remember
Key Points PDF p.231-
Service Providers
- Role: Development, testing, deployment.
- Risks: Security measures, communication.
-
Hardware Suppliers
- Role: Provide hardware.
- Risks: Compromised hardware, firmware vulnerabilities, tampering.
-
Software Providers
- Role: Libraries, frameworks, components.
- Risks: Vulnerabilities, outdated software.
-
Software Bill of Materials (SBOM)
- Definition: Inventory of software components.
- Purpose: Transparency, vulnerability identification, origin tracking.
-
Dependency Analysis and SBOM Tools
- OWASP Dependency-Check: Identifies dependencies, vulnerabilities.
- Comprehensive Tools: OWASP Dependency-Track, SPDX, CycloneDX