Application security, defined precisely.

Penetration testing is an authorized attack on a system to find weaknesses and prove what an attacker could do with them.

Scope, access and permitted techniques are agreed in writing before testing starts. A useful report states what was tested, what was not, and the evidence behind each finding.

Vulnerability scanning is automated checking of systems for known weaknesses and misconfigurations, without proving that each result can be exploited.

Scanner output needs triage, because some results are false positives and flaws such as broken business logic have no signature to match.

Penetration Testing as a Service is a delivery model that runs scoped penetration tests, findings and remediation work through a platform.

Providers differ on how often they test, who reviews findings and what retests include.

Dynamic Application Security Testing tests a running application by sending inputs and observing how it behaves.

It generally needs no source code. Coverage depends on reachable routes, authentication, test configuration and the techniques the tool supports.

Static Application Security Testing analyzes source code for weaknesses without running the application.

Techniques include pattern, data-flow and control-flow analysis. Findings need contextual review, because static analysis alone cannot prove runtime exploitability.

Black-box testing is testing that starts without supplied login credentials, from what an attacker can discover and reach within the authorized scope.

Grey-box testing, by contrast, starts with supplied accounts to examine signed-in workflows.

Grey-box testing is testing with supplied accounts and context, to examine authenticated workflows and permission boundaries.

It reaches flaws only a signed-in user can trigger, such as one customer opening another customer's records. Black-box testing starts without credentials.

Internal and external describe where a target is reached from: external targets face the internet, and internal targets sit on a private network.

Location is separate from access mode, so an internal target can still be tested black-box, without login credentials.

Adversarial exposure validation uses attack techniques to test whether exposures can be exploited and whether security controls respond as intended.

A business logic flaw is a weakness that lets someone perform an operation the business rules should forbid, such as reusing a one-time discount.

Other examples include skipping payment or accepting an invalid transfer amount. Finding them needs an understanding of the intended workflow across steps, roles and state changes.

An exploit chain combines several weaknesses or attacker actions to reach an outcome that no single step achieves alone.

For example, an information leak may reveal identifiers that help exploit a separate authorization flaw. A report should rate the combined impact, not each step on its own.

Broken Object Level Authorization is a flaw where an application does not check whether a requester may access or change a specific object.

Insecure Direct Object Reference (IDOR) is a common form of it. Valid access depends on permissions, not necessarily ownership.

Insecure Direct Object Reference is a flaw where changing an identifier in a request, such as an order number, exposes another user's object.

It is a common form of Broken Object Level Authorization (BOLA), the broader term used in API security.

Common Vulnerabilities and Exposures is a public catalogue that gives each disclosed cybersecurity vulnerability an identifier and a description.

It is not a complete inventory of application weaknesses. Testing can find vulnerabilities, such as business logic flaws, that have no CVE.

Virtual patching is a protective rule, such as a traffic filter or middleware rule, that reduces exploitation of a vulnerability until the code is fixed.

A good virtual patch is tested for coverage, bypasses and its effect on legitimate traffic. It does not replace the code fix.

An exposure window is the period during which a vulnerable system can be reached by an attacker.

Reports should state the start and end points used, such as discovery to mitigation or discovery to verified fix.

A retest checks whether a fix resolves a previously reported finding, by repeating the original evidence and relevant variations.

A mitigation that blocks one request does not prove the underlying code is fixed. Retest scope and terms are agreed for each engagement.

Audit-grade penetration testing is testing with a documented scope, method, reproducible evidence and professional review.

It is a descriptive term, not a formal certification or a guarantee of acceptance under a compliance framework.

The OWASP Top 10 is an awareness document listing the most critical security risk categories for web applications.

It is not a testing method. A thorough assessment follows a procedure such as the WSTG.

The Common Vulnerability Scoring System is a FIRST standard that rates a vulnerability's technical severity on a scale from 0 to 10.

A base score leaves out your business context, so a report should explain how each severity was decided.

CREST is a cybersecurity industry body that offers company accreditation and individual professional certifications.

A company's accreditation and an individual tester's certification are separate credentials, with different requirements.

The OWASP Web Security Testing Guide is OWASP's detailed methodology for testing web application security.

Where the OWASP Top 10 lists common risk categories, the WSTG is the procedural checklist a thorough assessment follows.

The Penetration Testing Execution Standard describes the seven phases of a penetration test, from pre-engagement interactions to reporting.

The phases are pre-engagement interactions, intelligence gathering, threat modeling, vulnerability analysis, exploitation, post-exploitation and reporting. Techniques are used only within the written authorization and rules of engagement.

A false positive is a reported security issue that is not valid in the stated context.

Reproduction, prerequisite checks and evidence review help catch these errors. Neither AI nor human review guarantees a zero false-positive rate.

A Generative Counter Exploit is a targeted Defend middleware rule generated from the evidence of an approved, supported finding.

Rules run in the Node.js SDK. They start in log-only mode and block only once your team turns on enforcement. A rule can allow or block a request, add a response header, or rewrite or mask the response; it does not rewrite the request. Rules cannot see sessions or the database, so ownership findings are logged, never blocked.

The kernel-level context driver is ManticoreAI's monitor of process activity on its own attack machines. It tells the AI when a tool is waiting for input, has opened a connection or has started a process, so the AI can drive interactive tools such as Burp, SQLMap and Metasploit instead of wrapping them in scripts.

It runs on ManticoreAI infrastructure, not yours. Internal testing may need the connector, and Defend needs its SDK; both are agreed during scoping.

Auditor, not Author is ManticoreAI's review model: AI writes each Assess finding, and a named consultant audits and approves it before you can see it.

The approval gate is enforced in the database, so an unapproved finding cannot enter a report or drive a Defend rule. Continuous (developer preview) findings do not go through consultant review.

ShieldProbe is ManticoreAI's offensive security platform, with four modules: Assess, Defend, Fix and Continuous.

Assess proves what an attacker can do, Defend can protect supported findings while the code is fixed, and Fix proposes the code change.

Assess is ShieldProbe's penetration testing module for web apps, APIs, networks and servers, with a named consultant approving each finding.

Black-box testing covers all of them; grey-box testing covers web apps and APIs only. Internal or external targets are tested within the agreed scope.

Defend is ShieldProbe's Node.js middleware that runs GCEs generated from approved, supported findings inside your application.

It starts in log-only mode and blocks only once your team turns on enforcement. Ownership findings are logged, never blocked.

Fix is ShieldProbe's remediation module: it drafts a patch for a finding in VS Code or Visual Studio (beta).

A developer reviews the patch and raises the pull request. Nothing merges automatically.

Continuous is ShieldProbe's developer preview that runs selected tests on the repository events you enable.

Its findings do not go through consultant review.