Cloud Application Security · Topic 4 of 6
Using Verified Secure Software
CCSP verified software: securing REST and SOAP APIs, supply-chain management for integrity, authenticity and licensing, third-party and open source code.
- 5 min
- APIs need authentication, per object authorization, validation, rate limits, TLS, inventory and logging.
- Integrity is unaltered; authenticity is from the claimed source; signatures prove both.
- An SBOM lists components and versions for fast vulnerability response.
What it is
Modern cloud applications are assembled more than written. They call third-party APIs, run on open source libraries, pull container base images and include commercial components. Using verified secure software means confirming each of these is genuine, unaltered, properly licensed and maintained before it reaches production.
APIs are both something you build and something you consume, so securing them is part of the same discipline.
How it works
Securing APIs
| Control | Purpose |
|---|---|
| Authentication | OAuth 2.0 access tokens, mutual TLS or signed requests; avoid static API keys where possible |
| Authorization | Check permissions per function and per object on every call |
| Input validation | Validate against a schema; reject unexpected fields |
| Rate limiting and quotas | Prevent abuse, scraping and resource exhaustion |
| Transport security | TLS for every call |
| API gateway | Central point for authentication, throttling, logging and policy |
| Inventory | Know every API version and endpoint, and retire old ones |
| Logging | Record caller, action, object and result |
REST APIs use HTTP methods and usually JSON, secured with OAuth 2.0 and TLS. SOAP APIs use XML messages and can use WS-Security for message level signing and encryption. XML based APIs need protection against XML attacks such as external entity injection, which XML firewalls or gateways can filter.
Supply-chain management
| Area | What to check |
|---|---|
| Vendor assessment | Security practices, certifications, vulnerability disclosure and patch history, financial stability |
| Integrity | The component has not been altered: checksums and hashes match published values |
| Authenticity | It comes from the claimed source: digital signatures verified against the publisher's key |
| Licensing | Licence terms permit your use; copyleft licences may impose obligations on your code |
A software bill of materials (SBOM) lists every component and version in a product, so that when a new vulnerability is announced you can tell quickly whether you are affected. Standard formats include SPDX and CycloneDX.
Supply chain attacks include compromised build systems that insert malicious code into signed updates, typosquatted packages with names similar to popular ones, and maintainers' accounts taken over to publish malicious versions.
Third-party software management
- Keep an inventory of all third-party software, including SaaS used by the application.
- Contract for security: vulnerability notification, patch timelines and support periods.
- Track end of life dates; unsupported software no longer gets fixes.
- Patch third-party components through the same change process as your own code.
- Limit the permissions granted to third-party integrations to what they need.
Validated open-source software
Open source is not less secure by nature, but its quality varies. Validate before use:
- Project health: active maintainers, recent releases, responsive security process.
- Known vulnerabilities: run SCA and check vulnerability databases.
- Integrity and provenance: download from official sources, verify signatures and hashes, and prefer builds with provenance attestations.
- Internal repository: developers pull approved packages from an internal mirror rather than directly from public registries.
- Ongoing monitoring: a component that was clean on adoption may have a vulnerability announced later.
Example: verifying integrity
sha256sum app-library-2.4.1.tar.gz
# Compare the printed digest with the value published by the project
# over a separate trusted channel; any difference means do not use itA hash proves integrity only if the published value itself is trustworthy, which is why signatures from a known key are stronger.
A worked example
A healthcare SaaS company learns that a widely used logging library has a critical remote code execution flaw. It has hundreds of services and does not know which use the library.
Its new process fixes this: every build produces an SBOM stored centrally, so the next time a flaw is announced a query lists affected services in minutes. Developers now pull packages only from an internal repository that holds verified, signed versions, and SCA blocks builds with critical known vulnerabilities.
How the exam asks about this
- "Which artefact lets an organization quickly determine whether a newly disclosed library vulnerability affects its products?" A software bill of materials.
- "How can a team confirm that a downloaded component came from the claimed publisher?" Verify its digital signature with the publisher's public key.
- "Which API risk is reduced by rate limiting?" Resource exhaustion and abuse such as scraping or brute force.
What to remember for the exam
- APIs need authentication, per object authorization, validation, rate limits, TLS, inventory and logging.
- Integrity is unaltered; authenticity is from the claimed source; signatures prove both.
- An SBOM lists components and versions for fast vulnerability response.
- Check licences: copyleft obligations can affect proprietary products.
- Validate open source for health, vulnerabilities and provenance, then monitor it.
A valid signature only proves who signed the code. If the publisher's build system was compromised, malicious code can arrive correctly signed, so monitor behaviour and advisories too.
Common mistakes
Trusting popularity. Widely used packages are attractive targets and have been compromised.
Checking components only on adoption. New vulnerabilities appear in old versions; monitoring must continue.
Ignoring licences. Legal exposure from licence violations is a supply chain risk too.
Check yourself
What is the difference between integrity and authenticity for a software component?
Integrity means the component has not been altered, while authenticity means it really came from the claimed publisher.
Why use an internal package repository?
It ensures developers use only verified, approved versions of components instead of pulling directly from public registries.
What protections can secure SOAP messages at message level?
WS-Security, which provides signing and encryption of XML messages.
Topic 4 of 6 in Cloud Application Security
Test yourself on Cloud Application Security
The full ISC2 CCSP question bank has 900 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by ISC2. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.