Secure Software Development: What to Require From an Outsourced Team

If you hire an outside team, put secure software development in the contract as specific practices you can check. A promise in the proposal is not enough. Require four things in writing: threat modelling at design time, a dependency and secrets policy, automated code scanning in CI, and access controls with audit trails at handover.

You are probably the CTO, or the founder doing the CTO job. Every vendor on your shortlist says they take security seriously. None of them tells you how you would know.

This is the list to put in front of them.

Why is "we follow best practices" not a security plan?

Because you cannot verify it. A real plan names the practice, the tool, the person responsible, the timing and the evidence you receive. "Best practices" names none of those, so when something breaks there is nothing in the contract to point to.

Vendors don't usually use vague language in bad faith. Security work is invisible in a sprint demo, and features are not. Under deadline pressure the invisible work slips first. Nobody notices until a customer, an auditor or an attacker does.

Outsourcing adds its own exposure. Developers rotate on and off your project. Laptops, personal GitHub accounts and shared credentials multiply. Without written rules, each new person brings their own habits.

What does it cost you to get this wrong?

The failures rarely look dramatic at first. An API key lands in a commit, and bots that constantly scan public repositories find it long before anyone on your side notices. A library with a known vulnerability sits unpatched for months because nobody was responsible for upgrades.

The painful part comes later. Adding authorization checks to a finished app means touching every endpoint and retesting every role. An enterprise prospect sends a security questionnaire, you cannot answer half of it, and the deal stalls. Six months after the contract ends, you find the vendor still has admin access to production.

Each of these is easy to prevent in week one and slow to fix in month nine.

Who does not need all of this?

You may be building a throwaway prototype with no real user data, no payments and no plan to show it to customers. If so, the full list is overkill. Keep two rules: no secrets in the code, and a written agreement that the prototype does not go to production without a security review.

The full list applies as soon as real users, personal data or money are involved.

What should the contract require?

Four practices. Each one below comes with wording you can adapt and a check you can run every sprint.

Threat modelling at design time

The team should write a short threat model before it builds anything that touches authentication, payments, personal data, file uploads or permissions. One page is enough: what is valuable, how someone could reach it, how it could be abused, and what stops that.

Contract wording to adapt: "For each feature handling authentication, payments, personal data or user permissions, the vendor delivers a written threat model before development starts, and updates it when the design changes."

If the team has never done this, STRIDE is a useful checklist of threats to start from. Watch for a model written once at kickoff and never touched again.

A dependency and secrets policy

Most of the code in a modern app comes from other people's libraries. Your contract should require:

• committed lockfiles
• a short reason for every new dependency
• automated update tooling such as Dependabot or Renovate
• a fixed window for patching critical vulnerabilities, for example seven days

Secrets need their own rules:

• no keys in source code or committed .env files
• secrets stored in a secrets manager such as AWS Secrets Manager, Doppler or HashiCorp Vault
• pre-commit scanning with gitleaks or TruffleHog
• rotation of every shared credential when a developer leaves the project

Automated code scanning in CI

Scanning should run on every pull request, not just before launch. A sensible baseline:

• static analysis with Semgrep or CodeQL
• dependency scanning with OSV-Scanner, Snyk or npm audit
• secret scanning
• container image scanning with Trivy, if you ship containers

Write two rules into the contract. The pipeline fails on high or critical findings. Any exception is written down with an owner and an expiry date.

Scanners have limits. They catch known patterns. They do not catch a missing ownership check that lets one customer read another customer's invoices. That takes code review against your threat model. This matters more now that many teams use AI coding assistants, which produce plausible code that often skips exactly these checks. Here is a breakdown of the security gaps common in AI-generated code.

Access controls and audit trails at handover

Every account should be yours from day one: cloud, code repository, domain, app store, payment provider and email sending. The vendor gets named individual accounts with only the access they need, MFA turned on and no shared logins.

Turn on audit logging so you can see who did what. That means AWS CloudTrail, the GitHub audit log and your identity provider's logs. Inside the product, admin actions such as role changes, refunds and data exports should write to an audit trail too.

At handover, require:

• a written list of every account and who has access to it
• removal or reduction of vendor access
• rotation of every secret the vendor touched
• a runbook for deploys and incident response

How do you check this every sprint without becoming the security team?

Add five minutes to the sprint review and ask the same questions every time:

1. Which stories this sprint touched sensitive data, and where is the threat model?
2. Can you show me the latest pipeline run and its scan results?
3. Are any critical vulnerabilities open past the patch window?
4. Did anyone join or leave the team, and what access changed?
5. Were any scan findings marked as exceptions, and when do they expire?

Two rules keep this honest. If the vendor cannot show evidence, treat the item as not done. If a critical finding is open past its window, it blocks the release, however good the demo looks.

What should you ask a vendor before you sign?

• Can you show me a redacted threat model from a past project? A good team has one ready. A vague team asks what you mean.
• What makes your pipeline fail? You want specific tools and thresholds, not "we run scans".
• Where do secrets live during development? The answer should name a tool, not "in a shared doc".
• Who owns the cloud accounts? The only right answer is you.
• What happens to your access when the contract ends? Listen for a checklist, not reassurance.

Make security a line item, not a feeling

The vendors worth hiring will welcome this list, because it makes their good habits visible to you. A vendor who pushes back on it has already told you what you needed to know.

At Geminate Solutions, clients own 100% of the code and IP, and we sign an NDA before we talk, so terms like these are where we start.

If your team ships with AI coding tools, the vibe coding security guide linked above lists the specific gaps to check. You can also send Geminate Solutions your plan or app for a free review, and we will reply within 24 hours.