Application, Cloud and Digital Platform Security

Introduction

Modern organisations depend on software applications, cloud services and digital platforms for communication, commerce, data processing and operational control. This dependence has changed cybersecurity from a perimeter-centred discipline into a system of continuous risk management. A vulnerability in source code, an incorrectly configured cloud storage resource, an exposed application programming interface (API), or a compromised software supplier can all become routes into sensitive systems.

Application, cloud and platform security therefore require coordinated attention to design, development, deployment, operation and retirement. Security cannot be added reliably at the end of a project. It must be treated as a quality attribute and integrated into governance, architecture, engineering and assurance processes.

This chapter examines secure software development, DevSecOps, APIs, web vulnerabilities, OWASP risks, cloud shared responsibility, container and mobile security, SaaS governance, configuration management and third-party platform risk.

Learning Objectives

By the end of this chapter, the learner should be able to:

1. Explain the principles of secure software development and DevSecOps.
2. Analyse common web and API vulnerabilities using OWASP-based approaches.
3. Apply the cloud shared-responsibility model to security decisions.
4. Identify security controls for containers, mobile applications and SaaS platforms.
5. Explain the importance of secure configuration and infrastructure as code.
6. Assess third-party and digital-platform risks using governance and assurance methods.
7. Recommend practical controls for a realistic application and cloud environment.

1. The Application and Platform Attack Surface

An attack surface is the collection of interfaces, technologies, identities, services and data stores that an attacker may attempt to influence. In a traditional application, the attack surface may include a web server, database and administrative interface. In a contemporary platform it may also include:

• source-code repositories and build pipelines;
• cloud consoles, identity providers and service accounts;
• public APIs and software development kits;
• containers, images, registries and orchestration platforms;
• mobile applications and embedded secrets;
• SaaS integrations and OAuth permissions;
• third-party libraries, plugins and managed services; and
• logs, backups and data-analytics environments.

The most significant risk is often not a single defect but an unsafe relationship between components. For example, an application may validate input correctly while an overly privileged cloud identity permits a compromised process to access unrelated databases. Security analysis must therefore consider both component vulnerabilities and system-level trust relationships.

The core security objectives remain confidentiality, integrity, availability, authenticity and accountability. In applications, these objectives are implemented through controls such as access control, validation, cryptography, secure session management, logging, resilience and change control.

2. Secure Software Development

2.1 Security throughout the lifecycle

Secure software development integrates security activities into every phase of the software development life cycle (SDLC):

The National Institute of Standards and Technology (NIST) Secure Software Development Framework (SSDF) groups practices into preparing the organisation, protecting software, producing well-secured software and responding to vulnerabilities. The framework is not a single development methodology; it is a set of practices that can be integrated with agile, DevOps or other delivery models.

2.2 Threat modelling

Threat modelling is a structured method for identifying how a system could be attacked and how risk can be reduced before implementation. A practical process is:

1. Describe the system, assets and business processes.
2. Draw data flows and identify trust boundaries.
3. Identify threats, including misuse by authorised users.
4. Estimate likelihood and impact.
5. Select controls and record residual risk.
6. Revisit the model when architecture or requirements change.

STRIDE is a commonly used mnemonic: spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege. STRIDE helps generate questions, but it does not replace professional judgement, abuse-case analysis or risk assessment.

A threat model should identify high-value assets such as payment data, credentials, health information, cryptographic keys and administrative functions. It should also consider non-human identities, event-driven integrations and supply-chain components.

2.3 Secure coding principles

Important principles include least privilege, fail-safe defaults, complete mediation, separation of duties, defence in depth, secure defaults and minimisation of attack surface. Input should be treated as untrusted until it has been validated for the expected type, length, range, encoding and business meaning.

Output encoding is distinct from input validation. Validation determines whether data is acceptable for a particular operation; encoding ensures that data is interpreted as data rather than executable markup or code in a particular output context. A value safe for HTML text may not be safe for a JavaScript string, SQL statement or shell command.

Developers should use parameterised database queries, established cryptographic libraries, secure random-number generators and framework-provided session protections. Passwords should be stored using a slow, salted, adaptive password-hashing function rather than encryption or a general-purpose hash. Secrets should be stored in an approved secrets-management system, not in source code, mobile packages or container images.

3. DevSecOps

DevSecOps extends DevOps by making security a shared responsibility across development, operations, security and management. Its aim is not merely to insert a security approval gate into a rapid pipeline. It is to make secure practices repeatable, automated and compatible with frequent delivery.

A mature DevSecOps pipeline may contain:

1. Plan: security requirements, risk classification and abuse stories.
2. Code: protected branches, peer review, secret scanning and secure coding guidance.
3. Build: software composition analysis (SCA), static application security testing (SAST) and reproducible build controls.
4. Test: dynamic application security testing (DAST), API tests, infrastructure tests and focused penetration testing.
5. Release: signed artefacts, approval rules, vulnerability thresholds and deployment policy checks.
6. Deploy: infrastructure as code, identity controls, environment separation and rollback.
7. Operate: runtime monitoring, vulnerability management, incident response and feedback to developers.

SAST examines source or compiled code without executing the application. DAST examines a running application from an external perspective. SCA identifies known vulnerabilities and licensing concerns in open-source components. Interactive application security testing combines runtime observation with knowledge of application behaviour. None of these methods is complete: static analysis can produce false positives, dynamic tests may miss inaccessible paths, and dependency databases may not contain newly discovered vulnerabilities.

Security gates should be risk-based. Blocking every theoretical warning can encourage teams to bypass controls, whereas ignoring critical exploitable weaknesses creates unacceptable exposure. Teams should define severity, exploitability, business impact, compensating controls and remediation deadlines.

4. Web Application and API Security

4.1 OWASP risks

The OWASP Top 10 is an awareness and education document, not a complete security standard. Its 2021 categories include broken access control, cryptographic failures, injection, insecure design, security misconfiguration, vulnerable and outdated components, identification and authentication failures, software and data integrity failures, security logging and monitoring failures, and server-side request forgery (SSRF).

Broken access control occurs when an application fails to enforce what an authenticated subject may do. A user changing an object identifier in a URL and viewing another customer’s record is an instance of insecure direct object reference, now understood as a form of broken access control. Authorisation must be checked on the server for every protected operation; hiding a button in the interface is not an access-control mechanism.

Cryptographic failures include using obsolete algorithms, poor key management, transmitting sensitive data without adequate protection and retaining unnecessary sensitive information. Transport Layer Security (TLS) protects data in transit but does not by itself guarantee correct authorisation, secure endpoints or safe data at rest.

Injection occurs when untrusted data is interpreted as commands or instructions. SQL injection, operating-system command injection and template injection are examples. Parameterised queries, safe APIs, contextual output encoding and strict validation are preferred mitigations.

Insecure design describes weaknesses in architecture or business logic that cannot be fixed reliably by a single code patch. Examples include an unlimited password-reset process, an approval workflow that permits self-approval or an account-recovery design that treats easily guessed information as proof of identity.

Security misconfiguration includes default credentials, unnecessary services, permissive cloud policies, verbose production errors and missing security headers. Vulnerable components create risk when libraries, frameworks, images or plugins are unsupported or not patched. Software and data integrity failures include unverified updates and build pipelines that permit unauthorised modification.

SSRF occurs when a server retrieves a resource based on attacker-controlled input and can be induced to access internal services or cloud metadata endpoints. Controls include allow-listed destinations, network egress restrictions, careful URL parsing, metadata-service protections and least-privileged workload identities.

4.2 API security

APIs expose business functions directly and are often consumed by mobile applications, partners and automated processes. The OWASP API Security Top 10 highlights risks such as broken object-level authorisation, broken authentication, unrestricted resource consumption, unrestricted access to sensitive business flows, server-side request forgery, security misconfiguration and unsafe consumption of APIs.

An API security programme should include:

• strong authentication appropriate to the client and risk;
• server-side authorisation at object and function levels;
• schema validation and strict content-type handling;
• rate limits, quotas and payload-size limits;
• protection against replay where relevant;
• secure error responses that do not disclose secrets;
• API inventory, version control and retirement of obsolete endpoints;
• centralised logging of authentication, authorisation and high-risk actions; and
• contract testing and negative testing.

Tokens should have limited scope, audience, lifetime and privileges. Long-lived credentials increase the impact of theft. API gateways can enforce common policies, but application services must still perform business authorisation because a gateway may not understand object ownership or workflow rules.

5. Cloud Security and Shared Responsibility

Cloud security is governed by a shared-responsibility model. The cloud provider is responsible for security of the cloud, including the physical facilities, underlying hardware and, depending on the service model, selected platform components. The customer is responsible for security in the cloud, including identities, data, configurations and workload-specific controls.

The division changes by service model:

This table describes common patterns, not a universal contract. The service agreement and provider documentation determine the exact boundary. A provider may offer encryption, logging or backup capabilities, but the customer must configure and use them correctly.

Common cloud failures include public storage exposure, excessive identity privileges, unprotected management interfaces, insecure security-group rules, disabled logging, unmanaged keys and untested backups. Cloud identity and access management (IAM) should use federation, multi-factor authentication, role-based or attribute-based permissions, short-lived credentials, separation of duties and regular access review.

Cloud governance should establish account or subscription structure, approved regions, tagging, data-residency requirements, logging standards, network patterns, encryption requirements and exception processes. Policy as code can detect prohibited configurations before deployment and continuously assess running resources.

6. Containers and Orchestration

Containers package an application and its dependencies while sharing the host operating-system kernel. They are not equivalent to virtual machines: a container escape or host compromise can affect multiple workloads. Container security must therefore cover the image, registry, runtime, orchestration layer and host.

Recommended practices include:

• use minimal, supported base images;
• pin dependencies and record software bills of materials (SBOMs);
• scan images during development and before deployment;
• sign images and verify provenance;
• run as a non-root user where possible;
• drop unnecessary Linux capabilities;
• use read-only filesystems and resource limits where practical;
• separate workloads using namespaces, network policies and appropriate node controls;
• protect cluster control planes and admission interfaces; and
• prevent secrets from being embedded in images or manifests.

Image scanning is not a complete risk assessment. A reported vulnerability may not be reachable or exploitable, while an unsafe application configuration may not appear in a package database. Runtime monitoring and configuration review remain necessary.

7. Mobile Application Security

Mobile applications operate in environments controlled partly by the user and therefore cannot be trusted to enforce business rules. The server must validate authorisation, prices, transaction states and entitlements. Client-side checks improve usability but are not security boundaries.

Mobile risks include insecure local storage, hard-coded secrets, weak authentication, insecure inter-process communication, certificate-validation errors, excessive permissions, reverse engineering and insecure third-party SDKs. Sensitive data should be minimised, stored using platform-protected facilities where appropriate and removed when no longer required. Applications should use secure transport and carefully implement certificate validation; disabling validation to solve a testing problem creates a serious production weakness.

Mobile release governance should include signing-key protection, dependency review, privacy analysis, update support and a mechanism for revoking compromised sessions or credentials. Mobile application management can help enforce device posture and organisational policy, but it does not make an untrusted device fully secure.

8. SaaS Governance and Digital Platforms

SaaS changes the operational model: the customer does not normally administer the underlying operating system, but remains responsible for account governance, data use and integration risk. Important controls include:

• single sign-on and phishing-resistant multi-factor authentication;
• role design based on least privilege and separation of duties;
• joiner, mover and leaver processes;
• periodic access certification;
• restrictions on administrator consent and third-party OAuth applications;
• data classification, retention and legal-hold controls;
• audit-log access and integration with security monitoring;
• backup, export and exit procedures; and
• contractual requirements for incident notification, subprocessors, data location and deletion.

SaaS security posture management can identify risky settings across cloud applications, but tools do not replace governance. Organisations should maintain an inventory of sanctioned and unsanctioned applications, often called shadow IT, and assess whether employees are uploading regulated or confidential information to unapproved services.

9. Configuration Management and Infrastructure as Code

Configuration management establishes a known, controlled and reviewable state for systems. A secure configuration baseline may specify identity settings, network exposure, logging, encryption, software versions, administrative access and backup behaviour.

Infrastructure as code (IaC) expresses infrastructure in version-controlled, reviewable files. It supports repeatability and reduces manual drift, but insecure code can reproduce insecurity at scale. IaC pipelines should use peer review, secret scanning, policy checks, state-file protection, least-privileged deployment identities and controlled promotion between environments.

Configuration drift occurs when the running environment differs from the approved baseline. Detection may compare actual settings with desired state; remediation should consider whether automatic correction could interrupt a critical service. Every exception should have an owner, justification, expiry date and compensating control.

10. Third-Party and Platform Supply-Chain Risk

Organisations inherit risk from cloud providers, SaaS vendors, open-source projects, managed service providers, payment processors and software libraries. Third-party risk management should be proportionate to data sensitivity, connectivity, privilege, concentration risk and operational criticality.

A practical lifecycle includes:

1. classify the service and information involved;
2. assess the supplier’s security capability and relevant assurance evidence;
3. define contractual controls and responsibilities;
4. restrict integration privileges and network connectivity;
5. monitor security, availability and material changes;
6. test incident coordination and business continuity; and
7. plan renewal, termination, data return and secure deletion.

Evidence may include independent assurance reports, penetration-test summaries, vulnerability-management practices, incident history, recovery objectives, encryption details and subprocessor information. Certifications can provide useful evidence of a control programme but do not guarantee that a particular implementation is secure.

Software supply-chain controls include dependency pinning, provenance verification, signed releases, protected build systems, SBOMs and rapid response to newly disclosed vulnerabilities. A supplier’s compromise can affect many customers simultaneously, making concentration and systemic risk important governance concerns.

11. Illustrative Case: Northstar Health Platform

Background

Northstar Health is an illustrative regional healthcare provider. It operates a patient portal, mobile application, cloud-hosted clinical services and SaaS collaboration tools. The portal uses APIs to connect appointment, billing and laboratory systems. A small development team deploys weekly through a cloud-based CI/CD pipeline.

Problem

An assessment found that a mobile API accepted a patient identifier supplied by the client without verifying that the authenticated user was authorised to view it. A cloud storage bucket used for application logs was publicly readable. The CI pipeline contained a long-lived cloud access key, and an external analytics SaaS application had broad access to patient-related event data.

Analysis

The patient-identifier weakness represented broken object-level authorisation. The public bucket was a security misconfiguration and created a confidentiality risk. The long-lived key violated least privilege and increased the impact of source-code or pipeline compromise. The analytics integration created a data-governance and third-party risk, even though the SaaS provider itself had strong security certification.

The organisation’s initial approach focused on scanning source code. This missed business-authorisation flaws, cloud configuration errors and excessive SaaS permissions. A broader threat model showed that the highest risks crossed organisational and technical boundaries.

Approach and solution

Northstar first disabled public access and rotated the exposed key. It replaced the key with a short-lived workload identity and separated deployment permissions from runtime permissions. API services added server-side ownership checks and tests for horizontal and vertical privilege escalation. The organisation introduced centralised cloud logging, alerting for public-resource changes and policy-as-code checks in the deployment pipeline.

The SaaS integration was redesigned to send minimised, pseudonymised events. Administrative consent was restricted, access was reviewed quarterly and the contract was updated to address incident notification, subprocessors, retention and deletion. A threat-modelling workshop was added to major feature planning, and security defects were prioritised according to patient impact and exploitability rather than scanner count.

Outcome and learning points

The case demonstrates that application security is a socio-technical problem. Secure code did not compensate for weak authorisation, insecure cloud configuration or excessive third-party access. Effective improvement required identity governance, secure engineering, cloud controls, privacy analysis, monitoring and management accountability.

12. Governance, Ethics and Regulation

Application and platform security involve ethical duties because failures can expose people to fraud, discrimination, physical harm or loss of privacy. Security testing must be authorised, scoped and conducted in a way that minimises disruption and protects discovered data. Organisations should provide responsible vulnerability-disclosure channels and avoid retaliatory treatment of good-faith researchers.

Regulatory obligations vary by jurisdiction and sector, but commonly concern privacy, breach notification, payment data, health information, records retention and supplier oversight. Compliance is a baseline, not proof of security. Governance should connect legal requirements to specific owners, technical controls, evidence and review dates.

Artificial intelligence introduces additional application-security concerns. AI systems may expose sensitive prompts, rely on untrusted retrieved content, produce unsafe tool instructions or be manipulated through prompt injection. Traditional controls remain essential: least privilege, input and output controls, monitoring, human approval for high-impact actions and protection of training and operational data.

13. Best-Practice Integration

A coherent security programme should:

• maintain an inventory of applications, APIs, cloud resources, SaaS services and suppliers;
• classify data and map it to processing locations and retention rules;
• use threat modelling for material architectural changes;
• automate security checks while retaining expert review;
• enforce server-side authorisation and least privilege;
• protect secrets and use short-lived credentials;
• apply secure baselines and continuously detect drift;
• monitor identity, configuration and high-risk business events;
• test backup restoration, incident response and supplier coordination;
• measure remediation time, coverage and recurrence rather than relying only on scan counts; and
• review controls after incidents, major changes and newly discovered vulnerabilities.

The objective is not to eliminate every vulnerability, which is unrealistic, but to reduce exposure, limit blast radius, detect misuse quickly and recover reliably.

Chapter Summary

Application, cloud and digital-platform security must be integrated across the entire technology lifecycle. Secure software development uses threat modelling, secure design, validated input, safe output handling, protected secrets and disciplined dependency management. DevSecOps makes security continuous and collaborative through practices such as SAST, DAST, SCA, policy checks and runtime monitoring.

OWASP risks provide a useful vocabulary for web and API weaknesses, especially broken access control, injection, insecure design, misconfiguration and SSRF. APIs require explicit object-level and function-level authorisation, rate controls, inventory and secure token management. Cloud security follows a shared-responsibility model whose exact boundary depends on the service and contract. Customers remain accountable for identities, data and configuration.

Containers, mobile applications and SaaS platforms introduce distinctive risks involving images, runtime isolation, client trust, permissions, integrations and governance. Configuration management and IaC improve consistency only when their own code, state and deployment identities are secured. Third-party risk requires lifecycle assessment, contractual controls, monitoring, resilience and exit planning. Effective security is therefore a combination of engineering, governance, privacy, monitoring and informed risk decisions.

Key Terms

Secure software development: Integrating security practices throughout the software lifecycle.

DevSecOps: A delivery approach that embeds security into development and operations.

Threat modelling: Structured identification and treatment of threats in a system design.

SAST: Static application security testing performed without executing the application.

DAST: Dynamic application security testing against a running application.

SCA: Analysis of third-party and open-source components for vulnerabilities and licensing issues.

API: An interface through which software systems exchange functions or data.

Broken access control: Failure to enforce permitted actions for an authenticated subject.

Injection: Treating untrusted input as executable commands or instructions.

SSRF: A vulnerability causing a server to make attacker-influenced requests to unintended resources.

IAM: Identity and access management for users, services and permissions.

Shared responsibility: Division of security duties between a cloud provider and customer.

Container: An isolated application package sharing the host operating-system kernel.

SaaS: Software delivered as a managed service by a provider.

Infrastructure as code: Defining infrastructure through version-controlled machine-readable files.

Configuration drift: Difference between an approved configuration and the running state.

SBOM: A record of software components contained in a product or system.

Least privilege: Granting only the permissions required for an authorised task.

Software supply chain: The people, processes, code and services used to produce and deliver software.

Review Questions

Short Answer Questions

1. What is the purpose of threat modelling?
2. Distinguish SAST from DAST.
3. Why is client-side authorisation insufficient for a mobile application?
4. What does the cloud shared-responsibility model mean?
5. Define configuration drift.

Long Answer Questions

1. Explain how security activities can be integrated into each phase of the software development lifecycle.
2. Discuss the major OWASP web application risks and their principal mitigations.
3. Compare security responsibilities in Infrastructure as a Service, Platform as a Service and Software as a Service.
4. Explain how an organisation can govern SaaS applications and OAuth integrations.
5. Evaluate the role of SBOMs, image signing and dependency management in software supply-chain security.

Analytical / Application Questions

1. A cloud-hosted API allows authenticated users to request any customer record by changing an identifier in the request. Analyse the vulnerability and propose preventive, detective and corrective controls.
2. An organisation discovers that a container image contains an old vulnerable library, but the vulnerable function is not used. Explain how the organisation should assess and manage the risk rather than relying solely on the scanner result.
3. Design a proportionate security-assurance plan for a third-party SaaS provider that will process confidential employee information and connect to the organisation’s identity provider.

Multiple Choice Questions with Answers

Question 1

Which activity most directly identifies trust boundaries and potential attack paths before implementation?

A. Threat modelling

B. User acceptance testing

C. Capacity planning

D. Data archiving

Correct Answer: A. Threat modelling

Question 2

Which control is the strongest general mitigation for SQL injection?

A. Hiding database error messages

B. Using parameterised queries

C. Increasing server memory

D. Disabling application logs

Correct Answer: B. Using parameterised queries

Question 3

Under the shared-responsibility model, which responsibility normally remains with the cloud customer?

A. Operating the provider’s physical data centre

B. Manufacturing the provider’s servers

C. Managing customer identities and permissions

D. Maintaining the provider’s virtualisation hardware

Correct Answer: C. Managing customer identities and permissions

Question 4

A user changes an object identifier in an API request and receives another customer’s data. What is the primary vulnerability?

A. Broken object-level authorisation

B. Denial of service

C. Certificate expiration

D. Image-layer duplication

Correct Answer: A. Broken object-level authorisation

Question 5

Which statement about containers is correct?

A. Containers always provide stronger isolation than virtual machines

B. Containers share the host kernel and therefore require host and runtime security

C. Container images cannot contain vulnerable dependencies

D. Running as root is required for all containers

Correct Answer: B. Containers share the host kernel and therefore require host and runtime security

Question 6

What is the main purpose of software composition analysis?

A. To measure network bandwidth

B. To identify risks in third-party and open-source components

C. To replace all penetration testing

D. To encrypt database backups

Correct Answer: B. To identify risks in third-party and open-source components

Question 7

Which practice best reduces the risk of a stolen cloud credential causing extensive damage?

A. Use a permanent administrator key

B. Share one account among the operations team

C. Use short-lived, least-privileged workload identities

D. Disable audit logging

Correct Answer: C. Use short-lived, least-privileged workload identities

Question 8

Why is infrastructure as code useful for security?

A. It eliminates the need for configuration review

B. It makes approved configurations repeatable and reviewable

C. It guarantees that all infrastructure is secure

D. It prevents all software vulnerabilities

Correct Answer: B. It makes approved configurations repeatable and reviewable

Question 9

Which control is particularly relevant to SaaS governance?

A. Periodic access certification and restriction of unnecessary OAuth permissions

B. Removing all audit logs

C. Allowing unrestricted administrator consent

D. Using identical passwords across SaaS services

Correct Answer: A. Periodic access certification and restriction of unnecessary OAuth permissions

Question 10

What does SSRF enable an attacker to influence?

A. The server’s outbound request to an unintended resource

B. The physical temperature of a data centre

C. The compiler’s programming language

D. The customer’s hardware warranty

Correct Answer: A. The server’s outbound request to an unintended resource