Secure custom software: a buyer’s due-diligence checklist

A software buyer inherits more than visible features. They inherit architectural decisions, third-party dependencies, deployment practices, support processes, and the supplier’s ability to respond when vulnerabilities are discovered.

NIST’s Secure Software Development Framework provides a useful procurement language across four areas: prepare the organization, protect the software, produce well-secured software, and respond to vulnerabilities. OWASP’s 2025 Top 10 adds current application-risk priorities including broken access control, security misconfiguration, and software supply-chain failures.

Questions to ask before contract signature

• —How are security requirements, threat models, privacy obligations, and abuse cases included in design?
• —How are authorization rules tested on the server rather than trusted to the user interface?
• —How are source code, build pipelines, secrets, release artifacts, and production access protected?
• —How are open-source dependencies inventoried, reviewed, updated, and monitored for vulnerabilities?
• —Which security tests run during development, before release, and after material changes?
• —What logs are available to customers, and how are security events investigated and retained?
• —What vulnerability disclosure, triage, remediation, notification, and support commitments apply?

Ask for evidence that matches the risk

Evidence may include architecture decisions, test summaries, dependency inventories, access reviews, deployment approvals, restoration results, incident procedures, and remediation records. The depth should reflect the system’s data, exposure, business criticality, and regulatory context.

Secure procurement makes responsibilities explicit before delivery pressure begins. It also gives the supplier and buyer a shared definition of what secure operation will require throughout the product lifecycle.