Hardware, mobile, virtualisation, cloud and supply-chain vulnerabilities

Objective 2.3 in this course covers vulnerabilities. The previous lesson took application, web and operating-system flaws; this one takes the remaining categories in CompTIA's scope note for it — hardware, mobile device, virtualisation, cloud-specific and supply chain.

Why this matters

What unites these five is that the vulnerability is usually somewhere you do not control: in firmware you cannot read, in a hypervisor a provider operates, in a phone the user owns, in a component a supplier shipped.

That changes the shape of the answer. For an application flaw the answer is "fix the code". For these, the answer is usually to establish what the provider is responsible for, what you are responsible for, and what compensating control covers the gap — which is why this objective keeps handing off to Domain 3's architecture material and Domain 5's third-party risk.

The lesson

Firmware, end-of-life and legacy hardware, and what 'legacy' costs

Firmware is code running below the operating system: UEFI/BIOS, the management controller, drive controllers, network card firmware. Two properties make it dangerous — it runs with the highest privilege on the machine, and it persists across operating system reinstalls. A compromise there survives the response action most people consider definitive.

It is also the code least likely to be patched. Firmware updates are riskier, less automated, sometimes require downtime, and are frequently not tracked by the vulnerability management programme at all. Secure boot and a hardware root of trust are the structural controls: they verify each stage of boot before handing over.

CompTIA separates two adjacent terms:

• Legacy hardware is old but still supported, or old enough that support is thin. It costs you in weaker cryptographic capability, missing platform mitigations and slower patching.
• End-of-life hardware receives no further updates of any kind. Whatever is discovered from now on is permanent.

The cost of legacy is the hidden part. It is not only the known vulnerabilities: it is that modern controls often cannot be applied at all. A switch that does not support 802.1X, a server without a TPM, an appliance whose maximum TLS version is one you should have disabled — each of these blocks a control you would otherwise deploy, and that blocked control is the real expense.

VM escape and resource reuse, and why the hypervisor is the boundary

In a virtualised estate the hypervisor is the security boundary. Everything above it assumes that boundary holds.

VM escape is the vulnerability class where code in a guest reaches the hypervisor or another guest. It is rare and it is severe, because it invalidates the assumption underneath the whole design: a compromised low-value guest becomes a path to every other workload on the host, including ones with a completely different trust level.

Resource reuse is the quieter problem. Memory, disk blocks and other resources are recycled between guests. If they are not properly cleared, one tenant's data can appear in another's allocation. The same idea applies to deleted cloud storage and to container layers.

Related items CompTIA names: VM sprawl, where machines multiply faster than anyone tracks them, leaving unpatched and unmonitored guests nobody owns — a vulnerability management failure rather than a technical flaw, and a very common real finding.

Controls: patch the hypervisor as a priority, do not place workloads of widely different sensitivity on the same host if you can avoid it, keep management interfaces off general networks, and keep an accurate inventory so sprawl is visible.

Cloud-specific vulnerabilities and the shared responsibility model's seam

Cloud vulnerabilities cluster in a specific place: the seam between what the provider secures and what you secure.

The shared responsibility model says the provider secures of the cloud and you secure in it, with the line moving by service type — in IaaS you own the operating system, in PaaS you do not, in SaaS you own little but your data and your access configuration. The exam tests the line, so know which side the OS, the application, the data and the access configuration fall on for each model.

The recurring real-world vulnerabilities:

• Misconfiguration, overwhelmingly the largest category. Storage buckets readable by anyone, databases exposed to the internet, over-permissive identity policies, logging never enabled. None of these are provider flaws.
• Insecure or over-privileged APIs and keys. Cloud is API-driven, so a leaked key is administrative access. Keys committed to repositories are a standing source of breaches.
• Multi-tenancy risk, the cloud form of resource reuse and escape above.
• Insufficient logging, which is not a vulnerability that lets anyone in but reliably turns a small incident into an unanswerable one.

The framing that scores marks: in cloud incidents, ask first whether the failure was on the customer's side of the line. It usually was.

Sideloading, jailbreaking and rooting, and the control they remove

Mobile devices are hardened by a model that assumes apps come from a curated store, are signed, and run sandboxed with permissions the user grants.

• Sideloading installs an application from outside the official store. The code review and signing checks the store performs are skipped.
• Jailbreaking (iOS) and rooting (Android) remove the manufacturer's restrictions to gain privileged access to the OS.

What they actually remove is the sandbox and the integrity guarantees, which are the very things the rest of the platform's security depends on. On a rooted device, per-app data separation cannot be relied upon, mobile device management controls can be defeated or spoofed, and attestation — the device proving its own state — becomes meaningless.

This is why MDM and conditional access check for rooting and jailbreaking and refuse enrolment or corporate access. It is also why "the user installed an app from a website" is a materially different finding from "the user installed a bad app from the store".

Other mobile vulnerability sources the exam names: unpatched devices where the manufacturer has stopped shipping updates (an end-of-life problem on a two-year cycle), insecure Wi-Fi and Bluetooth use, and lost or stolen devices — which is why remote wipe and device encryption are in the Domain 4 lesson on mobile deployment.

Service provider, hardware provider and software provider risk

CompTIA's three supply-chain categories, each with a characteristic failure:

• Service provider — an MSP, a hosting provider, an outsourced function. Characteristic failure: they hold privileged access to your estate, and their compromise becomes yours. Their sub-contractors are also in your supply chain, which organisations routinely fail to consider.
• Hardware provider — characteristic failures are counterfeit components, tampering in transit, and preinstalled firmware or software you did not ask for. The control is buying through authorised channels, verifying what arrives, and replacing vendor images with your own build.
• Software provider — characteristic failures are the compromised update and the backdoored dependency from the previous lesson, plus the simple case of a vendor with poor security practice whose product is full of holes.

Two practical instruments the exam expects you to recognise:

• A software bill of materials (SBOM) lists the components and dependencies inside a product. Its value is answering "are we affected?" in hours rather than weeks when a widely used library turns out to be vulnerable.
• Vendor due diligence and right-to-audit clauses, which are how you get any visibility at all into a third party's practices. Domain 5 covers these properly.

The honest summary: for supply chain you cannot fix the vulnerability, because it is not in your code. You manage exposure — know what you depend on, limit what each dependency can reach, and be able to answer quickly when one of them turns out to be the problem.

What to take into the exam

• Firmware compromise survives an OS reinstall; secure boot and a hardware root of trust are the structural answers.
• The hypervisor is the boundary, so VM escape invalidates every isolation assumption above it. Resource reuse is the quieter sibling.
• Most cloud incidents are customer-side misconfiguration, not provider flaws — know which side of the shared responsibility line each item sits on.
• Rooting and jailbreaking remove the sandbox and make attestation meaningless, which is why MDM blocks such devices.
• An SBOM's value is answering "are we affected?" quickly.