Secure Software, Cloud, API and Third-Party Risk

Introduction

Banking has become a software-intensive, cloud-enabled and highly interconnected industry. Customer onboarding, payments, credit decisions, open banking, mobile applications and fraud analytics increasingly depend on application programming interfaces (APIs), cloud platforms, managed services and external software components. These technologies improve speed and scalability, but they also enlarge the attack surface. A vulnerability in a library, identity service, cloud configuration or technology supplier can affect confidentiality, integrity, availability and trust across the banking ecosystem.

Traditional security models treated security as a final testing activity performed before deployment. Contemporary practice integrates security throughout the software life cycle and treats suppliers, platforms and interfaces as components of one socio-technical risk system. This chapter examines DevSecOps, secure coding, API protection, cloud shared responsibility, third-party risk management, software supply-chain assurance and continuous monitoring.

Learning Objectives

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

1. Explain the principles and operating model of DevSecOps.
2. Apply secure software-development and secure-coding principles.
3. Analyse common API threats and appropriate controls.
4. Distinguish customer and provider responsibilities in cloud computing.
5. Design a risk-based third-party and software-supply-chain assurance process.
6. Evaluate continuous monitoring, governance, regulatory and ethical implications.
7. Integrate technical evidence with banking risk and fraud-management decisions.

1. Security as a Life-Cycle and Ecosystem Responsibility

Secure software is not simply software that passes a penetration test. It is software designed, built, deployed and operated with explicit security requirements, controlled change, defensible architecture, observable behaviour and recoverability. Security objectives should be derived from business processes and information classifications.

The principal security properties are:

• Confidentiality: information is disclosed only to authorised parties.
• Integrity: information and processing are accurate, complete and protected from unauthorised alteration.
• Availability: systems and information are accessible when required.
• Authenticity: users, systems, messages and transactions can be reliably associated with their claimed identities.
• Accountability: actions can be attributed through trustworthy records.
• Resilience: services can continue or recover within acceptable limits after disruption.

For a bank, a security failure may also become a fraud event. For example, an altered payment instruction is an integrity breach; stolen session credentials create an authentication problem; and a compromised customer-data API may support identity theft or account takeover.

Security requirements should be traceable from business risk to control and evidence. A useful chain is:

Business service → information and assets → threats → risk scenarios → security requirements → controls → test evidence → operational monitoring.

This traceability prevents a common weakness: implementing isolated technical controls without demonstrating that material banking risks have been addressed.

2. DevSecOps

2.1 Meaning and rationale

DevSecOps extends DevOps by making security a shared responsibility of development, security and operations teams. It combines automation, collaboration, continuous feedback and risk-based decision-making. Security specialists do not disappear; rather, their expertise is embedded earlier and made available throughout delivery.

A typical secure delivery flow is:

1. Plan: identify data classifications, abuse cases, regulatory requirements and security acceptance criteria.
2. Design: perform threat modelling, define trust boundaries and choose secure architectural patterns.
3. Code: apply secure coding standards, peer review and controlled dependency management.
4. Build: run automated source-code, dependency, secret and configuration checks.
5. Test: conduct unit, integration, dynamic, API, resilience and targeted penetration testing.
6. Release: approve artefacts, verify provenance, apply segregation of duties and record exceptions.
7. Deploy: use hardened infrastructure, protected secrets, least privilege and controlled configuration.
8. Operate: monitor events, vulnerabilities, fraud indicators and service health.
9. Learn: feed incidents, defects and near misses into requirements, design and training.

The pipeline should produce auditable evidence rather than merely a pass/fail result. Evidence may include commit identity, test results, dependency versions, approvals, deployment records, vulnerability exceptions and production telemetry.

2.2 Shift-left and shift-right security

“Shift left” means addressing security earlier, when defects are cheaper to correct. Threat modelling during design is generally more effective than discovering an architectural flaw after deployment. “Shift right” complements this approach through runtime monitoring, incident response, attack-surface management and feedback from real operational conditions.

Neither approach is sufficient alone. Static analysis may identify an unsafe function but miss a business-logic flaw. Runtime detection may identify abuse but cannot replace secure design. Mature programmes combine preventive, detective and corrective controls.

2.3 Security gates and exceptions

A security gate should be risk-based. Blocking every release for a low-severity issue may encourage teams to bypass the process, while allowing an exploitable authentication defect is unacceptable. Exceptions should have a documented owner, rationale, compensating controls, expiry date and remediation plan. Permanent exceptions are usually evidence of unmanaged risk rather than governance.

Useful programme measures include remediation time by severity, percentage of critical services with threat models, dependency coverage, secret-detection coverage, escaped defects and the proportion of releases with complete evidence. Metrics should not reward teams for hiding vulnerabilities or generating large quantities of low-value alerts.

3. Secure Coding and Application Architecture

Secure coding transforms security principles into implementation decisions. Important practices include:

• Validate input using allow-lists where feasible, canonicalise data before validation and reject unexpected formats.
• Use parameterised queries rather than concatenating user input into SQL or other interpreters.
• Encode output according to its context, such as HTML, JavaScript, URL or SQL context.
• Apply strong authentication, secure session management and re-authentication for high-risk actions.
• Enforce authorisation on the server for every protected object and operation; do not rely on client-side controls.
• Use cryptographic libraries correctly, protect keys, and avoid inventing cryptographic algorithms.
• Store passwords with an adaptive, salted password-hashing function, never as reversible encryption or plaintext.
• Fail securely, avoiding disclosure of stack traces, credentials or sensitive internal details.
• Log security-relevant events without recording secrets, full payment-card data or unnecessary personal information.
• Apply resource limits to prevent denial-of-service conditions.
• Make security-relevant operations idempotent where appropriate, particularly in payment processing.

3.1 Threat modelling

Threat modelling is a structured analysis of how a system could be misused. It identifies assets, actors, trust boundaries, entry points, threats, controls and residual risks. STRIDE is one commonly used classification: spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege. It is a useful prompt, not a complete risk method.

For banking applications, threat modelling should include business abuse cases such as changing a beneficiary, replaying a payment request, manipulating a fraud score, bypassing transaction limits or exploiting differences between mobile and server-side validation.

A threat model should be maintained as architecture changes. It is not a one-time workshop document.

3.2 Vulnerability management

A vulnerability scanner identifies possible weaknesses; it does not determine business risk by itself. Prioritisation should consider exploitability, exposure, affected asset, data sensitivity, existing controls, active exploitation and plausible business impact. A severe vulnerability in an isolated development system may require less immediate action than a moderate weakness in an internet-facing payment API.

Risk treatment options are generally to mitigate, transfer, avoid or accept the risk. Acceptance must be authorised at an appropriate level and should be time-limited.

4. API Security

An API is a contract through which software systems exchange requests and responses. APIs are central to mobile banking, payment gateways, open banking, card processing, identity verification and fraud analytics. Their security must protect both the interface and the underlying business process.

4.1 Principal API risks

Important risks include:

• Broken object-level authorisation: a user changes an object identifier and accesses another customer’s account or document.
• Broken function-level authorisation: a lower-privileged identity invokes an administrative operation.
• Broken authentication: weak token handling, insecure password recovery or inadequate session invalidation.
• Excessive data exposure: responses return more personal or financial data than the client requires.
• Mass assignment: clients modify fields that should be controlled only by the server.
• Unrestricted resource consumption: attackers cause excessive processing, storage or transaction activity.
• Injection: untrusted input is interpreted as commands or queries.
• Improper inventory: forgotten, undocumented or obsolete API versions remain reachable.
• Unsafe consumption of APIs: a bank trusts external responses without validating origin, integrity, schema or business meaning.
• Business-logic abuse: technically valid requests are used to perform unauthorised or fraudulent sequences.

4.2 API control architecture

Effective controls include TLS for data in transit, strong client and user authentication, narrowly scoped and short-lived tokens, server-side authorisation, schema validation, rate and transaction limits, replay protection, idempotency keys, secure error handling, centralised logging and API discovery.

OAuth 2.0 is an authorisation framework, not a complete authentication solution. OpenID Connect adds an identity layer. Their secure use requires correct redirect-URI validation, token audience and issuer validation, secure storage, scope restriction and protection against token substitution. Mutual TLS may provide strong service-to-service authentication, but it does not replace authorisation or business controls.

Rate limiting should be linked to identity, device, network, endpoint and transaction context where appropriate. A single fixed limit is often inadequate: a read-only balance request and a beneficiary-creation request have different risks.

API logs should support investigation by recording request time, service, authenticated principal, transaction or correlation identifier, outcome and relevant risk signals. Sensitive values should be masked or tokenised. Log integrity and access control are essential because attackers may attempt to delete or alter evidence.

5. Cloud Security and Shared Responsibility

Cloud security is governed by a shared-responsibility model. The provider is responsible for security of the cloud, including the underlying facilities, hardware and core platform. The customer remains responsible for security in the cloud, although the boundary varies by service model.

The model is not a substitute for reading the provider’s service documentation. Responsibilities may differ by region, product, managed feature and deployment design.

5.1 Major cloud control areas

• Identity: centralised identity governance, least privilege, phishing-resistant multifactor authentication for privileged access, separation of duties and periodic access review.
• Configuration: secure baselines, policy-as-code, continuous configuration assessment and prevention of public exposure.
• Data: classification, encryption in transit and at rest, key-management governance, retention and deletion controls.
• Network: segmentation, private endpoints where appropriate, egress control and protected administrative paths.
• Workloads: hardened images, patching, container and serverless controls, runtime monitoring and vulnerability management.
• Resilience: tested backups, recovery procedures, regional dependency analysis and service-level objectives.
• Logging: centralised, time-synchronised, access-controlled and tamper-evident logs.

Cloud concentration creates a systemic issue: several institutions may depend on the same provider, identity service or software component. A bank should therefore assess concentration risk, portability, exit arrangements and correlated failure scenarios, not merely individual control compliance.

6. Third-Party and Supplier Risk

Third-party risk arises when an external party can access bank information, influence a critical process, operate technology, provide software or become a dependency for service continuity. Outsourcing accountability is not outsourcing responsibility. The bank remains responsible for understanding and managing the risk.

6.1 Risk-based due diligence

A proportionate assessment should consider:

1. Criticality: Could supplier failure interrupt payments, liquidity, customer access or regulatory reporting?
2. Access: Does the supplier access personal data, credentials, production systems or security telemetry?
3. Concentration: Is the service difficult to replace or shared across many critical processes?
4. Jurisdiction: Where are data, personnel and subcontractors located, and what legal regimes apply?
5. Control maturity: Are security governance, identity, resilience, vulnerability management and incident response credible?
6. Evidence: Can claims be supported by independent assurance, testing results and operational metrics?
7. Exit: Can the bank retrieve data, change provider and operate during transition?

Questionnaires are useful for consistency but weak as sole evidence. They should be supplemented by contracts, audit reports, technical demonstrations, penetration-test summaries, architecture reviews, references and observed performance.

6.2 Contractual controls

Contracts for material services should address security obligations, data use, confidentiality, subcontracting, location, access control, vulnerability notification, incident notification, audit rights, cooperation with regulators, resilience testing, recovery objectives, retention, deletion, insurance where relevant and termination assistance. Service-level agreements should not focus only on uptime; they may include restoration, security-event response, vulnerability remediation and evidence delivery.

7. Software Supply-Chain Assurance

Modern applications are assembled from open-source packages, commercial libraries, containers, build tools, cloud services and externally maintained pipelines. This creates dependency and provenance risk.

Important controls include:

• Maintain an accurate software bill of materials (SBOM) identifying components and versions.
• Pin or otherwise control dependency versions and review transitive dependencies.
• Obtain packages from trusted repositories and verify signatures or checksums where available.
• Use protected source repositories, branch controls and peer review.
• Isolate build systems and protect signing keys and deployment credentials.
• Produce provenance evidence showing how an artefact was built.
• Scan source code, dependencies, containers, infrastructure-as-code and secrets.
• Monitor advisories and determine whether vulnerable components are actually reachable or exploitable.
• Use reproducible or independently verifiable builds where feasible.
• Establish an emergency process for malicious or critically vulnerable dependencies.

An SBOM improves visibility but does not prove that software is secure. A component may be listed yet misconfigured, vulnerable through its use, or compromised after publication. Conversely, a vulnerability record may not apply to the bank’s configuration. Human analysis remains necessary.

8. Continuous Monitoring and Risk Analytics

Third-party assurance must continue after procurement. Monitoring may combine internal telemetry, supplier notifications, external attack-surface intelligence, vulnerability intelligence, certificate and domain changes, service performance, access reviews, audit evidence and incident history.

A useful risk model is a structured scoring aid rather than a claim of objective precision. For example:

Here, R is the risk score, L is an assessed likelihood and I is an assessed impact. The scales and definitions must be documented; multiplication is meaningful only when the scales are designed for that purpose. The result supports prioritisation and does not replace judgement.

A more operational view separates inherent risk from control effectiveness and residual risk. The bank should record assumptions, confidence, evidence age and treatment decisions. A high score based on stale questionnaire data should not be treated as equivalent to a high score supported by current technical evidence.

Relevant indicators include privileged-access anomalies, unapproved cloud exposure, expired certificates, delayed critical patches, unusual supplier data transfers, changes in beneficial ownership, repeated service degradation and failure to meet incident-notification obligations. Analytics can identify patterns, but automated decisions should have explainability, human review and safeguards against false positives.

9. Governance, Ethics and Regulation

Security governance should connect the board, executive risk owners, architecture, procurement, legal, privacy, technology, operations and fraud teams. Responsibility matrices should identify who owns a risk, who performs controls, who reviews evidence and who approves exceptions.

Regulatory expectations commonly emphasise operational resilience, outsourcing governance, protection of customer information, incident reporting, access management, auditability and management accountability. Exact obligations vary by jurisdiction and should be mapped to applicable banking, privacy, payments and critical-infrastructure requirements.

Ethical issues include surveillance of employees and suppliers, automated risk scoring, cross-border data use, discrimination in access decisions and collection of more telemetry than necessary. Security monitoring should be proportionate, transparent to authorised stakeholders, protected from misuse and governed by retention limits.

Artificial intelligence can assist code review, vulnerability triage, anomaly detection and supplier intelligence. However, generated code may contain insecure assumptions, proprietary data may be disclosed to an external model, and automated classifications may be difficult to explain. AI output requires human review, controlled data handling, testing and accountability.

10. Illustrative Case: A Bank’s Open-Banking Platform

Background

A fictional retail bank, Meridian Bank, launched an open-banking platform connecting mobile applications, external budgeting services and payment providers. The platform used cloud-hosted APIs, a commercial identity provider and numerous open-source packages.

Problem

A security review found that one API returned excessive customer fields, authorisation was checked inconsistently across endpoints, and an obsolete API version remained publicly accessible. A critical software library was also present in several services. Procurement records showed that one supplier’s subcontractor had production support access without a recent review.

Analysis

The bank initially treated each issue as a separate technical defect. A broader analysis identified a common governance problem: service ownership was unclear, API inventory was incomplete, supplier evidence was not linked to production assets, and the DevOps pipeline did not generate a reliable SBOM. Fraud analysts also observed unusual beneficiary-enquiry patterns, but the events were not correlated with API identity and device data.

Approach and solution

Meridian classified the payment and account-information APIs as critical services. It then:

• created an authoritative API inventory and retired the obsolete version;
• enforced object- and function-level authorisation centrally and through service tests;
• minimised response fields and introduced explicit data schemas;
• added scoped tokens, replay protection, transaction limits and idempotency controls;
• implemented SBOM generation and dependency monitoring in the delivery pipeline;
• rotated credentials and removed unnecessary supplier access;
• amended supplier contracts to require timely incident notification, subcontractor disclosure and evidence of control operation;
• correlated API, identity, device and transaction events for fraud investigation;
• tested cloud recovery and conducted a joint incident exercise with key suppliers.

Outcome

The bank reduced exposed API functionality, improved vulnerability response and gained traceability from a production service to its software components and suppliers. The exercise also showed that security and fraud analytics were mutually reinforcing: API misuse signals became useful fraud indicators, while fraud cases revealed weaknesses in authorisation and monitoring.

Learning points

1. An API inventory is a security and fraud-control asset.
2. Compliance documents cannot replace technical verification.
3. Supply-chain visibility is necessary for timely vulnerability response.
4. Third-party access should be treated as a privileged identity problem.
5. Security, resilience and fraud controls should be designed together.

11. Challenges and Limitations

Secure delivery can be weakened by legacy systems, incompatible release processes, scarce expertise, alert fatigue and excessive dependence on tools. Automated scanners produce false positives and false negatives. Cloud providers offer sophisticated controls, but misconfiguration remains a major customer risk. Contracts may provide audit rights that are difficult to exercise in practice. Small suppliers may have limited resources, while large providers may resist bespoke requirements.

Risk models also have limitations. Likelihood estimates can be uncertain, impact can be non-linear, and correlated suppliers can invalidate assumptions of independence. A low-frequency, high-impact event may deserve attention even when its numerical score is modest. Senior judgement, scenario analysis and stress testing are therefore essential complements to scoring.

12. Best-Practice Implementation Roadmap

A bank beginning or strengthening this programme can proceed in stages:

1. Identify critical services, information, APIs, cloud accounts, suppliers and software components.
2. Establish executive ownership, risk appetite and minimum security requirements.
3. Embed threat modelling, secure coding and automated testing into delivery workflows.
4. Implement identity, secrets, logging, vulnerability and configuration baselines.
5. Build API governance, including inventory, version control and abuse-case testing.
6. Map cloud responsibilities and continuously assess configuration.
7. Classify suppliers by criticality and access, then apply proportionate due diligence and contracts.
8. Generate SBOM and provenance evidence for important software.
9. Integrate security, operational and fraud telemetry.
10. Test incident response, recovery, supplier failure and exit scenarios.
11. Measure outcomes, review exceptions and improve controls using incidents and near misses.

Chapter Summary

Secure software and digital transformation require security to be integrated across design, development, deployment and operations. DevSecOps combines shared responsibility, automation and continuous feedback, while threat modelling and secure coding reduce defects before production. APIs require strong authentication, server-side authorisation, data minimisation, rate controls, inventory and business-logic protection. Cloud security depends on understanding the shared-responsibility boundary and continuously governing identity, configuration, data, workloads and resilience.

Third-party risk management is a life-cycle discipline covering criticality, access, concentration, evidence, contracts, monitoring and exit. Software supply-chain assurance requires component visibility, provenance, protected build systems and vulnerability response. Continuous monitoring and analytics can connect technical events to fraud and operational risk, but models and automation require human judgement. Effective governance combines technical controls, contractual accountability, regulatory compliance, ethical safeguards and tested resilience.

Key Terms

API: A defined interface through which software systems communicate.

API inventory: An authoritative record of APIs, versions, owners, exposure and dependencies.

Cloud shared responsibility: Allocation of security duties between a cloud provider and its customer.

DevSecOps: Integration of security practices throughout development, delivery and operations.

SBOM: Software bill of materials listing software components and versions.

Software provenance: Evidence describing where and how a software artefact was produced.

Threat modelling: Structured analysis of assets, threats, trust boundaries and controls.

Least privilege: Granting only the access necessary for an authorised task.

Object-level authorisation: Checking whether a requester may access a particular data object.

Idempotency: A property whereby repeating an operation produces the intended single logical result.

Supply-chain risk: Risk arising from software, services, suppliers and dependencies used by an organisation.

Third-party risk: Risk introduced by an external organisation’s access, services or failure.

Residual risk: Risk remaining after controls are applied.

Security gate: A defined release condition based on security evidence and risk tolerance.

Configuration drift: Unplanned divergence from an approved technical configuration.

Vulnerability management: Identification, assessment, prioritisation and treatment of weaknesses.

Operational resilience: Ability to continue and recover important services during disruption.

Provenance: Traceable origin and production history of an artefact or data item.

Review Questions

Short Answer Questions

1. What is the principal difference between DevOps and DevSecOps?
2. Why is server-side authorisation essential for API security?
3. Explain the cloud shared-responsibility model.
4. What information does an SBOM provide, and what does it not prove?
5. Why should supplier risk be monitored after contract signing?

Long Answer Questions

1. Explain how threat modelling, secure coding and runtime monitoring complement one another in a banking application.
2. Analyse the main security risks of APIs used in open banking and propose a layered control architecture.
3. Compare customer responsibilities in Infrastructure as a Service, Platform as a Service and Software as a Service.
4. Design a risk-based third-party assurance process for a critical payment supplier.
5. Discuss the governance, ethical and regulatory challenges of using AI in security and supplier-risk analytics.

Analytical / Application Questions

1. A bank discovers that a cloud-hosted API permits a customer to alter an account identifier in a request. Analyse the likely vulnerability, immediate containment actions, investigation requirements and long-term control improvements.
2. A critical supplier refuses to disclose its subcontractors but provides a favourable security questionnaire. Decide whether the bank should proceed, and justify your decision using criticality, access, evidence, concentration and exit considerations.
3. A vulnerability affects a widely used open-source library, but only one bank service appears to use the affected function. Develop a prioritisation and verification plan that combines SBOM data, application testing, exposure analysis and business impact.

Multiple Choice Questions with Answers

Question 1

Which practice most directly represents DevSecOps?

A. Performing one penetration test immediately before annual audit

B. Embedding security testing and feedback throughout the delivery life cycle

C. Transferring all security responsibility to the cloud provider

D. Allowing developers to approve their own production exceptions without records

Correct Answer: B. Embedding security testing and feedback throughout the delivery life cycle

Question 2

Which API weakness occurs when a user changes an object identifier and views another customer’s record?

A. Broken object-level authorisation

B. Excessive resource consumption

C. Improper cryptographic key rotation

D. Configuration drift

Correct Answer: A. Broken object-level authorisation

Question 3

In a typical Infrastructure as a Service arrangement, which responsibility normally remains with the customer?

A. Physical security of the provider’s data centre

B. Maintenance of the hypervisor

C. Security of the customer’s operating systems and applications

D. Manufacture of the provider’s servers

Correct Answer: C. Security of the customer’s operating systems and applications

Question 4

What is the principal purpose of a software bill of materials?

A. To guarantee that every component is vulnerability-free

B. To list software components and their versions for visibility and response

C. To replace penetration testing

D. To provide a customer’s disaster-recovery time

Correct Answer: B. To list software components and their versions for visibility and response

Question 5

Which control best limits the impact of a stolen API token?

A. Returning more data in each response

B. Using narrow scopes and short token lifetimes

C. Disabling all API logging

D. Relying only on client-side authorisation

Correct Answer: B. Using narrow scopes and short token lifetimes

Question 6

A supplier questionnaire is best understood as:

A. Conclusive proof that the supplier has no security risk

B. A useful evidence source that should be supplemented by validation

C. A replacement for contractual security obligations

D. A method for eliminating concentration risk

Correct Answer: B. A useful evidence source that should be supplemented by validation

Question 7

In the illustrative risk model R = L × I, what do L and I represent?

A. Logging and identity

B. Likelihood and impact

C. Latency and integrity

D. Loss and inventory

Correct Answer: B. Likelihood and impact

Question 8

Which API control is most relevant to preventing repeated processing of the same payment request?

A. Idempotency control

B. Public error messages

C. Long-lived unrestricted tokens

D. Disabling schema validation

Correct Answer: A. Idempotency control

Question 9

Why is cloud configuration monitoring important?

A. Cloud platforms cannot provide any security controls

B. Customer settings can create exposure even when the provider secures the underlying platform

C. It eliminates the need for identity governance

D. It makes supplier contracts unnecessary

Correct Answer: B. Customer settings can create exposure even when the provider secures the underlying platform

Question 10

Which feature is essential to a responsible security exception?

A. No named owner or expiry date

B. Permanent acceptance without rationale

C. Documented rationale, accountable owner, compensating controls and review date

D. Automatic approval for every critical vulnerability

Correct Answer: C. Documented rationale, accountable owner, compensating controls and review date