CCSP Applying the Secure SDLC: Cloud Risks, Threat Modeling and Secure Coding

Shared technology issues are the risks that come from many customers (tenants) running on the same underlying components, and in development the most important consequence is that the provider isolates its infrastructure, not your data inside your application. The hypervisor keeps one customer's virtual machines apart from another's, but once a SaaS application puts several of its own customers into one database schema, one cache or one queue, nothing below the application can tell those customers' data apart. Tenant separation then has to be written into the code.

The CCSP outline names four cloud-specific risks that the secure SDLC must design for. This lesson takes them in turn:

• Shared technology issues: tenants share databases, caches, queues and compute.
• CSP insider threats: provider staff with privileged access to the systems holding your data.
• Lack of visibility and control: in PaaS, SaaS and serverless, the customer cannot see or configure the layers below the application.
• Legal and jurisdiction issues: where data and its copies sit, and which governments can compel the provider to disclose it.

Where tenant data is mixed, and the control that separates it

The principle is to enforce separation at the exact point where tenants' data is mixed. Controls that act at a different layer (the host, the network edge, storage encryption, capacity) can be valuable for other reasons, but they cannot stop the application from handing one tenant's data, or one tenant's share of a resource, to another. A useful test when reviewing a design: if a developer forgets one check in one code path, does any tenant boundary still hold? If not, the separation is not yet designed in.

Fully separate infrastructure per tenant (a "silo" model) does remove sharing, and is a legitimate design for high-value tenants, but it costs more and is often ruled out by the business. The secure-SDLC skill is to make the shared design safe: the tenant identity comes from the authenticated session, never from a value the caller supplies, and it is enforced centrally rather than remembered by each developer.

A CSP insider threat is a provider employee or contractor who misuses privileged access to the infrastructure, platform or support tooling that holds customer data. Applications defend against it in two ways: by designing so that provider staff see as little as possible, and, where the provider must have access, by making that access customer-approved, time-limited and logged to the customer.

Minimizing what an insider can read

An insider with access to storage already sits behind the network controls, so only protection that travels with the data helps. Encrypting sensitive fields in the application before storage, with keys held in a customer-controlled HSM or key service outside the provider, leaves the insider holding ciphertext. Encryption whose keys the provider itself manages keeps keys and data under the same administrative domain: it protects against lost media and outside attackers, not against the provider's own privileged staff, whatever its rotation schedule. This is the same "separate the keys from the provider" principle covered with key management in the data security lessons; here it becomes a design decision made during development (which fields, encrypted where, with whose keys).

When the provider must have access

Customer-held encryption has a cost: data the provider cannot read is data its engineers cannot troubleshoot. When the business needs provider support on a managed database or service, the control shifts from preventing access to governing it:

• the customer approves each support session (many providers offer a customer lockbox or access-approval feature for this);
• the access is time-limited to the case;
• the customer receives the access records, so it knows whenever provider staff touched the data.

What assurance documents do and do not do

Third-party attestations and certifications describe how the provider screens, separates and monitors its staff. That is valuable assurance when choosing and reviewing a provider, but it is evidence about the provider's process, not a control the customer operates, and it does not reveal or limit any individual access to the customer's data. When judging a control against this risk, ask whose behaviour it constrains: a control that governs the customer's own staff, however sound, addresses a different actor. The provider-insider risk as an entry in a risk register is covered in the infrastructure risk assessment lesson; this lesson is about building the application so the risk is smaller.

Lack of visibility and control is the risk that, in PaaS, SaaS and serverless, the customer cannot see or configure the hosts, networks and much of the platform its application runs on, so the evidence an investigation needs must be produced by the application itself. Platform logs describe the platform; only the application knows which end user did what to which record.

The gap is sharpest when the application reaches its data through one service identity (a function role or a database connection account). Every query the database sees then comes from that single identity, so the database's own logs cannot name the end user behind a request.

Building this is a development task, so it belongs in the secure SDLC from the requirements stage: define the security events (sign-ins, failed and successful access decisions, reads and changes of sensitive data, administrative actions), the fields each event carries, and where events go. For audit use the record must be tamper-evident: sent to central, append-only (write-once) storage that the application itself cannot alter or delete, ideally in a separate account. An attacker who compromises the application should not also be able to erase the evidence. Never log secrets or full sensitive values; log identifiers.

The general rule: the provider can tell you what happened to its platform; only your application can tell you what happened to your data and on whose behalf.

Legal and jurisdiction issues are the risks that data ends up stored or processed where the law does not allow it, or that a government can compel the provider to hand it over. In application design they turn on two questions that are easy to confuse: where is every copy of the data, and who can be forced to read it.

Residency means every copy

A residency requirement (for example, "keep citizens' tax records, including any copy, inside the country") is not met by placing the primary database in a local region. Applications create copies constantly, and each one counts:

• read replicas and cross-region replication;
• backups and snapshots, including where the provider stores them by default;
• caches, especially a global content delivery network, which stores responses in edge locations around the world;
• logs, analytics exports, search indexes and support tickets that contain the data.

Mapping these copies is a design-phase activity (the data flow diagram should show them). The fix for a regulated copy outside the boundary is to stop that copy being created there, by excluding the data from the mechanism or constraining the mechanism to permitted locations. A control that protects a copy abroad still leaves a copy abroad. A common miss is the search index or analytics export a team adds months after the residency design was approved.

Compelled disclosure follows the provider, not the data

A provider headquartered in another country may be subject to its home law wherever it stores data, so in-country storage alone does not remove the risk of foreign compelled disclosure. Where the data sits within that provider's estate does not change whose law applies to the provider. The control that works is to make disclosed data useless: encrypt sensitive fields before they reach the provider, with keys only the customer holds, so a compelled provider can only hand over ciphertext. Contractual and certification measures improve transparency and the provider's privacy practice, but they cannot override a lawful order, so they reduce rather than remove the risk.

The broader legal frameworks (privacy laws, eDiscovery, conflicting international requirements) belong to the legal and compliance domain; the secure-SDLC point is that residency and jurisdiction become design requirements captured before the architecture is built.

Threat modeling is the structured analysis of a system's design to find what could go wrong, how an attacker could cause it and which controls should prevent it. It delivers the most value during design, when a flaw can be fixed on paper, and it must be repeated whenever the architecture, data flows, trust boundaries or dependencies change; otherwise it describes a system that no longer exists. Adding a mobile client, exposing an internal API publicly, or moving a component to a new service model are all reasons to update the model before building. A calendar-based review or post-release testing is valuable but comes after the design decision it should have informed; testing verifies the mitigations the model identified, it does not replace the model.

Where to look first: trust boundaries

Most threat models start from a data flow diagram (external entities, processes, data stores, data flows) with trust boundaries drawn where the level of trust changes: browser to API gateway, gateway to internal functions, functions to a managed database, and any call to or from a third party. Threats cluster on flows that cross a boundary, because that is where identity must be established, input validated and data protected in transit. With limited time, enumerate threats on boundary-crossing flows first; the assets behind a boundary are reached through those flows. Picking a control before the analysis is done is a common mistake: a single control usually answers one STRIDE category, and the model exists to find the others.

STRIDE: six threat categories, six violated properties

STRIDE is a mnemonic for classifying threats, usually applied to each element of the data flow diagram. Each category violates one security property, and the matching control restores that property.

Neighbouring categories are easy to swap, so reason from the violated property: ask what the attacker gains (a false identity, changed data, deniability, read access, an outage, extra rights) and the property follows. Note the dependency between two of them: authorization decisions rely on an identity that authentication has already established, so authorization controls cannot repair a spoofing weakness.

STRIDE classifies threats; the other three named models do different jobs. DREAD rates and ranks threats that have already been identified, while PASTA and ATASM are end-to-end processes for producing a threat model.

DREAD: scoring identified threats

DREAD scores each threat on five factors and uses the totals (or averages) to rank the list: damage potential (the CCSP outline expands the first letter as "Disaster"; Microsoft's original model used "Damage"), Reproducibility, Exploitability, Affected users and Discoverability. Its well-known weakness is subjectivity: two analysts can score the same threat very differently, which makes rankings inconsistent. The root-cause fix, when an organization wants to keep DREAD, is to write explicit scoring criteria for each level of every factor and calibrate the analysts on worked examples. Changing how the numbers are processed afterwards does not help while the analysts still interpret the scale differently.

DREAD is not the same thing as CVSS. CVSS (the Common Vulnerability Scoring System) uses defined metrics to score the severity of a specific vulnerability; DREAD rates the risk of a threat in your own design. CVSS is more consistent because its metrics are defined, but it measures something different.

PASTA: risk-centric, seven stages

PASTA (Process for Attack Simulation and Threat Analysis) is a risk-centric, attacker-focused methodology in seven stages:

1. Define business objectives
2. Define the technical scope
3. Decompose the application
4. Analyze threats (using threat intelligence about real attackers)
5. Analyze vulnerabilities and weaknesses
6. Model and simulate attacks
7. Analyze risk and impact

Starting from business objectives and ending with business impact is what makes it the fit when leadership wants results expressed as business risk and wants threat intelligence used. It is typically the most resource-intensive of the four.

ATASM: lightweight and architecture-first

ATASM, popularized by Brook Schoenfield, runs four steps in order: Architecture (understand how the system is built), Threats (the threat agents, their goals and methods), Attack Surfaces (where those agents can reach the system) and Mitigations (the defences to apply). It has no scoring model and is easy to teach to development teams, which is its main appeal.

Models combine: a team might follow ATASM or PASTA as the process, use STRIDE to enumerate threats inside it and DREAD to rank them. Attack trees are another valid technique that decomposes an attacker's goal into the ways to reach it.

Injection happens when user-controlled input is combined into something an interpreter parses (a SQL query, a shell command, a template, a query language), so the input is executed as syntax instead of being treated as data. The root-cause fix during development is always the same idea: use an interface that keeps the structure and the data separate, so the interpreter never parses the input.

The dynamic-SQL case is a common trap: safe parameter binding at one boundary does not protect a later point where the same value is concatenated into code, so the injection simply moves. Follow the value to wherever it is finally parsed. Declaring a parameter with a strict data type and length is not a substitute: it constrains numbers and dates usefully, but a string parameter can still carry SQL syntax within its length, and if the receiving code concatenates that string into a statement it is parsed as code all the same. The same logic applies to the shell: escaping tries to make input safe for a parser that should not be in the path at all.

Other layers still matter as defence in depth: allowlist validation of expected formats reduces attack surface, least privilege limits the damage of a successful injection, and filtering at the edge can buy time. Each one compensates for the flaw rather than removing it, because it works by recognising bad input, and a determined attacker routinely finds input that a filter misses. Awareness lists such as the OWASP Top 10 are covered in the application security awareness lesson; how testing finds these flaws is covered in the software assurance lesson.

Two development flaws are especially damaging in the cloud because they hand an attacker the workload's cloud credentials: server-side request forgery (SSRF) that reaches the instance metadata service, and secrets committed to source control.

SSRF and the metadata service

SSRF is a flaw where an attacker makes the server send a request to a destination the attacker chooses, typically through a feature that fetches a user-supplied URL, such as link previews, document import from a URL or a callback address. In the cloud the prize is the instance metadata service, a link-local address that returns the machine's temporary role credentials. Closing it takes controls at two levels:

• In the code: allowlist the permitted destinations and check the address after DNS resolution, not the URL string, rejecting private and link-local ranges. Apply the check to every hop: if the HTTP client follows redirects, a public host can answer with a redirect to the metadata address, so either stop following redirects or resolve and validate each one. (DNS rebinding, where a name resolves differently on a second lookup, is a separate bypass, which pinning the resolved address for the actual connection prevents.) String blocklists of the metadata IP are trivially bypassed with alternative encodings and hostnames.
• On the platform: require a session token for metadata requests, obtained beforehand by a separate call (or a header a plain forged request cannot set). SSRF usually lets an attacker choose only the URL of a simple request, so this blocks credential theft without a code change, which makes it the right immediate step while a code fix is pending.

Ask of any proposed control whether it stops the credentials being returned. Controls that limit what stolen credentials can do, or detect the theft afterwards, are worthwhile damage limitation but leave the request path open; controls that restrict who may use the feature do not help when the abuser is a legitimate user; and network changes that break the feature's purpose are not a fix.

Secrets in source code

A secret committed to a repository must be treated as compromised. Deleting the line in a new commit changes only the newest version: the old value remains in version history and in every clone, fork and cached copy, none of which can be recalled. The response has three parts:

1. Revoke or rotate the secret at its issuer, which is the only step that closes the exposure.
2. Move the replacement out of the repository: the workload retrieves it at runtime from a secrets manager using its own identity. Any variant that keeps the secret, encrypted or not, in files that travel with the code keeps it tied to source control.
3. Prevent recurrence with automated secret scanning on commits (pre-commit hooks and server-side scanning).

Clean-up steps on the repository itself are reasonable follow-ups, but the test is whether a step makes the leaked value useless. Only revocation at the issuer does that, because copies already outside your control cannot be recalled.

The CCSP outline names two secure-coding sources that do different jobs: OWASP ASVS defines what to build and verify, and SAFECode describes how to run a secure development program.

OWASP Application Security Verification Standard (ASVS)

ASVS is a catalogue of specific, testable security requirements for web applications and services, grouped into chapters by area, covering topics such as authentication, session management, authorization, encoding and validation of input, file handling, cryptography and logging. Teams use it to write security requirements into the SDLC and then to verify that the application meets them in design review, code review and testing. The current version is ASVS 5.0 (2025).

• Three cumulative levels. Each level includes every requirement of the levels below it, so an application claiming Level 2 must meet all Level 1 and all Level 2 requirements; requirements that appear only at a higher level are not needed to claim the level below it. Level 1 is the baseline, Level 2 is the level most applications should strive for, and Level 3 is for applications that must demonstrate the highest level of security.
• Documented decisions are verified separately from their implementation. Where ASVS cannot know the right value (permitted file types, size limits, which data is sensitive), it requires the organization to document its decision, and a related requirement checks that the implementation enforces it. The two are separate checks: having the decision written down satisfies only the documentation requirement, and the implementation requirement needs evidence that the code enforces what was written. ASVS leaves the values themselves to the organization.

SAFECode

SAFECode (the Software Assurance Forum for Excellence in Code) is a nonprofit formed by software companies to share secure development practice. Its best-known publication, Fundamental Practices for Secure Software Development, distils the practices that established vendors use across design, secure coding, managing third-party components, testing and validation, and handling reported vulnerabilities. It guides how the program is run, not a checklist to verify code against.

SAFECode and ISO/IEC 27034 both address process, but they differ in origin: SAFECode is practice guidance distilled from what member software companies already do, while ISO/IEC 27034 is a formal standard agreed through the international standards process. The two named sources complement each other: an organization can use SAFECode to design its development process and ASVS as the requirement set that process verifies. For the formal lifecycle frameworks (phases, methodologies, the NIST SSDF), see the secure SDLC process lesson.

Software configuration management (CM) is the discipline of identifying, controlling and recording every item that makes up a system (source code, build scripts, dependencies, infrastructure and application configuration) so that any version can be reproduced, traced and rolled back. Versioning is the mechanism: every change is a recorded version, and every release is a named baseline.

Control the path, not just the record

The strongest CM control makes the recorded path the only path. When configuration lives in version control and production can be changed only by promoting reviewed commits through the pipeline, an engineer cannot change a setting by hand without it being recorded, and the current baseline is always known. Ask of any CM control whether it prevents an unrecorded change or only finds one later, and whether it is technically enforced or relies on people following a procedure. Prevention by enforced path is strongest; detection still has a place, catching what slips past and confirming that the controlled path is the only one in use.

Reproducible releases

A release is reproducible only when its source is tagged and every build input is pinned. If builds pull a "latest" base image or unpinned library versions, rebuilding an old release produces a different artifact, which matters for audits, incident investigation and any patch to an older version. The practice is to tag each release in version control and pin base-image and dependency versions in version-controlled build files (lock files, image digests). Note the difference between keeping what a release produced (a stored artifact, useful for rollback) and being able to reproduce it from source (needed to change it): only pinned, versioned inputs give the second.

Good CM also supports security directly: reviewed, versioned changes give an audit trail of who changed what, rollback limits the impact of a bad release, and pinned dependencies make it possible to know exactly which component versions are in production. The supply-chain side of this (SBOMs, provenance, verifying third-party components) belongs to the verified secure software lesson.