Posts

Showing posts with the label Vulnerability Management

EPSS Explained: Predicting Exploitation for CySA+ Vulnerability Management

EPSS — the Exploit Prediction Scoring System — estimates the probability that a given vulnerability will be exploited in the wild within the next 30 days. It exists because CVSS, for all its usefulness, answers a question that is not quite the one vulnerability managers need to answer. CVSS tells you how bad a vulnerability would be if exploited. EPSS tells you how likely it is that anyone will bother. Those are different questions, and conflating them is the single most expensive mistake in vulnerability management. The Problem EPSS Solves A typical enterprise scan returns thousands of findings, a large share of them rated High or Critical by CVSS. Patching all of them promptly is not possible, so teams work down the list by severity. The trouble is that severity is a poor predictor of what attackers actually use. Only a small minority of published CVEs are ever exploited in the wild — consistently measured in the low single-digit percentages. Meanwhile, plenty of CVSS 9.8...

SBOM Explained: Software Bill of Materials for Security+ and CySA+

A software bill of materials , or SBOM , is a formal, machine-readable inventory of every component inside a piece of software — the libraries, frameworks, and dependencies it is built from, including the ones its dependencies pull in. You cannot patch what you do not know you are running. An SBOM is the answer to "are we affected?" before it takes three days to find out. The case for it was made decisively by Log4Shell in December 2021. A critical vulnerability landed in Log4j, a logging library embedded so deeply in the Java ecosystem that most organizations genuinely could not tell whether they used it. Teams spent weeks grepping filesystems. Organizations with accurate SBOMs answered the question in minutes. That contrast is why SBOMs went from a niche supply-chain idea to a procurement requirement and, in the United States, a federal one under Executive Order 14028. What Is Actually In One An SBOM entry typically records, for every component: Name and version ...

SCAP Explained: CVE, CVSS, CCE, CPE, XCCDF and OVAL for CySA+

SCAP — the Security Content Automation Protocol — is a set of open standards from NIST that let security tools describe configuration and vulnerability information in a common language. Its purpose is unglamorous and genuinely important: making compliance checking automated, repeatable, and comparable between tools. Before SCAP, every scanner spoke its own dialect. SCAP is the shared vocabulary that lets one tool's findings mean the same thing as another's. The practical problem it solves is auditing at scale. Checking one server against a hardening benchmark by hand takes hours. Checking ten thousand servers by hand is impossible, and doing it with ten different tools that each define "compliant" differently is worse than useless. The Component Standards SCAP is a framework of specifications rather than a single thing. The ones worth knowing by name: CVE — Common Vulnerabilities and Exposures. The unique identifier for a specific vulnerability, in the f...