Origin and Support of Third-Party Software

1. Why This Topic Matters

Modern applications are rarely built from scratch. Studies consistently show that 70 to 90 percent of a typical codebase consists of third-party components: open-source libraries, commercial off-the-shelf (COTS) products, outsourced modules, APIs, container base images, and cloud services. Every one of those components carries risk that your organization did not create but is now responsible for. Incidents such as the SolarWinds Orion compromise, the Log4Shell vulnerability in Log4j, the event-stream npm hijack, and the XZ Utils backdoor all demonstrate the same lesson: if you do not know where your software came from and who stands behind it, you cannot secure it.

For the CSSLP exam, this topic sits inside Domain 8 (Secure Software Supply Chain). ISC2 expects a security professional to be able to evaluate the origin (provenance and pedigree) of software and the support (ongoing maintenance, patching, and vendor viability) behind it before and after acquisition. This knowledge connects directly to risk management, secure acquisition, software bill of materials (SBOM), licensing, and secure operations.

2. What It Is: Key Concepts and Definitions

Third-party software is any software or component not developed in-house, including:
- COTS (Commercial Off-The-Shelf): purchased commercial products, usually closed-source, licensed per seat or subscription.
- GOTS (Government Off-The-Shelf): software developed by or for a government entity.
- OSS (Open Source Software): publicly available source code under licenses such as MIT, Apache 2.0, GPL, or LGPL.
- Outsourced or contracted development: custom code written by an external vendor or offshore team.
- Managed services and APIs: SaaS, PaaS, and third-party web services that your software depends on at runtime.

Origin refers to where software comes from and how it was produced. Two terms are important here:
- Provenance: the documented chain of custody of a component, from original author through every build, repository, and distribution point to your environment. Provenance answers the question: Can we prove this artifact is what it claims to be and came from where it claims to come from?
- Pedigree: the lineage and history of the software, including who the authors and maintainers are, what development practices were used, what dependencies it inherited, and its historical security record. Pedigree answers: Is this code from a trustworthy source with a trustworthy history?

Support refers to the ongoing commitment of the supplier or community to maintain the software. Support considerations include:
- Security patch availability and the speed of response to disclosed vulnerabilities.
- Release cadence and versioning discipline.
- Published end-of-life (EOL) and end-of-support (EOS) dates.
- A responsible or coordinated vulnerability disclosure process and a security contact.
- For commercial vendors: service level agreements (SLAs), warranties, indemnification, and financial viability.
- For open source: community health, number of active maintainers, bus factor, issue response times, and funding or foundation backing (for example, Apache Software Foundation, Linux Foundation, OpenSSF).
- Source code escrow arrangements that protect the acquirer if a vendor goes out of business.

Software Bill of Materials (SBOM) is the formal, machine-readable inventory of all components, versions, suppliers, and dependencies in a software product. Common formats are SPDX and CycloneDX. An SBOM is the foundation for understanding origin and tracking support status over time.

3. How It Works: The Lifecycle of Managing Third-Party Software

Step 1: Define policy and acceptance criteria. Before anyone downloads a library, the organization should have a third-party component policy. It defines approved sources (for example, an internal artifact repository that proxies and scans public registries), prohibited licenses, minimum support requirements, maximum tolerated vulnerability severity, and who must approve new components. This is often governed through a Software Composition Analysis (SCA) program and a security champion or architecture review board.

Step 2: Perform supplier and component due diligence (origin assessment).
- Identify the true source. Confirm the official project page, repository owner, and publisher identity. Watch for typosquatting (packages with names nearly identical to popular ones), dependency confusion (public packages that shadow internal package names), and repository hijacking (abandoned projects taken over by malicious maintainers).
- Verify integrity and authenticity. Validate cryptographic hashes against the publisher's published values, verify digital signatures (code signing certificates, GPG signatures, Sigstore or cosign signatures), and prefer reproducible builds. Download only from trusted, authenticated repositories over secure channels.
- Review pedigree. Examine commit history, contributor reputation, how long the project has existed, prior CVEs and how quickly they were fixed, and whether the project follows secure development practices (for example, OpenSSF Scorecard results, SLSA level, or vendor attestations such as a Secure Software Development Framework attestation).
- Assess the supplier. For commercial vendors, use questionnaires (for example, based on ISO 27001, SOC 2 reports, NIST SP 800-161 supply chain risk management guidance, or CSA CAIQ), review security certifications, and evaluate financial stability and geopolitical or legal exposure.
- Check licensing. Identify the license and confirm it is compatible with your intended distribution model. Copyleft licenses such as GPL may impose obligations on derivative works; permissive licenses such as MIT and Apache 2.0 have fewer restrictions but still require attribution. Unlicensed code should be treated as unusable.

Step 3: Evaluate support (support assessment).
- Confirm the component is actively maintained: recent releases, open issues being triaged, and security advisories being published.
- Determine EOL and EOS dates and align them with your product's planned lifespan.
- For vendors, negotiate contractual terms: SLAs for security patch delivery, right to audit, notification obligations when vulnerabilities are discovered, secure development requirements, and escrow for source code.
- For open source, consider whether commercial support is available (for example, enterprise distributions), whether you have the skills to fork and maintain internally if needed, and whether the project has a documented security policy (a SECURITY.md file and a security contact).

Step 4: Record and track (inventory). Generate or obtain an SBOM for every build. Store component metadata in a central inventory so that when a new CVE is announced you can immediately answer: Do we use this, where, and which version? Vulnerability Exploitability eXchange (VEX) documents can be used by suppliers to state whether a known vulnerability is actually exploitable in their product.

Step 5: Monitor continuously. Origin and support are not one-time checks. Subscribe to vendor and project security advisories, feed SBOM data into SCA tools that correlate against vulnerability databases (NVD, OSV, GitHub Advisory Database), track license changes, and watch for signs of abandonment or maintainer turnover. Reassess suppliers periodically and upon significant events such as acquisition, breach, or change of ownership.

Step 6: Plan for change and exit. Have a strategy for component replacement when support ends, a vendor fails, or a license changes unfavorably. Avoid lock-in through abstraction layers where practical. Define a deprecation process so that unsupported components are removed before they become unpatched attack surface.

4. Common Risks Tied to Origin and Support

- Malicious code injection in upstream components or build pipelines.
- Counterfeit or tampered binaries distributed through untrusted mirrors.
- Abandonware: components with no maintainer, leaving vulnerabilities permanently unpatched.
- Transitive dependencies: a direct dependency pulls in dozens of indirect dependencies with unknown origin.
- License non-compliance leading to legal exposure or forced disclosure of proprietary code.
- Vendor failure without escrow, leaving the organization unable to maintain critical software.
- Hidden functionality such as backdoors, telemetry, or undocumented features in COTS products.

5. Exam Tips: Answering Questions on Origin and Support of Third-Party Software

Tip 1: Distinguish provenance from pedigree. If a question asks about the chain of custody, build history, or proving an artifact is authentic, the answer relates to provenance. If it asks about the trustworthiness of the authors, development practices, and historical track record, the answer relates to pedigree. Both fall under origin.

Tip 2: When asked for the FIRST or MOST IMPORTANT step, think inventory and policy. CSSLP questions frequently reward the governance answer. You cannot assess what you have not identified, so creating an SBOM or component inventory, or establishing an acceptance policy, often precedes technical scanning.

Tip 3: Integrity verification means cryptography. Questions about confirming a downloaded component has not been altered point to verifying digital signatures and hashes from the publisher, not simply downloading from a popular website or relying on HTTPS alone. HTTPS protects the channel; signatures prove the publisher and integrity of the artifact itself.

Tip 4: Support questions are about the future. When a scenario mentions a component that is no longer updated, a vendor that has gone bankrupt, or an approaching end-of-life date, the exam is testing whether you recognize unsupported software as unmanaged risk. Look for answers involving replacement planning, source code escrow, commercial support contracts, or compensating controls, not simply continued use.

Tip 5: Know the contractual controls for COTS and outsourced code. Expect questions about what to include in contracts: SLAs for security patches, vulnerability notification requirements, right to audit, secure coding requirements, acceptance testing, warranties, and escrow. Escrow is the classic answer to vendor insolvency risk.

Tip 6: Open source is not free of obligation. If a question involves open-source components, consider license compliance (especially copyleft), the health of the maintainer community, and the fact that no one is contractually obligated to fix anything. The organization inherits responsibility for OSS it ships.

Tip 7: Recognize supply chain attack patterns by name. Be able to identify typosquatting, dependency confusion, repository or account hijacking, compromised build servers, and malicious updates. The mitigation theme is consistent: use trusted internal repositories, pin and verify versions, verify signatures, and apply least privilege to build pipelines.

Tip 8: SBOM is the enabling artifact. If a question asks how an organization can quickly determine exposure to a newly announced vulnerability in a widely used library, the answer is an accurate, maintained SBOM combined with SCA tooling. VEX complements the SBOM by communicating exploitability.

Tip 9: Eliminate answers that shift responsibility entirely to the vendor. The exam view is that the acquiring organization retains accountability for the security of everything it deploys. Answers like 'the vendor is responsible, so no action is needed' are almost always wrong.

Tip 10: Think risk management, not perfection. CSSLP favors answers that assess, prioritize, and manage risk proportionate to criticality. Banning all third-party software is unrealistic; accepting all of it blindly is negligent. The correct answer is usually the structured, repeatable process: define policy, assess origin and support, verify, inventory, monitor, and plan for exit.

6. Quick Review Checklist

- Can I prove where this component came from (provenance)?
- Do I trust who made it and how (pedigree)?
- Have I verified its signature and hash?
- Is it actively maintained, and when does support end?
- What are the license terms and are they compatible with my use?
- Is it recorded in my SBOM with its transitive dependencies?
- Do contracts or escrow protect me if the supplier fails?
- Am I monitoring advisories and reassessing periodically?
- Do I have a replacement plan?

Mastering these questions prepares you not only for the CSSLP exam but for the real-world responsibility of building software on a foundation you can trust.