Attacks come from two directions. So do we.

DedSec Technologies LLP builds two security platforms. Maphra works from the outside in: it maps everything your organisation exposes to the internet and proves what an attacker could actually reach. AppSecD works from the inside out: it catches the vulnerability in the pull request, before it ever becomes exposure.

Pick the direction your risk comes from and walk the chain step by step — what the attacker does at each stage, and what stops them.

Maphra — Autonomous external attack surface management

See your organisation the way an attacker sees it.

Maphra discovers everything your organisation exposes to the internet, decides what actually matters, and proves exploitability — continuously, without an agent and without a credential.

Maphra is an autonomous External Attack Surface Management platform. It starts from nothing more than a domain name and works outward the way an attacker would: enumerating subdomains, resolving infrastructure, fingerprinting live services, and attributing each discovered asset back to the organisation that owns it. Discovered surface is then classified, analysed and prioritised, so a security team sees the handful of exposures that are genuinely reachable rather than an undifferentiated asset inventory. Maphra also watches the parts of the attack surface that sit outside the perimeter entirely — leaked credentials in breach corpora, look-alike domains, impersonating applications and brand abuse — because those are attack paths that no internal scanner can see. It runs continuously rather than as a quarterly exercise, and every finding carries the evidence that produced it.

From the outside in: What can an attacker reach without any credentials? Category: External Attack Surface Management (EASM). The platform runs at https://maphra.dedsecops.com.

What Maphra covers

• External Attack Surface Management — Continuous discovery and attribution of internet-facing assets — subdomains, hosts, services, certificates, cloud endpoints and the shadow IT nobody registered.
• Threat Intelligence Hub — Advisories, CVE feeds and exploit intelligence correlated against the assets you actually operate, so a CVE only raises an alarm when it touches your surface.
• Vulnerability Management — Findings deduplicated across scans, tracked through new / reopened / fixed, with ownership, ageing and SLA rather than a re-issued PDF.
• Breach & Brand Monitoring — Credential exposure in breach corpora, dark-web mentions, look-alike domains and impersonating apps — the attack paths that never touch your network.
• Comprehensive Security Analysis — TLS and certificate posture, security headers, DNS hygiene, email authentication and misconfiguration checks across every discovered asset.

The chain, step by step

1. Reconnaissance

   What happens: An attacker starts with your domain and no access. They enumerate subdomains, scrape certificate transparency logs and map your DNS to find everything you own — including the assets you forgot.

   How Maphra answers it: Maphra runs the same enumeration continuously and attributes each asset back to your organisation, so the forgotten staging host shows up on your inventory before it shows up on theirs. (Asset discovery & attribution)

2. Finding the way in

   What happens: They fingerprint live services looking for an unpatched version, an exposed admin panel, a stale TLS configuration or a subdomain pointing at a deprovisioned cloud bucket.

   How Maphra answers it: Every discovered asset is fingerprinted and checked for exposure: service versions, certificate and TLS posture, security headers, DNS hygiene and takeover-prone records. (Comprehensive security analysis)

3. Credentials without hacking

   What happens: Often there is no exploit at all. A staff password from an unrelated breach still works, or a look-alike domain harvests one from a customer.

   How Maphra answers it: Breach corpora are monitored for your domains, and brand monitoring watches for look-alike domains and impersonating applications targeting your users. (Breach & brand monitoring)

4. Proving it is real

   What happens: A scanner listing a theoretical CVE tells you nothing. The attacker only cares about what actually works against your specific deployment.

   How Maphra answers it: Active checks validate exploitability against the live asset within an explicit scope boundary, so a finding arrives with evidence rather than a severity guess. (Autonomous validation)

5. Deciding what to fix first

   What happens: A team drowning in ten thousand findings fixes the wrong ones, and the reachable critical stays open.

   How Maphra answers it: Findings are deduplicated, correlated with exploit intelligence and ranked by real reachability, then tracked to closure with ownership and SLA. (Vulnerability management)

Inside Maphra

• Discovery that keeps going — Attack surface is not a document you produce once a year. Maphra re-runs discovery on a schedule, diffs the result against the last known surface, and tells you what appeared, what changed and what quietly disappeared. Subdomain and host enumeration · Service and technology fingerprinting · Certificate transparency monitoring · Change detection between runs
• Exposure analysis with the evidence attached — Each asset is examined for the things that actually get organisations breached — expired or weak TLS, missing security headers, permissive DNS, exposed panels — and each finding carries the raw response that produced it. TLS and certificate posture · Security header analysis · DNS and email authentication · Evidence retained per finding
• Breach and dark-web exposure — Credentials leak in breaches that have nothing to do with you, and get reused against you. Maphra tracks your domains across breach corpora and surfaces the accounts that need a reset. Credential exposure by domain · Dark and deep web mentions · Alerting on new exposure
• Brand and impersonation monitoring — Look-alike domains and impersonating applications are an attack path against your customers that never touches your infrastructure. Maphra watches for both. Look-alike domain detection · Impersonating application discovery · Continuous brand surveillance
• Risk scoring you can defend — A score is only useful if you can explain it to an auditor. Risk is derived from the observed exposure and its reachability, and the inputs stay visible. Reachability-weighted scoring · Trend over time · Per-asset breakdown
• Reporting for the people who ask — Board, auditor and engineer need different things from the same data. Reports are generated from the same evidence projection rather than re-keyed. Scheduled and on-demand reports · Evidence-backed findings · Multiple audiences from one dataset

Maphra at a glance

Category

External Attack Surface Management

Deployment

Agentless — starts from a domain name

Cadence

Continuous, scheduled and on-demand

Access

No credentials into your estate required

Maphra questions

What does Maphra need to get started?

A domain name. Maphra works from the outside in, so it needs no agent, no credential into your estate and no network access. Discovery begins from public data the same way an attacker would begin.

How is Maphra different from a vulnerability scanner?

A scanner tests a list of assets you give it. Maphra finds the assets first — including the ones nobody remembered — attributes them to your organisation, then analyses them. The discovery step is the product.

Does Maphra attack our systems?

Active validation runs only inside an explicit scope boundary you define, and the scope gate prevents active checks from reaching third-party hosts that merely appear in your surface.

How does Maphra handle findings that are not real?

Every finding carries the evidence that produced it, and findings are deduplicated across scans and tracked through new, reopened and fixed states rather than re-reported each run.

Log in to Maphra · Full Maphra detail

AppSecD — AI-native application security across the whole development lifecycle

Catch it in the pull request, not in the breach report.

AppSecD runs SAST, DAST, SCA, secret detection, IaC, container, Kubernetes and API security from one platform — wired into Git, gated at the pull request, and managed through a real vulnerability lifecycle.

AppSecD is an enterprise application security platform that consolidates the scanning disciplines a security team would otherwise buy separately. Static analysis runs across more than twenty languages through a farm of over fifteen analyzers with Semgrep as the primary engine. Secret detection runs against both the working tree and the full git history, because a credential deleted in the latest commit is still in the repository. Software composition analysis covers the major package ecosystems and adds typosquat, malicious-package and provenance checks on top of conventional CVE matching. Dynamic testing brings a further one hundred and fifty native checks alongside Nuclei, Dalfox, SQLMap and out-of-band interaction testing. Findings are not dumped as raw scanner output: they are deduplicated across scans, tracked through a lifecycle with ageing, SLA, assignment and maker-checker approval, and enriched by an AI layer that triages false positives, proposes fixes and assembles attack chains. It integrates with GitHub and GitLab, gates pull requests by policy, and runs shift-left inside the developer IDE.

From the inside out: What are we shipping into production right now? Category: Application Security Posture Management (ASPM). The platform runs at https://appsecd.com.

What AppSecD covers

• Static analysis (SAST) — Semgrep as primary engine plus Bandit, gosec, ESLint security, Brakeman, PHPStan/Psalm and SpotBugs with FindSecBugs — 20+ languages against OWASP Top 10, CWE Top 25 and custom rule packs.
• Secrets across history — TruffleHog and Gitleaks, deduplicated, run over the working tree and the full git history — API keys, tokens, private keys, database and cloud credentials.
• Supply chain (SCA) — Trivy and OSV across npm, PyPI, Go, Maven, RubyGems, Cargo, Packagist and NuGet, with typosquat detection, malicious-package detection, provenance checking and CISA KEV correlation.
• Dynamic & API testing — Nuclei, Dalfox, SQLMap, Commix, Katana, Arjun, FFuf and Interactsh for out-of-band detection, plus 150+ native checks and API discovery across 50+ web frameworks.
• Infrastructure & containers — Terraform, CloudFormation, Helm, Ansible and Pulumi rules; Dockerfile hardening with image CVE scanning; Kubernetes RBAC, network policy and pod security context analysis.
• Vulnerability lifecycle — Deduplication across scans, new / reopened / fixed state, ageing and SLA, assignment, and maker-checker approval so a finding cannot be closed unilaterally.

The chain, step by step

1. Threat modelling

   What happens: Most breaches trace back to a design decision nobody reviewed — a trust boundary that was never drawn, an authorisation model assumed rather than specified.

   How AppSecD answers it: Threat modelling starts before the code exists: components, trust boundaries and data flows are mapped so the controls that matter are identified while they are still cheap to add. (Threat modelling)

2. Code and dependencies

   What happens: A developer writes a query that concatenates input, or pulls a package whose maintainer account was taken over last week.

   How AppSecD answers it: SAST across 20+ languages runs alongside SCA with typosquat, malicious-package and provenance checks — and secret detection reads the git history, not just the diff. (SAST · SCA · secrets)

3. The pull request gate

   What happens: Without a gate, the finding becomes a ticket, the ticket becomes a backlog item, and the backlog item ships.

   How AppSecD answers it: Policy-driven gating blocks the pull request or commit when it introduces a violation, so the fix happens while the author still has the context. (PR / commit gating)

4. Is it actually reachable?

   What happens: A team that treats every finding as equally urgent stops treating any of them as urgent.

   How AppSecD answers it: Dataflow taint analysis traces source to sink across functions, and CVE-reachability answers whether the vulnerable code path can be reached at all before anyone is paged. (Taint & reachability analysis)

5. Exploit chain assembly

   What happens: Individually a medium and a low look ignorable. Chained together they are a path from unauthenticated request to data.

   How AppSecD answers it: The AI layer assembles attack chains across findings, showing how separately-unremarkable issues combine — and what the business impact of the chain is. (AI attack-chain analysis)

6. Running application

   What happens: Code review cannot see a misconfigured production header, an exposed API route or an injection that only appears once the app is assembled and running.

   How AppSecD answers it: DAST and API-sweep test the deployed application: 150+ native checks with Nuclei, SQLMap and out-of-band interaction detection across 50+ frameworks. (DAST · API security)

7. Closing the loop

   What happens: A finding that is found, ignored, re-found and re-ignored is worse than one never found — it consumes attention and buys nothing.

   How AppSecD answers it: Findings deduplicate across scans, carry ageing and SLA, get assigned to an owner, and need maker-checker approval to close. Security champions get a dashboard that tracks it. (Lifecycle · champions)

Inside AppSecD

• One platform instead of seven tools — SAST, DAST, SCA, secrets, IaC, containers, Kubernetes and API security run from a single platform against a single finding model — so a vulnerability is deduplicated once and tracked once, no matter which engine found it. 15+ SAST analyzers, 20+ languages · 150+ native DAST checks · Secrets across full git history · One deduplicated finding model
• Security intelligence mapped to your estate — An advisory only matters if you run the affected package. Every advisory is correlated against the versions, manifests and repositories actually present in your software estate, with CISA KEV flagged. 18 advisory feeds · Package-to-repository correlation · CISA KEV highlighting · Blast-radius view per CVE
• Static analysis with reachability — Findings are ranked by whether the vulnerable path can actually be reached. Interprocedural taint analysis traces source to sink across function boundaries, and CVE-reachability answers the only question that matters. Taint analysis v1 and v2 · Interprocedural dataflow · CVE reachability · OWASP and CWE rule packs
• A real vulnerability lifecycle — Findings deduplicate across scans and move through new, reopened and fixed. They carry ageing and an SLA, they get assigned, and closing one requires maker-checker approval. Deduplication across scans · SLA and ageing · Assignment and ownership · Maker-checker approval
• Security champions, measured — Champion programmes fail when nobody can see whether they work. Teams get a posture leaderboard and per-team attribution, so improvement is visible rather than asserted. Team posture leaderboard · Per-team finding attribution · Clean-rate tracking · Champion enablement
• AI that triages instead of guessing — 27 configurable AI features handle the work that consumes analyst time: false-positive triage, fix suggestion, attack-chain assembly, business-impact assessment and report summarisation. False-positive triage · Fix suggestion in context · Attack chain assembly · Business impact assessment

AppSecD at a glance

Category

Application Security Posture Management

Integrations

GitHub and GitLab, with PR and commit gating

Developer surface

VS Code, Cursor, Windsurf and JetBrains

API

Roughly 860 endpoints, OpenAPI documented

AppSecD questions

Does AppSecD replace our existing scanners?

It consolidates them. SAST, DAST, SCA, secrets, IaC, container, Kubernetes and API security all run from one platform against one deduplicated finding model, so the same vulnerability is not tracked three times in three tools.

How does it avoid burying developers in false positives?

Two ways. Reachability analysis determines whether a vulnerable path can actually be reached before anything is raised, and an AI triage layer labels likely false positives — with the label itself tracked, so triage quality is measurable.

Where does it fit in our pipeline?

It triggers on webhooks, scheduled runs, CI, ZIP upload or manually, and it gates pull requests and commits by policy. Developers also get results inside VS Code, Cursor, Windsurf and JetBrains before they push.

Can a developer close their own finding?

Not where you do not want them to. The lifecycle supports maker-checker approval, so a finding marked fixed or false-positive can require a second person to confirm it.

Log in to AppSecD · Full AppSecD detail

Talk to us

Book a walkthrough against your own estate rather than a canned demo: contact DedSec Technologies.