CCSP Verified Secure Software: API Security, Software Supply Chain and Open Source

Verified secure software is software whose security you have checked rather than assumed: the APIs it exposes are authenticated, authorized and validated, and every component you did not write yourself (a vendor product, an open-source library, a marketplace image) comes from an assessed source, arrives intact from its real publisher, carries licence terms you can meet, and stays supported for as long as you run it. Sub-domain 4.5 groups four official skills around that idea:

• Securing APIs: the interfaces every cloud application is built from and exposed through.
• Supply-chain management: vendor assessment, integrity, authenticity and licensing of what you acquire.
• Third-party software management: patching, end of support and continuity of software someone else builds.
• Validated open-source software: choosing, vetting and safely resolving open-source dependencies.

The thread through all four is that trust must be earned by evidence and enforced by a control. A popular library, a signed installer or an API behind a login page is not verified until you know what the evidence actually proves. Most questions on this topic turn on that gap: a control that is real and useful, but proves something other than what the scenario needs.

Scope guards: the OWASP Top 10 lists as awareness material belong to 4.1, SAST/DAST/SCA as testing methods to 4.4, API gateways, WAFs and XML firewalls as architecture components to 4.6, and federation and identity providers to 4.7. Evaluating a cloud provider's own certifications (SOC 2, Common Criteria) is 1.5. This lesson uses them only where they meet verified software.

API callers are authenticated with OAuth 2.0 access tokens when a user delegates access to an app, with API keys when only the calling application needs identifying, and with mutual TLS when two services must each prove their identity. The right choice depends on whether a user is involved and whether both sides must authenticate; the three are not interchangeable:

Two distinctions are worth holding firmly. First, delegation versus identity: when the requirement is "only what this user permitted this app to do", the answer is a scoped OAuth 2.0 token, because an API key or a shared service account collapses every user into one identity. Second, one-way versus mutual authentication: ordinary HTTPS authenticates only the server. When both ends of a connection must prove their identity, mutual TLS is the fit; network filtering or secret rotation can be useful controls, but neither is mutual authentication.

Keep credentials out of URLs

A credential in a URL query string is protected on the wire by HTTPS but is then written in clear to the access logs of every server and intermediary that handles the request, to browser history and to monitoring tools, and can leak in referrer headers. The fix has two parts: carry the credential in a request header (for example Authorization) so it stops being logged, and rotate the key, because every logged copy must be treated as compromised. Anything short of rotation leaves the copies already written still valid.

Authorization in an API means the server checks, on every request, that this caller may perform this action on this specific object. Authentication only establishes who is calling; the most common serious API flaw is an authenticated caller changing an identifier (an order number, an account ID) and receiving someone else's data. OWASP calls this broken object level authorization.

The root-cause fix is a server-side entitlement check per object: look up the requested record and confirm it belongs to, or is shared with, the caller before returning it. Anything that only makes requests harder or slower to make is not authorization; an identifier nobody can guess still returns the record to anyone who learns it, because the server never asked whether that caller was entitled to it.

Take authorization inputs from trusted sources

In a multi-tenant SaaS API the same principle applies to the tenant. Whenever an input that decides access (a tenant, organisation or account owner) is read from something the caller can edit, such as a path segment, a custom header or a body field, the caller controls the authorization decision even though their identity was verified. The fix is to derive the tenant from the validated, signed token (or from server-side records) and check every returned record against it. The rule generalises: authorization decisions use values the server trusts (validated token claims, server-side records), never values the client can edit.

Validating API input: server-side schemas and mass assignment

API input validation means the server checks every request against an allowlisted schema (types, ranges, formats, required fields and the set of fields permitted) before acting on it. Two failure patterns recur.

Trusting client-side checks. Validation in a mobile app or web page improves usability but provides no security, because anyone can call the API directly with a script. If a booking form refuses a date in the past but the endpoint does not, a script sending that date straight to the API gets it accepted. Hardening the official client protects that client, not the API, which still answers every other caller. Validation must live on the server.

Mass assignment. When an endpoint binds the whole request body onto an internal object, a caller can add properties they should never set, such as "emailVerified": true or a credit limit. The value is well formed and legal for the stored model, so checks of type and format alone accept it; the problem is who may set the field, not what it contains. The fix is a per-endpoint allowlist of the properties a client may set, or binding to a dedicated input object, rejecting everything else. A denylist of sensitive field names fails the first time someone adds a new one; an allowlist fails safe.

Rate limiting caps how many requests a client may make in a time window, and quotas cap usage over a longer period; a client that exceeds its limit receives HTTP 429 Too Many Requests (often with a Retry-After header) while other clients continue normally. Its purpose is to stop resource exhaustion and abuse, whether from an attacker or a runaway client integration, without cutting off legitimate users.

That last condition is what separates rate limiting from look-alikes: adding capacity absorbs excess load at growing cost but never stops one caller starving the rest, and knowing who a caller is says nothing about how much they may send.

What the limit is keyed on matters

A limit is only as fair as the identity it counts. Source IP address is a poor proxy for a client, in both directions: one address can stand for many callers (everyone on a campus network or behind a mobile carrier's gateway shares it), and one caller can spread its traffic across many addresses. When callers present credentials, apply limits per authenticated client (API key, OAuth client or token subject). Each legitimate client then gets its own budget wherever it connects from, and an abusive client is held to one budget however many addresses it uses. Tuning IP-based thresholds cannot fix either problem, because the thing being counted is wrong.

API inventory, discovery and version lifecycle

You cannot secure an API you do not know exists, so API security starts with an inventory of every exposed API and every live version, each with an owner, and a lifecycle that retires old versions. Two situations show why.

Deprecated versions. If a security fix ships only in the newest version while an older one stays reachable for a few remaining integrations, attackers simply call the older one. The root-cause practice is lifecycle management: track every exposed version, set deprecation dates, migrate remaining clients, and either back-port the fix or switch the old version off. Shielding an old version reduces some exposure, but the vulnerable code keeps serving requests until it is fixed or switched off.

Shadow APIs. APIs that exist outside the inventory, such as an endpoint stood up for a short project, one left behind by a migration, or one exposed by a component nobody reviewed, bypass every central control and appear in no documentation. The first step is discovery: use gateway, load balancer and flow logs, plus the cloud account's own resource configuration, to list every reachable API. Only then can each be assigned an owner, brought behind the gateway, tested, patched or retired. Every control applied only to the known list leaves the unknown APIs as they are.

Transport-level security protects the connection; message-level security protects the message itself. The choice depends on whether anything sits between the sender and the final recipient.

When a browser or client talks straight to the API with no intermediaries, there is one hop, and TLS on each HTTPS connection is the standard protection: confidentiality, integrity and server authentication. Message-level mechanisms add nothing there.

When a message crosses intermediaries that must not read or change it, TLS on each hop is not enough, because each intermediary decrypts and re-encrypts. For SOAP, the OASIS WS-Security standard applies XML Encryption and XML Signature to selected elements, so a sensitive field such as a patient identifier can stay encrypted all the way to the system that needs it while brokers still read the routing headers they depend on. Protecting only the elements that need it is the point.

Confidentiality is not origin

Encryption and signatures answer different questions. Encryption to the recipient's public key keeps a payload confidential, but public keys are public, so encryption alone proves nothing about the sender. To let a receiver confirm that each message came from the real sender and was not altered by any intermediary (for example events forwarded by an integration platform or message broker), the sender signs the payload, with a digital signature or a keyed hash using a secret the relay does not hold, and the receiver verifies it. Any check made at the connection level authenticates only the hop it sits on.

Supplier assessment is the evaluation of a vendor's security before you depend on it, and its value comes from acting on the results while you still can: rejecting an unsuitable vendor, or writing required controls, audit rights, breach notification and exit terms into the contract. That makes timing a security decision in its own right.

• Assess before you share sensitive data, including in pilots or proofs of concept. A trial loaded with production records already exposes them to an unassessed party.
• Assess before you sign. After signature, the company has lost its bargaining position; reviews scheduled after signature are useful ongoing controls but cannot change terms already agreed.
• Reassess periodically and on change (new data types, a breach at the supplier, ownership change).

Tier suppliers by risk

No team can assess hundreds of suppliers in depth. The first step is to tier suppliers by what they touch (sensitive data, production or network access) and how critical their product or service is. High-tier suppliers get in-depth assessment, evidence review and strong contract terms; low-tier suppliers get lightweight checks. Any approach that treats every supplier alike, or orders the work by something other than risk, spends the same effort on a stationery vendor as on the processor holding customer data.

Evidence used in an assessment typically includes security questionnaires (the CSA's CAIQ maps to the Cloud Controls Matrix), independent reports such as SOC 2 Type II or ISO/IEC 27001 certification, penetration-test summaries, secure-development attestations, SBOMs, and the right to audit. Each covers a different question: a SOC 2 report describes a control environment, not the components in a product.

The supplier-relationship standard

ISO/IEC 27036 (Cybersecurity — Supplier relationships) is the multi-part standard for managing information security in supplier relationships: Part 1 an overview and concepts, Part 2 requirements, Part 3 guidelines for hardware, software and services supply-chain security (the 2023 edition; earlier editions called it ICT supply-chain security), and Part 4 guidelines for the security of cloud services. Keep its neighbours apart: ISO/IEC 27034 is application security, 27017 is cloud-specific security controls, and 27018 is protection of PII in public clouds acting as processors. For U.S. federal practice, NIST SP 800-161 covers cybersecurity supply-chain risk management.

Integrity means the software has not changed; authenticity means it came from who it claims to come from; provenance means you know how and from what it was built. Each verification technique proves a different subset:

A hash is only as trustworthy as the place its reference value comes from. When the reference value is published in the same place as the file, whoever can alter one can alter the other, and the check passes. A digital signature is made with a private key the publisher holds elsewhere, so a substituted file fails verification against the publisher's known certificate, wherever it was downloaded from.

When the build itself is compromised

Code signing proves a release came out of the supplier's signing process and was not altered afterwards. If attackers insert code during the automated build, the legitimate key signs the malicious output and every customer check passes. Strengthening the signature or its key does not help, because the signature was never the weak point. The control that addresses this risk is build integrity: isolated, hardened, ideally reproducible build environments that generate tamper-evident provenance describing the source, build steps and inputs of each release. Frameworks such as OpenSSF's SLSA define levels for exactly this.

SBOM and VEX: knowing what is inside the software

A software bill of materials (SBOM) is a machine-readable inventory of the components in a software product: each component's name, version and supplier, and how components relate, including transitive dependencies. The two common formats are SPDX (published as ISO/IEC 5962) and CycloneDX (an OWASP standard).

Its main security use is vulnerability response. When a critical flaw is disclosed in a widely used library, an organisation that generates an SBOM at build time and stores one for every release can find every affected application, including through transitive dependencies, with a search. Evidence about how software behaves or how a supplier operates cannot answer that question quickly; only an inventory of what each release contains can.

VEX: which listed vulnerabilities actually matter

Matching an SBOM against vulnerability feeds flags every CVE in every listed component, including ones whose vulnerable code the product never calls, which buries customers in false positives. A VEX (Vulnerability Exploitability eXchange) document lets the supplier state, per vulnerability, whether the product is affected, typically as not affected (with a justification), affected, fixed or under investigation. VEX can be expressed in CSAF, CycloneDX or OpenVEX. It travels alongside the SBOM; it does not replace it. The SBOM stays a complete inventory; VEX adds the exploitability judgement on top of it.

Licence compliance is part of supply-chain management because every component you use brings obligations, and breaching them is a legal and financial risk to the business. For open source, the key split is permissive versus copyleft:

The cloud-specific point is the network-use gap. Running modified GPL code as a hosted service is not distribution, so a SaaS provider that never ships the software owes no source under the GPL. The AGPL v3 closes that gap: its section 13 requires offering the corresponding source of a modified version to every user interacting with it remotely. A company that ships software customers install, such as a desktop client or an on-premises appliance, is distributing, so a statically linked GPL library pulls the whole product under the GPL.

Commercial licences and cloud deployment rights

Commercial licences are often bound to owned hardware, sockets or cores, or a named environment. Before moving licensed software onto a provider's multi-tenant infrastructure, confirm first that the terms permit it, through licence mobility, a bring-your-own-licence programme or a new licence. Security evidence about the product, however strong, says nothing about whether the move is licensed.

Third-party software management keeps software that others build safe for as long as you run it. Three questions come up: who patches it, what happens when support ends, and what happens if the vendor disappears.

Who patches depends on the service model. In SaaS, the provider patches the application. In PaaS, the provider patches the platform; the customer patches its own code and the libraries it deploys. In IaaS, the provider secures the physical hosts and virtualization layer, and everything inside the instance is the customer's, including a third-party appliance image deployed from the provider's marketplace. Where the image came from does not change whose instance it is: unless a managed service is contracted, the customer applies the vendor's patches.

End of support. After a product's end-of-support date, newly found vulnerabilities go unpatched. When a migration cannot finish before that date, the strongest treatment for an important workload pairs a way to keep receiving security fixes through the gap (such as the vendor's paid extended support) with a dated migration plan: the first closes the exposure, the second ends it for good. Compensating controls only partly cover flaws that will never be fixed.

Vendor failure. Source code escrow places the source (and ideally build instructions) with an independent escrow agent, released to the licensee on defined events such as the vendor's insolvency or end of support. It protects continuity when the vendor can no longer fix defects. Contract promises that rely on the vendor continuing to exist and perform offer nothing once it does not.

Validated open-source software is open source that has been vetted before use and is obtained through a controlled path, rather than pulled straight from a public registry by whoever needs it. Validation has three parts.

Choose healthy projects. When two libraries offer the same features, the better supply-chain bet is the one that can respond to vulnerabilities: active and multiple maintainers, regular releases, and a published vulnerability-handling (security) policy. Popularity is not maintenance: a widely used library can still rest on one maintainer who has stopped responding. An abandoned dependency, for example a repository its maintainer has archived, is a frozen risk: archiving makes the repository read-only and leaves existing releases installable, so the code you run is unchanged, but the next vulnerability found in it will get no upstream fix. Plan to fork and patch it, add compensating controls or migrate.

Vet and enforce through a curated repository. Route builds through an internal repository or registry proxy that serves only approved packages and versions, with a request process for new ones. Builds can then resolve only vetted components, and developers stay productive. The value is in combining vetting with enforcement at the point of resolution; either alone leaves a gap.

Test in context. A component that is safe in one configuration may not be in yours; review its permissions, defaults and how your code calls it, and keep it in the SBOM so it is covered by vulnerability response.

Dependency attacks: typosquatting, dependency confusion and hijacked releases

Package managers resolve names and version ranges automatically, and three attacks exploit that resolution. Each is stopped by a different control, so match the control to the mechanism.

The key distinction is between getting the same bytes and getting the right package. Lockfile integrity hashes guarantee reproducibility, so every build receives the bytes recorded the first time, but they do not judge whether those bytes were what you meant to install. Name allowlists and scope binding decide which package is allowed; pinning decides when a new version may enter. CVE-based vulnerability scanning helps with none of the three, since freshly published malicious code has no CVE yet. Mature pipelines use all three controls.