Secure Software Development Guidelines

Every field you store is a field you have to protect, justify, retain and eventually delete. Data collected "because we might want it later" carries the full cost of protection and none of the value. Before adding a column, ask what product decision depends on it.

• Classify everything. Four tiers is plenty: public, internal, confidential, regulated. Let the tier drive the handling rules so you never decide case by case.
• Write a data inventory. For each element: what it is, why you have it, who owns it, where it lives, how long you keep it, how it dies. A spreadsheet is fine.
• Define retention when you add the field, even if the answer is seven years. Deciding is the point.

• Use an established identity provider. The primitives are subtle and the failure modes are severe. If you sell to businesses, support single sign-on early; it is the first thing enterprise buyers ask about.
• If you store passwords, hash them with Argon2 or bcrypt. Per-user salt, a cost factor you revisit. Never plain SHA, never anything reversible.
• MFA on every privileged path. Not just your admin console. Also the cloud account, the CI system, the source repo, the DNS registrar.
• Manage sessions deliberately. Absolute expiry plus idle timeout, Secure and HttpOnly cookies, server-side invalidation on logout and password change.
• Rate-limit login attempts per account and per source. Credential stuffing is automated and cheap.

Authentication says who is calling. Authorization decides what they may do, and it has to be right on every path, not just at the front door.

• A few roles, least privilege each. Resist per-user permission flags. They multiply until nobody can reason about the matrix.
• Enforce on the server, always. Hiding a button is a courtesy to honest users. Anyone else has the developer console open.
• Deny by default. A route with no declared permission should fail closed, so the endpoint a new engineer forgets about refuses to serve rather than serving everything.

• Separate cloud accounts, not namespaces. Account boundaries are the one boundary your provider enforces for you. An over-broad permission inside a shared account reaches everything.
• Separate credentials. A leaked development key must be worthless against production.
• Separate data. Lower environments get synthetic fixtures, never a copy of the production database.

• Use a real secrets manager. Every major cloud has one, and workload identity means your app never holds a bootstrap credential.
• Scan for secrets in CI and in history. Pre-commit hook plus pipeline check. Scan the full git history once when you adopt it; the interesting findings are usually old.
• One job per credential. Separate read from write, per service, with an expiry. Never one shared key used by every service and every engineer.
• Rotate on schedule and on events: suspected exposure, and whenever someone with access leaves.

• TLS 1.2+ on every public endpoint, HTTP redirected, HSTS on. Run an external scan to confirm.
• TLS internally too, service to service and app to database, not just at the edge.
• Managed encryption at rest on databases, object storage, queues, log stores. Flip it on at creation; it rarely inherits downstream.
• Managed keys, split permissions. Who can use a key and who can administer it are different questions. Answer them separately.

Log five classes of event and you cover what incidents and audits ask about: authentication (success and failure), administrative actions, permission changes, configuration changes, and data exports.

• Structured, not prose, so you can query instead of grepping under pressure.
• Centralized and append-only. Logs that live only on the machine that made them vanish exactly when you need them. Operators should not be able to edit history.
• UTC everywhere. Correlating across services needs one clock.
• Pick a retention period, usually a year for audit purposes, and configure it on purpose.

• Authenticate every request. Health checks should not enumerate internals.
• Authorize every action, per request, on the specific object touched. Once at the gateway is not enough.
• Validate input against an explicit schema and reject what fails, rather than sanitizing and hoping. Size limits on bodies, arrays and uploads.
• Rate-limit, tighter on login, password reset, invitations and exports.
• Serialize explicit fields. Serializers that default to "everything" leak new columns the day they are added.

Follow OWASP guidance and prefer framework defaults over clever code. The frameworks have already had the bugs you are about to write.

• Injection: parameterized queries or the ORM builder, never string concatenation into a query.
• XSS: let the template engine encode output. Any "render raw HTML" call gets reviewed.
• CSRF: framework tokens plus SameSite cookies.
• Deserialization: data formats, not object formats, for anything untrusted.
• Errors: generic message to the client, detail to the log. No stack traces in responses.

• Adopt deliberately. Is it maintained, does the license work for you, does it respond to security reports, how much transitive weight does it drag in.
• Commit lockfiles so builds are reproducible and a scan result means something.
• Scan on every commit and on a daily schedule. A vulnerability published tomorrow affects the dependency you did not touch today.
• Patch targets by severity, and hold them: critical in days, high in weeks, the rest on a planned cadence.
• Remove what you stopped using. Same risk, zero benefit.

• Lock the root account: MFA, no access keys, no daily use. Work through named users and roles.
• No standing admin. Elevated access is assumed for a purpose and expires.
• Provider audit logging on, every region, delivered somewhere the account's own admins cannot quietly edit.
• Closed network by default: no public databases, no open management ports, no public buckets unless they serve genuinely public assets.
• Infrastructure as code, reviewed and diffable. Console changes are invisible to your change process and are where drift starts.

• Pick an RTO and RPO and write them down. For an early B2B product, four hours down and fifteen minutes of data loss are defensible starting answers.
• Back up daily, keep 30 days, store a copy in another region. Point-in-time recovery on a managed database gets you most of the way.
• Health checks that reflect real dependencies, alerts routed to a person who agreed to be woken, and a written incident procedure with severity levels and customer communication times.

Three questions, answered in writing. What personal data do you process, including logs, analytics, support tickets and whatever customers upload into your product? Why, in one sentence per purpose? And how will you delete it, on request and on schedule, including from backups and every third party you shared it with?

• Join on internal ids, not email addresses, so pseudonymization is possible later.
• Keep a sub-processor list. Customers will ask and contracts will require it.
• Name an owner for data subject requests before the first one arrives. The deadlines are statutory.

The minimum viable version is four rules, each about a day to set up:

• Every change is peer reviewed, enforced by branch protection with self-approval off.
• Automated tests run on every change and block the merge on failure.
• Dependency and secret scanning run on every change, also blocking.
• Nothing reaches production without passing all three.

• Everything in version control: app code, infrastructure, migrations, pipeline config. If it can change production and is not in a repo, it is outside your process.
• Review before merge, by someone other than the author.
• Track what shipped: a deployment record linking the version to its changes and approver.
• Know the rollback, especially with database migrations. Write migrations backward-compatible with the running version and run them before the new code takes traffic, so a failure leaves the old version serving.

Five things to watch: system health (your customers should not be your monitoring), authentication failures (the visible signature of credential attacks), privilege and configuration changes, infrastructure alarms including certificate expiry and backup job failure, and data access far outside a principal's normal pattern.

Three artifacts. An architecture diagram: components, boundaries, where each runs, how they authenticate to each other, one page. A data-flow diagram showing where sensitive data enters, lives, moves and leaves; this one determines your audit scope, so accuracy here narrows the assessment. And a register of third-party integrations: what each receives, why, and where it operates.

First audits are rarely delayed by a missing policy document. Policies can be written in a week. They are delayed by absent history (an auditor testing six months of change control needs six months of records), by architectural retrofits (tenant isolation and deletion paths are engineering programs, not paperwork), and by nobody being able to say what the system actually does.