RedMaw vs vulnerability scanners
Keep the scanner. Add an adversary.
Vulnerability scanners provide systematic coverage. RedMaw adversarially tests supported systems to prove what an attacker can actually do and what they can reach.
Scanner
What weaknesses can we detect?
RedMaw
What can an attacker actually do?
Two different jobs
Both are worth doing. Neither substitutes for the other.
What a scanner does
Systematic detection and coverage.
Vulnerability scanners provide broad, repeatable coverage. They are useful for identifying known vulnerabilities, insecure configurations, exposed services and other detectable weaknesses across large environments. Keep them. They solve an important problem.
- Broad and repeatable across large estates
- Deterministic, so results are comparable over time
- Strong at known vulnerability classes and exposure
What RedMaw does
Adversarial discovery, validation and re-attack.
RedMaw starts from a different question: what can an attacker actually do? It adversarially tests supported applications, SaaS identities and AI systems, validates exploitable conditions, preserves evidence, prioritizes by impact and available reachability context, then re-attacks after remediation.
- Validates exploitability rather than reporting possibility
- Covers identity, SaaS and AI as first-class surfaces
- A finding does not need a CVE to matter
The shift
Known vulnerabilities are only part of the attack surface
A vulnerability does not become dangerous because somebody assigned it an identifier. It becomes dangerous because an attacker can use it.
AI-assisted security research is making that distinction harder to ignore. Anthropic runs a coordinated vulnerability disclosure programme for weaknesses Claude finds in widely used open-source software. Findings are triaged by external security firms, reported to maintainers, and only then do CVE and GitHub Security Advisory identifiers get assigned.
Read that ordering again, because it is the whole point. The weakness existed, and was findable, before it had an identifier. Anything relying on the catalogue was blind to it the entire time.
That does not make known-vulnerability data less useful. It makes it incomplete as a model of what an attacker knows.
The same principle applies well beyond software vulnerabilities. An attacker may:
- Exploit a broken authorization rule
- Reuse an exposed credential
- Abuse an OAuth grant that survives a password reset
- Reach data through an over-privileged SaaS identity
- Manipulate an AI system through prompt injection
None of those becomes important only once a vulnerability database names it.
What works against the environment that exists now?
The reframe
From known weakness to attacker outcome
Traditional vulnerability management naturally begins with the weakness. RedMaw begins with the attacker. The difference is subtle and it changes the output.
A scanner may tell you that a service, component or configuration deserves attention. RedMaw asks whether a supported weakness or security condition can be used, what consequence it creates, and whether the exposure remains after remediation.
Discover → Attack → Prove → Prioritize → Remediate → Re-attack
The goal is not a longer vulnerability list. It is a defensible answer to one question: what can an attacker actually reach?
Fairness
A CVE is useful. It is not a security boundary.
Known-vulnerability databases are one of the most useful coordination mechanisms in security. They let vendors, security teams and tooling providers share a common understanding of disclosed software weaknesses.
That system is not the problem. Treating it as the edge of the attack surface is.
Some exploitable conditions have no CVE because they are not conventional software vulnerabilities. Some have no CVE because nobody has found them yet. Some emerge only from how identities, permissions, applications, APIs and AI systems interact in one specific environment.
The attacker does not care which category a weakness belongs to. The security program eventually has to answer whether it works.
Side by side
Where the two models differ
Written to be fair to the alternative. A scanner is strong at the job it was built for.
| Dimension | Vulnerability scanner | RedMaw |
|---|---|---|
| Primary question | What weaknesses can we detect? | What can an attacker actually do? |
| Operating model | Systematic detection and coverage across defined assets. | Adversarial discovery and validation inside explicitly authorized scope. |
| Known vulnerabilities | Strong coverage of known vulnerability classes, exposed software and repeatable checks. | Known vulnerabilities can be tested, but CVE identity is not the boundary of the security model. |
| Contextual weaknesses | Coverage varies by product and test type. | Tests exploitable behavior such as authorization failures, business-logic abuse, exposed credentials, identity reachability and supported AI security failures. |
| SaaS and identity | Usually handled by separate identity, posture or SaaS security tooling. | A core RedMaw surface: roles, OAuth relationships, permissions, sharing, credentials and customer-controlled posture. |
| AI systems | Usually outside the core job of a traditional vulnerability scanner. | A core RedMaw surface, including prompt injection, disclosure, jailbreak and release-gate security testing. |
| Exploitability | A detected weakness may remain a possible security issue until further validation. | Validated exploitation and reproducible evidence are central to the product. |
| Prioritization | Typically driven by severity, asset context and scanner-specific risk signals. | Driven by validated impact and available attacker-reachability context, not severity alone. |
| Remediation | Usually reports the weakness and tracks whether it is no longer detected. | Keeps the finding as security state, routes work into existing tools and re-attacks the relevant condition after remediation. |
| Definition of fixed | Depends on the scanner and workflow. | The original security condition is tested again. Closure follows proof. |
Use both.
Coverage and adversarial validation solve different problems. Removing either one makes the program weaker.
Keep a vulnerability scanner for broad, deterministic coverage and hygiene. Add RedMaw when you need to know which weaknesses are actually exploitable, what attacker-relevant outcome they create, whether identities, SaaS permissions or AI systems introduce exposure outside the scanner's core model, and whether remediation survives the same adversarial test.
Questions
What buyers ask about the distinction
- Is RedMaw a vulnerability scanner?
- No. Vulnerability scanning is useful, but it is not the RedMaw category. RedMaw is an autonomous adversarial security platform. Its job is to test supported systems adversarially, validate exploitable conditions and prove what an attacker can actually reach.
- Does RedMaw only validate vulnerabilities a scanner already found?
- No. Scanner findings can be useful input, but RedMaw is not limited to them. Many attacker-relevant conditions are contextual rather than CVE-driven: broken authorization, business-logic abuse, exposed secrets, OAuth grants, over-broad SaaS permissions and AI security failures can all matter without a CVE being the defining object.
- Does RedMaw find zero-days?
- Not in the sense that phrase usually implies. RedMaw is not a source-code analysis engine. What it does do is surface and validate exploitable behavior that no CVE represents: in deployed applications and APIs, in identities and SaaS configuration, and in AI systems. Whether a weakness has an identifier is a different question from whether it works.
- Why not just improve our scanner coverage?
- More coverage is useful, but it answers a different question. A larger inventory of possible weaknesses still leaves the team deciding what is genuinely exploitable and what the attacker can reach. RedMaw adds that adversarial layer.
- Should we replace our vulnerability scanner with RedMaw?
- No. Keep the scanner for broad deterministic coverage. RedMaw is the adversarial validation layer that tests where possibility becomes attacker-relevant reality.
- What changes when AI can discover vulnerabilities that were never catalogued?
- It weakens the assumption that defenders can wait for every important weakness to become a known identifier before it matters. The defensive question has to expand from “are we patched against what is known?” to “what can an adversary discover and exploit in what we run today?” RedMaw is built around that second question.
Boundary
What RedMaw does not claim
A comparison page is the easiest place to overstate a product. These are the limits.
RedMaw is also not a reason to remove broad vulnerability scanning, and it does not replace a human red team. For especially novel work, top human expertise remains complementary.
Stop assuming you are secure. Prove it.
Keep the coverage you have. Add an adversary that tests whether any of it holds.