Security hole

A security hole is a weakness in a system, network, application or any other digital component that an attacker can use to compromise the security of that system.

Security holes are potential entry points. They get used to run attacks, steal data, interrupt services, or in the worst case take full control of the affected system.

Finding and fixing them is what protects the integrity, confidentiality and availability of information, which is why it is treated as continuous work rather than a project.

They come from several places: mistakes in how software was written, wrong configuration, missing updates, or a design that was flawed from the start.

Managing them well means going looking before somebody else does. Organisations use security assessments, vulnerability scanning and penetration testing to find the holes in their own systems and applications.

Once a hole is found it has to be patched or otherwise corrected, and until it is, the exposure is real rather than theoretical.

Where to read more

OWASP, Vulnerability Management: the Open Web Application Security Project publishes practical material on managing vulnerabilities, including how to find and mitigate security holes in web applications.

NIST, Guide to Enterprise Patch Management Technologies: a detailed guide to patch management technology, which is the part of the answer that closes known holes.

CVE Details: a database of publicly known software vulnerabilities, useful for looking up a specific hole and understanding which products and versions it affects.

A worked example

A company runs an out of date database management system with a known security hole. An attacker finds the weakness and uses SQL injection to reach and modify the database.

Exploiting it gives them unauthorised access to confidential information: customer records, financial data. A single unpatched component is enough to compromise the integrity and confidentiality of everything stored behind it.

Mitigating it means applying the security patches and keeping the database software current, which sounds obvious and is the step that gets skipped.

Security hole, bug, CVE and attack surface

All four turn up in the same sentence in a lot of reports, and they are four different things.

The security hole is the defect: something somebody can use to do what they should not be able to.

A bug is a programming error. Every security hole is a defect, and not every defect is a hole: a button that renders wrong is a bug and changes nothing about security. The hole is the defect that also has consequences.

A CVE is the public identifier assigned to a specific defect in a specific product so that everybody is talking about the same one. It is a name, not a measurement: it does not say how much it matters to you. And the reverse holds too. Your own code has no identifier at all, so an organisation can have flawless patching and still be compromised through its own application. Counting identifiers does not measure risk.

The attack surface is not a list of holes: it is the list of places where a hole would count. It is bigger, and it changes every day.

In one sentence: the bug is the error, the hole is the error somebody can use, the CVE is its public name when it has one, and the attack surface is where it would matter.