8.3 Container, Secrets, and ICS Vulnerability Assessment

The rest of the 3.1 types of scans list is easy to skip in a study plan that still thinks "vulnerability scan" means Nessus versus a /24. CompTIA also wants container scans (including sidecar), secrets scanning, and industrial control systems (ICS) vulnerability assessment via manual assessment and port mirroring. These are discovery techniques. They are still not exploitation.

Specialized discovery tools such as BloodHound, TruffleHog, Grype, Trivy, Kube-hunter, and PowerSploit appear on the same 3.1 tool list; they are covered in the next chapter. This section is the scan type decision, not the product walkthrough.

Container scans: image versus sidecar

A container image scan inspects the image as an artifact: operating-system packages in the base layer, language runtimes, bundled libraries, and sometimes mis-set file permissions. You run it in the registry or in CI before the image is scheduled. The finding is "this tag still ships a CVE in openssl" or "this layer copies a .pem into /app." You have not executed a container escape. You have not even needed a running pod.

A sidecar scan is a Kubernetes (and similar orchestrator) pattern. A sidecar is a companion container in the same pod as the application, sharing namespaces such as the network namespace. A sidecar scanner watches traffic, collects an inventory, or runs checks against the workload without rebuilding the application image. Exam writers use "sidecar" as a vocabulary item: if the stem says a scanner container sits beside the app in the pod, the 3.1 type is a container sidecar scan, not a CIDR SYN sweep of the worker node and not SAST of the Dockerfile alone.

Do not collapse three different objects. Scanning the Dockerfile as text is closer to SAST/IaC. Scanning the built image in the registry is an image scan. Running a sidecar next to the live workload is a runtime-adjacent container scan. Kube-hunter-style cluster tests belong with later specialized tools; the type here is still "container," with sidecar as the named subtype.

Secrets scanning as a scan type

Objective 2.2 already taught secrets enumeration during recon: you notice an AKIA key in JavaScript or a password on a guest share. Secrets scanning on 3.1 is the scanner and pipeline version of that hunt. A secrets scanner walks git history, CI logs, container layers, Helm values, and .env files looking for private keys, cloud access keys, API tokens, and passwords.

The finding is the location and type of the secret. Handling does not change from enumeration: treat it as a live credential, store it only in the agreed evidence channel, recommend rotation and a secrets manager, and do not paste it into a public chatbot or gist. Exam trap: calling a git-history AWS key "DAST" because the app is deployed, or calling it host-based OS fingerprinting. If the technique is pattern-matching credential material in repos or images, the 3.1 type is secrets scanning.

Secrets scanning overlaps container image scans when a key is baked into a layer. Report both: the image has a CVE and a copied key. Overlap does not merge the types.

ICS vulnerability assessment: observe, do not blast

ICS and operational technology (OT) are not an ordinary /24. Programmable logic controllers (PLCs), safety instrumented systems, and engineering workstations can fault when they receive unexpected probes, long TCP connect scans, or default plugin packs written for Windows and Apache. Do not blast OT with Tenable Nessus default plugins just because the scanner can route to the address.

CompTIA lists two ICS techniques.

Manual assessment means architecture review with plant engineers, protocol allow-lists, firmware and patch inventories from the vendor or the historian — not from a reckless SYN flood — walkdowns of engineering workstations, and careful, vendor-supported checks. You are discovering weakness by understanding the system, not by treating a PLC like a misconfigured IIS box.

Port mirroring (a Switch Port Analyzer, or SPAN, session, or a network TAP) copies traffic to a sensor so you can observe ICS protocols — Modbus, DNP3, EtherNet/IP, OPC — without writing setpoints. Observation is the safety-preserving discovery method. You still need rules of engagement, a change window if anything active is later authorized, and an out-of-band way to stop if a process alarm fires.

Purdue model: cross-reference, do not retake chapter 3

The Purdue model (objective 1.3) remains the scoping map: Level 0 physical process, Level 1 basic control (PLCs), Level 2 area supervisory, Level 3 site operations, Levels 4–5 enterprise IT. Chapter 3 taught why hopping from Level 3 operations onto Level 1 logic is a safety and authorization problem. For 3.1, use that map to choose the assessment method. Enterprise IT at Level 4–5 may tolerate an authenticated Nessus pass. Level 1 controllers generally want manual review and mirrored observation, not default plugin blasts. Do not re-derive all six levels on the exam; apply them: if the stem names PLCs or a plant network, pick manual assessment and port mirroring.

Nikto against every HTTP listener in a plant is the same class of mistake. An engineering workstation might speak HTTP; a PLC that faults on a banner grab is not a web-server lab.

Keep discovery inside the RoE. A sidecar you were not authorized to schedule is a change to production. A SPAN port you were not given is not a free tap. A secret you found is still a live credential. ICS observation that stays read-only is how testers leave the plant in the same state they found it — which is the point of a vulnerability assessment that is not an exploit engagement.