Security testing glossary

An attack path is the sequence of steps an attacker could take, often chaining several small weaknesses, to get from an initial foothold to something valuable such as customer data or admin access.

Scanners report findings one at a time, but real breaches rarely depend on a single flaw. A low-severity information leak plus a weak password reset plus an overly broad role can add up to a full account takeover. Thinking in attack paths helps a buyer understand which fixes break the most chains, so remediation effort goes where it removes the most real risk rather than where the individual scores look highest.

Guide: What is a penetration test?See also: Attack surface, Lateral movement, Privilege escalation, Penetration test

An organization's attack surface is the full set of systems, applications, APIs, identities and data an attacker could reach or try to abuse, from the internet or from inside the network.

Attack surfaces grow quietly: a forgotten staging server, a new SaaS integration, a test API left public. You cannot defend what you do not know exists, so the first stage of most good security tests is mapping what an attacker can actually see. For a buyer, an accurate inventory is also what makes scoping a test realistic, since anything left off the list goes untested.

Guide: How to prepare for a penetration testSee also: External attack surface management, Attack path, Scope

An authentication bypass is a flaw that lets someone access a system or account without supplying valid credentials, for example by skipping a login step or abusing a broken session or reset flow.

Authentication is the front door, so a bypass is usually treated as critical: it can expose every account it touches. Causes include logic errors in multi-step logins, predictable or reusable reset tokens, missing checks on alternative endpoints such as mobile APIs, and misconfigured single sign-on. These flaws are hard for automated scanners to spot because they depend on how the application is supposed to behave, which is why manual testing of login, reset and session handling matters.

Guide: What is a penetration test?See also: Broken access control, MFA, Privilege escalation

Black-box testing is a security test where the testers start with no inside knowledge, credentials or source code, approaching the target the way an outside attacker would.

Black-box tests answer the question of what an unauthenticated stranger can do. They are realistic for internet-facing exposure, but much of the engagement time goes to discovery, and areas behind login may get little coverage. Many buyers get more value per day from a gray-box test that supplies accounts, keeping a black-box component for the external perimeter.

Guide: Black box vs gray box vs white box penetration testingSee also: Gray-box testing, White-box testing, Scope

The blue team is the group responsible for defending an organization: monitoring, detecting and responding to attacks, and hardening systems so they are harder to compromise.

In an exercise, the blue team is measured on whether it notices and contains the simulated attacker. Day to day, it is whoever owns detection, patching and configuration, which in a small company may be one engineer or an outside provider. Offensive testing is most useful when its findings flow straight to the blue team with enough evidence and fix detail to act on quickly.

See also: Red team, Purple team, Remediation

Broken Object Level Authorization (BOLA) is an API flaw where the server does not check that the caller is allowed to access the specific object, such as a record or file, named in the request.

BOLA is ranked first (API1:2023) in the OWASP API Security Top 10. It is the API-focused name for the same idea as IDOR, and it is common because every endpoint that takes an object ID needs its own ownership check. A single missed check can let one customer read or change another customer's data. Testing for it requires at least two accounts and an understanding of which data should belong to whom.

Guide: Black box vs gray box vs white box penetration testingSee also: IDOR, Broken access control, OWASP API Security Top 10

Broken access control is any failure to enforce what an authenticated or anonymous user is allowed to see or do, letting them reach data or actions outside their intended permissions.

It is ranked A01 in the OWASP Top 10:2025, the same position it held in 2021, and the 2025 edition also folds server-side request forgery into this category. Examples include viewing other users' records, calling admin functions from a normal account, or editing data by changing an ID. Because the rules are specific to each business, these flaws are mostly found by people testing with several roles, not by generic scanners.

Guide: What is a penetration test?See also: IDOR, BOLA, Privilege escalation, OWASP Top 10

A bug bounty is a program in which an organization invites independent security researchers to find and report vulnerabilities in defined systems, paying rewards for valid, in-scope findings.

Bounties bring many different perspectives and pay only for results, but coverage is uneven: researchers pick what interests them, and nothing guarantees a given feature gets tested. They also require a team ready to triage reports. Many organizations use a bounty alongside scheduled penetration testing rather than instead of it, and start with a simple disclosure policy before offering rewards.

Guide: Responsible disclosure and bug bounties: how they work and how to set one upSee also: Coordinated vulnerability disclosure, security.txt, Penetration test

The CISA Known Exploited Vulnerabilities (KEV) catalog is a public list, maintained by the US Cybersecurity and Infrastructure Security Agency, of CVEs with reliable evidence of active exploitation.

CISA started the catalog in 2021 under Binding Operational Directive 22-01, which sets remediation deadlines for US federal civilian agencies. Everyone else can use it as a free prioritization signal: if a vulnerability in your environment is on the KEV list, attackers are already using it, which matters more than a severity score alone. It pairs well with EPSS for deciding what to patch first.

See also: CVE, EPSS, CVSS, Remediation

Continuous penetration testing is ongoing offensive testing that keeps attacking systems as they change, instead of testing once a year and leaving long gaps between point-in-time snapshots.

Modern teams ship changes weekly or daily, so an annual test can be outdated within a month. Continuous testing aims to catch new exposure soon after it appears and to re-check fixes automatically. It does not remove the need for human judgment, and some compliance programs still expect a formal periodic report. See how Brexa approaches it on the continuous testing page.

Guide: Continuous penetration testing: what it is and when it is worth itSee also: PTaaS, Penetration test, Retest, External attack surface management

Coordinated vulnerability disclosure (CVD) is the practice of a finder privately reporting a vulnerability to the affected vendor and agreeing on timing before any public details are released.

CVD gives the vendor time to fix the issue before attackers learn about it, while still informing users eventually. International standards ISO/IEC 29147 (disclosure) and ISO/IEC 30111 (handling) describe how vendors should receive and process reports. For any company, publishing a clear disclosure policy and a security.txt file makes it easy for well-meaning researchers to reach the right people.

Guide: Responsible disclosure and bug bounties: how they work and how to set one upSee also: Bug bounty, security.txt, Zero-day

Cross-site scripting (XSS) is a web vulnerability where an application includes untrusted input in a page without proper encoding, letting an attacker's script run in other users' browsers.

A script running in a victim's browser acts as that user: it can read what they see, perform actions in their session, or alter the page. In the OWASP Top 10:2025 it falls under A05 Injection. Modern frameworks encode output by default, so XSS today often appears where developers bypass those defaults, render rich content, or build HTML by hand. Output encoding and a strong Content Security Policy are the main defenses.

See also: SQL injection, OWASP Top 10, DAST

A CVE is a unique public identifier, such as CVE-2024-12345, assigned to a specific publicly disclosed vulnerability so that vendors, tools and defenders can all refer to the same issue.

The CVE Program is operated by MITRE with sponsorship from CISA, and IDs are issued by many authorized CVE Numbering Authorities. A CVE describes a flaw in a particular product, while a CWE describes the general type of weakness. Penetration test findings in your own custom code usually have no CVE, which is one reason scanner output and pentest output look so different.

See also: CWE, CVSS, CISA KEV, EPSS

CVSS is an open standard maintained by FIRST for rating the technical severity of a vulnerability on a 0 to 10 scale; the current version, CVSS v4.0, was published in November 2023.

A CVSS score describes how bad a flaw is in general, not how risky it is in your environment. Version 3.1 scores are still common in vulnerability databases alongside v4.0. Treat the number as one input: whether the flaw is reachable, already exploited (CISA KEV), likely to be exploited (EPSS), and what data it exposes usually matter more when deciding what to fix first.

Guide: How to read a penetration test reportSee also: CVE, EPSS, CISA KEV, Remediation

CWE is a community-developed catalog, maintained by MITRE, of common types of software and hardware weaknesses, such as CWE-89 for SQL injection, used to classify the root cause of vulnerabilities.

Where a CVE names one specific bug, a CWE names the category of mistake behind it. Good penetration test reports often tag findings with CWE IDs, which helps engineering teams spot patterns, for example several findings sharing the same missing authorization check, and fix the underlying habit rather than one symptom at a time.

Guide: How to read a penetration test reportSee also: CVE, Vulnerability, OWASP Top 10

Dynamic Application Security Testing (DAST) is automated testing that probes a running application from the outside, sending requests and analyzing responses to detect vulnerabilities.

DAST tools are good at broad, repeatable checks for known patterns such as missing security headers or simple injection points, and they fit well in a delivery pipeline. They struggle with business logic, multi-step flows and authorization between users, which is where manual penetration testing adds the most. Many teams run DAST continuously and commission human testing for depth.

Guide: Penetration testing vs vulnerability scanningSee also: SAST, Vulnerability scanner, Penetration test

EPSS is a free, data-driven model from FIRST that estimates the probability a published CVE will be exploited in the wild within the next 30 days; version 4 was released in March 2025.

Most vulnerabilities with high CVSS scores are never exploited, so patching by severity alone spreads effort thin. EPSS scores are updated daily and help teams focus on the small share of issues attackers are actually likely to use. It applies only to CVEs, so it says nothing about flaws in your own custom code, which is what penetration testing tends to find.

See also: CVSS, CISA KEV, CVE

An exploit is a technique or piece of code that takes advantage of a vulnerability to make a system do something its owners did not intend, such as reveal data or grant access.

The difference between a vulnerability and an exploitable vulnerability is the difference between a theoretical issue and a real one. A key value of penetration testing is demonstrating, safely and within agreed rules, that a weakness can actually be exploited, which gives engineering teams confidence that a finding is worth fixing and helps leadership prioritize.

Guide: What is a penetration test?See also: Vulnerability, Proof of concept, Zero-day

External attack surface management (EASM) is the continuous discovery and monitoring of an organization's internet-facing assets, such as domains, IPs, cloud services and exposed applications.

EASM answers what you have exposed, often surfacing assets that no one remembered, like old marketing sites or forgotten test environments. It usually stops at identifying and flagging exposure rather than proving what an attacker could do with it. Pairing it with penetration testing turns a list of assets into a list of proven risks.

Guide: Continuous penetration testing: what it is and when it is worth itSee also: Attack surface, Continuous penetration testing, Vulnerability scanner

A false positive is a reported vulnerability that, on investigation, is not real or not exploitable in that environment, for example a scanner flagging a version number that has already been patched.

False positives cost engineering time and erode trust in security reports, and automated scanners produce them regularly. One of the clearest differences between a scan and a penetration test is that testers are expected to validate findings by hand before reporting them. When comparing providers, ask how findings are verified and whether unproven issues are labeled as such.

Guide: Penetration testing vs vulnerability scanningSee also: Vulnerability scanner, Proof of concept, Penetration test

Gray-box testing is a security test where testers receive partial inside knowledge, typically user accounts, API documentation or architecture notes, but not full source code.

Gray-box is the most common choice for web applications and APIs because it balances realism and efficiency. Supplying accounts at different permission levels lets testers spend their time on authorization, business logic and data exposure instead of guessing how to log in. It reflects a realistic threat too: a malicious customer or a stolen account already has that level of access.

Guide: Black box vs gray box vs white box penetration testingSee also: Black-box testing, White-box testing, Scope

An Insecure Direct Object Reference (IDOR) is an access control flaw where changing an identifier in a request, such as an invoice number, returns another user's data because ownership is not checked.

IDOR is one of the most common ways customer data leaks from web applications, and it often looks harmless in code review because each request appears valid. Hard-to-guess IDs reduce the risk but do not fix it; the real fix is a server-side check that the caller owns or may access the object. In APIs the same issue is called BOLA.

See also: BOLA, Broken access control, Gray-box testing

ISO/IEC 27001 is the international standard for an information security management system (ISMS); the current edition is ISO/IEC 27001:2022, which organizations can be certified against by accredited auditors.

The standard asks you to identify risks and choose controls from Annex A, including technical vulnerability management, but it does not prescribe a penetration test by name. In practice many organizations use pentests as evidence that controls work, and auditors often expect some form of technical testing. The scope and frequency should follow your own risk assessment. Read more in penetration testing for compliance.

Guide: Penetration testing for compliance: what PCI DSS, SOC 2, ISO 27001 and HIPAA actually requireSee also: SOC 2, PCI DSS, Penetration test

Lateral movement is how an attacker who has compromised one system or account moves on to others in the same environment, looking for more access and more valuable targets.

Initial access is often low value on its own, such as one employee laptop or one service account. Damage grows when an attacker can pivot from there using shared credentials, flat networks or trust relationships between systems. Internal network and cloud testing measure how far that pivot can go, and fixes usually involve segmentation, unique credentials and least privilege.

Guide: What is a penetration test?See also: Privilege escalation, Attack path, Least privilege

Least privilege is the security principle that every user, service and system should have only the minimum access needed to do its job, and nothing more.

Excess permissions turn small incidents into large ones: a leaked key with read access to one bucket is a minor issue, while the same key with admin rights is a breach. Applying least privilege limits how far an attacker can get after any single compromise. Cloud and identity testing frequently find over-broad roles, unused admin accounts and long-lived tokens that quietly violate it.

See also: Privilege escalation, Lateral movement, MFA

Mean time to remediate (MTTR) is the average time between a vulnerability being identified and it being fixed and verified, often tracked separately for each severity level.

Finding vulnerabilities only reduces risk once they are fixed, so MTTR is a useful measure of whether a security program actually works. Long remediation times usually point to unclear ownership, vague findings or competing priorities rather than technical difficulty. Clear fix steps, a named owner per finding and a fast retest are the practical ways to bring it down.

Guide: Retesting and fix verificationSee also: Remediation, Retest, Vulnerability

Multi-factor authentication (MFA) requires a user to prove identity with two or more independent factors, such as a password plus a hardware key or authenticator app, before access is granted.

MFA blocks most attacks that rely on stolen passwords, but not all MFA is equal. CISA recommends phishing-resistant methods such as FIDO2 security keys and passkeys, because codes sent by text message or push prompts can be phished or approved by mistake. Identity testing checks not only whether MFA is enabled, but whether there are legacy logins, recovery flows or service accounts that skip it.

See also: Authentication bypass, Least privilege, Social engineering

A mitigation is a measure that reduces the likelihood or impact of a vulnerability being exploited without removing the underlying flaw, such as a firewall rule, feature flag or extra monitoring.

Mitigations buy time when a full fix is slow, for example when a vendor patch is not available yet or a code change needs a release cycle. They are valuable but should be tracked as temporary, because the root cause remains. A good report distinguishes the permanent fix from interim mitigations, and a retest should confirm the mitigation actually blocks the attack.

Guide: Retesting and fix verificationSee also: Remediation, Retest, Vulnerability

The OWASP API Security Top 10 is an awareness list from the Open Worldwide Application Security Project of the most critical API security risks; the current edition was published in 2023.

APIs have their own failure patterns, so OWASP keeps this list separate from the main web Top 10. The 2023 edition ranks Broken Object Level Authorization first and includes broken authentication, unrestricted resource consumption and server-side request forgery. It is a useful checklist when scoping API penetration testing, though a thorough test goes beyond any list.

See also: BOLA, OWASP Top 10, SSRF

The OWASP Top 10 is a widely used awareness document from the Open Worldwide Application Security Project listing the most critical web application security risks; the current edition is the OWASP Top 10:2025.

The 2025 edition keeps Broken Access Control at A01, moves Security Misconfiguration to A02, and adds Software Supply Chain Failures and Mishandling of Exceptional Conditions. It is a starting point, not a complete testing standard: passing an OWASP Top 10 checklist does not mean an application is secure. Many buyers use it to confirm a web test covers the basics.

Guide: What is a penetration test?See also: Broken access control, Security misconfiguration, OWASP API Security Top 10, CWE

PCI DSS is the security standard from the PCI Security Standards Council for organizations that store, process or transmit payment card data; the current version is PCI DSS v4.0.1.

Unlike SOC 2 or ISO 27001, PCI DSS explicitly requires penetration testing. Requirement 11.4 calls for internal and external testing at least once every 12 months and after significant changes, plus verification that segmentation controls work. It also requires regular vulnerability scans. The scope depends on how card data flows through your systems, so reducing that footprint can shrink what must be tested.

Guide: Penetration testing for compliance: what PCI DSS, SOC 2, ISO 27001 and HIPAA actually requireSee also: SOC 2, ISO/IEC 27001, Penetration test, Scope

A penetration test is an authorized, simulated attack on an organization's systems by security testers who try to find and safely exploit vulnerabilities, proving which ones pose real risk.

A pentest goes further than a scan: testers chain weaknesses, test business logic and confirm impact by hand, then report findings with evidence and fix guidance. It is always bounded by a signed scope and rules of engagement. Buyers commission one for a launch, a customer security review, compliance, or simply to learn where they are exposed before an attacker does.

Guide: What is a penetration test?See also: Vulnerability assessment, Red team, Rules of engagement, Retest

Privilege escalation is when an attacker with limited access gains higher permissions, such as a normal user becoming an administrator or a web process gaining control of the underlying server.

Escalation can be vertical (gaining a more powerful role) or horizontal (gaining another user's access at the same level). It is often the step that turns a modest finding into a serious one. Testing with several account roles is the most reliable way to find these paths in applications, while cloud and internal tests look for misconfigured roles, permissions and services.

See also: Lateral movement, Broken access control, Least privilege

A proof of concept (PoC) is a minimal, controlled demonstration that a vulnerability is real and exploitable, showing impact without causing damage.

A clear PoC is what separates a confirmed finding from a theoretical one. In a penetration test report it usually takes the form of evidence such as screenshots, request and response records, or a short description of the reproduced steps, enough for engineers to verify the issue and later confirm the fix. It removes debate about whether a finding matters.

Guide: How to read a penetration test reportSee also: Exploit, False positive, Retest

Penetration Testing as a Service (PTaaS) is a delivery model that combines penetration testing with a software platform for scheduling tests, viewing findings in real time and tracking remediation.

PTaaS replaces the static PDF with a live view of findings, often with integrations into ticketing tools and on-demand retests. The underlying testing quality still depends on the people and methods behind the platform, so buyers should look past the dashboard at how findings are proven and how deep testing goes. It is closely related to continuous penetration testing.

Guide: How to choose a penetration testing companySee also: Continuous penetration testing, Penetration test, Retest

Purple teaming is a collaborative exercise in which offensive (red) and defensive (blue) teams work together, running attacks and immediately tuning detections and controls in response.

Instead of a red team staying hidden and reporting at the end, a purple exercise is open: each technique is run, the defenders check whether they saw it, and gaps are fixed on the spot. It is an efficient way to improve detection and response, and suits organizations that already have monitoring in place and want to know whether it works.

See also: Red team, Blue team, Penetration test

A red team engagement is an objective-based simulation of a real adversary, testing whether an organization's people, processes and defenses can detect and stop a determined attack.

Where a penetration test tries to find as many vulnerabilities as possible in a defined scope, a red team pursues a goal, such as reaching a specific dataset, often using stealth and multiple techniques. It is most useful for mature organizations with a defensive team to test. Companies earlier in their program usually get more value from penetration testing first.

Guide: What is a penetration test?See also: Blue team, Purple team, Penetration test, Social engineering

Remediation is the work of fixing a vulnerability at its root cause, such as patching software, correcting code or changing a configuration, so the weakness no longer exists.

Remediation is where security testing pays off, and it is often the slowest part. It goes faster when each finding has a clear owner, a plain-language explanation of the risk and specific fix steps for the technology involved. A remediation is only complete once a retest confirms the original attack no longer works, since partial or incorrect fixes are common.

Guide: Retesting and fix verificationSee also: Mitigation, Retest, Mean time to remediate

A retest is a follow-up check, after a fix is deployed, that repeats the original attack to confirm the vulnerability is actually closed and that the fix did not introduce new problems.

Fixes often address the exact example in a report while leaving a sibling endpoint or parameter vulnerable. A retest closes that gap and gives you evidence for auditors and customers that issues were resolved. When buying a test, check whether retesting is included, how long the window is and whether retest results appear in an updated report.

Guide: Retesting and fix verificationSee also: Remediation, Mitigation, Mean time to remediate

Rules of engagement (RoE) are the agreed, signed terms that govern a security test: what may be tested, when, with which techniques, what is off limits and how to communicate and stop if needed.

The RoE turns testing from an attack into an authorized engagement. It typically covers testing windows, prohibited actions such as denial of service, how sensitive data is handled, emergency contacts and what happens if a critical issue is found mid-test. A clear RoE protects both sides and is the first document to ask a provider for.

Guide: Rules of engagement for penetration testingSee also: Scope, Penetration test, Red team

Static Application Security Testing (SAST) is automated analysis of source code, bytecode or binaries to find security weaknesses without running the application.

SAST runs early, often on every pull request, and points directly to the line of code involved, which makes fixes cheap. Its weaknesses are noise and blind spots: it can flag code that is not reachable and miss issues that depend on configuration or runtime behavior. It complements DAST and manual testing rather than replacing them.

Guide: Penetration testing vs vulnerability scanningSee also: DAST, White-box testing, Secrets exposure

The scope of a security test is the documented list of systems, applications, environments and accounts the testers are authorized to test, along with anything explicitly excluded.

Scope drives both cost and value. Too narrow and important exposure goes untested; too broad and effort is spread thin. A good scope names specific domains, IP ranges, applications and user roles, and says whether production or staging is in play. Anything outside it must not be touched, which is why accurate asset inventory before a test matters so much.

Guide: How to prepare for a penetration testSee also: Rules of engagement, Attack surface, Penetration test

Secrets exposure is when credentials such as API keys, passwords, tokens or private keys end up somewhere an attacker can find them, like a public repository, client-side code, logs or a misconfigured bucket.

A single leaked cloud or payment key can give direct access without exploiting any code at all, which makes this one of the highest-impact and most preventable issues. Deleting a secret from code is not enough, because history and copies persist. The fix is to rotate the exposed secret, move secrets into a dedicated manager and add scanning to catch future leaks.

See also: Security misconfiguration, SAST, Least privilege

Security misconfiguration is a weakness caused by insecure settings rather than faulty code, such as default passwords, public storage, verbose error messages or unnecessary services left enabled.

It ranks A02 in the OWASP Top 10:2025, reflecting how much of modern risk now lives in configuration of cloud services, containers and third-party platforms. These issues are easy to introduce and easy to miss, because each setting may be changed by a different person or tool. Configuration baselines, infrastructure as code reviews and periodic cloud testing help keep them in check.

See also: OWASP Top 10, Secrets exposure, Attack surface

security.txt is a small text file, standardized in RFC 9116, published at /.well-known/security.txt that tells security researchers how to report vulnerabilities to an organization.

The file must include at least a Contact field and an Expires date, and can point to a disclosure policy, encryption key and acknowledgments page. It costs minutes to set up and removes the most common obstacle in coordinated disclosure: a researcher not knowing who to tell. It is a sensible first step before considering a bug bounty.

Guide: Responsible disclosure and bug bounties: how they work and how to set one upSee also: Coordinated vulnerability disclosure, Bug bounty

SOC 2 is an attestation report, defined by the AICPA, in which an independent auditor evaluates a service organization's controls against the Trust Services Criteria, such as security and availability.

SOC 2 does not strictly require a penetration test, but its criteria call for identifying and evaluating vulnerabilities, and many auditors and customers expect a recent pentest as supporting evidence. A Type II report covers how controls operated over a period of time. For many software companies selling to larger customers, SOC 2 is the main trigger for a first test. See penetration testing for compliance.

Guide: Penetration testing for compliance: what PCI DSS, SOC 2, ISO 27001 and HIPAA actually requireSee also: ISO/IEC 27001, PCI DSS, Penetration test

Social engineering is manipulating people, through phishing emails, phone calls or impersonation, into revealing information, approving access or taking actions that weaken security.

Many breaches start with a person rather than a technical flaw, which is why some engagements include authorized phishing simulations or help desk impersonation tests. The goal is to improve processes, such as identity checks for password resets and phishing-resistant MFA, not to blame individuals. These tests require especially clear rules of engagement and leadership sign-off.

See also: MFA, Red team, Rules of engagement

SQL injection is a vulnerability where untrusted input is placed into a database query in a way that lets an attacker change the query's meaning, potentially reading or altering data.

It is one of the oldest web vulnerabilities and falls under A05 Injection in the OWASP Top 10:2025. Parameterized queries and safe ORM usage prevent it reliably, so it now tends to appear in raw queries, reporting features, search filters and legacy code. Because a single instance can expose an entire database, it remains a priority finding whenever it appears.

See also: Cross-site scripting, OWASP Top 10, DAST, CWE

Server-side request forgery (SSRF) is a flaw where an attacker can make a server send requests to destinations of the attacker's choosing, often internal systems the attacker cannot reach directly.

Features that fetch a URL, such as link previews, webhooks or file imports, are common sources. In cloud environments SSRF can reach internal metadata services or admin interfaces, which is why it can be severe. The OWASP Top 10:2025 folds it into Broken Access Control, and the OWASP API Security Top 10 2023 lists it as API7. Allowlisting destinations and restricting network egress are typical fixes.

See also: Broken access control, OWASP API Security Top 10, Security misconfiguration

A threat model is a structured description of what a system does, what is worth protecting, who might attack it and how, used to decide which security controls and tests matter most.

Threat modeling answers four simple questions: what are we building, what can go wrong, what are we doing about it, and did we do a good job. Even a lightweight version helps a buyer scope a test well, by pointing testers at the most sensitive data flows and roles instead of spreading effort evenly. Sharing it with testers usually improves results.

Guide: How to prepare for a penetration testSee also: Attack surface, Scope, Attack path

A vulnerability is a weakness in software, configuration or process that an attacker could use to compromise the confidentiality, integrity or availability of a system or its data.

Not every vulnerability is equally important. Its real risk depends on whether it is reachable, how easily it can be exploited and what it exposes. That is why the same issue might be critical in one company and minor in another, and why good testing explains the business impact of each finding, not just its technical severity.

Guide: How to read a penetration test reportSee also: Exploit, CVE, CWE, CVSS

A vulnerability assessment is a structured review that identifies, validates and prioritizes security weaknesses in defined systems, giving an organization a clear list of what to fix first.

Assessments range from largely automated scanning to expert-led reviews where each finding is confirmed by hand. Compared with a full penetration test, the emphasis is usually on breadth and prioritization rather than chaining issues to show maximum impact, though the line between the two varies by provider. Ask exactly what is validated manually. Brexa offers a one-time vulnerability assessment.

Guide: Vulnerability assessment vs penetration testSee also: Penetration test, Vulnerability scanner, Remediation

A vulnerability scanner is an automated tool that checks systems or applications against a database of known issues, such as outdated software versions and common misconfigurations, and reports matches.

Scanners are fast, cheap to run often and good at catching known, well-documented problems across many assets. They produce false positives, cannot judge business logic or authorization between users, and do not prove impact. Most organizations benefit from running scanners continuously and using penetration testing to cover what scanners cannot. PCI DSS, for example, requires both.

Guide: Penetration testing vs vulnerability scanningSee also: DAST, False positive, Penetration test

White-box testing is a security test where testers have full inside knowledge, including source code, architecture documents and configuration, alongside access to the running system.

With code access, testers can trace exactly how input flows and find issues that would take far longer to discover from outside, such as subtle authorization gaps or unsafe use of cryptography. It gives the deepest coverage per day and is well suited to critical applications, though it requires sharing sensitive material under clear agreements.

Guide: Black box vs gray box vs white box penetration testingSee also: Gray-box testing, Black-box testing, SAST

A zero-day is a vulnerability that is unknown to the vendor or has no available fix at the time it is discovered or exploited, leaving defenders zero days of warning.

Zero-days get headlines, but most breaches use known, unpatched vulnerabilities or simple misconfigurations. For most companies, fast patching, least privilege and good detection do more than worrying about zero-days specifically. Flaws found in your own custom code during a test are technically unknown issues too, which is why they are handled privately until fixed.

See also: Coordinated vulnerability disclosure, Exploit, CISA KEV