Most application vulnerabilities are not exotic. They are missing authorisation checks, secrets committed to a repository, an outdated library nobody updated, or a mobile app that stores tokens where they are easy to extract. Each is cheap to prevent when the decision is made, and expensive to fix once the application is in production and holding customer data.
A secure software development lifecycle (secure SDLC) is the discipline of making those decisions deliberately, by attaching specific security activities to every phase of delivery rather than a single test at the end. Whether you are a CTO running an internal team, a product owner commissioning an agency, or a founder about to ship a first app, the same sequence applies. This guide walks through each phase for web and mobile applications, the standards worth anchoring to, and the questions to ask of whoever builds your software.
Why Security Has to Start at the Requirements Stage
The OWASP Top 10:2025 lists Insecure Design (A06) as its own category and makes the point bluntly: a secure design can still have implementation defects, but an insecure design cannot be fixed by a perfect implementation. If the data model lets any signed-in user request any customer record, no amount of careful coding or late testing will make the product safe.
The major frameworks agree on the remedy. NIST's Secure Software Development Framework (SP 800-218, version 1.1, published in February 2022) organises its practices into four groups: Prepare the Organization, Protect the Software, Produce Well-Secured Software, and Respond to Vulnerabilities. NIST released a draft of version 1.2 in December 2025. CISA's Secure by Design guidance, revised in October 2023, asks software makers to take ownership of customer security outcomes, embrace radical transparency and accountability, and lead from the top.
Write Requirements That Can Be Verified
"The app must be secure" is not a requirement. Useful security requirements are specific enough to pass or fail. The OWASP Application Security Verification Standard (ASVS) provides exactly that for web applications and services: version 5.0.0, released in May 2025, contains around 350 requirements across 17 chapters. For mobile apps, the OWASP Mobile Application Security Verification Standard (MASVS) plays the same role, with eight control groups running from storage and cryptography to resilience and privacy.
ASVS defines three levels. Level 1 is the minimum starting point, Level 2 is the level most applications should be striving for, and Level 3 is for applications that need to demonstrate the highest levels of security. The standard itself suggests that buyers can require a given level from a supplier and ask for proof, which makes it a practical tool for contracts.
Privacy belongs in the same conversation. Article 25 of the GDPR requires data protection by design and by default, so decide now what personal data the application genuinely needs, how long it is kept and who can see it.
Threat Modelling Before the Architecture Is Fixed
Threat modelling is a structured way of asking what could go wrong before it does. The OWASP Threat Modeling Cheat Sheet recommends doing it early, ideally during design, and maintaining the model as the system changes. It is built around the four questions set out in the Threat Modeling Manifesto.
- What are we working on?
- What can go wrong?
- What are we going to do about it?
- Did we do a good enough job?
In practice, the team draws the system, including clients, APIs, data stores, third-party services and the trust boundaries between them, then walks each data flow with a prompt list. STRIDE, which Microsoft uses in its Threat Modeling Tool and the OWASP cheat sheet uses as its main example, is a good place to start.
| STRIDE Category | Example in a Web or Mobile App |
|---|---|
| Spoofing | A stolen session token replayed from another device |
| Tampering | Modified API requests that change prices or account IDs |
| Repudiation | Administrative actions with no audit trail |
| Information Disclosure | Verbose error messages or over-broad API responses |
| Denial of Service | Unthrottled login or search endpoints |
| Elevation of Privilege | A regular user calling an admin-only endpoint directly |
The output is a list of threats, each mapped to a control or an explicitly accepted risk. Keep it alongside the code, and update it whenever a new feature moves a trust boundary.
Secure Design and Secure Coding
Authentication and Authorisation as Core Features
Identity and permission models should be designed, not accumulated. Decide how users authenticate, when multi-factor authentication is required, how tokens expire and are revoked, and how authorisation is checked on the server for every request. The least-privilege thinking behind implementing zero trust security applies inside an application too. If your application will rely on existing corporate identity systems, an identity and access review of those systems is worth doing first.
Data Handling, APIs and Code Review
Validate input on the server, encode output for its context, use parameterised queries, and encrypt sensitive data in transit and at rest. Design APIs to return only the fields each client needs: a response that a mobile app filters on the device is still fully visible to anyone who inspects the traffic. Prefer well-maintained framework features over hand-rolled security code, and require peer review of every change.
Dependencies, Secrets and the Software Supply Chain
Modern applications are mostly third-party code. The OWASP Top 10:2025 ranks Software Supply Chain Failures third (A03), covering compromises in the process of building, distributing or updating software, and recommends tracking transitive as well as direct dependencies and monitoring sources such as the National Vulnerability Database. A workable baseline looks like this.
- Pin dependency versions and commit lock files so builds are reproducible
- Generate a software bill of materials (SBOM) with every build and remove unused components
- Review new dependencies before adopting them, including maintenance activity and licence
- Keep secrets in a dedicated secrets manager, never in source code, configuration files or mobile app bundles
- Scope, rotate and isolate credentials for CI/CD, cloud and third-party APIs per environment
- Protect the build pipeline itself with least-privilege access and mandatory review of its configuration
Building SAST, DAST and SCA Into CI/CD
Automated testing catches known classes of defect on every change. Each tool type sees something different, so they complement rather than replace each other.
| Tool Type | What It Examines | Typical Stage | Main Limitation |
|---|---|---|---|
| SAST | Source code for insecure patterns | Every pull request | False positives and little insight into business logic |
| SCA | Third-party components against known vulnerabilities | Every build and on a schedule | Only finds publicly known issues |
| Secret scanning | Commits and history for exposed credentials | Before commit and on every push | A leaked secret must still be rotated |
| DAST | The running application from the outside | Staging deployments | Covers only paths it can reach |
Start with a small set of high-confidence rules that block the build, and report the rest without blocking. A pipeline that fails on hundreds of low-quality findings teaches developers to ignore it.
Security Testing Before Release
Automated tools are weakest at the vulnerabilities that matter most in custom applications: broken access control, flawed business logic and chains of minor issues. Before a significant release, test the build against the requirements you set at the start. ASVS and MASVS give testers a checklist, and the OWASP Mobile Application Security Testing Guide (MASTG), whose version 2.0.0 was released in June 2026, provides test procedures for Android and iOS.
For higher-risk releases, add an independent manual assessment; our guide on how to prepare for a penetration test covers scoping, test accounts and environments. Either way, findings are fixed before release or documented as accepted risks with a named owner.
Mobile-Specific Concerns for iOS and Android
Mobile apps run on devices you do not control, and the app package can be downloaded, decompiled and modified by anyone. The OWASP Mobile Top 10 2024 reflects this: Improper Credential Usage sits at M1 and Inadequate Supply Chain Security at M2, with Insecure Communication, Insufficient Binary Protections and Insecure Data Storage also on the list.
- Secure storage: Keep credentials and keys in the platform facilities built for them, such as the iOS Keychain and the Android Keystore system, not in plain preferences or files
- No embedded secrets: Treat anything shipped in the app bundle as public, and issue short-lived, user-scoped tokens from your backend instead
- Network security: Use TLS for all traffic; Android apps targeting Android 9 (API level 28) or higher have cleartext traffic disabled by default, so justify any opt-out
- Privacy: Request only the device permissions a feature needs, in line with the privacy controls MASVS added in version 2.1.0
- Hardened builds: Disable debugging and sensitive logging in release builds, and add resilience controls where the app protects high-value assets
Keeping Applications Secure After Launch
Release is the start of the maintenance phase, not the end of the security work. Vulnerabilities will be disclosed in components you depend on, and the attack surface grows with every integration. Keep dependency monitoring running against production releases, patch on agreed timelines, and monitor security-relevant events with detection that does not rely on known patterns alone, as our comparison of AI and signature-based detection explains. Practise continuous attack surface discovery so forgotten staging environments do not become entry points, publish a way for researchers to report vulnerabilities, and make sure your incident response plan covers a compromised application.
What the Cyber Resilience Act Means for App Makers
If you place software products on the EU market, the Cyber Resilience Act (Regulation (EU) 2024/2847) turns much of this lifecycle into law. It entered into force on 10 December 2024 and its main obligations apply from 11 December 2027, but the Article 14 reporting obligations have applied since 11 September 2026: manufacturers must send an early warning of an actively exploited vulnerability within 24 hours of becoming aware of it, followed by a fuller notification within 72 hours.
Its manufacturer obligations read like a secure SDLC checklist: a documented cybersecurity risk assessment, no known exploitable vulnerabilities at release, secure by default configuration, an SBOM covering at least top-level dependencies, a coordinated vulnerability disclosure policy, and security updates for a support period that must generally be at least five years. A backend service the manufacturer develops, and which its mobile app needs to function, can fall in scope as a remote data processing solution, while the recitals point to the NIS2 Directive, rather than the CRA, for cloud service models such as SaaS. Fines for breaching the essential requirements or manufacturer obligations reach up to EUR 15 million or 2.5% of total worldwide annual turnover, whichever is higher. Our ISO 27001 and NIS2 readiness guide covers the organisational side.
Conclusion: Questions to Ask Before You Commission an App
A secure software development lifecycle is not a product or a single test. It is a set of habits attached to each phase, from verifiable requirements and a living threat model to real testing before release and disciplined maintenance afterwards. If you are commissioning an application, these questions separate a team that builds security in from one that tests for it at the end.
- Which security standard and level will the application be built and verified against?
- Will we receive the threat model and a record of the controls implemented against each risk?
- How are dependencies, SBOMs and secrets managed in the build pipeline?
- What testing happens before each release, and how are findings resolved or documented?
- Who monitors, patches and updates dependencies after handover?
This is the approach behind our secure web and mobile application development service. We design, build and deliver applications for the browser, iOS and Android, with threat modelling shaping the architecture, authentication and authorisation built as core features, and every release tested before it ships. You receive working software together with the design record and test evidence needed to maintain it securely after handover. If you already run an application, a cybersecurity audit can assess it before you build on it.
Found this useful?
