Software Developer Security Due Diligence for Product Owners

Evaluate product security capability, not confident vocabulary

When hiring a software developer, security due diligence should establish whether the person or team can recognize the product's risks, translate them into engineering work, produce credible evidence, and leave the owner able to operate safely. It should not become a trivia test or a request for an impossible guarantee. Strong candidates explain boundaries, tradeoffs, responsibilities, and verification in the context of the proposed system rather than reciting a list of tools.

Separate enterprise security from product security. A provider may protect its own laptops and accounts while delivering an application with weak authorization, unsafe recovery, or no update plan. Conversely, a small independent developer may not carry every enterprise certification but can demonstrate disciplined client-owned infrastructure, threat-aware design, review, testing, monitoring, and handover. CISA's Secure by Demand guidance encourages buyers to examine how suppliers take responsibility for customer security outcomes, communicate transparently, and build security into the product lifecycle.

Begin with a concise product risk brief for every candidate. Identify users, organizations, sensitive information, privileged actions, integrations, availability needs, likely abuse, regulatory context, and the harm caused by failure. Ask each candidate to clarify the brief before proposing controls. Their questions reveal more than a yes-or-no response about “best practices.” A developer who immediately promises complete security without asking what must be protected has not yet scoped the work.

Ask for an architecture and ownership walkthrough

Request a simple system boundary covering clients, application services, databases, file storage, background work, identity, administrators, and external providers. Ask where trust changes and where authorization is enforced. Use one realistic action—such as a customer downloading a file or a manager approving a payment—and have the candidate trace identity, permission, validation, data access, audit evidence, failure, and recovery from start to finish.

Listen for explicit server-side authorization and organization isolation. Hiding a button in the interface does not prevent a direct request. A strong explanation identifies the actor, requested operation, target resource, organization boundary, current state, and policy decision. It also addresses indirect paths such as exports, search, file URLs, background jobs, administrative tools, and notifications. Ask how tests would prove that one customer cannot access another customer's resource even if an identifier is discovered.

Clarify ownership before implementation. The business should normally control its domain, source repository, cloud project, production data, payment account, email service, analytics, and app-store accounts, with named access granted to the developer. Require individual identities, multifactor authentication where supported, least privilege, and an owner-controlled recovery route. The proposal should say who creates each resource, who pays recurring charges, who can deploy, and how the developer's access can be revoked without disabling the product.

Inspect secure-development evidence in proportion to risk

NIST's Secure Software Development Framework organizes practices around preparing the organization, protecting software, producing well-secured software, and responding to vulnerabilities. Use those areas to structure the interview without demanding the same paperwork from every project. Ask how requirements and risks are recorded, source and build access are protected, changes are reviewed, dependencies are managed, releases are identified, and reported weaknesses are assessed and corrected.

Request sanitized examples rather than customer secrets: a security acceptance criterion, a pull-request review, a dependency-risk decision, an authorization test, a deployment record, or an incident learning note. Evidence should show reasoning and follow-through, not only tool output. A scanner can identify known patterns but cannot decide whether a support user should see a particular record or whether an account-recovery route matches business policy. Ask who interprets signals and how unresolved findings affect release.

OWASP SAMM offers a maturity model spanning governance, design, implementation, verification, and operations. It can help a buyer ask balanced questions, but maturity should fit the engagement. A short low-risk public tool may use lightweight records and automated checks. A multi-tenant platform handling confidential documents needs deeper architecture review, access testing, operational monitoring, and response planning. Due diligence should reveal a deliberate level of rigor, not reward the largest collection of process labels.

Test how the developer reasons about common failure paths

Present a scenario that matches the product. For a client portal, ask what happens when an invited email address belongs to the wrong person, a staff member changes organizations, a file link is forwarded, an upload contains unexpected content, or an administrator loses access. For an integration, ask about duplicate delivery, expired credentials, a timeout after the provider completed the action, and a malicious remote payload. Require both prevention and recovery, because real systems eventually encounter partial failure.

Evaluate identity recovery closely. The candidate should distinguish verification, authentication, authorization, and administrative override. Ask who can reset access, what evidence is required, whether sensitive changes trigger reauthentication or notification, and how a compromised administrator is handled. Shared administrator credentials and developer-controlled owner accounts are serious warning signs. Recovery that depends entirely on the same lost mailbox or one unavailable developer is not a complete recovery route.

Ask where sensitive information could escape outside the primary database. Mature answers include browser storage, URLs, logs, error trackers, analytics, support attachments, email, backups, exports, test data, AI tools, and third-party integrations. The developer should minimize collection, separate environments, protect secrets, restrict access, and define retention. Encryption matters, but it does not correct excessive data collection, broad permissions, or confidential content copied into an uncontrolled log.

Define verification and acceptance before signing

Turn important risks into acceptance evidence within the proposal. Evidence may include automated tests for authorization and business rules, manual abuse cases, configuration inspection, a dependency report with documented triage, an audit-log demonstration, a backup restoration, accessibility evaluation, or a qualified independent assessment where consequence warrants it. The acceptance plan should state who performs each check, in which environment, when remediation is verified, and what remains explicitly outside scope.

The OWASP Application Security Verification Standard can provide detailed application-security requirements and a basis for procurement. Reference a specific version and selected controls appropriate to the system rather than requesting vague “OWASP compliance.” A credible developer will help map product risks to relevant requirements, note exclusions, and explain evidence. They should not claim that one automated scan proves an entire application conforms to a standard.

Require demonstrations against meaningful negative cases. A successful login is not evidence of tenant isolation; attempt access with the wrong user and a directly supplied identifier. A file upload completing is not evidence of safe handling; test size, type, authorization, interrupted processing, and retrieval. A backup job completing is not evidence of recovery; restore representative data into an isolated environment. Security acceptance becomes useful when it observes the promised boundary under pressure.

Price continuing responsibility and incident readiness

Security work continues after release because dependencies, platforms, staff, threats, and product behavior change. The proposal should assign monitoring, alerts, dependency updates, platform upgrades, access reviews, backup checks, certificate and domain renewals, vulnerability intake, and emergency deployment. Ask what maintenance window and response arrangement the quoted price includes. A low build price can conceal an owner who has no practical way to keep the product current.

Walk through a suspected incident. Determine who receives the report, preserves evidence, limits further harm, identifies affected users and data, restores service, communicates with accountable owners, and verifies correction. Do not expect a developer to replace legal, privacy, insurance, or specialist incident roles. Expect them to know their technical responsibilities, escalate uncertainty, preserve useful logs without unnecessary sensitive content, and maintain a reachable path for urgent product issues.

Define response expectations realistically. A solo developer cannot honestly promise continuous instant response without an arrangement that supplies coverage. A larger agency does not automatically provide effective escalation because it has more employees. Compare named responsibility, availability, access, documentation, and rehearsal. The right model matches the consequence of downtime or exposure and gives the owner a fallback when the primary person is unavailable.

Require a secure and usable handover

List handover artifacts in the contract: current source, build and deployment instructions, environment inventory, data-flow overview, role model, production access procedure, secret locations without copying secret values into documents, backup and restoration process, monitoring, integration ownership, known risks, open findings, dependency status, and recovery contacts. Documentation should be tested by someone other than its author before final acceptance.

Confirm that the owner can export its data, view billing, rotate access, deploy a known version, and engage another qualified engineer. Identify proprietary components, licenses, vendor-owned accounts, and restrictions before they become embedded. A custom application is not meaningfully owned if the buyer possesses source files but lacks the infrastructure, data access, release knowledge, or legal right needed to run them.

Schedule access removal as part of handover. Replace shared credentials, revoke individual accounts that are no longer needed, review service identities, rotate exposed or transferred secrets, and preserve audit history. Avoid deleting the evidence required to understand past changes. The objective is a stable responsibility transition, not an abrupt disconnection that leaves scheduled jobs, certificates, or emergency access without an owner.

Compare candidates with an evidence-based scorecard

Score risk understanding, architecture clarity, authorization design, account ownership, development controls, verification, data handling, operations, incident response, handover, communication, and commercial fit. Weight each category according to the proposed product. Mark unsupported answers as unknown and separate correctable process gaps from hard ownership or integrity concerns. A polished security deck should not outweigh weak answers about the actual system.

Use the same scenario and follow-up questions for finalists. Ask what they would do, what evidence they would produce, what the client must own, what requires a specialist, and what remains uncertain. Favor candidates who expose assumptions and scope validation work over those who make every risk sound easy. Security competence includes knowing when the consequence requires privacy counsel, a penetration tester, an accessibility specialist, or a cloud-security review beyond the developer's own expertise.

Pair this evaluation with the application security requirements checklist and the software development proposal checklist. Share the product boundary, sensitive data, critical actions, current infrastructure, and desired ownership through the project questionnaire, or use quick contact to discuss a focused security and architecture review before committing to a build.

Authoritative references

• CISA Secure by Demand Guide
• NIST Secure Software Development Framework
• OWASP Software Assurance Maturity Model
• OWASP Application Security Verification Standard

Related software planning guides

• Application Security Implementation Roadmap for Product Owners
• Privacy Engineering Requirements Checklist for Custom Software
• Application Security Requirements Checklist for Software Buyers