Containers, cloud and tooling
Summary: this lesson goes through the families of tools — SAST, DAST, SCA, image scanning, infrastructure as code analysis, CSPM — explaining what each one detects and what it cannot detect. Then it covers container hardening and the cloud's shared responsibility model, two subjects where mistakes are frequent and costly.
1. The families of tools
If you only enable one, enable SCA. It is the one that covers the most frequent attack vector, produces the fewest false positives, and gets set up in fifteen minutes. SAST, noisier, will come later.
Point 6 deserves to be understood, because it complements point 5 in an essential way. Infrastructure as code analysis checks your code. CSPM checks reality. And the two always diverge: someone changed a setting manually during an incident, and never put it back. This is what we call drift, and only CSPM detects it.
2. SAST versus DAST — the comparison
| Criterion | SAST | DAST |
|---|---|---|
| When | As soon as the code is written | Deployed application required |
| Vision | White box (sees the code) | Black box (sees the outside) |
| Finds | Dangerous code patterns | Actually reachable vulnerabilities |
| False positives | Many | Few |
| False negatives | Few on what it knows | Many (only covers what it reaches) |
| Points to the faulty line | Yes | No |
| Covers configuration | No | Yes |
| Speed | Seconds to minutes | Minutes to hours |
The complementarity is real and not just theoretical. SAST tells you "line 84, this query is built by concatenation" — precise and immediately actionable. DAST tells you "I managed to extract data through the search field" — less precise but proven exploitable.
There is also IAST, a hybrid approach that instruments the application during functional testing to observe its internal behavior. Less widespread, but it strongly reduces SAST's false positives.
3. Securing container images
Point 2 is the most important, and the most often neglected. By default, a container runs as root. If an attacker compromises your application and then manages to escape the container — which remains rare but has happened — they obtain elevated rights on the host machine. Adding a dedicated user takes two lines in a Dockerfile.
Point 1 is the most effective by volume. Moving from a full base image to a slim variant can bring the number of reported vulnerabilities down from several hundred to a handful. You fixed nothing — you simply removed unnecessary code. It is the attack surface minimization principle applied to containers.
Point 7 explains a frequent confusion: an image you haven't modified in six months is more vulnerable today than when it was created, because new flaws have been published in the meantime on its packages. Scanning must be recurring, not just at build time.
4. The shared responsibility model
This is the most costly misunderstanding of the cloud. The major providers have security resources almost no company can match. But that does absolutely not protect against a storage bucket you made public, or an administration role granted too broadly.
The good news: this category of errors is entirely detectable automatically. That is exactly what infrastructure as code analysis and CSPM do. The subject is also covered in our cloud course.
5. Where to place the checks in the pipeline
The principle guiding this placement: the earlier the check, the more economical it is and the better it is accepted. A developer gladly fixes a problem flagged in their editor; they are far less welcoming of the same problem raised three weeks later by an external team.
6. Calibrating blocking without paralyzing
The most useful distinction in practice: block on production dependencies but not on development ones. A flaw in a testing tool never reaches your users, and blocking on it is the best way to get your control disabled out of exasperation.
A progressive rollout tip: first enable all your controls in report-only mode for two to four weeks. That way you measure the real noise, you clean up the past, and you only make blocking what is sustainable.
7. The tooling summary table
| What you want to avoid | The tool that detects it | Where to place it |
|---|---|---|
| SQL injection in your code | SAST | Editor, change proposal |
| Vulnerable dependency | SCA | Change proposal, daily |
| Secret in the code | Secrets detection | Local hook, then CI |
| Base image full of flaws | Image scanning | Build, then recurring |
| Public cloud storage | Infrastructure as code analysis | Change proposal |
| Configuration drift in production | CSPM | Continuously |
| Actually exploitable vulnerability | DAST | Staging, periodically |
| Abnormal behavior in production | Runtime detection | Continuously |
| Image substituted before deployment | Signature + verification | Admission |
This table is an implementation plan usable as is. Don't try to enable everything at once: follow the order of cost-effectiveness — secrets detection, then SCA, then infrastructure as code analysis, then the rest.
Remember in 30 seconds
- SAST = source code analysis, precise but noisy. DAST = attacks the running application, less precise but proven exploitable. SCA = dependencies, the best value-for-effort ratio.
- If you only enable one tool, enable SCA. Fifteen minutes, covers the most frequent attack vector.
- Infrastructure as code analysis checks the code, CSPM checks reality. The two always diverge: that is drift.
- Containers: minimal base image, never root, multi-stage build, no secret in the layers, pinned versions, read-only filesystem, recurring scanning.
- Moving to a slim base image can bring the number of vulnerabilities down from several hundred to a handful.
- An unchanged image becomes vulnerable over time — flaws are published after it was built.
- Shared responsibility: the provider secures the cloud, you secure what you put in it. Almost all cloud incidents come from a customer misconfiguration.
- The earlier the check, the more economical and accepted it is.
- Block on: detected secret, critical exploitable vulnerability in production, public data exposure. Report the rest.
- Start in report-only mode for two to four weeks before making anything blocking.