Acquiring software securely and AI-assisted development

Most of the software an organization runs was not written by its own developers. It buys commercial products, subscribes to software as a service, adopts open source applications, hires contractors to build custom systems, lets business users assemble applications on low-code platforms and, increasingly, has developers write code with the help of AI assistants. The CISSP objective 'assess the security impact of acquired software' asks managers to evaluate and control the risks that come with each of these routes. This lesson covers the acquisition routes, the due diligence and contract terms that manage their risks, and the specific questions raised by AI in development.

Acquisition routes and their risks

The common thread is that buying software transfers some work to others but never transfers accountability. If a SaaS provider leaks customer data, the organization that collected the data still answers to regulators and customers. Due diligence before purchase and oversight afterwards are therefore part of due care.

Due diligence before acquisition

Security assessment should begin when requirements are written, not after a product has been chosen. The requirements for an acquisition should include security requirements derived from the data the software will handle and the risks of the business process, such as support for the organization's single sign-on and multifactor authentication, role-based access, audit logging that can be exported to the SIEM, encryption, data residency, and timely security patches. Products that cannot meet mandatory requirements should be eliminated early, before the business becomes attached to them.

Supplier assessment draws on several kinds of evidence. Security questionnaires, ideally based on standards such as the Cloud Security Alliance's CAIQ or the Shared Assessments SIG, collect the supplier's own statements. Independent attestations carry more weight: a SOC 2 Type II report describes the operating effectiveness of a service organization's controls over a period, usually twelve months, as tested by an independent auditor; ISO/IEC 27001 certification shows that an information security management system meets the standard. Reports must be read, not just collected: check the scope, the period, exceptions found by the auditor and the complementary user entity controls the customer must perform. For software products, ask about the supplier's secure development practices, such as alignment with the NIST SSDF, SBOM availability, vulnerability disclosure policy, average time to fix critical vulnerabilities and support lifetime. Where the risk justifies it, the organization can test the product itself or commission a third-party assessment, within the limits the licence allows.

Public sector buyers add their own frameworks. In Canada, the Government of Canada assesses cloud services against its cloud security profile based on the Cyber Centre's ITSG-33 control catalogue and relies on assessments under the Canadian Centre for Cyber Security's cloud service provider program, and it is introducing the Canadian Program for Cyber Security Certification for defence suppliers. Provincial governments and Crown corporations often require similar assurances. Private sector buyers in regulated industries, such as federally regulated financial institutions under OSFI Guideline B-10, must perform risk-based due diligence and keep oversight of material third-party arrangements throughout their life.

# Weighted supplier security assessment for a SaaS candidate (illustrative weights and scores 0-5)
criteria = {
    'SSO and MFA support':            (0.15, 5),
    'Independent attestation (SOC 2 Type II, ISO 27001)': (0.20, 4),
    'Secure development evidence (SSDF, SBOM)': (0.15, 2),
    'Vulnerability disclosure and patch times': (0.15, 3),
    'Logging and SIEM export':        (0.10, 4),
    'Data residency and encryption':  (0.15, 5),
    'Exit: data return and deletion': (0.10, 2),
}
mandatory = {'SSO and MFA support': 3, 'Data residency and encryption': 4}
score = sum(w * s for w, s in criteria.values())
fails = [k for k, minimum in mandatory.items() if criteria[k][1] < minimum]
print(f'Weighted score: {score:.2f} / 5')
print('Mandatory criteria met' if not fails else 'Mandatory failures: ' + ', '.join(fails))
weak = [k for k, (w, s) in criteria.items() if s <= 2]
print('Address in contract or compensate:', '; '.join(weak))

Weighted score: 3.65 / 5
Mandatory criteria met
Address in contract or compensate: Secure development evidence (SSDF, SBOM); Exit: data return and deletion

Contract terms

The contract is where security expectations become enforceable. Security schedules or addenda commonly cover: compliance with stated security standards; notification of security incidents within a defined time; the right to audit or to receive independent audit reports annually; vulnerability management commitments, including maximum times to fix critical vulnerabilities and notification of vulnerabilities affecting the customer; provision of SBOMs on request; data location, encryption, return and deletion at the end of the contract; restrictions on subcontractors; background checks for personnel with access; cooperation in investigations; and the supplier's support lifetime for each version. For custom development, contracts should also state who owns the source code, require delivery of source and build instructions, prohibit undisclosed functionality such as backdoors and time bombs, require the contractor to follow the organization's secure coding standard, and define security acceptance testing before payment.

Software escrow addresses the risk that a supplier goes out of business or stops supporting a critical product. The supplier deposits source code, build instructions and documentation with a neutral escrow agent, to be released to the customer if defined events occur. Escrow is only useful if the deposit is kept current and verified, and if the customer has or can obtain the skills to maintain the code.

Operating acquired software

After purchase, the organization must keep doing its part. That includes secure configuration (default settings in commercial products and SaaS tenants are often permissive), applying vendor patches promptly, monitoring the supplier's security notices, reviewing SaaS configuration regularly with tools such as SaaS security posture management, reviewing user access, integrating logs, and reassessing the supplier periodically and after significant incidents. CISSP-112 and CISSP-116 cover configuration and patch management. Under the shared responsibility model, a SaaS provider secures its platform, but the customer remains responsible for who can access its tenant, how the tenant is configured and what data is placed there.

Low-code platforms and citizen developers

Low-code and no-code platforms let business users build applications, automations and integrations with little or no traditional programming. They deliver real value, but they also create applications that no developer has reviewed, connect to sensitive data with the creator's own permissions, and multiply quickly beyond the knowledge of IT. Governance should include an inventory of citizen-built applications, environment separation between personal experiments and business-critical solutions, data loss prevention policies that restrict which connectors can be combined, least-privilege service connections rather than personal credentials, a review path for applications that become important, and training for citizen developers. OWASP has published a Top 10 for low-code and no-code risks that is a useful checklist.

AI-assisted development

AI coding assistants based on large language models suggest code, explain unfamiliar code, write tests and can carry out multi-step development tasks as agents. Surveys show most developers now use them. They can raise productivity, and they can also introduce new risks that a manager must govern.

The guiding principle is that AI-generated code is code like any other and enters the product only through the same controls: review by an accountable human, automated scanning, tests and the security gate. The organization should publish an acceptable use policy that names approved tools, states what data may be shared with them, and requires that the developer who merges code is responsible for it regardless of its source.

Organizations that build AI features into their own products face further risks. The OWASP Top 10 for Large Language Model Applications (2025 edition) lists risks such as prompt injection, sensitive information disclosure, supply chain risks in models and datasets, excessive agency and improper output handling. Models and datasets are now part of the software supply chain: they should be obtained from trusted sources, inventoried (some organizations extend their SBOMs into AI bills of materials), scanned where possible and documented with model cards. NIST SP 800-218A, finalized in 2024, extends the SSDF with practices for developing generative AI and dual-use foundation models. AI-430 and AI-460 cover AI safety, evaluation and responsible AI in depth.