Application Security Lifecycle and Threat Modeling

What it is

Applications are written, built, deployed and run by people and pipelines, and each step can introduce risk. An architect designs security across the whole life cycle, not just the runtime. This topic covers four things: evaluating the security posture of the existing application portfolio, threat modeling to find design weaknesses, a full life cycle strategy and standards and practices for secure development, and mapping technologies to application security requirements.

How it works

Evaluating the security posture of an application portfolio

1. Inventory every application: owner, data handled, exposure (internet, internal), technology, hosting, dependencies and identities used.
2. Tier by business criticality and data sensitivity so effort goes where risk is highest.
3. Assess each against baselines: authentication method, secrets handling, patch level, dependency vulnerabilities, logging, network exposure and recovery.
4. Use tooling to gather evidence rather than questionnaires alone:

1. Prioritize remediation: retire unused apps, fix the highest risk first, and set minimum standards for the rest.

Threat modeling

Threat modeling is a structured way to find security problems at design time, when they are cheapest to fix.

1. Define scope and draw a data flow diagram: external entities, processes, data stores, data flows and trust boundaries.
2. Identify threats for each element, commonly with STRIDE:

1. Rate and prioritize risks (likelihood and impact, or a scheme such as DREAD).
2. Decide the response: mitigate, transfer, accept or avoid, and record the decision.
3. Validate with testing and review, and update the model when the design changes.

The Microsoft Threat Modeling Tool helps draw diagrams and generate STRIDE threats. Threat model business critical applications first and revisit the model for major changes, since it also drives test cases and monitoring.

A full life cycle strategy for application security

The Microsoft Security Development Lifecycle (SDL) and similar frameworks add security practices to every phase.

Standards and practices for the development process

• Secure coding standards based on the OWASP Top 10 (and the OWASP Application Security Verification Standard as a requirement list) covering input validation, output encoding, authentication, session management, access control and error handling.
• Source control protections: branch protection, required reviews, signed commits, least privilege repository access, secret scanning with push protection.
• Pipeline security: treat pipelines as critical assets, use federated credentials rather than stored secrets, limit service connection scope, run scans as gates, protect agents.
• Dependency management: scan open source components, keep a software bill of materials, use controlled package feeds and pinned versions, and respond to new advisories.
• Infrastructure as code scanning for misconfigurations before deployment.
• Environments: separate dev, test and production, with no real production data in test and controlled access.
• Release controls: approvals, artifact signing, and promotion only of the artifact that passed the gates.
• Runtime feedback: monitoring and bug bounty or vulnerability disclosure, feeding findings back into backlog.

Mapping technologies to application security requirements

A worked scenario

A company has 300 applications and no consistent view of risk. The architect inventories them, tiers by data sensitivity and exposure, uses Defender for Cloud, DevOps security and Entra reports to collect evidence, and finds a dozen internet facing, high data apps with weak authentication and old dependencies. They threat model the top three using STRIDE, require secret scanning, SAST and dependency scanning in pipelines, and set signed artifacts and approvals for release.