SAST, DAST, IAST, SCA: Testing the Cloud Application Pipeline, and the Supply Chain Attacks That Slip Past It
Chris Rees
25+ years in IT · Pluralsight author, 4.6/5 across 2,000+ ratings
A modern cloud application is a thin layer of code the team wrote on top of hundreds of packages they did not, built by a pipeline, deployed by another pipeline, and run on a platform someone else operates. CCSP Domain 4 is about securing all of that, and its questions divide into two families: where in the pipeline each kind of test belongs, and what to do about the code that arrived from outside. The second family is where the exam has been putting its weight, because it is where the breaches have been.
Four kinds of testing, four places in the pipeline
The testing vocabulary looks like alphabet soup until you place each tool at the stage where it can see what it needs.
Static application security testing reads source code without running it, at commit, and finds patterns: an unparameterized query, a hard-coded credential, an unsafe deserialization call. It is fast and it produces false positives, because it cannot know whether a path is reachable. Dynamic application security testing attacks the running application from outside, with no knowledge of the code, and finds what is actually exploitable through the interfaces an attacker would use. Interactive application security testing instruments the running application from inside, so it sees both the request and the code path it took, which cuts the false positives of static analysis and the blind spots of dynamic. Software composition analysis inventories the third-party components and checks them against vulnerability databases and license terms; it is the only one of the four that looks at code the team did not write.
The exam's questions are about fit. A flaw in a library the team never modified is found by SCA, not by SAST. A flaw that only appears when two components interact under load is found by DAST or IAST, not by reading code. A credential committed to the repository is found by secrets scanning at commit, and the correct remediation includes rotating it, because the history keeps it forever.
Black box, white box, and abuse cases
The same distinction that governs penetration testing governs application testing. Black box testing knows nothing about the internals and simulates an outside attacker; it is what DAST does. White box testing has the source and the design; it is what SAST and code review do. The exam's point is that they find different things and a program needs both.
Abuse case testing is the practice the objective names specifically. Functional tests confirm the application does what a legitimate user wants. Abuse cases confirm it refuses what an attacker wants: a negative quantity in a shopping cart, a file upload renamed to look like an image, a request for another user's record by changing an identifier. They come out of the threat model, and a scenario describing an application that passed every test and was still exploited through its business logic is describing a test suite with no abuse cases. Non-functional testing covers the properties that are not features: performance under load, behavior when a dependency is unavailable, and whether logging captures what an investigation would need.
The supply chain: the code you did not write
Dependency confusion exploits how package managers resolve names. If your build asks for a package by name and can reach both a private registry and a public one, the tool may take the public copy, especially if its version number is higher. The attacker only has to guess the internal name and publish. The control is to make the resolver incapable of choosing: scoped names, a private registry that proxies and pins the public one, and exact versions.
Typosquatting relies on a human mistake, and it is caught by refusing to install anything not on an approved list, backed by review when a new dependency is added.
The two red boxes are the hard cases, because the package or the pipeline was trustworthy until it was not. A compromised maintainer ships a malicious version of a real package; the controls are pinning exact versions rather than ranges, verifying signatures, waiting before adopting new releases, and keeping a record of exactly what was pulled. A compromised build is the worst case, because the malicious code is signed with your own key and every downstream customer trusts it; the controls are ephemeral, hardened build runners with least privilege, provenance attestations that describe how each artifact was produced, and treating the pipeline as production infrastructure with its own monitoring.
Cloud-specific gates: infrastructure and images
Two gates in the pipeline diagram have no on-premises ancestor, and the exam expects you to know why they exist. Infrastructure-as-code scanning checks the templates that create cloud resources before they run: a storage bucket declared public, a security group open to the world, a database without encryption, a role with wildcard permissions. Because the template is the source of truth, a misconfiguration caught there never reaches an account, and one caught later has to be traced back to the template or it will simply be redeployed. Container image scanning checks the base image and its packages for known vulnerabilities and secrets before the image is admitted to a registry, and an admission policy that refuses unscanned or failing images is the enforcement. Both gates exist because in the cloud the environment is itself code, and code can be tested before it becomes infrastructure. A scenario about a misconfigured resource that keeps reappearing after being fixed in the console is describing a template that was never corrected.
The SBOM, and the two things it lets you answer
A software bill of materials is the inventory that makes the supply chain visible, and the exam frames it as answering two questions the alternative cannot. When a new vulnerability is announced in a library, an SBOM tells you in minutes which of your applications contain it and at what version. When a package is revealed to have been compromised, an SBOM tells you whether you ever built with the bad release. Without one, both questions become an investigation. The SBOM is generated at build, stored with the artifact, and required from vendors for the software you acquire, which is how objective 4.5 on using verified secure software connects to the pipeline.
Integrity versus authenticity is the vocabulary the exam attaches here. A hash proves a package was not altered in transit (integrity). A signature from a key you trust proves who published it (authenticity). A compromised maintainer's package passes both, which is why version pinning and provenance sit alongside them rather than being replaced by them.
Licensing is the last supply chain risk in the objective and the one security people forget. Copyleft licenses can require that software incorporating the component be released under the same terms, which for a commercial product is a business risk that arrived through a dependency. SCA tools report license as well as vulnerability, and a scenario about a product that cannot ship because of a component's license is a software composition question, not a legal curiosity.
Four stems, decoded
- A build unexpectedly pulled a package from a public registry with the same name as an internal library. Dependency confusion. Scope the names, pin the versions, and stop the resolver reaching both sources for the same name.
- A vulnerability is announced in a logging library; the organization takes three days to determine which of its forty services are affected. No SBOM. Generate one at build for every artifact and keep it with the release.
- An application passed static analysis, dynamic scanning and a code review, and was breached through a business logic flaw in its refund process. No abuse cases. Derive them from the threat model and test the refusals, not just the features.
- A vendor's signed update contained an implant; the signature was valid. A compromised build or maintainer, which signatures do not detect. Provenance attestation, ephemeral runners and delayed adoption, plus the SBOM to establish exposure.
Key takeaways
- Place each test where its input exists: SAST and secrets at commit, SCA and SBOM at build, DAST and IAST at test, infrastructure and image scanning at deploy, WAF and runtime protection at run.
- Black box finds what an attacker can reach; white box finds what the code contains. Abuse cases test the refusals a functional suite never exercises.
- Dependency confusion and typosquatting exploit naming; compromised maintainers and builds exploit trust. Pin, scope, verify, delay, and attest provenance.
- An SBOM answers "are we affected" and "did we ever pull it" in minutes. Hashes prove integrity, signatures prove authenticity, and neither catches a trusted source that turned.
- Licenses are a supply chain risk too. Copyleft arrives through dependencies, and SCA reports it.
Application testing and verified software are objectives 4.4 and 4.5 of CCSP Domain 4, Cloud Application Security, 16% of the exam. The flaw families the tests look for are the ones in secure coding, and the same supply chain controls apply to models and training data. Work all 28 topics with our CCSP Domain 4 study guide.
#CCSP #ISC2 #CloudSecurity #DevSecOps #SAST #DAST #SBOM #SoftwareSupplyChain #ApplicationSecurity #CyberSecurity
Secure the code you did not write
Software assurance and verified software are two of seven objectives in CCSP Domain 4, 16% of the exam. Work all 28 topics, from awareness and the secure development lifecycle through testing, supply chain, application architecture and identity solutions, with 70 practice questions.
Get the CCSP Domain 4 guideKeep reading
Snapshot, Hash, Isolate: Digital Forensics When the Server Is Someone Else's
Every forensic rule you learned assumes you can pull the plug. In the cloud you cannot, and the disk belongs to someone else. CCSP Domain 5 on investigating on infrastructure you do not own: forensic readiness before the incident, isolate versus terminate, acquisition by snapshot and hash, chain of custody across a provider, what the provider will and will not give you, and the communication clock that starts the moment personal data is involved.
Read CCSP deep divesVM Escape, Management Plane, Noisy Neighbor: The Cloud Threat List and the Controls CCSP Maps to Each
A director asks what happens to the shops if the provider has a very bad day, and the answer is an availability figure. That is a likelihood; the question was about impact. CCSP objectives 3.3 and 3.4: risk identification and analysis for cloud infrastructure, the threats the platform itself invites, from VM escape and hypervisor compromise to management plane abuse and noisy neighbors, the four treatment strategies, and the physical, system, virtualization, identity and audit controls the exam expects you to match to each.
Read CCSP deep divesUptime Tiers, N+1 vs. 2N, Pilot Light vs. Warm Standby: Designing for Failure in the Cloud
In the cloud, the question is not whether something will fail but how large the failure will be. CCSP Domain 3 on resilience: the four failure scopes from instance to provider, the Uptime Institute's data center tiers and what each one guarantees, N+1 against 2N redundancy, the four cloud disaster recovery patterns from backup-and-restore to active-active, the recovery service level, and the shared responsibility for staying up.
ReadFollow Skillthropic
Keep learning between study sessions
The same exam-focused teaching, in smaller pieces, wherever you scroll.
Enjoyed this? Get the AI security news that matters.
Join The AI Security Brief for the top AI security news, plus what's important to the C-suite. Free, straight to your inbox.
No spam. Unsubscribe anytime.