Vulnerability Category Sorter

Vulnerability categories exist because the category decides who fixes the problem and which control makes it go away. A weak cipher is not patched, a careless click is not firewalled, and a flaw etched into silicon cannot be fixed by the vendor whose software happens to run on it. The sorting rule for all sixteen items is one question: what is actually defective? Not what the attacker eventually does with it, and not which technologies happen to be named in the sentence. Network vulnerabilities are weaknesses in the protocols, services and devices that carry traffic. Telnet listening with no authentication on a managed switch is a network service that should not be reachable at all; a default SNMP community string of "public" left on every device is a network management protocol shipped wide open. Software vulnerabilities are defects in code — the unpatched buffer overflow in a web server's request parser, and the SQL injection in a login form that pastes user input straight into a query. The zero-day in a PDF rendering library belongs here too, and it is worth seeing why: a zero-day is still an ordinary software bug. What "zero-day" describes is the state of the patch, not the nature of the flaw. That distinction is the one that matters in patch management — the category tells you which team owns the fix, and zero-day tells you no fix exists yet, so the response has to be a compensating control instead of a patch. Hardware vulnerabilities are defects in silicon and firmware, and both examples show why the fix never quite matches the flaw. Spectre is a speculative execution flaw in the CPU itself; the mitigations ship as microcode and operating-system updates, but the defect is in the chip, and no amount of clean application code removes it. The firmware bug in a network card is the item most often miscategorized as Network, because the word network is right there in the sentence. Look instead at what is defective: the code burned into the card's own firmware, which is exactly why the attacker survives an OS reinstall. The operating system is the thing being reinstalled, so it cannot be where the weakness lives. Human vulnerabilities are weaknesses in what people do. The untrained employee clicking a phishing link and the disgruntled insider walking out with customer data are the two classic shapes — the unwitting user and the malicious one — and they need different controls: awareness training for the first, offboarding procedure and monitoring for the second. The developer who hard-codes a password into a public repository is the harder call. The password ends up inside source code, so Software looks right, but no compiler, library or patch is at fault; a person made a decision. When the fix is "train the person, and give them a secrets manager to use instead", the weakness is human. Cryptographic vulnerabilities are the category this activity exists to pull apart, because they are routinely filed under Software and then behave nothing like software bugs. A software bug is a mistake in an implementation, and it is fixed by correcting the implementation. A cryptographic vulnerability is a failure of the cryptography itself — a broken algorithm, a deprecated protocol, or mishandled key material — and correcting the code around it does not help. MD5 used to hash passwords is not a bug in the hashing routine; MD5 does precisely what it was designed to do, and what it was designed to do is no longer strong enough. The fix is a different algorithm. TLS 1.0 left enabled on a public-facing server is a protocol whose design permits the POODLE downgrade; the fix is to stop offering the protocol, not to patch it. Private keys sitting unencrypted in world-readable files is improper key management, and it is the item most often confused with the world-readable cloud bucket over in Process/Configuration. Both are permission mistakes, so ask what the exposed asset is. A bucket of ordinary data is a provisioning failure. An exposed private key destroys every guarantee the cryptography was providing — the certificate can be impersonated and captured traffic may become readable — so when the asset is key material, the weakness is cryptographic. Process and Configuration vulnerabilities are weaknesses in how the organization runs and sets things up, rather than in any product. A production environment with no change control lets untested patches go straight in; nothing is technically broken, the procedure is simply missing. The world-readable cloud bucket is the configuration half: no product defect, no bad code, just a setting nobody applied at creation. The item that genuinely divides people is the legacy router using MD5 to authenticate OSPF. MD5 and hash collisions are both in the sentence, so Cryptographic is a reasonable first answer — and this set files it under Network. The reason is that these categories name the primary domain of the weakness, not every technology that appears in it. The defective thing is a routing protocol deployment on a network device; MD5 is the mechanism by which it is weak, and the remediation is a network task — reconfigure OSPF authentication, or replace the router that cannot. Compare it with the MD5 password item, where the hash is the application's entire security property and there is no other domain to point at. Real vulnerabilities sit on boundaries like this constantly, which is why scoring frameworks such as CVSS grade impact and exploitability rather than asking you to pick a bucket. The six categories are still worth knowing cold, because they are how a finding gets routed: network engineering, application development, hardware and vendor management, security awareness, cryptography, or governance. Choosing the wrong one does not merely misfile the report — it sends it to a team that cannot fix it.