10.2 Verified Secure Software (Domain 4.5)
Key Takeaways
- Domain 4.5 is about using verified secure software: securing APIs, supply-chain management (vendor assessment, integrity, authenticity, licensing), third-party software management, and validated open-source software.
- API security requires authentication, authorization, schema validation, rate limiting, inventory of versions, encryption in transit, and least-privilege scopes—not only a public OpenAPI doc.
- Supply-chain security covers vendor risk, artifact integrity and authenticity (signatures, hashes, provenance), and license compliance across commercial and open-source components.
- Third-party software needs inventory, patch/version policy, contractual security requirements, and monitoring—shadow IT libraries and unmanaged SaaS APIs undermine assurance.
- Validated open-source means deliberate selection, pin/verify, SCA/SBOM, maintained projects, and rebuild hygiene—not blind copy-paste from the internet into production images.
Use Verified Secure Software
Domain 4.5 focuses on using verified secure software—confidence that what you build on, with, and expose is trustworthy. The August 2026 outline lists: securing Application Programming Interfaces (APIs); supply-chain management (vendor assessment, integrity, authenticity, licensing); third-party software management; and validated open-source software. Domain 4.4 tested your software; 4.5 emphasizes the ecosystem of interfaces and components that compose modern cloud apps.
Why “Verified” Matters
Cloud applications are assembly projects: managed services, open-source libraries, commercial SDKs, partner APIs, container base images, CI plugins, and infrastructure modules. Attackers increasingly target the supply chain and API layer because one compromised dependency or one unauthenticated API can bypass carefully written business code.
| Risk theme | Example |
|---|---|
| Malicious or compromised package | Typosquatting or dependency confusion in a build |
| Unsigned or altered artifact | Tampered container in a registry |
| Unassessed vendor SaaS | Data flows to a tool with weak controls |
| Insecure API exposure | BOLA on a partner integration endpoint |
| License surprise | Copyleft obligations in a proprietary product distribution |
| Abandoned open source | Unpatched critical CVE in a dead project |
Exam framing: Prefer answers that establish provenance, least privilege, continuous inventory, and contractual/technical verification—not “we trust popular projects by default.”
Securing Application Programming Interfaces (APIs)
APIs are the primary attack surface of cloud-native systems. Securing them is mandatory for “verified secure software” because even perfect library hygiene fails if the interface is open.
Core API Security Controls
| Control | Purpose |
|---|---|
| Authentication | Prove caller identity (OAuth2/OIDC tokens, mTLS, API keys only with tight constraints) |
| Authorization | Enforce object- and function-level access (prevent BOLA and broken function authZ) |
| Input validation / schema enforcement | Reject unexpected fields and types; stop mass assignment |
| Output control | Minimize data returned; no stack traces to clients |
| Rate limiting and quotas | Protect availability and cloud cost; blunt credential stuffing |
| Encryption in transit | TLS everywhere; modern cipher suites |
| Inventory and versioning | Know every endpoint; retire shadow and deprecated versions |
| Logging and monitoring | Auth failures, privilege use, anomalous volumes |
| Threat protection | API gateway policies, WAF/API security engines where appropriate |
| Least-privilege scopes | Tokens grant minimum claims and audiences |
| Webhook security | Signatures, timestamps, replay protection |
| SSR and egress controls | Server-side fetches only to allow-listed destinations |
API Design Security Patterns
- Zero trust between services: service identity (mesh mTLS or platform identity) rather than flat internal network trust.
- Consistent authZ middleware: never re-implement tenant checks differently per handler.
- Explicit allow-lists for CORS and redirects.
- Idempotency and replay defenses for payment-like operations.
- Pagination and bulk controls to prevent full-store extraction.
- Contract-first design with security requirements in the contract review.
API Gateways as Control Points
Central gateways (detail also appears in 4.6) provide authentication offload, throttling, schema validation, IP allow-lists, and unified logging. Gateways do not replace correct object-level authorization in the service—BOLA often survives a gateway that only checks “valid JWT.”
Common API Failures on Exams
| Failure | Why it hurts |
|---|---|
| API keys in mobile/SPA clients as sole auth | Extractable; no user binding |
| Trusting client-supplied tenant IDs | Cross-tenant data access |
| Verbose errors and open OpenAPI on production without auth | Recon made easy |
| Forgotten v1 still live after v2 launch | Unpatched legacy surface |
| Unlimited expensive queries | Denial of wallet / DoS |
Worked example: A B2B SaaS exposes /api/v2/documents/{id}. JWT auth is required (good), but the service loads documents by ID without checking org_id from the token (bad). Verified secure software practice: centralized authZ, automated abuse tests, and gateway only as defense-in-depth—not the sole control.
Supply-Chain Management
Software supply-chain management ensures components entering your system are assessed, authentic, integral, and license-acceptable. The outline highlights vendor assessment, integrity, authenticity, and licensing.
Vendor Assessment
Before adopting a commercial library, SaaS dependency, managed AI API, or critical open-source stewarded product, assess:
| Assessment area | Questions |
|---|---|
| Security program | SDLC, vulnerability disclosure, patch cadence |
| Assurance reports | SOC 2, ISO 27001, pen test summaries (scoped correctly) |
| Data handling | What data leaves your tenant; subprocessors; residency |
| Identity integration | SSO/MFA support; SCIM; least-privilege admin models |
| Business viability | Longevity, support, escrow if critical |
| Incident history | Breach transparency and response quality |
| Contract terms | Security schedule, audit rights, breach notification, liability |
Vendor assessment is risk-based: a color-picker npm package and a payments processor do not get the same depth, but both enter an inventory.
Integrity
Integrity means the artifact you run is the artifact you intended—unmodified.
| Practice | Mechanism |
|---|---|
| Cryptographic hashes | Pin expected digests for packages and images |
| Lockfiles | Deterministic dependency resolution |
| Immutable references | Deploy by digest, not mutable latest |
| Reproducible builds | Same inputs → same outputs where feasible |
| Controlled build environment | Hardened runners; limited egress; no untrusted plugins |
| Runtime drift detection | Alert if running image ≠ approved digest |
Authenticity
Authenticity means the artifact truly comes from the claimed publisher.
| Practice | Mechanism |
|---|---|
| Code signing / image signing | Verify signatures before deploy |
| Provenance attestations | Link artifact to source repo, commit, builder identity |
| Trusted registries | Private mirrors; block unknown public pulls in prod pipelines |
| Publisher verification | Namespace protection; verified org accounts |
| Commit signing | Optional strengthening of source authenticity |
Integrity without authenticity can still accept a correctly hashed malicious package if you hashed the wrong publisher’s build. Authenticity without integrity can accept a signed-then-tampered path if verification is skipped at deploy.
Licensing
Licensing is a legal and compliance dimension of supply-chain risk:
- Track licenses via SCA tools and legal review for reciprocal/copyleft obligations.
- Maintain an allow/deny/review license policy aligned to product distribution model (SaaS internal use vs redistributed software).
- Record attribution requirements for notices files.
- Treat license violations as release blockers similar to critical CVEs when policy says so.
| Supply-chain pillar | Failure mode |
|---|---|
| Vendor assessment | Unvetted SaaS becomes a data exfil path |
| Integrity | Pipeline ships altered binary |
| Authenticity | Dependency confusion / typosquat |
| Licensing | Forced disclosure or distribution rights conflict |
End-to-End Supply-Chain Flow (Exam Mental Model)
- Select — approved sources and vendor assessment.
- Acquire — from trusted registries/mirrors.
- Verify — signature + hash + SCA.
- Build — locked dependencies; SBOM emitted.
- Sign — outbound artifact authenticity for deployers.
- Deploy — policy admits only verified digests.
- Operate — continuous CVE monitoring; revoke/rotate on compromise.
- Retire — remove unused components to shrink surface.
Third-Party Software Management
Third-party software management is the operational program for commercial packages, SDKs, agents, plugins, and embedded components you did not write.
Lifecycle Controls
| Stage | Controls |
|---|---|
| Request / intake | Business justification; security review; data classification impact |
| Approval | Architecture and risk acceptance; license OK |
| Onboarding | Add to CMDB/SBOM inventory; owners assigned |
| Configuration | Secure defaults; disable unused modules; least privilege connectors |
| Maintenance | Patch SLAs; version skew limits; vendor advisory monitoring |
| Integration security | API keys in secret stores; scoped credentials; network egress rules |
| Review | Periodic access and necessity reviews |
| Offboarding | Revoke credentials; remove agents; confirm data deletion |
Categories of Third-Party Risk in Cloud Apps
- Runtime agents (APM, EDR, logging)—high privilege; validate publisher and updates.
- CI/CD plugins—can steal secrets from pipelines; pin versions and limit permissions.
- Mobile/desktop SDKs—may exfiltrate telemetry; review privacy and update mechanism.
- Embedded analytics or chat widgets—supply third-party JavaScript; CSP and SRI help.
- Managed SaaS APIs—shared responsibility for your configuration and OAuth grants.
Policy Essentials
- No anonymous third-party in production without inventory entry.
- Prefer platform-native services when they reduce undifferentiated risk—but still configure them securely.
- Contractual security requirements for material vendors (encryption, breach notice, support for SSO/MFA, audit evidence).
- Technical enforcement where possible: allow-listed registries, admission controllers, package proxies that block unknown deps.
- Incident playbooks that include vendor compromise scenarios (revoke tokens, rotate keys, rebuild images).
Relationship to Configuration Management
Third-party components are configuration items: versioned, authorized, and promotable. “Someone’s laptop has a license key in a text file” is not third-party management.
Validated Open-Source Software
Open source is essential to cloud ecosystems; validated open source is intentional, verified, and maintained—not unreviewed copy-paste.
Validation Practices
| Practice | Detail |
|---|---|
| Provenance | Prefer well-known projects with active maintainers and transparent governance |
| Pinning | Exact versions/digests; controlled upgrades |
| SCA + SBOM | Continuous vulnerability and license visibility |
| Review of high-risk deps | Crypto, auth, parsers, deserialization libraries get deeper review |
| Minimalism | Fewer dependencies reduce exposure |
| Fork policy | Know when you fork and who patches |
| Build from source when required | For high assurance, rebuild rather than trust prebuilt binaries alone |
| Container base images | Use minimal distroless/hardened bases from trusted publishers; rebuild often |
| Contribution hygiene | Internal patches upstreamed or tracked as carry-forward risk |
Open-Source Threat Patterns
| Pattern | Mitigation |
|---|---|
| Typosquatting | Exact names; private proxies; caution on install scripts |
| Dependency confusion | Namespace strategy; prefer private scope; configure registries correctly |
| Protestware / sabotage | Pin versions; review changelogs on upgrade; runtime allow-lists |
| Abandoned projects | Health metrics; replace before critical CVE with no patch |
| Malicious maintainers / account takeover | Signature verification; delay adoption of brand-new major versions in critical paths |
| Build-system compromise | Hermetic builds; verify upstream release processes for critical deps |
“Validated” vs “Popular”
Popularity is a weak signal alone. Validation combines technical verification (hash, signature, SCA), operational health (maintenance, community), and fit-for-purpose security review. A popular package with a dangerous default API still needs secure usage guidance in your coding standards.
Integrating 4.5 with 4.4 and 4.3
- SCA and pipeline gates (4.4) enforce open-source validation continuously.
- CM and versioning (4.3) make third-party versions auditable.
- Secure coding (4.3) governs how you call third-party and API clients (timeouts, cert validation, least data).
End-to-End Scenario
A team builds a multi-tenant document API on containers. They secure the API with OIDC, strict authZ, schema validation, and rate limits. Supply chain: only private registry base images; cosign verification; SCA fail on critical CVEs; license allow-list. Third-party: PDF rendering engine under vendor assessment with pinned version and network egress deny-by-default. Open source: lockfile, SBOM per release, quarterly dependency health review. That is Domain 4.5 in production form.
Putting Domain 4.5 Together for the Exam
- If the stem is about interfaces, lead with API authN/authZ, inventory, and abuse-resistant design.
- If the stem is about components entering the build, lead with supply-chain integrity/authenticity/SCA.
- If the stem is about commercial tools/agents, lead with third-party lifecycle management.
- If the stem is about npm/PyPI/crates/images from the internet, lead with validated open-source practices—not blind trust.
- Combine contractual vendor assessment with technical verification; neither alone is complete for high risk.
Common Traps
- Treating API gateway presence as complete API security.
- Equating “open source is free” with “open source is safe without validation.”
- Using mutable tags and unverified public images in production.
- Ignoring license risk as “only a legal problem” outside CCSP scope—it is on the outline under supply chain.
- No inventory of third-party CI plugins that hold cloud deploy credentials.
- Vendor assessment once at purchase with no ongoing advisory monitoring.
Which set best reflects supply-chain management elements called out for Domain 4.5?
A microservice validates JWTs at the API gateway but loads any document ID the caller requests without checking tenant membership. What is the primary API security failure?
Before promoting a container to production, the pipeline verifies a publisher signature and matches the image digest to an approved hash, then runs SCA. Which supply-chain properties are primarily being enforced?
What best describes validated open-source software use in a CCSP-aligned cloud app program?