CompTIA Exam Prep - ITF+, A+, Network+, Security+, CySA+

A container image is an operating system distribution, a language runtime, a set of libraries, and your application, all frozen into one artifact. Scanning it means answering a question that spans every one of those layers: what known vulnerabilities are inside this thing we are about to run in production, and which of them actually matter. Two different inventories in one artifact Image scanners have to handle two package worlds at once. The operating system layer is enumerated from the distribution's package database — the same metadata the package manager uses. Matching those against distribution security advisories is reliable, provided the scanner understands backported patches. Distribution maintainers routinely fix a vulnerability without changing the upstream version number, so a naive version comparison reports flaws that were patched weeks ago. The application layer is enumerated from language-specific manifests and lock files. This is ordinary software compositio...

Key rotation replaces a cryptographic key with a new one. The reasons are straightforward; the reason it goes wrong is that a key is rarely in only one place, and rotating it without knowing where they all are causes an outage. Why rotate at all Limiting exposure. A key compromised at some unknown point protects everything it ever encrypted. Rotating bounds that window — material encrypted under a retired key is unaffected by compromise of the current one, and vice versa. Cryptoperiod limits. Every key has a usable lifetime based on how much data it protects and how much cryptanalysis it is exposed to. Some modes have hard limits on data volume under a single key. Personnel change. Where a human ever held or could have held the key material, rotation on departure is the only way to revoke that knowledge. Compliance. Several frameworks mandate defined cryptoperiods, and an auditor will ask for evidence of rotation rather than a policy stating it happens. Practice. The u...

Applications built on large language models introduce a risk class that existing controls do not cover well, because the system's instructions and its input arrive through the same channel and in the same form. Everything below follows from that one architectural fact. Prompt injection A model receives a prompt containing the developer's instructions and the user's content concatenated together. The model has no reliable way to distinguish which text is authority and which is data — they are both just tokens. Content that says "ignore previous instructions and do X" may be followed. The structural parallel is SQL injection : code and data sharing one channel. The difference is that SQL injection has a complete fix in parameterized queries, where the database is told explicitly which part is structure and which is value. No equivalent exists for language models. There is no parameterization primitive, and prompt-based defences are heuristics an attacker can wo...

Code signing attaches a digital signature to software so a recipient can confirm who published it and that it has not been altered since. It is the mechanism behind every "verified publisher" prompt and every silently accepted driver installation. What it proves is narrower than most people assume, and that gap is where the exam questions live. The mechanics The publisher hashes the software and encrypts the hash with their private key. That signature, along with the signing certificate, travels with the file. On the receiving side, the system hashes the file, decrypts the signature using the public key from the certificate, and compares. A match means the file is byte-for-byte what was signed. The certificate itself is validated up the chain to a trusted root, and revocation is checked. Signature valid plus chain valid plus certificate not revoked equals a trusted install; any failure produces a warning or a refusal depending on the platform's policy. Certificate au...

Hard-coded secrets — API keys, database passwords, private keys, access tokens — committed into source control are one of the most reliable ways into an organisation. Secrets scanning is the practice of finding them before somebody else does. Why it is worse than it sounds Three properties make a committed secret unusually dangerous. Git history is permanent. Deleting the line and committing does not remove the secret. It remains in the history, retrievable by anyone who can clone the repository. The fix is rotation, not deletion — a point covered below, and the single most important thing to get right. Repositories spread. Forks, clones, CI caches, developer laptops, backups. Once a secret is in history, every copy carries it. Public exposure is exploited fast. Automated scanners watch public repositories continuously, and credentials pushed to a public repository are frequently used within minutes. Cloud keys in particular get picked up and used for cryptomining almost immedi...

A build-time scan tells you what was known to be vulnerable on the day you shipped. The question that arrives later — a new advisory lands, and are we affected — is a different one, and answering it requires knowing what is in every artefact currently deployed, not what was in the one you scanned. The gap between build-time and continuous Scanning in the pipeline, as described under software composition analysis , catches vulnerabilities known at build time. It cannot catch vulnerabilities disclosed afterwards, and nothing about the artefact changes when they are. So an application built clean six months ago may now contain three critical vulnerabilities, with no build, no commit and no alert. The only way to know is to hold the inventory of what was shipped and re-evaluate it as new advisories appear. That is the function: a repository of SBOMs for every component and version in the estate, continuously matched against vulnerability data, generating notifications when...

An update mechanism is an authorized remote code execution channel . It runs with high privilege, it executes whatever the server sends, and it is designed to do so without asking the user. Every property that makes updating convenient makes the channel worth attacking, and this article is about the channel specifically rather than the broader vendor risk covered under supply chain security . The four ways a channel is hijacked Transport interception. An update fetched over plain HTTP with no signature verification can be replaced by anyone on the path. This should be extinct and is not — embedded devices, industrial equipment, and older applications still do it, and it is a routine finding in device assessments. Server compromise. The attacker gains control of the distribution infrastructure and replaces the artifact at source. Signature verification defeats this only if the signing key is held somewhere the attacker did not reach, which is the argument for hardware-backed...

Most of the code in a modern application was not written by the team that ships it. Frameworks, libraries, and their dependencies typically make up the large majority of a deployed artifact, and every one of them carries whatever vulnerabilities it has. Software composition analysis is the practice of finding out what you are actually shipping and what is wrong with it. Transitive dependencies are the problem A team declares perhaps twenty direct dependencies. Each of those pulls in its own, and those pull in more, so the resolved tree commonly runs to hundreds or thousands of packages. Almost nobody has reviewed that tree. When a vulnerability is announced in a low-level utility library, the question "are we affected" is unanswerable by reading your own manifest, because the affected package is four levels down and was never chosen by anyone. That is why the recent high-profile dependency incidents caused such widespread scrambling: organizations could not determine expo...

Scanning dependencies for known vulnerabilities tells you about problems that already have a CVE number. Governance is the upstream question: which components you take on in the first place, how you keep them current, and how you get rid of the ones that become liabilities. It is the part that prevents findings rather than reporting them. Evaluating a dependency before adopting it Adding a library is a long-term commitment to someone else's code and someone else's maintenance. A short check before the first import costs minutes and saves years. Maintenance signals. When was the last release, and how quickly do security issues get fixed? A project with an eighteen-month gap since its last commit is not maintained, whatever its popularity. Bus factor. How many people can merge changes? A great deal of critical infrastructure is maintained by one unpaid person, which is a supply chain risk and a burnout risk simultaneously. Dependency weight. A package pulling in forty tr...

Four categories of application security testing exist because each one sees something the others cannot. Choosing between them is the wrong framing; knowing which finds what, and therefore what you are still blind to, is the useful skill. DAST: testing the running application Dynamic Application Security Testing exercises a deployed application from the outside, sending requests and analysing responses. It has no access to source code — it behaves like an attacker with a browser and a great deal of patience. Its strength is that it tests what is actually running: the deployed configuration, the web server, the framework, the authentication flow, and the interactions between components. A finding is real by construction, because the scanner reproduced it against the live system, which keeps false positives low. It reliably finds injection flaws, cross-site scripting, authentication and session weaknesses, security header and TLS misconfiguration, information disclosure in erro...

A monolith is one deployable unit where components call each other in memory. Microservices split that into independently deployable services communicating over the network. The organizational arguments are well rehearsed; the security consequence is simpler and rarely stated plainly: internal function calls become network requests , and everything follows from that. What actually changes In a monolith, one component calling another is a function call. There is nothing to intercept, nothing to authenticate, and nothing on the wire. The security boundary is the edge of the application. Split it into forty services and those calls cross a network. Each is now an opportunity for interception, each needs to establish who is calling, and each service is independently reachable by anything that can route to it. The attack surface multiplied, and the perimeter model stopped describing anything useful. That is the honest summary, and the mitigations below all follow from it. Identity re...

APIs fail differently from web interfaces, and the reason is structural: a web page decides what to show you, while an API answers what you ask for. Remove the interface that was shaping the requests and a whole category of assumptions stops holding. Broken object level authorization The most common and most damaging API flaw. An endpoint accepts an object identifier and returns that object without checking whether the caller is entitled to it. The web interface only ever sent the user's own identifier, so nobody wrote the check. Testing it is mechanical: capture a request for your own resource, change the identifier, and see what comes back. Sequential numeric identifiers make enumeration trivial; random identifiers make it harder and are not a fix, because obscurity is not authorization. The related failure is broken function level authorization — an administrative endpoint that checks authentication but not role, reachable because the button was merely hidden in the inter...

Configuration management tools apply a declared desired state to many systems and reapply it on a schedule. The security value is not that they save time — it is that they make configuration known, reviewable and self-correcting , which addresses the drift problem that defeats most hardening programmes. Declarative and idempotent Two properties that explain why this works. Declarative means you describe the end state rather than the steps: this package is installed, this service is running, this file has these contents and these permissions. The tool determines what needs changing. Idempotent means running it repeatedly produces the same result. A system already in the desired state is left alone; one that has drifted is corrected. Together they turn drift from something you detect into something that reverts automatically. A setting disabled during troubleshooting at 2 a.m. is restored at the next run, which is a stronger control than any amount of scanning — the di...

A webhook is an HTTP callback: instead of your application repeatedly asking a service whether anything happened, the service posts to a URL you provide when something does. It replaces polling, it is the backbone of most SaaS integration, and it is an unauthenticated public endpoint accepting data that drives your business logic — which is why the security details matter. Polling versus push Polling wastes requests and adds latency: check every minute and you make 1,440 requests a day to learn about three events, each up to a minute late. Webhooks invert this. The event arrives immediately and no request is wasted, at the cost of running a reachable endpoint and handling delivery reliability yourself — a webhook you were not listening for is simply missed unless the sender retries. The receiver's problem Your endpoint is on the public internet and anyone can post to it. Nothing about a request proves it came from the service it claims. Signature verification is th...

Applications need credentials — database passwords, API keys, certificates, tokens for other services — and the default place they end up is a configuration file or an environment variable set from one. That works until you need to rotate one, audit who used it, or find out where it is, at which point the absence of a system becomes the problem. Why secrets end up in repositories Not carelessness, mostly. A developer needs the application to run locally, puts the credential in a configuration file, and commits it because the file is needed to run. It works, so nobody revisits it. The consequence is that the secret is in the version history permanently , readable by everyone with repository access, present in every clone, and surviving deletion of the line. Removing it requires rewriting history, which is disruptive and frequently incomplete — and the right response is to treat it as compromised and rotate. Public repositories are scanned continuously for committed...