8.4 Acquired Software & Third-Party Security
8.4 Acquired Software & Third-Party Security
Organisations rarely build every application, library, platform and service themselves.
They buy commercial products, adopt open-source components, commission software from external developers, outsource application operation and consume cloud services.
Each choice changes: what the organisation controls directly, what it must rely on a supplier to do, what evidence is available and what risks remain with the customer.
CISSP 8.4 therefore asks security professionals to assess the security impact of acquired software rather than assuming externally sourced technology is somebody else's problem.
Assess Before You Buy
Define requirements and investigate product and supplier risk before dependence develops.
SECURITY BEFORE CONTRACTDefine Responsibilities
Know what the supplier does, what the customer does and how assurance will be obtained.
OUTSOURCE WORK, NOT ACCOUNTABILITYManage the Lifecycle
Monitor vulnerabilities, support, supplier changes, incidents and eventual exit.
ACQUISITION IS NOT ONE-TIMEAssess Security Impact of Acquired Software
The current ISC2 CISSP Exam Outline explicitly names five acquisition categories.
Commercial software created for general sale or licensing rather than specifically built for one customer.
Software whose source is available under an open-source licence, often maintained by communities, foundations or commercial sponsors.
Software developed or supplied by an external organisation, including custom development and externally sourced components.
Services where an external provider operates or manages software or enterprise applications on the customer's behalf.
Official 8.4 Topics
Where 8.4 Fits
Integrate security throughout development.
WHEN?
Secure languages, tools, repositories, CI/CD and AppSec testing.
WHERE & WITH WHAT?
Assess whether software-security controls and mitigation work.
DOES IT WORK?
Assess security impact when software or services come from outside.
WHO BUILT / RUNS IT?
Define and apply secure coding guidelines and standards.
HOW SHOULD CODE BE WRITTEN?
Outsource the Work - Not the Accountability
A supplier may:
But the customer organisation still experiences the business consequences if the acquired technology exposes sensitive data, interrupts critical operations or violates requirements.
The Secure Software Acquisition Lifecycle
Define Security Requirements First
Security requirements should reflect the importance and intended use of the acquired software.
Required authentication, federation, MFA, privileged access and role-management capabilities.
Encryption, key-management expectations, data segregation, backup and secure deletion needs.
Required audit events, customer access to logs, retention and integration with monitoring systems.
How vulnerabilities are identified, reported, prioritized, fixed and communicated.
Expected update mechanisms, support timescales and customer responsibilities for deployment.
Whether secure defaults, hardening guidance and security-relevant settings are available.
Availability, recovery, backup and continuity needs appropriate to business criticality.
Personal-data handling, retention, sub-processors and other privacy requirements where applicable.
Security implications of APIs, identity federation, agents, connectors and network access.
Support duration, end-of-life notification, migration and exit expectations.
Due Diligence
Due diligence means obtaining enough relevant information about a product and supplier to make an informed acquisition decision.
Understand who the supplier is, important ownership/control relationships and who ultimately provides the service.
Understand where the software, components and service dependencies originate.
Assess relevant development, vulnerability management, access-control and operational security practices.
Consider vulnerabilities, incidents, patch behaviour and support track record in context.
Consider whether the supplier and service can withstand disruption and continue meeting critical obligations.
Understand important subcontractors, cloud dependencies and fourth parties where they materially affect risk.
Confirm supported versions, maintenance expectations and lifecycle plans.
Use evidence appropriate to risk - documentation, testing, attestations, certifications, reports, demonstrations or other assurance sources.
Due Diligence Memory Aid
Supplier Security Evidence
No single evidence type proves that acquired software is secure.
Can provide structured information about supplier practices, but answers may need validation and risk-based follow-up.
Can provide useful third-party assurance within its defined scope.
May demonstrate testing of a product or service under specified conditions.
Can provide supplier assertions about development practices, but the assurance level depends on the attestation and context.
Can improve visibility into software components and dependencies.
Shows how external researchers or customers can report security weaknesses.
Provides practical evidence of how the supplier communicates and responds to product security issues.
Can clarify security design, responsibility boundaries and required customer controls.
Security in Contracts and Agreements
Where appropriate, important security expectations should become explicit supplier obligations rather than informal assumptions.
Define which controls belong to supplier, customer and any shared operating process.
Define how material product or service vulnerabilities will be communicated.
Define how and when relevant security incidents are reported and coordinated.
Define support expectations and responsibilities for security fixes appropriate to the service.
Where appropriate, define evidence, reporting, audit rights or assurance information available to the customer.
Define relevant requirements for access, storage, location, retention, return and deletion.
Define expectations around important downstream providers or material service changes.
Address material changes that could alter the security posture or responsibility model.
Define transition support, data return/deletion and other exit obligations.
Document known gaps, compensating controls, ownership and residual-risk treatment.
Commercial-Off-The-Shelf - COTS
COTS software is a commercial product created for a broad market rather than developed specifically for one customer.
Established functionality, support, documentation and a larger user base may reduce development effort.
The customer usually cannot dictate the product architecture or internal implementation.
Security depends partly on how the organisation configures and integrates the product.
Patches, new features and support lifecycle may depend heavily on the supplier.
Widely deployed products can attract substantial attacker attention because one exploit may affect many customers.
Customers must balance security updates with compatibility, availability and change-management requirements.
"Everyone Uses It"
A business wants to purchase a popular enterprise application.
The vendor says: "More than 20,000 companies use our product, so security review is unnecessary."
Open-Source Software
Open-source software can be highly mature and widely trusted, or small, abandoned and poorly maintained.
The security assessment should therefore examine the actual project and usage context rather than assuming that "open source" is either inherently safer or inherently less secure.
Is the software actively maintained and are security fixes still being released?
Does the project depend on one or a very small number of maintainers?
Is the component obtained from the expected source using integrity-verifiable distribution mechanisms where available?
What direct and transitive components are introduced?
How are vulnerabilities reported, triaged and remediated?
Does the project provide supported versions, security policy and update guidance?
Can the organisation meet the software's licence obligations and usage constraints?
Who inside the organisation is responsible for updating, monitoring and eventually replacing the component?
🔓 Open Source: Transparency ≠ Automatic Security Visible code still needs review, maintenance and governance
Source availability can enable inspection, community review, independent fixes and transparency.
A project can still be under-resourced, abandoned, maliciously compromised, poorly designed or heavily dependent on vulnerable components.
Open-Source Adoption Memory Aid
Third-Party Software
Third-party software is a broad concept covering software supplied, developed or maintained by an external organisation.
A supplier may build a bespoke application specifically for the organisation.
The application may embed proprietary externally supplied libraries, SDKs or components.
Software may depend on externally operated APIs or services.
External developers may require controlled access to source repositories, environments and data.
Suppliers may receive privileged support access that creates additional identity and monitoring risk.
The customer may need evidence that the supplier uses secure development and vulnerability-management practices appropriate to risk.
🔗 Your Supplier Has Suppliers Too Third-party risk can contain fourth-party and sub-tier risk
Managed Services
In a managed service, an external provider performs operational responsibilities for software or an enterprise service.
Understand how provider administrators access customer systems and how privileged actions are authenticated and logged.
Define who patches, configures, monitors, backs up and restores each part of the service.
Define how provider and customer coordinate detection, investigation, notification and recovery.
Understand how provider-initiated changes are tested, approved, communicated and rolled back.
Define which reports, logs, assessments or other evidence are available to demonstrate service security.
Understand supplier recovery capabilities, dependencies and how service failure affects the organisation.
Understand which customer data the provider can access, process, store, back up or transfer.
Plan how operations, data and knowledge can transition to another provider or back in-house.
"They Manage Everything"
A business outsources operation of a critical enterprise application.
Management concludes: "The provider manages it now, so our security team no longer needs visibility."
Cloud Services
ISC2 explicitly gives three cloud-service examples: SaaS, IaaS and PaaS.
The crucial security distinction is how much of the technology stack the provider controls and how much remains under customer control.
SaaS
Customer consumes the provider's application.
LEAST STACK CONTROLPaaS
Customer deploys applications on a provider-managed platform.
CONTROL THE APPIaaS
Customer deploys workloads on provider-managed infrastructure.
CONTROL MORE OF THE STACKSaaS vs PaaS vs IaaS - Think About Control
| Layer | SaaS | PaaS | IaaS |
|---|---|---|---|
| Application | Mostly provider | Customer | Customer |
| Application Runtime / Platform | Provider | Mostly provider | Customer |
| Guest OS | Provider | Provider | Customer |
| Virtualization / Core Infrastructure | Provider | Provider | Provider |
| Customer Users / Data / Configuration | Shared responsibilities remain | Shared responsibilities remain | Shared responsibilities remain |
Software as a Service - SaaS
With SaaS, the customer consumes an application operated by the provider.
Can the service integrate with enterprise identity, MFA, lifecycle provisioning and privileged-access requirements?
Which security settings remain the customer's responsibility and are secure defaults available?
How is customer data accessed, stored, backed up, exported, retained and deleted?
Which audit records can the customer obtain and for how long?
APIs, connectors and marketplace extensions can create additional trust relationships.
The customer depends heavily on provider patching, application security and platform operation.
The provider may update features and architecture without the customer controlling each release.
Can data and configuration be exported in a usable form if the service is terminated?
Platform as a Service - PaaS
PaaS provides a managed platform on which the customer deploys applications.
Provider typically manages more of the operating platform, runtime and underlying infrastructure.
The customer remains responsible for its application code and application-level security.
The customer still determines how its application handles and protects business data.
Platform IAM and service permissions require secure customer configuration.
Databases, queues, secrets, functions and other managed services each introduce configuration and dependency considerations.
Runtime versions and platform deprecations can affect customer application security and supportability.
Infrastructure as a Service - IaaS
IaaS gives the customer more control over the workload stack and therefore more direct security responsibility.
Commonly secures physical infrastructure, core networking and virtualization layers.
Customer commonly configures, hardens and patches the guest OS.
Customer deploys and secures its own applications and services.
Customer must securely configure identities, roles, keys and administrative access.
Security groups, virtual networks, routing and exposure are commonly customer-configurable.
Customer decisions often determine encryption, keys, backup, retention and access patterns.
Cloud Shared Responsibility Memory Aid
Shared responsibility means divided responsibility - not equal responsibility.
"The Cloud Provider Secures It"
A company deploys an Internet-facing virtual machine in IaaS.
The guest operating system is unpatched and the customer configures a firewall rule allowing administrative access from the entire Internet.
SBOMs and Component Visibility
Acquired products can contain:
A Software Bill of Materials can help identify components and support vulnerability response.
Component transparency is useful evidence. It does not prove secure architecture, secure configuration, secure custom code or absence of unknown vulnerabilities.
Vulnerability & Patch Management
May identify, fix and communicate product vulnerabilities.
Must determine whether affected software is used, assess exposure and apply the required remediation under its control.
Incident coordination, prioritization, testing and deployment may require cooperation.
If fixes will no longer be supplied, replacement, isolation or other risk treatment may be required.
⏳ End of Life & End of Support Supplier lifecycle becomes customer risk
When a supplier stops supporting software:
Supplier Risk Changes Over Time
Acquisition or restructuring can alter supplier governance, jurisdiction, strategy or capability.
A supplier under pressure may reduce security investment, support or staffing.
Service dependencies can change the data path, control environment and resilience model.
A previously on-premises product may move to SaaS or introduce new cloud dependencies.
Patch frequency, response quality or product investment may deteriorate.
A supplier breach can materially change the risk assessment and require additional controls or reconsideration.
Acquired Software Lifecycle Memory Aid
Exit Strategy & Vendor Lock-In
Security planning should consider how the organisation can stop using the product or service.
Can customer information be exported in a usable format?
Can important configuration, policy and metadata be migrated?
Can supplier accounts, tokens, integrations and certificates be revoked cleanly?
How will customer data and backups be deleted when retention obligations permit?
Will the supplier provide reasonable assistance during migration?
Are there realistic alternative products or architectures?
Can operational knowledge and documentation move to the replacement team or supplier?
Can the customer obtain required records before access to the old service ends?
The Cheapest Product Fails a Mandatory Security Requirement
Product A is cheapest but cannot meet the organisation's required authentication and logging controls.
Product B costs more and meets the requirements.
Assurance Should Be Risk-Based
Limited business impact and no sensitive information may justify lighter due diligence and assurance.
Sensitive personal information and broad user access justify stronger security, privacy, IAM and incident requirements.
High confidentiality, integrity, availability and regulatory impact justify deep product and supplier assurance.
🧠 45 CISSP Practice Scenarios COTS, open source, third-party, managed services and cloud
An organisation needs accounting software quickly and chooses a widely sold commercial package with standard features.
Which official 8.4 category?
Commercial-off-the-shelf - COTS.
A vendor says the product is secure because thousands of other organisations use it.
CISSP response?
Popularity is not security evidence; assess the product and supplier against the organisation's requirements and risk.
A COTS product cannot support the organisation's required MFA method.
Best action before purchase?
Assess the gap, available compensating controls and residual risk before acquisition rather than discovering it after deployment.
A supplier will not provide source code for a proprietary product.
Does this automatically make the product insecure?
No. Proprietary/COTS software can still be assessed using available evidence, testing, assurance, contractual commitments and operational controls.
A commercial product is approaching end of support in six months.
What should acquisition consider?
Lifecycle and supportability risk, including patch availability, migration effort and replacement planning.
An open-source library has public source code and a permissive licence.
Does source availability prove security?
No. Transparency can enable review, but it does not guarantee maintenance, secure design or absence of vulnerabilities.
A critical open-source project has one volunteer maintainer and infrequent releases.
Primary acquisition concern?
Maintenance and resilience risk should be assessed along with technical security.
An open-source component has no known vulnerabilities today.
Is the acquisition assessment complete?
No. Consider provenance, maintenance, dependency risk, licence obligations, update path and future vulnerability response.
A team downloads an open-source package from an unofficial mirror rather than the project's expected distribution channel.
Which concern?
Provenance and integrity of the acquired component.
A package is free of charge.
Does that mean it has no acquisition or lifecycle cost?
No. Integration, maintenance, patching, assurance, support and replacement still create cost and risk.
A third party develops custom software specifically for the organisation.
Who owns the security risk?
The organisation remains accountable for the risk even though development is outsourced.
A vendor contract says only 'supplier will use industry-standard security.'
What is the weakness?
The security requirement is vague and difficult to verify or enforce.
A high-risk supplier refuses to disclose its vulnerability notification process.
What should the acquirer do?
Treat the lack of evidence as relevant acquisition risk and investigate or require appropriate commitments before relying on the product.
A supplier can remotely administer a critical application using permanent shared credentials.
Primary concern?
Supplier privileged access and accountability require stronger controls.
A vendor uses subcontractors to operate parts of the service but the customer does not know who they are.
Which risk?
Fourth-party/sub-tier dependency risk and reduced visibility into the service supply chain.
A supplier passes a security questionnaire once during procurement and is never reassessed for ten years.
What is wrong?
Third-party security is lifecycle risk; supplier, product and threat conditions can change after acquisition.
A vendor suffers a breach affecting the customer's service but has no contractual incident-notification timeframe.
What acquisition issue?
Security incident notification expectations should have been defined before the event.
A supplier releases a critical patch, but the customer does not deploy it for months.
Is the vendor solely responsible?
No. Acquired-software security often requires actions from both supplier and customer.
A supplier promises patches but gives no support lifecycle or end-of-life notice.
Why does this matter?
The customer cannot plan security maintenance and replacement reliably.
A procurement team wants evidence about a supplier's development and vulnerability-management practices.
Useful approach?
Risk-based due diligence and assurance evidence appropriate to the importance of the software.
A supplier provides an SBOM.
What does the SBOM prove?
It improves component transparency but does not prove that the software is secure.
A supplier has a vulnerability disclosure policy and clear channel for researchers.
What does this support?
Evidence of a process for receiving and handling vulnerability reports, though effectiveness still needs consideration.
A vendor says its product has never had a vulnerability.
CISSP interpretation?
Treat the claim cautiously; absence of disclosed vulnerabilities is not strong proof of security.
A managed service provider operates an enterprise application for the customer.
Which official 8.4 category?
Managed services.
A managed-service contract clearly defines availability but says nothing about logging, privileged access or incident handling.
Primary problem?
Security responsibilities and assurance requirements are incomplete.
A customer outsources operation of a security-sensitive service and stops monitoring it entirely.
CISSP response?
Outsourcing operations does not remove the need for governance and oversight.
A managed service uses a downstream cloud provider.
What should the customer consider?
Dependencies and sub-tier providers can affect security, resilience, data handling and contractual responsibilities.
A customer buys a SaaS HR platform.
What does the provider generally control more than the customer?
The application and much of the underlying platform/infrastructure, while the customer still controls areas such as users, data use and configuration available to it.
A SaaS customer assumes the provider will automatically configure the customer's user roles correctly.
What principle is missed?
Shared responsibility; the customer remains responsible for the controls under its control.
An organisation uses PaaS to deploy its own application.
What typically remains with the customer?
The customer retains significant responsibility for its application, data, identities and configuration while the provider manages more of the platform.
An organisation runs virtual machines in IaaS.
What changes compared with SaaS?
The customer controls and secures more of the stack, commonly including guest OS, applications, identities and configurations.
A cloud provider is certified against a recognised standard.
Does certification transfer all responsibility to the provider?
No. Certification is useful evidence but does not remove customer responsibilities or prove the customer's configuration is secure.
A cloud contract does not define how customer data will be returned or deleted at termination.
Which acquisition concern?
Exit, data portability and secure disposal should be considered before dependence develops.
A SaaS provider allows only 30 days of audit-log retention, while the customer requires one year for investigations.
Best time to identify this gap?
Before acquisition or contract commitment.
A cloud service does not support integration with the customer's identity provider.
What should happen?
Assess whether the service can meet IAM requirements or whether compensating controls and residual risk are acceptable before adoption.
A supplier hosts customer data in locations the customer did not expect.
Why can this matter?
Data location can affect legal, contractual, privacy, resilience and operational requirements and should be understood as part of acquisition.
A vendor's product includes many third-party and open-source components.
Which lesson?
Acquired software can contain its own supply chain; supplier software is not necessarily wholly supplier-written.
A critical product has no feasible replacement and proprietary data formats make migration extremely difficult.
Which risk?
Vendor lock-in and exit risk can increase operational and security exposure.
A supplier changes ownership and its support capability deteriorates.
Why reassess?
Supplier risk can change even when the software itself has not changed.
The cheapest product cannot meet mandatory security requirements, while a slightly more expensive product can.
CISSP procurement view?
Security requirements and risk should influence acquisition decisions rather than price alone.
A business owner wants to deploy a third-party SaaS tool before security review because 'no software is installed locally.'
CISSP response?
SaaS is still acquired software/service and can create data, identity, integration and supplier risk.
A product fails one security requirement but a strong compensating control reduces the risk to an accepted level.
Can it ever be acquired?
Potentially, if the residual risk is understood and accepted by the appropriate authority according to organisational governance.
Which five categories are explicitly listed in current CISSP 8.4?
Answer?
COTS, open source, third-party, managed services and cloud services including SaaS, IaaS and PaaS.
What is the most important lifecycle principle for acquired software?
Best answer?
Assess before acquisition, define responsibilities, monitor throughout use, manage updates and vulnerabilities, and plan for exit or end of support.
Management asks for the central purpose of CISSP 8.4.
Best answer?
Assess the security impact of software and services the organisation does not fully build or control, then manage supplier, product, service and lifecycle risk accordingly.
Recognise the Clue Words
Packaged Commercial Product
Standard product sold to many customers.
COTSPublic Source Code
Externally maintained software.
Open SourceExternal Developer / Supplier
Software created outside the organisation.
Third-PartyProvider Operates the Application
Operations outsourced.
Managed ServiceHosted Application Consumed Directly
Customer manages least of the stack.
SaaSProvider Platform + Customer App
Shared application-development platform.
PaaSVirtual Machines / Customer OS
Customer controls more of the stack.
IaaSBefore Contract
Investigate product and supplier.
Due DiligenceSecurity Requirements in Purchase
Make expectations explicit.
Acquisition RequirementsSupplier Uses Subcontractor
Dependency behind the vendor.
Fourth Party / Sub-TierList of Components
Software transparency.
SBOMHow Will Vulnerabilities Be Reported?
Supplier vulnerability process.
Disclosure / NotificationHow Fast Are Patches Supplied?
Maintenance expectation.
Patch / Remediation CommitmentProduct Near End of Support
Lifecycle risk.
EOL / EOSCan We Leave the Service?
Avoid unmanaged dependence.
Exit StrategyCustomer + Provider Duties
Cloud control boundary.
Shared ResponsibilityProvider Certification
Assurance input.
Evidence, Not GuaranteeFree Package
Still needs governance.
Open Source ≠ No RiskVendor Builds It
Risk still belongs to customer.
Accountability RetainedCheapest Product
Cost is not the only criterion.
Risk-Based Acquisition⚠️ Common CISSP Mistakes Acquired software changes control - not accountability
Large adoption may provide useful market evidence, but it does not prove the product meets the organisation's security requirements.
A secure product can still be deployed insecurely through weak configuration, permissions or integrations.
Public source code does not inherently make software insecure.
Potential visibility is not the same as actual review, maintenance or secure design.
Open-source use can create integration, maintenance, assurance, licensing, support and replacement costs.
Unknown, undisclosed or newly introduced weaknesses may still exist.
An SBOM provides component transparency; it does not certify that the product is secure.
Self-attestation can be useful evidence but should be interpreted in context.
A questionnaire is one information source and may not adequately cover high-risk acquisitions.
The organisation still owns the business impact and must manage residual risk.
A contractual requirement creates an obligation; assurance is still needed that the requirement is being met.
A provider's certification does not automatically cover every service, configuration or customer responsibility.
Outsourced operation still requires governance, assurance and performance/security monitoring.
Cloud changes the control boundary; it does not transfer all security responsibility.
Customers commonly retain responsibility for users, access, data use, configuration and integrations.
PaaS gives the customer responsibility for applications deployed on the provider-managed platform.
In common IaaS models the customer retains substantial responsibility for workloads, operating systems and application configuration.
The split varies by service model, provider and contract.
Supplier, product, vulnerability and support conditions change over time.
The customer may still need to assess, test and deploy the patch.
Unsupported software can become a structural risk requiring replacement or isolation.
Exit difficulty can become a security and resilience problem.
Fourth parties can affect data, operations, resilience and incident response.
8.2 secures the development ecosystem used to build software. 8.4 assesses software and services acquired from external sources.
8.4 applies acquisition security specifically to software and software services; broader enterprise supply-chain risk appears elsewhere in CISSP too.
Quick Reference
| If you see... | Think... |
|---|---|
| Commercial packaged application | COTS |
| Source available under open licence | Open Source |
| Externally developed software | Third-Party |
| Provider operates enterprise application | Managed Service |
| Hosted application used by customer | SaaS |
| Provider platform, customer deploys app | PaaS |
| Provider infrastructure, customer manages VM/workload | IaaS |
| Investigate supplier before purchase | Due Diligence |
| Define security before contract | Acquisition Requirements |
| Supplier's supplier | Fourth Party / Sub-Tier |
| Component inventory | SBOM |
| Patch and vulnerability expectations | Supplier Security Obligations |
| Product no longer supported | EOL / EOS Risk |
| Provider/customer control split | Shared Responsibility |
| How to retrieve data and leave | Exit Strategy |
| Difficult proprietary migration | Vendor Lock-In |
| Vendor says it is certified | Assurance Evidence, Not Guarantee |
| One-time supplier questionnaire | Insufficient Lifecycle Oversight |
| External provider suffers incident | Incident Notification / Coordination |
| Vendor built it | Organisation Still Owns Risk |
Five Official Acquisition Categories
8.4 Master Memory Aid
Buy carefully → define responsibility → verify continuously → leave safely.
The Software Acquisition Leader's Questions
Key Takeaways
CISSP 8.4 is: Assess security impact of acquired software.
The current ISC2 outline explicitly includes: Commercial-Off-The-Shelf - COTS, open source, third-party software, managed services and cloud services including SaaS, IaaS and PaaS.
The central principle is: externally sourced software changes who performs controls, but it does not remove the customer's need to understand and manage risk.
Organisations rarely control the complete software supply chain.
Acquired products may contain supplier-written code, commercial components, open-source libraries, cloud services and downstream providers.
Supplier trust should therefore be evidence-based and risk-based.
Secure acquisition begins before procurement.
Define important security requirements before selecting the product so candidates can be assessed consistently.
Requirements may include identity, access control, MFA, logging, encryption, vulnerability handling, patching, resilience, data protection, integrations and lifecycle support.
A product that cannot meet a mandatory requirement creates a risk decision.
The organisation may need a different product, a compensating control, a contractual commitment or formal treatment of residual risk.
Due diligence investigates the supplier and product sufficiently to support an informed decision.
Supplier identity, provenance, security practices, resilience, supportability, dependencies and assurance evidence can all be relevant.
Due diligence should be proportionate to risk.
A low-impact internal utility does not require the same acquisition assurance as a core banking platform.
A questionnaire can be useful evidence.
But: questionnaire ≠ complete due diligence.
Certifications, independent reports, supplier attestations, SBOMs, security test results, vulnerability policies and architecture documentation can also provide useful evidence.
But no single artifact proves that the acquired software is secure.
COTS means commercial software created for a broad market rather than specifically for one customer.
COTS can reduce development effort and provide established support.
But customers have less control over internal architecture, implementation and vulnerability-remediation schedules.
COTS security therefore depends heavily on product selection, vendor capability, secure configuration, integration and maintenance.
Popularity is not proof of security.
Widely deployed COTS products can also become attractive attacker targets because one vulnerability may affect many customers.
Open-source software should not be classified as automatically secure or insecure.
Source availability can enable transparency and independent review.
But: visible source ≠ reviewed source.
Evaluate the actual project's maintenance, provenance, dependencies, vulnerability process, support model and licence.
Open-source software may be free to acquire but still creates lifecycle cost.
Somebody must monitor vulnerabilities, test updates, manage compatibility and replace the component when necessary.
Third-party software includes externally developed or supplied applications and components.
A supplier developing custom code should still be expected to satisfy security requirements appropriate to the product's risk.
External developers and support teams can also create privileged-access risk to source repositories, build systems, production environments and business data.
Supplier access should therefore be authenticated, authorized, monitored and removed when no longer required.
Suppliers can depend on other suppliers.
These fourth-party or sub-tier relationships can affect data handling, resilience, incident response and security.
Trust is not automatically transitive.
A supplier's claim that its subcontractor is secure is not necessarily sufficient evidence for a high-risk dependency.
Managed services transfer operational tasks to an external provider.
They do not eliminate customer governance.
Define responsibility for privileged access, patching, monitoring, backups, change management, incident response, recovery and data handling.
Security obligations are easier to manage when they are explicit.
Contracts and service agreements can address relevant security responsibilities, vulnerability notification, incident notification, patching, evidence, data handling, subcontractors, service changes and exit.
But: contract ≠ proof that the control is operating.
Ongoing assurance remains necessary.
Cloud services are also acquired software/service relationships.
SaaS, PaaS and IaaS differ primarily in how control of the technology stack is divided.
With SaaS, the provider operates most of the application stack.
The customer still commonly controls important areas such as users, access, configuration, integrations and how customer data is used.
With PaaS, the provider manages more of the platform while the customer develops and secures its application.
With IaaS, the provider manages underlying infrastructure while the customer normally controls and secures more of the workload stack.
Therefore: more customer control usually means more customer security responsibility.
Shared responsibility does not mean equal responsibility.
The exact split depends on the service model, product and contract.
A provider can secure its cloud infrastructure while the customer configures an insecure workload.
Provider certification does not automatically make the customer's use secure.
Certifications and independent assurance are evidence within a defined scope.
Customers still need to understand what the assurance covers and what remains their responsibility.
Acquired software can contain its own software supply chain.
SBOMs can improve visibility into those components.
But: SBOM ≠ security certification.
Vulnerability management continues after acquisition.
Suppliers may produce security advisories and fixes.
Customers still need to determine whether they use the affected product, assess exposure, test remediation and deploy changes under their responsibility.
Patch available ≠ patch deployed.
End-of-life and end-of-support dates are security concerns because future vulnerabilities may no longer receive fixes.
Products approaching end of support should trigger migration or other risk-treatment planning before support actually ends.
Supplier risk also changes over time.
Ownership changes, financial distress, new subcontractors, security incidents, architecture changes and declining support can all alter the risk profile.
Third-party assessment should therefore be lifecycle-based rather than a one-time procurement questionnaire.
Exit strategy matters.
Before becoming dependent on a supplier, consider how data, configuration, identities, operations and evidence can be migrated or removed.
Vendor lock-in can become a security and resilience problem when an organisation cannot leave an insecure or unsupported supplier without unacceptable disruption.
The secure acquisition lifecycle is:
define requirements → investigate supplier and product → assess risk → establish obligations → onboard securely → monitor → patch and reassess → exit safely.
Remember the Domain 8 boundaries:
8.1 = integrate security through the lifecycle.
8.2 = secure the development ecosystem and perform AppSec testing.
8.3 = assess whether software security is effective.
8.4 = assess security impact of acquired software and services.
8.5 = define and apply secure coding guidelines and standards.
The central CISSP principle for 8.4 is:
know what you are acquiring, know who you are depending on, define which security responsibilities belong to whom, obtain evidence appropriate to the risk, monitor the relationship throughout its lifecycle and retain a safe path to exit.
📚 Sources & Further Reading Current acquisition, supplier-risk, cloud and software supply-chain references
- ISC2 - CISSP Certification Exam Outline
View the current CISSP Exam Outline - NIST SP 800-161 Rev. 1 Update 1 - Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations
View NIST C-SCRM guidance - NIST SP 1326 - Cybersecurity Supply Chain Risk Management: Due Diligence Assessment Quick-Start Guide
View the final 2026 NIST due-diligence guide - NIST SP 800-218 - Secure Software Development Framework - SSDF Version 1.1
View NIST SSDF - NIST SP 800-145 - The NIST Definition of Cloud Computing
View NIST cloud-service definitions - NIST SP 500-292 - NIST Cloud Computing Reference Architecture
View the NIST cloud reference architecture - CISA - Secure by Demand Guide: How Software Customers Can Drive a Secure Technology Ecosystem
View CISA Secure by Demand guidance - CISA - Software Acquisition Guide for Government Enterprise Consumers
View CISA software-acquisition guidance - CISA / Enduring Security Framework - Managing Open Source Software and Software Bill of Materials
View open-source and SBOM supply-chain guidance