Security Architecture · Topic 4 of 12
Software Supply Chain and End of Life
Control software supply chain risk with SBOMs, signing and provenance, then manage patching, end of life, decommissioning and secure disposal of systems.
- 5 min
- A supply chain attack compromises a supplier to reach many customers.
- An SBOM lists components and versions so you can check exposure quickly.
- Code signing proves origin and integrity, so protect the signing keys.
What it is
Modern software is mostly assembled from other people's components. Every library, build tool, container image and hardware part is a link in a supply chain that attackers can target.
The later life cycle matters just as much. Systems must be patched while supported, retired when support ends, and disposed of without leaking data.
How it works
Software supply chain threats
Attackers compromise a supplier so their malicious change reaches many victims at once. Examples include a tampered update, a poisoned build system, or a malicious package published to a public repository.
Typosquatting uses a package name that resembles a popular one. Dependency confusion tricks a build into pulling a public package instead of an internal one with the same name.
Hardware has similar risks, such as counterfeit or tampered components, so procurement from trusted sources matters.
Software bill of materials
A software bill of materials (SBOM) is a machine readable inventory of the components inside a piece of software, with versions. When a new vulnerability is announced, the SBOM lets you check at once whether you are affected. Common formats include SPDX (Software Package Data Exchange) and CycloneDX.
An SBOM is an inventory, not a vulnerability list. You still compare it with vulnerability data to know what to fix.
Integrity and provenance controls
| Control | Purpose |
|---|---|
| Code signing | Proves who released the code and that it was not changed afterwards |
| Hash verification | Confirms a downloaded file matches the publisher's value |
| Trusted repositories | Pull components only from vetted sources, often through an internal mirror |
| Dependency pinning | Fix versions so a surprise update cannot enter a build |
| Provenance records | Show where, when and how an artifact was built |
| Isolated, hardened build systems | Stop an attacker from altering code during the build |
Verify signatures before deployment, and keep signing keys in protected hardware or a key management service. A stolen signing key lets an attacker release malware that looks trusted.
Vendor and component assessment
Assess suppliers before adopting them. Review their secure development practices, vulnerability disclosure process, patch history and how they respond to incidents. Prefer components with active maintenance, and have a plan to replace abandoned ones.
Patch and vulnerability management
Track every system in an inventory, scan for missing patches, and rank fixes by severity, exposure and exploitation. Test patches before wide rollout and keep a rollback path. When a patch cannot be applied, use a compensating control such as isolation, a virtual patch on a web application firewall, or extra monitoring.
End of life and end of support
End of life (EOL) means the vendor stops selling a product. End of support (EOS) means it no longer issues security fixes. A system past EOS gets no patches, so every new vulnerability stays open.
Options for such systems are replacement, vendor extended support, strong isolation, or restricted access with extra monitoring. Document the risk acceptance and a retirement date.
Decommissioning and disposal
Retirement should be a controlled process.
- Confirm the data's retention duties and any legal hold.
- Move or archive data that must be kept.
- Revoke accounts, keys, certificates and network rules.
- Remove the asset from monitoring, inventory and the configuration database once handled.
- Sanitize storage by clear, purge or destroy according to data classification, using cryptographic erase for encrypted media where appropriate.
- Record the disposal with evidence such as a certificate of destruction.
Forgotten cloud resources and orphaned Domain Name System (DNS) records are common leftovers. They can allow subdomain takeover, where an attacker claims a name that still points to a deleted service.
What to remember for the exam
- A supply chain attack compromises a supplier to reach many customers.
- An SBOM lists components and versions so you can check exposure quickly.
- Code signing proves origin and integrity, so protect the signing keys.
- Pin dependencies and use trusted repositories to resist typosquatting and dependency confusion.
- EOS systems receive no security fixes, so isolate and monitor them if they cannot be replaced.
- Compensating controls such as virtual patching help when a patch is not possible.
- Disposal must match data classification, and records prove it happened.
- Decommissioning includes revoking access and cleaning inventory, DNS and monitoring.
If a scenario says a critical vulnerability appeared in a library, the first useful asset is an SBOM that shows which products contain it.
Common mistakes
Believing a signed file is safe. A signature proves origin and integrity, not that the code is free of flaws or that the signer was not compromised.
Treating an SBOM as a scanner. It tells you what is present and must be matched to vulnerability data.
Assuming deleted means gone. Cloud snapshots, backups and orphaned records may remain after a service is turned off.
Leaving EOS systems on the main network. An unpatchable system should be segmented and watched.
Do not reuse or resell media that held sensitive data without sanitizing it to the level the data classification requires.
Check yourself
Work through these three questions.
What problem does an SBOM solve?
It shows which components and versions a product contains, so you can quickly tell whether a newly disclosed vulnerability affects you.
Why isolate an end of support system?
It no longer receives security fixes, so network isolation and monitoring reduce the risk of exploitation.
What is dependency confusion?
An attack that tricks a build into using a malicious public package instead of an internal package with the same name.
Topic 4 of 12 in Security Architecture
Test yourself on Security Architecture
The full CompTIA SecurityX CAS-005 question bank has 654 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by CompTIA. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.