Secure software development - CTO’s guide

August 19, 2024

Most security failures in software teams are not exotic: a key committed to a repository, a dependency nobody updated for two years, an admin endpoint that checks the role only in the UI. Each is cheap to prevent and expensive to clean up after release. A CTO's job is not to pick tools but to make the safe path the default and to have evidence that the team follows it. Below is a practical secure development lifecycle, loosely mapped to the NIST Secure Software Development Framework.

Security requirements and threat modeling before code

Security requirements belong in the backlog next to functional ones. For each product, write down:

• What data you handle and how sensitive it is: credentials, payment, health or personal data.
• Which roles exist and what each role must never be able to do.
• Which regulations and customer contracts apply, such as GDPR, PCI DSS or HIPAA.
• Authentication and session rules: MFA, token lifetime, account lockout.

The OWASP Application Security Verification Standard (ASVS) offers ready-made requirements grouped by risk level.

Threat modeling does not need special software. For any feature that touches authentication, payments, file uploads, integrations or personal data, the developer and reviewer spend half an hour on four questions: what are we building, what can go wrong, what will we do about it, did we do a good job. Record the answers in the ticket; five concrete threats beat a long report.

Secure coding standards developers will follow

A coding standard works only if it is short, specific to your stack and enforced by tooling. Base it on the OWASP Top 10 and cover at least:

• Parameterized queries or an ORM; no SQL built from strings.
• Output encoding by default in templates, with every bypass flagged in review.
• Server-side authorization on every endpoint, including mobile and internal APIs. Broken access control tops the OWASP list for a reason.
• Approved libraries for cryptography and password hashing (Argon2id or bcrypt); no home-made crypto.
• No stack traces shown to users, no secrets or personal data in logs.

Turn as many rules as possible into linter or SAST rules so reviews discuss design, not style. AI-generated code gets the same review and scanning as human-written code, and only approved AI tools may see your source.

Dependencies and the software supply chain

Most of the code you ship was written by others; treat it as attack surface:

• Commit lockfiles and build from them in CI.
• Pin CI actions and base images to commit SHAs or digests, not mutable tags.
• Generate an SBOM (CycloneDX or SPDX) for every release and store it with the artifact. When the next Log4Shell-scale issue appears, "are we affected?" takes minutes, not days.
• Automate updates with Dependabot or Renovate; merge minor updates weekly, plan major ones.
• Vet new packages: maintenance activity, license and the exact name. AI assistants sometimes suggest packages that do not exist, and attackers register such names.
• Track end-of-life dates of runtimes and frameworks, because unsupported software stops receiving security fixes.

CISA's work on open source security shows where US expectations are heading. For software products sold in the EU, the Cyber Resilience Act has required reporting of actively exploited vulnerabilities since September 2026, and most other obligations, including an SBOM, apply from December 2027.

Secrets management

• Keep credentials in a secrets manager (your cloud provider's or HashiCorp Vault) and inject them at runtime. Never store them in repositories, images, wikis or mobile app bundles, which can be unpacked.
• Enable secret scanning with push protection on every repository, and scan the full history once.
• Prefer short-lived credentials: OIDC federation from CI to the cloud rather than stored access keys.
• Separate secrets per environment; developers rarely need production values.
• Rehearse rotation. A leaked key stays an incident until it is rotated, even if the commit was deleted.

Code review and automated scanning in CI/CD

The pipeline is the enforcement point, because it runs on every change:

• Protected main branch, review by someone other than the author, no direct pushes, admins included.
• SAST, for example Semgrep or CodeQL, on every pull request.
• Dependency scanning on every build and nightly, because new CVEs hit code you have not touched.
• Secret, container image and infrastructure-as-code scanning where relevant.
• Authenticated DAST against staging on a schedule and before releases.

At first, block only on high-confidence, high-severity findings. A gate that fails builds on noise gets bypassed; a narrow, respected gate works.

Access control and least privilege

• Phishing-resistant MFA (passkeys or hardware keys) for source control, cloud console and CI.
• Named accounts with role-based access; no shared logins.
• Production access is rare, time-limited and logged; routine deploys go through the pipeline.
• Service accounts and CI tokens are scoped to one repository and environment.
• Same-day offboarding and a quarterly access review.
• Storage and databases are private by default; misconfigured cloud storage remains a frequent cause of data exposure.

Developer laptops are part of the perimeter too; see our guide to protecting the data of remote employees.

Logging, monitoring and incident response

Log logins and failures, MFA and password changes, permission changes, admin actions and bulk exports. Ship logs to central storage developers cannot edit, retain them as contracts and law require, and alert on bursts of failed logins or new admin accounts.

Write a one-page incident runbook before you need it: who decides, how to reach them at night, how to revoke tokens and rotate keys, how to preserve evidence, who informs customers and regulators. GDPR generally requires reporting a personal data breach to the supervisory authority within 72 hours of becoming aware of it. Rehearse the runbook once a year.

Security testing before a release

• No open critical or high findings, or a written, time-boxed exception you signed.
• Every threat in the feature's threat model has a mitigation or an accepted risk.
• Manual testing of the riskiest flows: login, password reset, payments, file upload.
• For mobile apps, check local storage, certificate validation and what the bundle exposes; see what to test in a mobile app.
• An external penetration test at least yearly and after major architecture changes, with a retest of fixes.

Metrics a CTO can track

• Time to remediate vulnerabilities by severity, against an agreed SLA.
• Critical and high findings past their SLA.
• Share of repositories with branch protection and all scanners enabled.
• Dependencies and runtimes past end of life.
• Secrets detected in code and time to rotate them.
• Share of high-risk features with a recorded threat model.
• Repeat findings: the same bug class twice means a missing rule or test.

Do not celebrate a falling count of raw findings; it often means a scanner was switched off.

How to start in a small team

You do not need a security department. Spread the work over a quarter:

1. Week one: MFA everywhere, no shared accounts, secret scanning and branch protection on.
2. Month one: secrets moved to a manager, leaked ones rotated, lockfiles and automated updates enabled.
3. Month two: SAST and dependency scanning in CI, blocking only on high severity; a one-page coding standard.
4. Month three: central logs with a few alerts, the incident runbook, threat models for high-risk tickets.

Name one engineer as security owner with real time allocated, not as a side job.

What to require from an outsourcing vendor

When an offshore team writes your code, put these expectations in the contract:

• Signed NDA, clear IP ownership, repositories owned by your company.
• Access rules agreed before the first commit: named accounts, MFA, least privilege, same-day offboarding.
• No production personal data in development or test environments without your approval.
• CI/CD with automated tests and security scanning, with results you can see.
• An SBOM and third-party license list with each release.
• Fix times for vulnerabilities by severity and a deadline for incident notification.
• Disclosure of subcontractors and of AI tools used on your code.
• Your right to commission penetration tests and code audits.

Ask for evidence, not a policy PDF: branch protection settings, a sample scan report, the access list. At 4K-Soft, the NDA is signed and access rules are agreed before the first commit, and every project runs CI/CD with automated testing.

Start with access, secrets and dependencies, where fixes are cheap and pay off immediately, then add threat modeling and release testing once the team is used to the gates. If you need a team that works this way from day one, contact 4K-Soft.