What is code security in the cloud?
Code security is the practice of finding security defects in the artefacts that build a system — application source, dependencies, infrastructure-as-code templates and pipeline configuration — before they are deployed. It combines static analysis, dependency analysis, IaC scanning and secret detection, applied continuously as code changes.
The four techniques, and what each one can see
They are usually sold together and they look for different things.
SAST — static application security testing. Reads source code without running it, tracing how untrusted input flows to a dangerous operation. Catches injection, unsafe deserialisation, path traversal, weak cryptography. It sees code paths that tests never execute, and it produces false positives where it cannot prove a path is unreachable.
SCA — software composition analysis. Inventories dependencies, including transitive ones, and matches them against known vulnerabilities. Most of the code shipped is not written in-house, so this is usually where the volume is. Its weakness is the inverse of SAST's: it reports a vulnerable package whether or not the vulnerable function is ever called.
DAST — dynamic application security testing. Exercises the running application from the outside. It finds what is genuinely reachable, including configuration and deployment problems no static tool sees, but only on paths it manages to reach.
IaC scanning. Evaluates Terraform, CloudFormation, Helm charts and Kubernetes manifests against policy before anything is created. This is the earliest possible point to catch a misconfiguration — the template that will create a public bucket, rather than the public bucket.
Secret detection cuts across all of them: credentials in source, in image layers, in pipeline configuration, in committed state files.
Why fixing it in the console makes it come back
This is the failure that makes code security a cloud security concern rather than an application security one.
A posture tool reports a storage bucket with public access. An engineer opens the cloud console, unchecks the box, marks the finding resolved. The next terraform apply recreates the bucket exactly as the template describes it — public — because the template was never changed.
The finding returns, gets re-triaged, gets fixed in the console again. Everyone is working, nothing is improving.
The fix has to land where the resource is defined. That requires knowing which template, repository and line produced a given running resource — which means connecting the code side to the runtime side rather than running two programmes that never meet.
Reachability is what makes the numbers usable
A dependency scan on a mature service commonly returns hundreds of findings. Fixing them in CVSS order is a reasonable-sounding strategy that wastes most of the effort, because severity describes the vulnerability, not your exposure to it.
Three questions change the order:
- Is the vulnerable function actually called? A critical CVE in a code path the application never executes is not a critical risk to that application.
- Is the workload reachable? The same container behind an internal service and behind an internet-facing load balancer carries very different risk.
- What can it reach next? A vulnerable workload with a read-only role is contained. The same workload with a role that can assume other roles is an entry point.
None of those questions can be answered from the code alone, which is why code findings become useful when they are joined to runtime context.
Where it belongs in the pipeline
| Stage | What runs | What it should block |
|---|---|---|
| Pre-commit | Secret detection | Any credential, always |
| Pull request | SAST diff, SCA on changed dependencies, IaC policy | New Critical or High on changed code |
| Build | Image scan, SBOM generation | Base images with known critical CVEs |
| Pre-deploy | IaC policy against the plan | Templates that would violate posture policy |
| Runtime | Posture, reachability, drift | Nothing — it reports; blocking here breaks production |
The rule that keeps this survivable: gate on the delta, not the backlog. A pipeline that fails on every pre-existing finding gets switched off within a fortnight. One that fails only on newly introduced findings holds the line while the backlog is worked separately.
What good looks like
- Secret detection running before code leaves a laptop, not after it reaches the default branch.
- SCA prioritised by reachability, not by CVSS.
- IaC policy evaluated against the plan, so the misconfiguration is prevented rather than reported.
- Every runtime finding traceable back to the template and repository that produced it.
- One inventory across code and cloud, so "which running workloads contain this dependency?" is a query rather than a project.
Frequently asked questions
What is the difference between SAST, DAST and SCA?
SAST reads your source code without running it. DAST exercises the running application from outside. SCA inventories third-party dependencies and matches them against known vulnerabilities. They find different classes of defect and none of them substitutes for another.
Why do cloud misconfigurations come back after being fixed?
Because they were fixed in the console while the infrastructure-as-code template that created them was left unchanged. The next apply recreates the original configuration. A fix only holds when it lands where the resource is defined.
Should a build fail on every security finding?
No. Gate on newly introduced findings and work the existing backlog separately. A pipeline that fails on every pre-existing issue is switched off or bypassed within weeks, which is worse than no gate at all.
What is reachability analysis in dependency scanning?
Determining whether the vulnerable function in a dependency is actually invoked by your application. It typically removes the large majority of raw findings and is the difference between a dependency report you can act on and one you cannot.