Objective 2.2 · Lesson 2 of 2

Connect cloud posture, build artefacts, and detection results

Cloud and simulation reports answer different questions from a traditional port scan. Correlating their evidence helps distinguish a risky configuration, a vulnerable component, and a defensive control that failed.

Read cloud findings in their resource context

ScoutSuite and Prowler can assess cloud configuration through service APIs. Their findings may concern identity permissions, network exposure, logging, or storage settings rather than an exposed software version. Start with the account, region, resource identifier, evaluated rule, observed value, and assessment permissions. A skipped check caused by insufficient access belongs in the coverage record; it is not a passing result.

Determine whether a flagged resource is deployed, reachable, and handling important data. Cloud permissions and network rules interact, so one permissive setting may not establish the entire access path. Conversely, a private endpoint does not cancel an excessive identity permission. Retain the separate findings, explain the path each could enable, and ask the relevant owner to validate effective access.

Compare intended and deployed states

Checkov examines infrastructure-as-code and related configuration for policy concerns. Trivy can inspect artefacts such as container images for vulnerable components and configuration issues. Record exactly what was assessed: a source file, image digest, repository revision, or running resource. A finding against an unused build and a finding against the image deployed in production have different immediate operational implications.

Correlate these identifiers with deployment records instead of assuming the newest repository commit is live. A source fix may not yet have reached the environment, while a manual cloud correction can be overwritten by the next deployment. Where intended and deployed states differ, assign actions for both. Rebuild or redeploy as needed, then validate the artefact and the effective service configuration.

Evaluate control behaviour with evidence of execution

Breach attack simulation evaluates how defences behave during controlled activity. Atomic Red Team provides focused technique tests; Caldera supports orchestrated emulation. Review which actions actually executed, which prerequisites were met, and which controls were expected to prevent, detect, or respond. A failed simulation step is not automatically evidence that a security product blocked it; setup or permission errors can produce the same status.

Correlate the exercise timeline with host logs, sensor health, alerts, and analyst handling. Distinguish activity prevented before completion, activity recorded without an alert, and an alert that reached nobody responsible. These are different improvement tasks. Keep the exercise within approved synthetic or isolated environments, document cleanup, and rerun the agreed test after changing the detection or response workflow.

Keep these points in mind

  • Attach cloud findings to exact resources and record permission-related gaps.
  • Link source revisions and image digests to deployed instances before assigning exposure.
  • A simulation needs execution evidence before prevention or detection can be evaluated.

Pause and practise

Checkov shows a storage policy fixed in source, while Prowler still reports the old deployed permission. Write the next two checks.

Show a worked response

Compare the checked source revision with the deployment record and the exact cloud resource. Then inspect the effective deployed policy with the owner. If the change has not shipped, track deployment and repeat the cloud check; if drift is present, reconcile the deployment process so the next release does not restore the unsafe setting.

← Previous lesson