Application, API, and DevSecOps Security

Introduction and Context

Cloud applications are assembled from source code, third-party libraries, application programming interfaces (APIs), containers, infrastructure-as-code (IaC) templates, managed services, and automated deployment pipelines. This architecture improves speed and scalability, but it also expands the attack surface. A vulnerability may be introduced in application logic, a dependency, an API contract, a container image, a cloud permission, or a build process.

Application security therefore cannot be postponed until production. It must be integrated throughout the software development lifecycle (SDLC). DevSecOps is the organizational and technical approach of embedding security responsibilities, controls, and feedback into development and operations while preserving the automation and collaboration associated with DevOps.

The aim is not to make every developer a security specialist. Rather, it is to establish secure defaults, automated checks, clear ownership, risk-based decision-making, and rapid remediation. Security teams provide expertise and guardrails; developers address defects close to where they are introduced; operations protect runtime environments and monitor for abuse.

Learning Objectives

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

1. Explain the security responsibilities of applications, APIs, pipelines, and cloud infrastructure.
2. Apply a basic threat-modelling process using assets, trust boundaries, threats, and mitigations.
3. Distinguish static, dynamic, software-composition, secret, container, and IaC scanning.
4. Describe secure API design, authentication, authorization, validation, and abuse protection.
5. Recommend CI/CD safeguards and explain the purpose of an SBOM.
6. Evaluate software supply-chain risks and propose practical governance controls.
7. Integrate security activities into a realistic cloud development workflow.

1. The Application Security Problem in Cloud Environments

Traditional applications were often deployed to a small number of controlled servers. Cloud-native systems may use multiple accounts, regions, containers, serverless functions, managed databases, queues, identity providers, and external SaaS services. Consequently, security depends on both code and configuration.

Important assets include:

• customer data, credentials, tokens, and encryption keys;
• business functions such as payments, account recovery, and administrative actions;
• source code, build artifacts, signing keys, and deployment credentials;
• cloud resources and their configuration;
• availability, integrity, confidentiality, and audit records.

A useful principle is defence in depth. An application should not depend on one control, such as a firewall. Authentication, authorization, input validation, secure session management, encryption, logging, monitoring, rate limiting, and cloud identity controls should reinforce one another.

The shared-responsibility model remains relevant. A cloud provider may secure physical facilities and managed service infrastructure, while the customer remains responsible for application code, identities, data classification, configuration, and often operating-system or container security. The exact division varies by service model, so it must be verified for each provider and service.

2. Threat Modelling Before Implementation

Threat modelling is a structured method for identifying what can go wrong, why it could happen, and how risk can be reduced. It is most valuable early in design, when architectural changes are less expensive.

A practical process is:

1. Define scope. Identify the system, users, external services, data flows, and security objectives.
2. Identify assets. Record data, functions, identities, secrets, and availability requirements.
3. Draw trust boundaries. Mark transitions between users, public networks, application services, databases, cloud accounts, and third parties.
4. Identify threats. Consider unauthorized access, manipulation, disclosure, denial of service, repudiation, and supply-chain compromise.
5. Assess risk. Estimate likelihood and impact using an agreed qualitative or quantitative method.
6. Select mitigations. Prefer architectural and preventive controls, followed by detection and response.
7. Record assumptions and residual risk. Assign owners and revisit the model after significant change.

The STRIDE mnemonic is commonly used to organize threats: Spoofing identity, Tampering with data, Repudiation, Information disclosure, Denial of service, and Elevation of privilege. It is a checklist rather than a complete risk assessment. Threat modelling should also consider privacy, regulatory obligations, operational resilience, and misuse by legitimate users.

A threat model should be a living engineering artefact. It can be represented in an issue tracker and linked to requirements, tests, and deployment controls. For example, if a public API accesses customer records, the model should identify the API gateway, authentication service, authorization decision, database, logging system, and administrative interfaces.

3. Secure Coding Foundations

Secure coding reduces the likelihood that ordinary inputs can cause unauthorized behavior. Core practices include:

Input handling

Treat all external input as untrusted, including HTTP parameters, uploaded files, message-queue content, and data received from partner APIs. Validate type, length, range, encoding, and business rules. Prefer allow-lists where practical. Validation should occur at trust boundaries, but it must not be the only defence.

Use parameterized database queries or a well-designed data-access layer rather than constructing SQL through string concatenation. Encode output according to its context—HTML, JavaScript, URL, SQL, or operating-system command contexts require different protections. File uploads require size limits, type verification, safe storage names, malware inspection where appropriate, and prevention of executable interpretation.

Identity and authorization

Authentication establishes who or what is requesting access; authorization determines what that identity may do. Authorization must be enforced on the server for every protected operation. Never rely solely on hidden user-interface controls or identifiers supplied by the client.

Use least privilege, deny-by-default policies, short-lived credentials, secure session handling, multi-factor authentication for privileged actions, and careful separation of human and machine identities. Object-level authorization is especially important in APIs: a user authorized to access one invoice must not automatically access another invoice by changing an identifier.

Secrets and cryptography

Passwords should be stored using an adaptive, salted password-hashing scheme rather than reversible encryption or unsalted hashes. API keys, private keys, and database credentials should be stored in an approved secrets manager, not in source code, images, logs, or ordinary configuration files.

Use established cryptographic libraries and protocols. Encryption does not replace authorization, and key management is as important as the encryption algorithm. Keys should have controlled access, rotation procedures, usage monitoring, and separate environments.

Errors and logging

Error responses should help legitimate users recover without disclosing stack traces, credentials, internal paths, or database details. Logs should support detection and investigation, recording relevant events such as authentication failures, privilege changes, sensitive-data access, and deployment activity. Sensitive values must be masked or excluded. Logs require access control, integrity protection, retention rules, and privacy review.

4. API Security

An API is a contract through which software exchanges data or invokes functions. Common styles include REST, GraphQL, gRPC, and event-driven interfaces. API security must address the entire lifecycle: design, implementation, publication, operation, and retirement.

Secure API design

An API specification should define authentication, authorization, input schemas, output fields, error behavior, rate limits, and security requirements. Minimize returned data. Avoid exposing internal database models directly because this can reveal fields that were never intended for clients.

Use TLS for data in transit and validate certificates appropriately. OAuth 2.0 and OpenID Connect are widely used for delegated authorization and identity, but they must be configured correctly. Access tokens should have appropriate audience, scope, lifetime, and issuer validation. A token’s possession should not be treated as unlimited authority.

API gateways can provide TLS termination, routing, authentication integration, schema checks, quotas, rate limiting, threat detection, and centralized logging. They do not remove the need for authorization within the service, especially where decisions depend on the requested object or business context.

Typical API threats and controls

Rate limiting should be designed around the protected resource, identity, IP address, and business operation. A single global limit may be ineffective or unfair. Controls should also address pagination limits, request size, file size, query complexity, and concurrency.

GraphQL requires particular care because clients can request deeply nested or computationally expensive queries. Schema authorization, depth or complexity limits, batching controls, and introspection policy should be considered. Webhooks require signature verification, replay protection, timeout controls, and safe retry handling.

5. Security Testing and Automated Scanning

No single scanner detects every defect. Effective programmes combine complementary techniques and human review.

• SAST examines source or bytecode without executing the application. It can identify unsafe functions, injection paths, and insecure patterns early, but may produce false positives and miss runtime configuration problems.
• DAST tests a running application from an external perspective. It can find observable authentication, session, and input-handling weaknesses, but coverage depends on reachable paths and test quality.
• IAST instruments applications during testing to combine runtime evidence with code context.
• Software composition analysis (SCA) inventories open-source dependencies and compares versions with vulnerability and licence information.
• Secret scanning detects likely credentials in repositories, commits, images, and build logs. Detection must be followed by immediate revocation and replacement.
• Container and artifact scanning examines operating-system packages, language dependencies, image configuration, and provenance.
• IaC scanning checks templates for excessive permissions, public storage, unencrypted resources, insecure network rules, and policy violations.
• Fuzz testing supplies unexpected or malformed inputs to discover crashes and validation defects.

Scanning results require triage. A vulnerability identifier alone does not determine business risk. Teams should consider exploitability, exposure, affected asset, compensating controls, data sensitivity, and whether the vulnerable component is actually reachable. A risk-based exception should have an owner, justification, expiry date, and compensating controls.

Security tests should be treated as code. Their configuration, test data, and expected results should be version-controlled. Tests must avoid causing harm to production systems or exposing real personal data.

6. CI/CD Security Controls

A secure pipeline protects source code, dependencies, build systems, artifacts, deployment credentials, and production environments. A typical sequence is:

1. Developer commits code and opens a reviewed change.
2. The pipeline performs formatting, unit tests, secret scanning, SAST, SCA, and IaC checks.
3. The application is built in an isolated, reproducible environment.
4. The artifact is scanned, signed or attested, and stored in a controlled registry.
5. Integration and security tests run in an ephemeral environment.
6. Promotion requires policy checks and appropriate approval.
7. Deployment uses short-lived, least-privilege identity.
8. Runtime monitoring and post-deployment verification provide feedback.

Branch protection, peer review, protected pipeline configuration, separation of duties for sensitive production changes, and audit trails reduce insider and supply-chain risk. A pipeline should not expose long-lived cloud keys to arbitrary build steps. Prefer workload identity or short-lived federated credentials, with permissions limited to the required environment and action.

Pipeline gates should be meaningful. Blocking every low-confidence finding encourages bypasses and alert fatigue. Conversely, critical vulnerabilities, leaked credentials, unsigned artifacts, or violations of mandatory policy should prevent promotion unless a documented emergency process is invoked.

7. Infrastructure-as-Code Security

IaC expresses infrastructure in declarative templates. It improves consistency and reviewability, but insecure templates can replicate weakness at scale. Controls should include:

• code review and version control for all templates;
• scanning for public exposure, excessive IAM permissions, unencrypted storage, unrestricted network rules, and disabled logging;
• policy-as-code with approved organizational rules;
• separate state storage with encryption and access control;
• protection against state-file leakage, since state may contain sensitive values;
• drift detection between declared and actual infrastructure;
• validation of modules and providers before use;
• separate accounts, subscriptions, projects, or workspaces for environments.

IaC security is not limited to syntax. A syntactically valid template may still violate data-residency, identity, backup, resilience, or segregation requirements. Cloud architecture review and runtime verification remain necessary.

8. SBOM and Software Supply-Chain Security

A software bill of materials (SBOM) is an inventory of components contained in a software product, including direct and, where possible, transitive dependencies. Useful SBOM formats include SPDX and CycloneDX. An SBOM commonly records component names, versions, suppliers, relationships, and identifiers such as package URLs or vulnerability-database references.

An SBOM does not prove that software is secure. It enables faster impact analysis when a vulnerability is disclosed, supports licence review, and improves procurement and incident response. Its quality depends on completeness, accuracy, provenance, and regular updating.

Supply-chain controls include:

• approved dependency repositories and version constraints;
• lockfiles and reproducible builds where feasible;
• review of maintainer, licence, release, and vulnerability signals;
• provenance and build attestations;
• signed commits, artifacts, and container images where operationally justified;
• isolated build workers and protected release branches;
• dependency update automation with testing;
• monitoring for malicious packages, typosquatting, dependency confusion, and compromised maintainers;
• rapid revocation and rotation of signing or publishing credentials.

The SLSA framework is an example of a provenance-oriented approach to improving software supply-chain integrity. It should be understood as a maturity and assurance framework, not as a substitute for application testing or organizational governance.

9. Illustrative Case: A Cloud Retail API

Background

A fictional online retailer operates a cloud-native order platform. A web application and mobile application call REST APIs hosted behind an API gateway. Services run in containers, use a managed database, and are deployed through a Git-based CI/CD pipeline.

Problem

A security review finds three weaknesses. First, the order endpoint checks that a customer is logged in but does not verify ownership of the requested order. Second, a dependency used for image processing has a known vulnerability. Third, the pipeline stores a long-lived cloud access key as a repository variable.

Analysis

The first issue is broken object-level authorization and can disclose personal and payment-related information. The second creates supply-chain and remote-exploitation risk depending on exposure and exploitability. The third increases the impact of repository or pipeline compromise because an attacker could retain access beyond the immediate build.

Threat modelling identifies the customer, API, order service, database, image-processing library, repository, pipeline, registry, and cloud account as relevant assets and trust boundaries. The security objectives are confidentiality of orders, integrity of deployments, and least-privilege operation.

Approach and solution

The development team adds a server-side authorization check based on the authenticated customer identity and order ownership. Tests attempt cross-customer access and must receive a safe denial response. The dependency is upgraded after compatibility testing; where immediate upgrading is impossible, the vulnerable feature is disabled and an exception is documented with an expiry date.

The long-lived key is revoked. The pipeline is changed to use federated, short-lived credentials restricted to the required registry and deployment actions. Secret scanning is enabled, artifacts are scanned and recorded in an SBOM, and production promotion requires review plus successful security gates. API rate limits, structured audit logging, and post-deployment monitoring are added.

Outcome

The retailer reduces unauthorized-data risk, limits the potential blast radius of pipeline compromise, and gains an inventory that can be queried when new dependency vulnerabilities are announced. The controls do not guarantee security; they make weaknesses more difficult to introduce, easier to detect, and faster to contain.

Learning points

1. Authentication without object-level authorization is insufficient.
2. Dependency risk must be managed continuously, not only during initial development.
3. Build credentials are high-value assets and should be short-lived and narrowly scoped.
4. Security requirements should be converted into automated tests and enforceable policy.

10. Governance, Ethics, and Contemporary Practice

Security decisions affect privacy, access to services, and organizational power. Monitoring should be proportionate, transparent, access-controlled, and compliant with applicable privacy law. Security testing must be authorized and carefully scoped. Researchers and employees need a responsible disclosure route that encourages reporting rather than retaliation.

Accessibility and inclusive design are also security concerns. A recovery flow that assumes one device, one language, or a particular physical ability may exclude legitimate users and encourage unsafe workarounds. Automated fraud and risk systems should be tested for unjustified discrimination.

Artificial intelligence can assist secure coding by suggesting tests, summarizing findings, detecting anomalous code changes, and helping triage vulnerabilities. However, generated code may contain insecure assumptions, licence problems, hallucinated dependencies, or exposed confidential prompts. AI-generated changes require ordinary review, testing, provenance, and approval. Organizations should define what code and data may be submitted to external AI services.

Contemporary practice is moving toward secure-by-design principles, memory-safe languages for suitable components, identity-aware service networking, continuous verification, software attestations, and platform engineering that provides secure reusable templates. These developments improve consistency but do not eliminate the need for threat modelling, professional judgment, and accountability.

Best-Practice Checklist

A diploma-level practitioner should be able to verify that:

• security requirements and trust boundaries are documented;
• authentication and authorization are tested separately;
• input, output, error, session, and secret-handling controls are implemented;
• APIs use explicit schemas, TLS, rate limits, and object-level authorization;
• source, dependencies, secrets, containers, and IaC are scanned;
• findings are triaged using exposure and business impact;
• CI/CD uses protected branches, isolated builds, short-lived credentials, and signed or traceable artifacts;
• an accurate SBOM is generated and maintained;
• exceptions are approved, owned, time-limited, and reviewed;
• logs, monitoring, incident response, and recovery are tested.

Chapter Summary

Cloud application security is a lifecycle discipline. Threat modelling identifies assets, trust boundaries, threats, and mitigations before implementation. Secure coding protects inputs, identities, secrets, data, sessions, and error paths. API security requires both strong protocol controls and fine-grained business authorization. SAST, DAST, SCA, secret, container, IaC, and fuzz testing provide complementary evidence rather than a single guarantee.

DevSecOps embeds these practices into CI/CD through code review, automated testing, protected pipelines, least-privilege identities, artifact integrity, and runtime feedback. IaC controls prevent insecure cloud configurations from being replicated. SBOMs improve visibility into dependencies and support vulnerability response, while supply-chain security addresses provenance, repositories, build systems, maintainers, and release processes. Effective security remains risk-based, ethical, measurable, and continuously improved.

Key Terms

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

Trust boundary: A point where data or authority crosses between different trust levels.

DevSecOps: Integration of security practices into development and operations workflows.

API: An interface through which software requests data or actions from another system.

Authentication: Verification of an identity.

Authorization: Determination of what an authenticated identity may do.

Least privilege: Granting only the permissions necessary for an activity.

SAST: Static application security testing of code or compiled artefacts.

DAST: Dynamic testing of a running application.

SCA: Analysis of third-party and open-source dependencies.

Secret scanning: Detection of credentials or sensitive tokens in technical artefacts.

Infrastructure as code: Declarative management of infrastructure through versioned files.

Policy as code: Machine-enforced representation of organizational rules.

CI/CD: Continuous integration and continuous delivery or deployment.

SBOM: A machine-readable inventory of software components and relationships.

Software supply chain: People, processes, tools, dependencies, and systems used to create and deliver software.

Provenance: Evidence describing how, where, and from what sources an artifact was produced.

Defence in depth: Use of multiple reinforcing security controls.

Residual risk: Risk remaining after controls have been applied.

Review Questions

Short Answer Questions

1. Why should threat modelling begin before application implementation?
2. Distinguish authentication from authorization.
3. What problem does an SBOM help an organization solve?
4. Name three types of automated security scanning and state what each examines.
5. Why are short-lived pipeline credentials preferable to long-lived access keys?

Long Answer Questions

1. Explain how a secure API design can reduce broken object-level authorization, injection, data exposure, and denial-of-service risks.
2. Describe a DevSecOps CI/CD pipeline and identify security controls at each major stage.
3. Compare SAST, DAST, SCA, secret scanning, container scanning, and IaC scanning, including important limitations.
4. Explain how threat modelling, secure coding, testing, and runtime monitoring reinforce one another.
5. Discuss the role of SBOMs, provenance, signing, and dependency governance in software supply-chain security.

Analytical / Application Questions

1. A developer discovers a critical vulnerability in a library used by a public image-processing API. Propose an immediate response, a short-term mitigation, and a long-term preventive control.
2. An API verifies that a user is logged in but allows the user to request any invoice by changing an invoice number. Identify the threat, explain the underlying design failure, and specify tests and controls that should be implemented.
3. Design a security gate policy for a cloud deployment pipeline. State which findings should block production, which may require documented exceptions, and how you would avoid alert fatigue.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes authorization from authentication?

A. Authentication determines permissions, while authorization verifies identity

B. Authentication verifies identity, while authorization determines permitted actions

C. Authentication encrypts data, while authorization compresses it

D. Authentication applies only to APIs, while authorization applies only to databases

Correct Answer: B. Authentication verifies identity, while authorization determines permitted actions

Question 2

Which control most directly prevents a user from viewing another customer’s order by changing an order identifier?

A. Client-side hiding of the order identifier

B. A longer password requirement

C. Server-side object-ownership authorization

D. Disabling application logs

Correct Answer: C. Server-side object-ownership authorization

Question 3

What is the principal purpose of software composition analysis?

A. To inspect third-party dependencies for versions and known vulnerabilities

B. To measure network bandwidth during production

C. To replace all application security testing

D. To encrypt source code in a repository

Correct Answer: A. To inspect third-party dependencies for versions and known vulnerabilities

Question 4

Which practice best reduces the risk of a compromised CI/CD pipeline retaining cloud access?

A. Using one permanent administrator key for all environments

B. Embedding credentials in container images

C. Using short-lived, narrowly scoped federated credentials

D. Disabling audit logs for build jobs

Correct Answer: C. Using short-lived, narrowly scoped federated credentials

Question 5

What does an SBOM primarily provide?

A. A guarantee that software has no vulnerabilities

B. An inventory of software components and their relationships

C. A replacement for authorization checks

D. A list of all users currently logged in

Correct Answer: B. An inventory of software components and their relationships

Question 6

Which activity is characteristic of DAST?

A. Examining source code without executing the application

B. Testing a running application from an external perspective

C. Listing only the cloud provider’s physical facilities

D. Signing a developer’s personal laptop

Correct Answer: B. Testing a running application from an external perspective

Question 7

Why is policy-as-code useful for infrastructure security?

A. It makes security reviews unnecessary

B. It automatically guarantees business continuity

C. It expresses rules that can be checked consistently and automatically

D. It prevents all vulnerabilities in third-party libraries

Correct Answer: C. It expresses rules that can be checked consistently and automatically

Question 8

Which threat category involves an attacker pretending to be another identity?

A. Spoofing

B. Repudiation

C. Denial of service

D. Information disclosure

Correct Answer: A. Spoofing

Question 9

Which API control helps limit resource-exhaustion attacks?

A. Unlimited pagination and unrestricted request sizes

B. Rate limits, quotas, and query complexity limits

C. Returning every database field in every response

D. Removing authentication from read operations

Correct Answer: B. Rate limits, quotas, and query complexity limits

Question 10

Which statement about security scanning is most accurate?

A. One scanner can reliably detect every application vulnerability

B. Scanning results should be triaged using exposure, exploitability, and business impact

C. Low-confidence findings should always block every deployment permanently

D. Scanning eliminates the need for threat modelling

Correct Answer: B. Scanning results should be triaged using exposure, exploitability, and business impact