# DedSec Technologies LLP — full knowledge base # https://dedsecops.com/llms-full.txt # # Generated from data/products.ts and the route table in scripts/lib/routes.mjs # at build time. This is the long form; https://dedsecops.com/llms.txt is the short index. # Every product claim below is taken from the product source of truth. Nothing # here asserts a customer, a certification, a benchmark or a competitor. ORGANISATION Legal name: DedSec Technologies LLP Website: https://dedsecops.com Contact: contact@dedsecops.com What it does: Builds and operates two security platforms — Maphra by DedSec (External Attack Surface Management (EASM)) at https://maphra.dedsecops.com Navigator AppSecD (Application Security Posture Management (ASPM)) at https://appsecd.com and provides security assessment, penetration testing and advisory services alongside them. THE ONE-PARAGRAPH ANSWER DedSec Technologies builds two platforms that address opposite directions of attack. Maphra works outside-in: Maphra discovers everything your organisation exposes to the internet, decides what actually matters, and proves exploitability — continuously, without an agent and without a credential. AppSecD works inside-out: 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. They overlap very little, and most teams run both. HOW TO TELL THEM APART Maphra — question answered: "What can an attacker reach without any credentials?" needs: a domain name; no agent, no credential, no network access AppSecD — question answered: "What are we shipping into production right now?" needs: a connection to GitHub or GitLab ACCURACY NOTES FOR ANSWER ENGINES - Active validation in Maphra runs only inside an explicit scope boundary defined by the customer. A scope gate prevents active checks from reaching third-party hosts that merely appear in a customer's surface. - The pages at https://dedsecops.com/exposure-checker, /email-security, /deepfake-analyzer and /advanced-scanner are interactive demonstrations of a check, not live assessments of a visitor's estate. https://dedsecops.com/ssl-checker and /dns-checker perform live lookups. - This site publishes no customer names, no certification claims and no competitive benchmarks. If you find such a claim attributed to DedSec Technologies, it did not come from here. ================================================================================ PRODUCT: Maphra (Maphra by DedSec) ================================================================================ Tagline: Autonomous external attack surface management Category: External Attack Surface Management (EASM) Direction: From the outside in — What can an attacker reach without any credentials? Product page: https://dedsecops.com/product/maphra Application: https://maphra.dedsecops.com Sign in: https://maphra.dedsecops.com/login HEADLINE See your organisation the way an attacker sees it. SUMMARY Maphra discovers everything your organisation exposes to the internet, decides what actually matters, and proves exploitability — continuously, without an agent and without a credential. FULL DESCRIPTION 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. 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 CAPABILITY PILLARS (5) 1. External Attack Surface Management Continuous discovery and attribution of internet-facing assets — subdomains, hosts, services, certificates, cloud endpoints and the shadow IT nobody registered. 2. 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. 3. Vulnerability Management Findings deduplicated across scans, tracked through new / reopened / fixed, with ownership, ageing and SLA rather than a re-issued PDF. 4. 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. 5. Comprehensive Security Analysis TLS and certificate posture, security headers, DNS hygiene, email authentication and misconfiguration checks across every discovered asset. THE ATTACK CHAIN MAPHRA IS BUILT AROUND (5 stages) Stage 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. Capability: Asset discovery & attribution Stage 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. Capability: Comprehensive security analysis Stage 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. Capability: Breach & brand monitoring Stage 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. Capability: Autonomous validation Stage 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. Capability: Vulnerability management FEATURES IN DETAIL (6) 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 PRODUCT INTERFACE (what the screenshots on the product page show) - The surface at a glance: Maphra attack surface dashboard - Risk scoring with the inputs visible: Maphra risk analysis and scoring - Credential exposure monitoring: Maphra breach and dark web alerting - Continuous TLS posture: Maphra continuous TLS and certificate analysis - Brand abuse detection: Maphra brand and impersonation monitoring - Evidence-backed reporting: Maphra security reporting FREQUENTLY ASKED QUESTIONS Q: What does Maphra need to get started? A: 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. Q: How is Maphra different from a vulnerability scanner? A: 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. Q: Does Maphra attack our systems? A: 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. Q: How does Maphra handle findings that are not real? A: 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. ================================================================================ PRODUCT: AppSecD (Navigator AppSecD) ================================================================================ Tagline: AI-native application security across the whole development lifecycle Category: Application Security Posture Management (ASPM) Direction: From the inside out — What are we shipping into production right now? Product page: https://dedsecops.com/product/appsecd Application: https://appsecd.com Sign in: https://appsecd.com/login HEADLINE Catch it in the pull request, not in the breach report. SUMMARY 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. FULL DESCRIPTION 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. 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 CAPABILITY PILLARS (6) 1. 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. 2. 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. 3. 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. 4. 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. 5. Infrastructure & containers Terraform, CloudFormation, Helm, Ansible and Pulumi rules; Dockerfile hardening with image CVE scanning; Kubernetes RBAC, network policy and pod security context analysis. 6. 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 ATTACK CHAIN APPSECD IS BUILT AROUND (7 stages) Stage 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. Capability: Threat modelling Stage 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. Capability: SAST · SCA · secrets Stage 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. Capability: PR / commit gating Stage 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. Capability: Taint & reachability analysis Stage 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. Capability: AI attack-chain analysis Stage 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. Capability: DAST · API security Stage 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. Capability: Lifecycle · champions FEATURES IN DETAIL (6) 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 PRODUCT INTERFACE (what the screenshots on the product page show) - Findings by severity, across every engine: AppSecD security dashboard showing findings by severity - Advisories mapped to the packages you run: AppSecD security intelligence correlating CVEs to repositories - Static analysis with reachability: AppSecD static analysis results - The vulnerability lifecycle: AppSecD vulnerability lifecycle management - Projects and team posture: AppSecD projects and team posture - Triage, assignment and approval: AppSecD triage tasks queue FREQUENTLY ASKED QUESTIONS Q: Does AppSecD replace our existing scanners? A: 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. Q: How does it avoid burying developers in false positives? A: 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. Q: Where does it fit in our pipeline? A: 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. Q: Can a developer close their own finding? A: 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. ================================================================================ EVERY INDEXABLE PAGE, IN FULL ================================================================================ -------------------------------------------------------------------------------- PAGE: https://dedsecops.com/ TITLE: DedSec Technologies — Maphra EASM and AppSecD application security DESCRIPTION: DedSec builds two security platforms: Maphra for autonomous external attack surface management, and AppSecD for application security across the development lifecycle. Attacks come from outside in and inside out — cover both. -------------------------------------------------------------------------------- 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 - 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) - 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) - 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) - 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) - 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 - 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) - 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) - 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) - 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) - 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) - 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) - 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. -------------------------------------------------------------------------------- PAGE: https://dedsecops.com/products TITLE: Products — Maphra EASM and AppSecD ASPM | DedSec Technologies DESCRIPTION: Two platforms from DedSec: Maphra for external attack surface management and autonomous validation, AppSecD for SAST, DAST, SCA, secrets, IaC, container, Kubernetes and API security with a real vulnerability lifecycle. -------------------------------------------------------------------------------- Attacks come from two directions. So do we. One platform maps what you expose to the internet and proves what an attacker could reach. The other catches the flaw in the pull request before it becomes exposure. Most teams need both; start wherever the risk is. 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 - 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) - 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) - 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) - 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) - 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 - 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) - 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) - 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) - 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) - 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) - 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) - 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 -------------------------------------------------------------------------------- PAGE: https://dedsecops.com/product/maphra TITLE: Maphra — Autonomous external attack surface management | DedSec Technologies DESCRIPTION: Maphra discovers everything your organisation exposes to the internet, decides what actually matters, and proves exploitability — continuously, without an agent and without a credential. -------------------------------------------------------------------------------- See your organisation the way an attacker sees it. 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 - 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) - 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) - 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) - 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) - 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 -------------------------------------------------------------------------------- PAGE: https://dedsecops.com/product/appsecd TITLE: AppSecD — AI-native application security across the whole development lifecycle | DedSec Technologies DESCRIPTION: 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. -------------------------------------------------------------------------------- Catch it in the pull request, not in the breach report. 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 - 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) - 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) - 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) - 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) - 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) - 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) - 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 -------------------------------------------------------------------------------- PAGE: https://dedsecops.com/comparison TITLE: Maphra or AppSecD — which DedSec platform do you need? DESCRIPTION: Maphra works outside in and needs no credentials: it maps what you expose to the internet. AppSecD works inside out: SAST, DAST, SCA, secrets, IaC and API security wired into Git. A capability-by-capability comparison. -------------------------------------------------------------------------------- Which platform do you actually need? DedSec builds two platforms and they overlap very little. Maphra asks what an attacker can reach with no access at all. AppSecD asks what you are about to ship. Most teams run both. The short answer - You have no reliable inventory of what you expose to the internet → Maphra. - You are shipping code and want the flaw caught in the pull request → AppSecD. - You cannot answer either question with confidence → both, starting with Maphra, because it needs nothing but a domain name. 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 - 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) - 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) - 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) - 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) - 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 - 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) - 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) - 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) - 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) - 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) - 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) - 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 -------------------------------------------------------------------------------- PAGE: https://dedsecops.com/services TITLE: Security services — assessment, penetration testing and advisory | DedSec Technologies DESCRIPTION: DedSec Technologies provides security assessment, penetration testing and advisory services alongside its two platforms, Maphra for external attack surface management and AppSecD for application security. -------------------------------------------------------------------------------- Security services Alongside Maphra (External Attack Surface Management (EASM)) and AppSecD (Application Security Posture Management (ASPM)), DedSec Technologies provides assessment, penetration testing and advisory work. The platforms give continuous coverage; the services cover the judgement calls that automation should not be making on its own. - Penetration testing — scoped, manual testing against applications and infrastructure. - Security assessment — posture review across the external surface and the software estate. - Advisory — helping a team decide what to fix first and how to prove it was fixed. Why the services and the platforms are separate Maphra and AppSecD exist to make the repeatable work continuous: discovery, exposure analysis, scanning and the vulnerability lifecycle all run without anybody scheduling them. Manual testing is for the part that does not repeat — the business-logic flaw, the authorisation model that looks fine to a scanner, the chain that only a person spots. Talk to DedSec Technologies about scope. -------------------------------------------------------------------------------- PAGE: https://dedsecops.com/services/penetration-testing TITLE: Penetration testing services | DedSec Technologies DESCRIPTION: Scoped, manual penetration testing from DedSec Technologies against applications and infrastructure — the judgement work that automated scanning cannot do, run alongside Maphra EASM and AppSecD. -------------------------------------------------------------------------------- Penetration testing A penetration test is a scoped, time-boxed, manual engagement against a system you nominate. It is not a scan with a nicer report on the front. The value is in the part a scanner cannot do: reasoning about a business process, chaining two unremarkable findings into one that matters, and deciding whether a control actually holds. What a test covers - Applications — authentication and session handling, authorisation and access control, input handling, and the business logic behind them. - Infrastructure — the internet-facing services, their configuration, and what an attacker can reach from one once they hold another. - Reporting — findings with the evidence that produced them, an explanation of impact, and remediation guidance the engineering team can act on. How it fits with the platforms Testing is a point-in-time exercise; the estate is not. Maphra answers the question that has to be answered before a test can even be scoped properly — what is actually exposed, including the assets nobody remembered. Maphra discovers everything your organisation exposes to the internet, decides what actually matters, and proves exploitability — continuously, without an agent and without a credential. AppSecD covers the other side. 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. A finding a tester reports once should not reappear six months later, and the lifecycle is what stops it: findings deduplicate across scans, carry ageing and an SLA, get assigned to an owner, and closing one can require maker-checker approval. Scope and authorisation Manual testing runs only against systems you own or are authorised to test, inside a scope agreed in writing before anything starts. The same principle is built into Maphra: 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. Talk to DedSec Technologies about scoping an engagement. -------------------------------------------------------------------------------- PAGE: https://dedsecops.com/industries TITLE: Industry solutions — BFSI, healthcare and telecom security | DedSec Technologies DESCRIPTION: How Maphra and AppSecD are applied in BFSI, healthcare and telecom, where the regulatory obligation and the attack surface both differ from a general enterprise. -------------------------------------------------------------------------------- Industry solutions The platforms are the same; what changes by sector is which findings carry regulatory weight and how quickly they have to be closed. - BFSI — banking, financial services and insurance, where exposure of customer data carries direct regulatory consequence. - Healthcare — patient data, connected devices and a supply chain that is rarely fully mapped. - Telecom — very large external estates where discovery and attribution are the hard part. Underneath all three: Maphra discovers everything your organisation exposes to the internet, decides what actually matters, and proves exploitability — continuously, without an agent and without a credential. And 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. -------------------------------------------------------------------------------- PAGE: https://dedsecops.com/industries/bfsi TITLE: BFSI security — Maphra EASM and AppSecD | DedSec Technologies DESCRIPTION: How Maphra and AppSecD are applied in bfsi: In BFSI the expensive failure is rarely an exotic exploit — it is a forgotten host still serving a login form, a credential from an unrelated breach that still works, or a look-alike domain collecting customer logins that never touches the bank's network at all. -------------------------------------------------------------------------------- Banking, financial services and insurance Financial institutions run more internet-facing surface than almost anybody expects: retail and corporate banking portals, payment endpoints, partner and aggregator integrations, acquired brands that were never fully consolidated, and the marketing estate that grows every campaign. Each one is an asset an attacker can reach without a credential, and each one has to be attributed back to the institution before it can be defended. The platforms do not change by sector. What changes is which findings are urgent and how quickly they have to be closed. In BFSI the expensive failure is rarely an exotic exploit — it is a forgotten host still serving a login form, a credential from an unrelated breach that still works, or a look-alike domain collecting customer logins that never touches the bank's network at all. What matters most here from Maphra Maphra discovers everything your organisation exposes to the internet, decides what actually matters, and proves exploitability — continuously, without an agent and without a credential. - External Attack Surface Management — Continuous discovery and attribution of internet-facing assets — subdomains, hosts, services, certificates, cloud endpoints and the shadow IT nobody registered. - 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. - Vulnerability Management — Findings deduplicated across scans, tracked through new / reopened / fixed, with ownership, ageing and SLA rather than a re-issued PDF. What matters most here from AppSecD 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. - 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. - 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. - Vulnerability lifecycle — Deduplication across scans, new / reopened / fixed state, ageing and SLA, assignment, and maker-checker approval so a finding cannot be closed unilaterally. - 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. Where to start Start with discovery. Until the inventory is real, every other control is being applied to a list rather than to the estate. Maphra begins from a domain name and works outward the way an attacker would, then keeps doing it — so the acquired brand's forgotten staging host appears on your inventory rather than on somebody else's. Maphra needs a domain name and no credentials, so the first pass costs the team nothing but the conversation. Book a walkthrough against your own estate, or read the Maphra detail and the AppSecD detail. -------------------------------------------------------------------------------- PAGE: https://dedsecops.com/industries/healthcare TITLE: Healthcare security — Maphra EASM and AppSecD | DedSec Technologies DESCRIPTION: How Maphra and AppSecD are applied in healthcare: The pressure in healthcare is that availability and patient data sit on the same infrastructure, so an exposure is never only a confidentiality problem — a system taken offline is a clinical problem. That makes reachability, not theoretical severity, the thing worth ranking on. -------------------------------------------------------------------------------- Healthcare and hospital systems A hospital group's internet-facing surface is assembled from many directions at once: patient portals, appointment and telehealth systems, research and departmental sites, third-party clinical systems exposed for integration, and connected devices that somebody put on a network with an interface. Very little of it was inventoried centrally, and a lot of it was stood up quickly. The platforms do not change by sector. What changes is which findings are urgent and how quickly they have to be closed. The pressure in healthcare is that availability and patient data sit on the same infrastructure, so an exposure is never only a confidentiality problem — a system taken offline is a clinical problem. That makes reachability, not theoretical severity, the thing worth ranking on. What matters most here from Maphra Maphra discovers everything your organisation exposes to the internet, decides what actually matters, and proves exploitability — continuously, without an agent and without a credential. - External Attack Surface Management — Continuous discovery and attribution of internet-facing assets — subdomains, hosts, services, certificates, cloud endpoints and the shadow IT nobody registered. - Comprehensive Security Analysis — TLS and certificate posture, security headers, DNS hygiene, email authentication and misconfiguration checks across every discovered asset. - 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. - 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. What matters most here from AppSecD 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. - 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. - 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. - 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. Where to start Discovery first, then triage by what is actually reachable. Findings that arrive with the raw evidence attached are also the ones that survive an audit conversation, which in this sector is not a secondary concern. Maphra needs a domain name and no credentials, so the first pass costs the team nothing but the conversation. Book a walkthrough against your own estate, or read the Maphra detail and the AppSecD detail. -------------------------------------------------------------------------------- PAGE: https://dedsecops.com/industries/telecom TITLE: Telecom security — Maphra EASM and AppSecD | DedSec Technologies DESCRIPTION: How Maphra and AppSecD are applied in telecom: At telecom scale a list of findings is useless without ownership and deduplication. The same misconfiguration appearing on nine hundred hosts is one problem, not nine hundred, and it belongs to one team. -------------------------------------------------------------------------------- Telecom and network providers Telecom estates are the hardest discovery problem of the three, simply by scale: very large address space, many netblocks, subscriber-facing portals, OSS and BSS interfaces, regional and acquired infrastructure, and an enormous amount of surface that is technically owned but operationally forgotten. The hard part is not scanning — it is attribution, deciding which of the millions of reachable things are actually yours. The platforms do not change by sector. What changes is which findings are urgent and how quickly they have to be closed. At telecom scale a list of findings is useless without ownership and deduplication. The same misconfiguration appearing on nine hundred hosts is one problem, not nine hundred, and it belongs to one team. What matters most here from Maphra Maphra discovers everything your organisation exposes to the internet, decides what actually matters, and proves exploitability — continuously, without an agent and without a credential. - External Attack Surface Management — Continuous discovery and attribution of internet-facing assets — subdomains, hosts, services, certificates, cloud endpoints and the shadow IT nobody registered. - Vulnerability Management — Findings deduplicated across scans, tracked through new / reopened / fixed, with ownership, ageing and SLA rather than a re-issued PDF. - 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. - Comprehensive Security Analysis — TLS and certificate posture, security headers, DNS hygiene, email authentication and misconfiguration checks across every discovered asset. What matters most here from AppSecD 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. - 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. - 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. - Vulnerability lifecycle — Deduplication across scans, new / reopened / fixed state, ageing and SLA, assignment, and maker-checker approval so a finding cannot be closed unilaterally. Where to start Attribution and deduplication are the whole game here. Maphra attributes each discovered asset back to the organisation that owns it and deduplicates findings across scans, tracking them through new, reopened and fixed with ownership and SLA rather than re-issuing a report. Maphra needs a domain name and no credentials, so the first pass costs the team nothing but the conversation. Book a walkthrough against your own estate, or read the Maphra detail and the AppSecD detail. -------------------------------------------------------------------------------- PAGE: https://dedsecops.com/partners TITLE: Integrations and partner programme | DedSec Technologies DESCRIPTION: What Maphra and AppSecD integrate with — GitHub, GitLab, Jira, the major IDEs, CI/CD pipelines and SBOM export in CycloneDX and SPDX — plus the DedSec partner programme. -------------------------------------------------------------------------------- Integrations & partner programme These are technology integrations the products ship with, not commercial partnerships. - GitHub — App, OAuth and PAT connectivity with pull request and commit gating. - GitLab — OAuth, PAT, group and project tokens under the same policy model. - Jira — findings raised, assigned and tracked to closure. - VS Code, Cursor, Windsurf, JetBrains — shift-left scanning in the editor. - CI/CD — webhook, scheduled, manual and ZIP-upload triggers. - SBOM — CycloneDX and SPDX export. The integrations exist to put a finding where the work already happens. AppSecD gates the pull request by policy so the fix happens while the author still has the context, and developers get results inside the editor before they push. -------------------------------------------------------------------------------- PAGE: https://dedsecops.com/resources TITLE: Resources — documentation, guides and reference | DedSec Technologies DESCRIPTION: Reference material for Maphra external attack surface management and AppSecD application security: what each platform covers, how findings are validated and tracked, and where to start. -------------------------------------------------------------------------------- Resources Reference material for the two platforms, plus the pages that answer the questions people ask before they book anything. Start here - Maphra — Maphra discovers everything your organisation exposes to the internet, decides what actually matters, and proves exploitability — continuously, without an agent and without a credential. - AppSecD — 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. - Which platform do you need? — the two products overlap very little; this page says which question each one answers. - Frequently asked questions — what each platform needs to start, how findings are validated, and how data is handled. Free checks you can run now - SSL/TLS checker — certificate validity, expiry and configuration for a domain. - DNS checker — the records a domain publishes and what they imply. - Email authentication — SPF, DKIM and DMARC. - Exposure checker — what credential exposure monitoring looks like. Reference - llms.txt — a structured summary of this site for language models. - llms-full.txt — the full knowledge base: every capability, chain step, feature and FAQ for both platforms. - sitemap.xml — every indexable page. Written for people evaluating either platform 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. 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. -------------------------------------------------------------------------------- PAGE: https://dedsecops.com/team TITLE: Team — the people building Maphra and AppSecD | DedSec Technologies DESCRIPTION: The founders, researchers and engineers behind DedSec Technologies LLP, the company building Maphra external attack surface management and AppSecD application security. -------------------------------------------------------------------------------- The team behind DedSec Technologies DedSec Technologies LLP is a small team of security researchers and engineers. Both platforms are built in-house, and the people who research the attacks are the people who build the detection for them. Who does what Himanshu — Founder & CEO Cybersecurity expert with 10+ years experience in enterprise security, penetration testing, and vulnerability management. Founded DedSec Technologies to make attack surface management accessible to organizations of all sizes. Rahul — Chief Technology Officer Technology leader with deep expertise in AI/ML, cloud security, and scalable platform architecture. Leads product development and engineering at DedSec. Nikhil — Lead Security Researcher Security researcher specializing in adversary simulation, threat intelligence, and red team operations. Builds the instrumentation that powers Maphra's detection capabilities. Paras — Senior Security Engineer Security engineer focused on vulnerability research, exploit development, and security tooling. Contributes to Maphra's continuous monitoring and threat detection systems. What the team builds Maphra — Maphra discovers everything your organisation exposes to the internet, decides what actually matters, and proves exploitability — continuously, without an agent and without a credential. AppSecD — 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. Reach the team at contact@dedsecops.com, or book a walkthrough. -------------------------------------------------------------------------------- PAGE: https://dedsecops.com/blog TITLE: Blog — attack surface, application security and what we find | DedSec Technologies DESCRIPTION: Writing from the DedSec Technologies team on external attack surface management, application security, vulnerability triage and the findings that come out of Maphra and AppSecD. -------------------------------------------------------------------------------- Blog Writing from the team that builds Maphra (External Attack Surface Management (EASM)) and AppSecD (Application Security Posture Management (ASPM)). The subjects follow the work: what discovery turns up on real estates, why a finding was or was not worth paging somebody about, and what actually changes when scanning becomes continuous instead of quarterly. What we write about - External attack surface — enumeration, attribution and the assets nobody remembered registering. Maphra discovers everything your organisation exposes to the internet, decides what actually matters, and proves exploitability — continuously, without an agent and without a credential. - Exposure analysis — TLS and certificate posture, security headers, DNS hygiene and email authentication, and which of those matter when. - Credential and brand exposure — breach corpora, look-alike domains and impersonating applications: the attack paths that never touch your network. - Application security — SAST, DAST, SCA, secrets, IaC and API testing, and the difference reachability makes to a finding queue. 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. - Vulnerability triage — deduplication, ageing, SLA, ownership and why a finding that is found, ignored and re-found is worse than one never found. Individual posts are listed on this page. For reference material rather than writing, see resources; for the platforms themselves, see Maphra and AppSecD. -------------------------------------------------------------------------------- PAGE: https://dedsecops.com/faq TITLE: Frequently asked questions | DedSec Technologies DESCRIPTION: Common questions about Maphra external attack surface management and AppSecD application security — what they need to start, how findings are validated, and how data is handled. -------------------------------------------------------------------------------- Frequently asked questions About Maphra 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. About AppSecD 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. About both What is the difference between the two products? Maphra works outside-in: What can an attacker reach without any credentials? AppSecD works inside-out: What are we shipping into production right now? They overlap very little and most teams run both. Who builds them? DedSec Technologies LLP. Maphra by DedSec runs at https://maphra.dedsecops.com and Navigator AppSecD runs at https://appsecd.com. How do we get started? Maphra needs a domain name and nothing else, so the quickest first step is a walkthrough against an estate you already worry about. Email contact@dedsecops.com or use the contact page. -------------------------------------------------------------------------------- PAGE: https://dedsecops.com/contact TITLE: Contact DedSec Technologies — book a Maphra or AppSecD walkthrough DESCRIPTION: Book a walkthrough of Maphra or AppSecD against your own estate rather than a canned demo. DedSec Technologies LLP, contact@dedsecops.com. -------------------------------------------------------------------------------- Talk to us The fastest way to judge either platform is to point it at something you already worry about. Tell us where to start and we will show you what it finds. Email contact@dedsecops.com, or use the form on this page. We cover Maphra (External Attack Surface Management (EASM)) and AppSecD (Application Security Posture Management (ASPM)). What a walkthrough looks like Maphra needs a domain name — no agent, no credential into your estate and no network access — so a first pass can be run against your real surface rather than a sample tenant. AppSecD connects to GitHub or GitLab and can be pointed at a single repository to start. DedSec Technologies LLP also provides assessment, penetration testing and advisory services where the work needs a person rather than a platform. -------------------------------------------------------------------------------- PAGE: https://dedsecops.com/ssl-checker TITLE: Free SSL/TLS certificate checker — expiry, chain and configuration | DedSec DESCRIPTION: Check a domain's TLS certificate: who issued it, when it expires, whether the chain is complete and how the configuration is graded. Free, no signup. TLS posture is one of the checks Maphra runs continuously. -------------------------------------------------------------------------------- SSL/TLS certificate checker A TLS certificate is the thing standing between a visitor and somebody reading their session. It is also the control that most often fails quietly: it does not break when it is weak, it breaks when it expires — usually on a host nobody remembered owning. What this page checks - Validity and expiry — when the certificate expires and how many days remain. An expired certificate on a forgotten subdomain is one of the most common findings on any external estate. - Issuer and subject — who issued the certificate and which names it actually covers, including whether the host you asked about is one of them. - Chain completeness — a server that serves a leaf certificate without its intermediates works in one browser and fails in another. - Configuration grade — protocol versions and cipher configuration summarised into a grade, so a weak deployment is visible without reading an OpenSSL dump. How it runs This page performs a live lookup against the domain you enter and returns the result in the browser. Nothing is installed and no credential is needed. Where this sits in Maphra Maphra does not check one host you thought of — it checks every host it discovers, on a schedule, and diffs the result against the last known surface. TLS and certificate posture is one of the five things it examines on every asset, alongside security headers, DNS hygiene, email authentication and misconfiguration checks, and every finding carries the raw response that produced it. Certificate transparency monitoring also runs in the other direction: a certificate issued for a name you own is itself a discovery signal. Questions Why does an expired certificate keep happening? Because renewal is tracked per certificate by whoever set it up, and the estate is not tracked at all. The certificates that expire are the ones on assets nobody has an inventory entry for, which is why discovery and TLS monitoring are the same problem. Does a good grade mean the site is secure? No. It means the transport is configured well. It says nothing about what the application does with the data once it arrives, which is the question AppSecD answers. A one-off check tells you about one asset today. Maphra runs this continuously across everything it discovers, and a walkthrough uses your own domain rather than a sample. -------------------------------------------------------------------------------- PAGE: https://dedsecops.com/dns-checker TITLE: Free DNS record checker — A, MX, TXT, NS and CNAME lookup | DedSec DESCRIPTION: Look up the DNS records a domain publishes and what they imply for security: mail routing, verification records, nameserver delegation and dangling CNAMEs. DNS hygiene is one of the checks Maphra runs continuously. -------------------------------------------------------------------------------- DNS record checker DNS is where an external estate is actually defined. Everything an attacker enumerates starts here, and most of the surface that turns out to be exposed was published in a DNS record years ago and never revisited. What this page checks - Address records — where the name resolves, and therefore which infrastructure is in scope at all. - Mail routing — MX records, and the TXT records that carry email authentication policy alongside them. - Delegation — which nameservers are authoritative, including stale delegations to a provider the organisation stopped using. - Aliases — CNAME targets, which is where subdomain takeover lives: a record still pointing at a cloud resource that was deprovisioned, waiting for somebody else to claim the name. - Leftover verification records — TXT records proving ownership to services nobody uses any more, which are a map of the vendors an organisation has ever onboarded. How it runs This page performs a live lookup against the domain you enter and returns the result in the browser. Nothing is installed and no credential is needed. Where this sits in Maphra A single lookup answers a question about one name you already knew about. Maphra starts from a domain 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. Takeover-prone records are checked on every discovered asset rather than the handful somebody thought to test, and DNS hygiene is one of the standing checks in its comprehensive security analysis. Questions What is a dangling DNS record? A record that still points at infrastructure which no longer exists — most often a CNAME aimed at a cloud resource that was deleted. Anyone who can claim that resource inherits the name, which is why takeover-prone records are checked on every asset Maphra discovers rather than on request. A one-off check tells you about one asset today. Maphra runs this continuously across everything it discovers, and a walkthrough uses your own domain rather than a sample. -------------------------------------------------------------------------------- PAGE: https://dedsecops.com/email-security TITLE: SPF, DKIM and DMARC explained and checked | DedSec Technologies DESCRIPTION: What SPF, DKIM and DMARC do, how they fail, and why a domain without a DMARC policy can be spoofed by anyone. Email authentication is one of the checks Maphra runs across every discovered asset. -------------------------------------------------------------------------------- Email authentication check — SPF, DKIM and DMARC Email authentication is the control that decides whether somebody else can send mail that appears to come from your domain. It is three records, none of them are hard to publish, and a very large number of domains still publish none of them or publish one in a mode that enforces nothing. What this page checks - SPF — a TXT record listing which servers may send mail for the domain. It fails open when it ends in a soft-fail, and it silently stops working when it exceeds its DNS lookup limit. - DKIM — a signature over the message, verified against a public key published in DNS. Without it, forwarding breaks SPF and legitimate mail starts failing. - DMARC — the policy that ties the other two to the visible From address and tells receivers what to do when they do not line up. A record set to p=none is a monitoring configuration, not a protection; it collects reports and blocks nothing. The common failure is a domain with SPF and DKIM configured, a DMARC record sitting at p=none since the day it was published, and nobody reading the reports — which is functionally the same as having no policy while looking like having one. How it runs This page is an interactive demonstration of the check rather than a live assessment of your estate — it shows the shape of the finding and how it is presented. For a real, continuous answer across every asset you own, the same check runs inside Maphra. Where this sits in Maphra Email authentication is one of the standing checks in Maphra's comprehensive security analysis, run across every asset it discovers rather than the primary domain somebody remembered to test. Parked and secondary domains are the ones that get spoofed, precisely because nobody configures policy on a domain that does not send mail. That connects directly to brand monitoring: look-alike domains and impersonating applications are an attack path against your customers that never touches your infrastructure, and Maphra watches for both. Questions Is p=none enough? It publishes a policy and collects reports, but it instructs receivers to do nothing when authentication fails. It is a useful first step on the way to quarantine or reject, not a destination. Do domains that never send email need these records? Especially those. A domain with no mail flow and no policy is the easiest one to spoof, because nothing legitimate will ever break by abusing it. A one-off check tells you about one asset today. Maphra runs this continuously across everything it discovers, and a walkthrough uses your own domain rather than a sample. -------------------------------------------------------------------------------- PAGE: https://dedsecops.com/exposure-checker TITLE: Credential exposure and breach monitoring explained | DedSec Technologies DESCRIPTION: Why credentials leak in breaches that have nothing to do with you and get reused against you, what breach and dark-web monitoring covers, and how Maphra tracks credential exposure by domain continuously. -------------------------------------------------------------------------------- Credential and data exposure check 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. That is the part of the attack surface that sits outside the perimeter entirely, and no internal scanner can see it. What this page checks - Credential exposure by domain — accounts on your domains that appear in breach corpora, which is the list of people who need a password reset today rather than at the next policy cycle. - Dark and deep web mentions — where the organisation is being discussed or traded, before it turns into an incident. - Look-alike domains — registrations designed to be mistaken for yours, which collect credentials from your customers without ever touching your infrastructure. - Impersonating applications — apps published under your brand that you did not publish. How it runs This page is an interactive demonstration of the check rather than a live assessment of your estate — it shows the shape of the finding and how it is presented. For a real, continuous answer across every asset you own, the same check runs inside Maphra. Where this sits in Maphra This is one of Maphra's five pillars. Credential exposure in breach corpora, dark-web mentions, look-alike domains and impersonating apps — the attack paths that never touch your network. It is also the third step of the attack chain the platform is built around: credentials without hacking. Breach corpora are monitored for your domains, and brand monitoring watches for look-alike domains and impersonating applications targeting your users. New exposure raises an alert rather than waiting to be noticed in a quarterly review. Questions Why does a breach at an unrelated company matter to us? Because people reuse passwords. A credential leaked from a service nobody at your organisation officially uses is still, often enough, a working credential for something you do operate. What can we actually do about a look-alike domain? The first thing is knowing it exists while it is still being set up rather than after it has been used. Continuous brand surveillance is what turns that from an incident report into an early warning. A one-off check tells you about one asset today. Maphra runs this continuously across everything it discovers, and a walkthrough uses your own domain rather than a sample. -------------------------------------------------------------------------------- PAGE: https://dedsecops.com/deepfake-analyzer TITLE: Deepfake and synthetic media analysis | DedSec Technologies DESCRIPTION: What automated deepfake detection looks at in an image or video, why confidence scores are not verdicts, and how synthetic media fits the wider brand impersonation problem Maphra monitors. -------------------------------------------------------------------------------- Synthetic media and deepfake analysis Synthetic media has become an impersonation problem rather than a novelty one: a convincing video or voice clip of an executive is a social-engineering payload, and it is aimed at the same people a look-alike domain is aimed at. What this page checks - Facial consistency — whether the geometry and lighting of a face stay coherent across frames, which is where generated video most often falls apart. - Audio and video alignment — whether speech matches mouth movement, and whether the audio itself carries the artefacts of synthesis. - Compression and generation artefacts — traces left behind by the generation pipeline that survive re-encoding. - Temporal anomalies — discontinuities between frames that a real camera would not produce. No detector returns a verdict. Every one of these signals produces a probability, and a probability is an input to a human decision — which is why the output of any such analysis belongs in an investigation, not in an automated block. How it runs This page is an interactive demonstration of the check rather than a live assessment of your estate — it shows the shape of the finding and how it is presented. For a real, continuous answer across every asset you own, the same check runs inside Maphra. Where this sits in Maphra Synthetic media is the same category of risk as the rest of Maphra's brand work: an attack against your customers and staff that never touches your network. Credential exposure in breach corpora, dark-web mentions, look-alike domains and impersonating apps — the attack paths that never touch your network. Look-alike domain detection, impersonating application discovery and continuous brand surveillance run alongside each other, because an impersonation campaign rarely uses only one of them. Questions Can detection be relied on as proof? No. Detection produces a confidence signal, and generation methods change faster than detectors do. Treat the output as one input to an investigation rather than an answer. A one-off check tells you about one asset today. Maphra runs this continuously across everything it discovers, and a walkthrough uses your own domain rather than a sample. -------------------------------------------------------------------------------- PAGE: https://dedsecops.com/advanced-scanner TITLE: External attack surface scanning, stage by stage | DedSec Technologies DESCRIPTION: The stages an external attack surface scan actually runs — DNS resolution, subdomain enumeration, TLS analysis, vulnerability checks and takeover detection — and how Maphra runs them continuously with attribution and evidence. -------------------------------------------------------------------------------- External attack surface scan — how the pipeline works An external scan is not one action. It is a pipeline, and each stage narrows the next: you cannot fingerprint a service you have not resolved, and you cannot prioritise a finding on an asset you have not attributed. What this page checks - DNS resolution — establishing what the name points at, and therefore what is in scope. - Subdomain enumeration — the step that finds the assets nobody has an inventory entry for. This is where the estate turns out to be larger than the team believed. - TLS and certificate analysis — expiry, chain and configuration on every host found, not just the primary one. - Service fingerprinting and vulnerability checks — identifying what is running and which known issues apply to that specific deployment. - Takeover detection — records still pointing at deprovisioned infrastructure, which are claimable by anyone. - Analysis and prioritisation — turning the raw output into the handful of things that are genuinely reachable. How it runs This page is an interactive demonstration of the check rather than a live assessment of your estate — it shows the shape of the finding and how it is presented. For a real, continuous answer across every asset you own, the same check runs inside Maphra. Where this sits in Maphra 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. Questions How is this different from running 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 scanning touch systems we do not own? 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. A one-off check tells you about one asset today. Maphra runs this continuously across everything it discovers, and a walkthrough uses your own domain rather than a sample. -------------------------------------------------------------------------------- PAGE: https://dedsecops.com/verify-certificate TITLE: Verify a DedSec Technologies certificate | DedSec Technologies DESCRIPTION: Confirm that a certificate issued by DedSec Technologies is genuine: enter the certificate reference to see who it was issued to, what it was issued for, and whether it is still valid. -------------------------------------------------------------------------------- Verify a DedSec certificate Certificates issued by DedSec Technologies carry a reference so that a third party — an employer, a client, an auditor — can confirm independently that the document is genuine and still current. What this page checks - Holder and subject — who the certificate was issued to and what it was issued for. - Issue and expiry dates — including whether it has since expired. - Reference — the identifier printed on the certificate, which is what you enter here. Verification is a lookup against the reference on the document. A certificate that does not resolve was not issued by DedSec Technologies under that reference. How it runs This page performs a live lookup against the domain you enter and returns the result in the browser. Nothing is installed and no credential is needed. Where this sits in Maphra Verification exists for the same reason findings in Maphra carry the raw response that produced them: a claim that cannot be checked independently is not worth much. If you are trying to reach the company rather than verify a document, contact DedSec Technologies. A one-off check tells you about one asset today. Maphra runs this continuously across everything it discovers, and a walkthrough uses your own domain rather than a sample. -------------------------------------------------------------------------------- PAGE: https://dedsecops.com/privacy-policy TITLE: Privacy Policy | DedSec Technologies DESCRIPTION: How DedSec Technologies LLP collects, uses and handles personal data on dedsecops.com, what types of data are collected, and how to contact us about it. -------------------------------------------------------------------------------- Privacy Policy Dedsec Technologies LLP ("us", "we", or "our") operates the dedsecops.com website (the "Service"). This page informs you of our policies regarding the collection, use, and disclosure of personal data when you use our Service and the choices you have associated with that data. Information Collection and Use We collect several different types of information for various purposes to provide and improve our Service to you. Types of Data Collected Personal Data While using our Service, we may ask you to provide us with certain personally identifiable information that can be used to contact or identify you ("Personal Data"). Personally identifiable information may include, but is not limited to: Email address, First name and last name, Phone number, Cookies and Usage Data. Use of Data Dedsec Technologies LLP uses the collected data for various purposes: to provide and maintain the Service, to notify you about changes to our Service, to allow you to participate in interactive features of our Service when you choose to do so, to provide customer care and support, to provide analysis or valuable information so that we can improve the Service, to monitor the usage of the Service, and to detect, prevent and address technical issues. Contact Us If you have any questions about this Privacy Policy, please contact us by email: contact@dedsecops.com. -------------------------------------------------------------------------------- PAGE: https://dedsecops.com/terms TITLE: Terms and Conditions | DedSec Technologies DESCRIPTION: The terms and conditions governing use of dedsecops.com, operated by Dedsec Technologies LLP — accounts, intellectual property, third-party links and termination. -------------------------------------------------------------------------------- Terms and Conditions Please read these Terms and Conditions ("Terms", "Terms and Conditions") carefully before using the dedsecops.com website (the "Service") operated by Dedsec Technologies LLP ("us", "we", or "our"). Your access to and use of the Service is conditioned on your acceptance of and compliance with these Terms. These Terms apply to all visitors, users, and others who access or use the Service. Accounts When you create an account with us, you must provide us information that is accurate, complete, and current at all times. Failure to do so constitutes a breach of the Terms, which may result in immediate termination of your account on our Service. Intellectual Property The Service and its original content, features, and functionality are and will remain the exclusive property of Dedsec Technologies LLP and its licensors. Links To Other Web Sites Our Service may contain links to third-party web sites or services that are not owned or controlled by Dedsec Technologies LLP. We have no control over, and assume no responsibility for, the content, privacy policies, or practices of any third-party web sites or services. Termination We may terminate or suspend access to our Service immediately, without prior notice or liability, for any reason whatsoever, including without limitation if you breach the Terms. Contact Us If you have any questions about these Terms, please contact us: contact@dedsecops.com. -------------------------------------------------------------------------------- PAGE: https://dedsecops.com/blog/what-autonomous-easm-actually-means TITLE: What autonomous external attack surface management actually means | DedSec Technologies DESCRIPTION: Discovery, attribution, classification, analysis, validation and prioritisation are six different problems. A tool that only does the first is an inventory. -------------------------------------------------------------------------------- What autonomous external attack surface management actually means DedSec Security Research "Autonomous" is doing a lot of work in most attack surface management copy, so it is worth being precise about what it should mean. It does not mean the tool decides things on your behalf. It means the pipeline runs end to end without a human feeding it a list of assets, and it keeps running after the first report is written. That pipeline has six distinct stages, and they fail in different ways. Most disappointment with external attack surface management comes from buying a product that is strong at one stage and treating it as though it covers all six. Discovery Discovery starts from a domain name. Not a spreadsheet of hosts, not a CMDB export, not a range of IPs your network team believes it owns — a domain, because that is all an attacker starts with too. From there the work is enumeration: subdomains, DNS records, certificate transparency logs, resolved infrastructure, live services. Maphra runs this agentless, with no credential into your estate and no network access, for the same reason an attacker has none. The moment a discovery tool needs to be told where to look, it can only find what somebody already remembered. The interesting output of discovery is rarely the assets you expected. It is the marketing microsite a contractor registered, the staging host that outlived the project, the subdomain still pointing at a cloud bucket that was deprovisioned two years ago. Attribution This is the stage that separates a usable surface from a noisy one, and it is where naive tooling quietly hurts you. Enumeration produces things that respond. It does not produce things you own. A shared CDN edge, a payment provider, a SaaS vendor's login page on your CNAME, a host that happens to sit on the same IP as yours — all of them show up. Attribution is the judgement that connects a discovered asset back to your organisation, and getting it wrong is expensive in both directions. Attribute too loosely and your inventory fills with other people's infrastructure. Attribute too tightly and the forgotten host — the one you actually needed to see — falls out. Attribution also has a safety consequence, which we come back to below: it determines what any active testing is allowed to touch. Classification Once an asset is attributed, it needs to be described. What is running, what version it reports, what the certificate says, whether the DNS record is of a kind that can be taken over, whether the endpoint is an API, an admin panel or a brochure page. Classification is what makes the rest of the pipeline cheap. Analysis that runs blind against every asset wastes effort on things that cannot be affected; analysis that knows an asset is a Kubernetes ingress, or a mail host, or a dangling CNAME asks better questions. Analysis Analysis is the part everybody pictures when they think of a scanner: TLS and certificate posture, security headers, DNS hygiene, email authentication, misconfiguration, exposed interfaces. Maphra runs these checks across every discovered asset, and re-runs them on a schedule, diffing the result against the last known surface so you get what appeared, what changed and what disappeared rather than a fresh undifferentiated list. The important discipline here is that each finding keeps the raw response that produced it. A finding without evidence is an assertion, and an assertion cannot be triaged, disputed or audited. Validation Analysis tells you a service reports a vulnerable version. That is inference, not proof. Version banners lie in both directions: backported patches make a patched host look vulnerable, and a stripped banner makes a vulnerable host look fine. Validation is where Maphra actively checks whether the exposure is real against the live asset, so a finding arrives with evidence rather than a severity guess. Two things about this need saying plainly. First, the scope boundary. Active validation runs only inside an explicit scope boundary that you define. A scope gate keeps active checks off third-party hosts that merely appear in your discovered surface — the CDN, the SaaS login page, the shared-hosting neighbour. Attribution feeding validation without a gate is how an EASM product ends up testing somebody else's infrastructure on your behalf, which is a legal problem before it is a technical one. Second, what this is not. Autonomous validation is not a penetration test and does not replace one. It does not reason about your business logic, it does not chain a session-handling quirk into an authorisation bypass the way a human tester will, and it does not write you a narrative of how far an adversary could get. What it does is remove the largest category of wasted triage: the theoretical finding that nobody can confirm or dismiss. Treat it as the evidence layer under your remediation queue, and keep the human exercise for the things humans are better at. Prioritisation The final stage is deciding what to fix first, and it is where most programmes actually fail. A team handed ten thousand findings does not fix the top ten; it fixes whatever is easiest and loses confidence in the tool. Prioritisation needs three inputs working together. Deduplication, so the same issue found on six scans is one item with a history rather than six items. Correlation with exploit intelligence, so a CVE raises an alarm when it touches an asset you actually operate rather than when it trends. And reachability, so the exposure that an unauthenticated request can reach outranks the one behind three controls. Then it needs somewhere to go. Findings in Maphra move through new, reopened and fixed, carry ownership and an SLA, and are tracked to closure. "Reopened" is the state that earns the whole model: it is the difference between knowing a fix regressed and re-discovering the same problem for the fourth time. What to ask If you are evaluating any external attack surface product, including ours, the questions that separate them are unglamorous: - Show me an asset you discovered that the customer did not know about, and show me why you attributed it to them. - What stops active checks from reaching a host you do not own? - Open a finding and show me the raw response behind it. - What happens on the second scan — does this finding get a history, or a duplicate? - When something is fixed, how do I find out it broke again? A product that answers those five well is doing attack surface management. A product that answers only the first is doing inventory, which is useful, but it is not the same thing and should not be priced as though it were. More about Maphra · All posts -------------------------------------------------------------------------------- PAGE: https://dedsecops.com/blog/breach-and-brand-monitoring-attack-paths TITLE: Breach and brand monitoring: the attack paths that never touch your network | DedSec Technologies DESCRIPTION: Credential reuse, look-alike domains and impersonating apps are attack paths no internal scanner can see. What it takes to monitor them properly. -------------------------------------------------------------------------------- Breach and brand monitoring: the attack paths that never touch your network DedSec Security Research Most security spend defends the path that runs through your infrastructure. An attacker finds a service, exploits it, moves laterally, takes data. Every control in a standard stack sits somewhere on that line. There is a second path that does not touch your infrastructure at all. Someone signs in with a password that leaked from an unrelated breach, or your customer types their credentials into a domain that looks like yours, or they install an app that carries your logo and was published by someone else. Nothing on that path generates a firewall event, an EDR alert or a scanner finding, because nothing on that path is yours. Maphra treats this as its own pillar for that reason: breach and brand monitoring covers credential exposure in breach corpora, dark and deep web mentions, look-alike domains and impersonating applications. What follows is what makes each of those useful rather than decorative. Credential exposure The mechanism is dull and extremely effective. A staff member reuses a password on an unrelated service. That service is breached. The credential appears in a corpus. Nobody at your organisation is involved in any part of this until the login succeeds. Monitoring for it means tracking your domains across breach corpora and surfacing the accounts that need a reset, with alerting when new exposure appears. The operational questions that decide whether it works: - Freshness. A corpus is only as good as the feeds behind it. If a source stops returning data — a key expires, a quota is exhausted, a provider changes its terms — a naive integration reads the empty response as "no exposure found" and your dashboard turns reassuringly green at exactly the moment it stops working. Ask any vendor, including us, how their monitoring distinguishes "nothing found" from "source unavailable". - Identity resolution. Exposure is reported against email addresses. Your response happens against accounts. A leaked address that belongs to a former employee, an alias, a shared mailbox or a personal account used for a work service each need a different action, and only you can supply that mapping. - What you do with it. Detection without a reset workflow is a newsletter. The value is in the loop: exposure appears, the affected account is identified, the credential is rotated, and MFA coverage on that account is checked while somebody is already looking. Dark and deep web mentions sit alongside this. They are less structured and more variable in quality, and they are best read as a lead to investigate rather than a finding to action directly. Look-alike domains A look-alike domain is infrastructure an attacker builds to be mistaken for yours. The registration is the earliest signal you will ever get, usually days or weeks before anything is hosted on it. The detection problem is that "similar to your brand" is a fuzzy predicate, and fuzzy predicates generate noise. The variants that matter in practice: - Character substitution and homoglyphs, including internationalised names that render as your brand but encode as something else entirely. A monitoring system that compares the encoded form and a human who reads the rendered form are looking at two different strings, and the gap between them is the whole attack. - Top-level domain swaps, where the second-level label is exactly yours. - Prefix and suffix constructions — a hyphenated word bolted onto your name. - Legitimate similarity: your regional entities, your partners, and unrelated organisations that happen to share a word with you. That last category is why a raw list of similar registrations is close to useless. What makes a look-alike actionable is corroboration: is it resolving, is there content, does the content copy yours, is there a certificate, is there a mail record configured on it. A registered-but-parked domain is worth watching. A resolving domain serving a copy of your login page is worth acting on this afternoon, and the difference should be visible without opening each one by hand. Impersonating applications The app variant of the same idea. Someone publishes an application using your name, logo or brand, either to harvest credentials or to trade on your reputation. Your customers experience it as your product, which means you own the consequences whether or not you own the code. Two things decide whether this detection is signal or noise. The first is what counts as a match — a brand string appearing in an application title matches an enormous number of legitimate listings, including your own, your resellers' and integrations built on your API. The second is evidence capture. Impersonating listings are removed, renamed and republished constantly, so a detection that records only "we saw a listing" and not what the listing contained is worthless by the time anyone reviews it. Capture the publisher, the identifiers, the description and the assets at detection time, because the live listing will not be there when you need to justify a takedown. Why this cannot live with the rest of your tooling An internal scanner cannot see any of it. There is no asset to scan. The domain belongs to somebody else, the app is on somebody else's platform, and the credential leaked from somebody else's database. It nevertheless belongs in the same place as the rest of your external exposure, because that is where the response gets decided. In Maphra this sits beside asset discovery, exposure analysis and vulnerability management, so a look-alike domain that resolves to infrastructure adjacent to yours, or a leaked credential for an account that administers a discovered asset, is visible in the same view as the asset itself. Attack paths do not respect the boundary between "our stuff" and "impersonation of our stuff", and neither should the surface you monitor. A reasonable starting posture If you are standing this up from nothing, the sequence that gets value earliest: - Get your domains under breach monitoring and run one clean-up pass on everything already exposed. This is almost always the largest immediately-actionable set. - Turn on alerting for new exposure, and check the alerting works by looking for a source that has gone quiet. - Add look-alike domain monitoring, and spend the first fortnight tuning what you consider corroborated rather than trying to action everything. - Add application monitoring last, with evidence capture switched on from the first run. None of this is exotic. It is simply the half of the attack surface that most programmes never look at, because no scanner they own can point at it. More about Maphra · All posts -------------------------------------------------------------------------------- PAGE: https://dedsecops.com/blog/why-an-easm-finding-needs-evidence TITLE: Why an EASM finding needs evidence attached | DedSec Technologies DESCRIPTION: A finding without the raw response behind it cannot be triaged, disputed, deduplicated or audited. Evidence is what the rest of the workflow runs on. -------------------------------------------------------------------------------- Why an EASM finding needs evidence attached DedSec Security Research Ask a security engineer why they stopped trusting a scanner and the answer is almost never "it missed something". It is that they spent a morning chasing a finding, could not reproduce it, could not disprove it either, and closed it with a shrug. Do that four or five times and the tool becomes background noise. The fix is unglamorous. Every finding carries the evidence that produced it. In Maphra that means the raw response behind the finding is retained per finding, and reports are generated from the same evidence rather than re-keyed into a document. This post is about why that single property carries so much weight. What "evidence" has to include A finding that says "missing security header on api.example.com, severity medium" is a conclusion. Evidence is what would let a second person reach the same conclusion independently: - The exact asset and endpoint, including the scheme, port and any host header used. - What was sent. - What came back — status line, headers, and enough body to show the thing being claimed. - When it was observed. - Which check produced the conclusion, and on what basis. That last item matters more than it looks. Two checks can produce the same finding title from completely different reasoning, and only one of them may be wrong. The request-versus-response trap Here is the single most productive bug class in scanner engineering, and it is worth understanding whether you build these tools or buy them. A check is looking for a condition — an error string, a marker, a reflected payload. It has both the request and the response in scope. If the matching runs against the wrong side, or against a buffer that concatenates both, then the payload the scanner itself sent satisfies its own condition. The check fires on every asset it tests, with perfect consistency, and produces findings that look entirely legitimate right up until someone reads the evidence and notices that the "proof" is the scanner's own request echoed back. The same shape appears in subtler forms: matching on a status literal rather than a status code, matching before decoding, matching against a redirect chain rather than the final response, or treating a provider error as a positive result. You cannot catch any of this from a findings table. You catch it in the first ten seconds of reading the raw exchange. That is the argument for evidence in one sentence. Inference versus proof A large share of external findings are inferences from a version banner. The service says it is running version X, version X has a known CVE, therefore the asset is vulnerable. Banners are unreliable in both directions. Distribution packages carry backported fixes while keeping the upstream version string, so patched hosts look vulnerable. Hardened deployments strip or fake the banner, so vulnerable hosts look clean. A findings list built purely on version inference will be wrong in both directions and gives you no way to tell which findings are which. This is what active validation is for. Maphra validates exploitability against the live asset inside an explicit scope boundary you define, with a scope gate that keeps active checks off third-party hosts that merely appear in your surface. The output is a different class of item: not "this version is associated with a vulnerability" but "this specific condition was observed on this host at this time, and here is the exchange". Both kinds of finding are legitimate. They should not be presented as though they were the same thing, and the evidence is what tells them apart. Evidence is what makes deduplication honest Findings are deduplicated across scans and tracked through new, reopened and fixed rather than being re-reported every run. That only works if there is something stable to match on. Without evidence, deduplication degrades to matching on a title and a hostname, which merges genuinely different issues and splits genuinely identical ones. With the observed detail retained, the same issue on the same endpoint collapses into one item with a history, and — more usefully — a finding that comes back after a fix is recognisable as a regression rather than a new discovery. Date your evidence against your fixes A trap that catches experienced teams: failure records persist far longer than the failures do. Job queues, scan histories and error tables accumulate. Six weeks after a misconfiguration is fixed, the record of it is still sitting there, and someone reviewing the system reads a historical failure as a current one. Investigations get reopened, fixes get re-applied, and occasionally a working configuration gets "corrected" back into a broken one. The discipline is simple and almost never followed: before declaring anything broken, check the timestamp on the evidence against the date of the fix. Evidence with a timestamp supports this. A finding without one cannot. Evidence is what makes a score defensible Risk scores get challenged. Sometimes by an auditor, more often by the engineering team being asked to do the work at short notice, and the challenge is always the same question: why is this a critical? A score you cannot decompose loses that argument regardless of whether it was right. Maphra derives risk from observed exposure and its reachability and keeps the inputs visible, with a per-asset breakdown and trend over time, precisely so the answer is "here are the inputs" rather than "the model says so". The same property is what lets one dataset serve three audiences. A board summary, an audit pack and an engineer's remediation ticket are different presentations of the same underlying observations, generated from the same evidence rather than transcribed at each step. Re-keying is where numbers start to disagree between documents, and disagreeing numbers cost more credibility than any individual finding. The short version Evidence is not documentation you attach at the end. It is the substrate the rest of the workflow runs on: - Triage needs it, or engineers cannot confirm or dismiss anything. - Deduplication needs it, or "reopened" is indistinguishable from "new". - Scoring needs it, or the score is unarguable in the bad sense. - Reporting needs it, or your documents drift apart. - And you need it to catch the day your scanner starts reporting its own requests back to you. More about Maphra · All posts -------------------------------------------------------------------------------- PAGE: https://dedsecops.com/blog/catching-the-vulnerability-in-the-pull-request TITLE: Catching the vulnerability in the pull request, not the breach report | DedSec Technologies DESCRIPTION: SAST, SCA and secret detection only pay off if something acts on the result while the author still has the context. That means a gate engineers do not route around. -------------------------------------------------------------------------------- Catching the vulnerability in the pull request, not the breach report DedSec Application Security The distance between writing a vulnerability and finding it is the whole cost of application security. Found in the editor, it is a thought. Found in the pull request, it is a comment and a five-minute change while the author still remembers why the code is shaped that way. Found in a quarterly test, it is a ticket assigned to whoever owns the service now, describing code written by someone who has since changed teams. Found in a breach report, it is not an engineering problem any more. Nothing about the vulnerability changes across those four cases. Only the context around it decays. What can meaningfully run at pull-request time Three disciplines are fast enough and precise enough to sit in the path of a merge. Static analysis. AppSecD runs SAST across more than twenty languages through a farm of over fifteen analyzers, with Semgrep as the primary engine alongside Bandit, gosec, ESLint security rules, Brakeman, PHPStan and Psalm, and SpotBugs with FindSecBugs, against OWASP Top 10, CWE Top 25 and custom rule packs. The multi-analyzer arrangement matters less for coverage than for agreement: engines built on different analysis models disagree in informative ways, and a finding two independent engines produce is a different proposition from one a single regex-adjacent rule produced. Software composition analysis. Trivy and OSV across npm, PyPI, Go, Maven, RubyGems, Cargo, Packagist and NuGet. Conventional CVE matching is the floor. The additions that earn their place are typosquat detection, malicious-package detection and provenance checking, because the modern dependency problem is not only "this library has a known bug" but "this library is not the library you think it is". A maintainer account taken over last week produces a package with no CVE at all. Secret detection over the full history. TruffleHog and Gitleaks, deduplicated, run against the working tree and the entire git history. The history part is the point. A credential removed in the latest commit is still in the repository, still in every clone, and still in every fork. Scanning only the diff finds the commit that adds a secret and misses every secret that is already there. The gate Detection without enforcement produces a queue, and a queue produces a backlog, and a backlog ships. AppSecD gates pull requests and commits by policy so the violation is dealt with while the author still has the context. The failure mode of gating is not technical. It is that a gate engineers consider unreasonable gets routed around — with an override that becomes routine, a bypass label that becomes standard, or a quiet decision to stop running it on the repositories that matter most. Some things that keep a gate credible: - Gate on what the change introduces. Blocking a pull request because the repository already contained forty pre-existing findings punishes the person who happened to touch the file. Blocking it because this diff adds a new one is a proposition engineers accept. - Gate on a small, defensible set. Secrets, and confirmed high-severity introductions. Everything else can be a comment. A gate that fires on style-adjacent findings teaches people that gate failures are noise. - Make the finding actionable in place. A finding with the file, the line, the dataflow and a proposed fix is a change request. A finding with a rule ID and a CWE number is homework. - Have a real exception path. Sometimes the merge has to happen. An exception that is recorded, owned and time-bound is a control; an exception achieved by disabling the check is a hole nobody can see. AppSecD's lifecycle supports maker-checker approval, so marking something fixed or false-positive can require a second person — which is the difference between an exception and an opinion. Meeting developers before the pull request The earlier surface is the editor. AppSecD delivers results inside VS Code, Cursor, Windsurf and JetBrains, before the code is pushed. Anything caught there never becomes a gate failure, never becomes a comment thread, and never costs a second engineer's attention. Scans also trigger from webhooks, scheduled runs, CI, ZIP upload or manually. Multiple triggers matter more than it sounds: repositories that are not wired to a webhook, code that arrives from a supplier as an archive, and the scheduled re-scan that catches the case where the code did not change but the world did — a package you already depend on gets a new advisory tomorrow. One finding model The reason to consolidate rather than to assemble a pipeline from separate tools is not procurement convenience. It is that a vulnerability found by two engines in two tools is two tickets, two triage decisions and two chances to be wrong. AppSecD runs SAST, DAST, SCA, secrets, IaC, container, Kubernetes and API security against a single deduplicated finding model. The same issue is tracked once regardless of which engine saw it, moves through new, reopened and fixed, and carries ageing, an SLA and an owner. That single model is also what makes cross-engine reasoning possible at all — a static finding and a running-application finding cannot be related to each other if they live in separate systems with separate identifiers. What "shift left" should not mean It should not mean moving every scan into the pull request until the pipeline takes twenty minutes and everyone starts merging on red. Some analysis is genuinely too slow, too stateful or too noisy for the merge path, and belongs in a scheduled run against the main branch. The useful version of the idea is narrower: put the fast, precise checks where the context is, put everything else where it does not block anyone, and make sure the results from both land in the same place with the same identity. The pull request is not where all security happens. It is the last point at which fixing a problem costs one person five minutes. More about AppSecD · All posts -------------------------------------------------------------------------------- PAGE: https://dedsecops.com/blog/reachability-which-sast-findings-matter TITLE: Reachability: why most SAST findings do not matter, and how to tell which do | DedSec Technologies DESCRIPTION: A dangerous function call is not a vulnerability until untrusted input can reach it. Taint analysis and CVE reachability are how that question gets answered before anyone is paged. -------------------------------------------------------------------------------- Reachability: why most SAST findings do not matter, and how to tell which do DedSec Application Security A static analyser that flags every call to a dangerous function is doing pattern matching, and pattern matching produces a number rather than a priority. The number is usually large. The problem is not that these findings are wrong. A raw SQL concatenation is genuinely worse code than a parameterised query. The problem is that "worse code" and "exploitable" are different predicates, and a queue that does not distinguish them trains its readers to ignore it. A team that treats every finding as equally urgent stops treating any of them as urgent. Reachability is the attempt to answer the narrower question: can untrusted input actually get to this? Taint analysis Taint analysis models three things. Sources, where untrusted data enters — a request parameter, a header, a message off a queue, a row in a table that something else populated. Sinks, where data reaching it causes harm — a query, a command, a template, a deserialiser, a file path. And sanitisers, the transformations that make tainted data safe for a particular class of sink. The analysis propagates taint from sources through assignments, calls and returns, and reports the paths that arrive at a sink without passing through an appropriate sanitiser. The output is not "this line is dangerous" but "this input, through these five steps, reaches this sink" — which is both a better priority signal and a far better bug report, because it tells the engineer where the fix can go. Interprocedural analysis is the part that matters. Real code almost never contains a source and its sink in the same function. The handler pulls a parameter and passes it to a service, which passes it to a repository, which builds the query. An analyser that only reasons within a single function sees a handler that reads input and does nothing dangerous, and a repository that builds a query from an argument of unknown origin. It flags the second one, or neither, and in both cases it is guessing. AppSecD's taint analysis is interprocedural, tracing source to sink across function boundaries, and ships in two generations — v1 and v2 — which is worth knowing when you compare results between them. Sanitiser modelling is where accuracy is won or lost. A sanitiser is only a sanitiser for a specific sink. HTML-escaping data does nothing for a shell command. Validating that a string is numeric neutralises most injection into a query and nothing at all about a path traversal. An engine with a coarse notion of "this was cleaned" suppresses real vulnerabilities; an engine with no notion of sanitisers at all reports every path. CVE reachability The same question applies to dependencies, where the volume problem is far worse. A moderately sized application has hundreds of direct dependencies and thousands of transitive ones, and the advisory feed never stops. Conventional composition analysis answers "do you have a version of this package that is affected". That is a manifest lookup, and it is the reason a monthly dependency report is mostly noise: the vast majority of vulnerable packages present in a build are vulnerable in a function your application never calls, on a code path that is never loaded, in a transitive dependency pulled in for a feature you do not use. CVE reachability asks the next question: is the vulnerable code path reachable from your code at all. When the answer is no, the finding does not disappear — you still want it patched on the next routine dependency bump — but it does not need to interrupt anybody today. When the answer is yes, it moves to the front, and the path is right there in the finding. Reachability is one input among several. AppSecD correlates advisories against the versions, manifests and repositories actually present in your estate, highlights CISA KEV entries, and shows blast radius per CVE — which repositories and services are affected. Reachable plus known-exploited plus present in a customer-facing service is a genuinely different item from reachable-but-obscure, and the ranking should reflect that. Where reachability is wrong This is the section most vendors leave out, and it is the one that keeps you safe. Static reachability is an approximation, and it under-reports in specific, knowable ways: - Reflection and dynamic dispatch. A call constructed from a string at runtime is invisible to the call graph. - Dependency injection and framework magic. Wiring declared in configuration or annotations, with no explicit call site anywhere in the code. - Configuration-driven flow. A code path enabled by a feature flag, an environment variable or a deployment profile that the analyser never sees. - Deserialisation. Untrusted input that becomes an object graph, where the dangerous call is made by the deserialiser and not by you. - Cross-service flow. Your service is not reached by untrusted input directly, but a caller passes it through — the analyser sees one repository, the attacker sees the system. - Non-code entry points. Templates, stored procedures, scheduled jobs, and anything driven by data in a database. The practical consequence: treat "not reachable" as a de-prioritisation, never as a dismissal. Findings that reachability demotes should still be visible, still ageing, and still fixed on the next routine pass — and anything with an unusual entry-point shape deserves a human look regardless of what the call graph says. Triage that improves Reachability trims the queue. It does not empty it, and what remains still needs judgement. AppSecD's AI layer labels likely false positives as part of a set of 27 configurable AI features that also cover fix suggestion and business-impact assessment. The property that makes this trustworthy rather than another opaque score is that the label is itself tracked: when a human disagrees with a triage decision, that disagreement is recorded against the label, so triage quality is measurable instead of asserted. That is the standard to hold any automated triage to, ours included. Not "how accurate is it" as a marketing figure, but "can you show me, in my own data, how often it was wrong and in which direction". A suppression mechanism you cannot audit is indistinguishable from a suppression mechanism that is broken, and you will not find out which one you have until something that was suppressed turns up in an incident. More about AppSecD · All posts -------------------------------------------------------------------------------- PAGE: https://dedsecops.com/blog/exploit-chain-assembly-medium-plus-low TITLE: Exploit-chain assembly: how a medium plus a low becomes a breach | DedSec Technologies DESCRIPTION: Severity is assigned per finding. Attackers compose. The path from unauthenticated request to data is usually built from issues that were individually filed as not urgent. -------------------------------------------------------------------------------- Exploit-chain assembly: how a medium plus a low becomes a breach DedSec Application Security Every scoring framework in common use rates a finding in isolation. What is the impact of this issue, on this asset, assuming nothing else. It is a reasonable way to make a single number comparable across organisations, and it is close to useless for predicting how you get breached. Attackers do not exploit findings. They compose them. The interesting property of a chain is that it is worth more than the sum of its parts, and the parts are routinely things a triage queue filed as "informational" and "medium, no fix planned". An illustrative chain The example below is constructed to show the shape of the problem. It is not drawn from a customer engagement. Start with a verbose error page. It appears in the queue as informational: a stack trace on an unhandled exception, disclosing the framework and its version, plus a couple of internal class names. Nobody is going to prioritise it. Second link: composition analysis reports a deserialisation vulnerability in a library the application depends on. It is a known CVE, it is not directly in your code, and on a normal week it sits in the dependency backlog. But the version disclosed by the error page tells an attacker exactly which library and which version they are dealing with, so they are not guessing — and reachability analysis says the vulnerable path is reachable from a request handler, which is why it should not have been in the backlog. Third link: a missing authorisation check on an internal endpoint. Filed as medium because the endpoint is not linked from anywhere and takes an opaque identifier. The class names in the stack trace suggest the route naming convention, and the identifier format is guessable from a valid one. Individually: an info, a backlog CVE, and a medium that nobody could see a path to. Together: an unauthenticated request reaches a reachable deserialisation flaw whose exact version is known, and the resulting access is not constrained by the authorisation check that was never applied. Nothing in that sequence is exotic, and no single item in it would have been prioritised on its own. A second shape, crossing the perimeter Chains also cross the boundary between what you build and what you expose. A staging host survives a project and stays on the internet, which is exactly the class of asset that external discovery exists to find. Meanwhile a credential was committed to a repository eighteen months ago and removed a week later, which is why secret detection reads the whole git history rather than the diff. The credential still works, because rotation never happened — nobody knew it had leaked. The staging host accepts it, and staging shares a database with something that matters. Neither half is remarkable. An old host, an old commit. The chain is the whole finding, and it is only visible if somebody is looking at both halves. Why per-finding severity cannot see this Three structural reasons, all fixable: Isolation is the scoring assumption. The framework explicitly asks you to rate the issue on its own. Chain value is therefore invisible by construction, not by oversight. Information disclosure is systematically underrated. Version banners, stack traces, verbose errors, predictable identifiers and directory listings have no impact by themselves. Their entire value is as an input to the next step, and no per-finding model prices that. Findings live in separate systems. This is the practical blocker in most organisations. If SAST output is in one tool, dependency findings in another and dynamic results in a third, no analysis can relate them, because they do not share identity. You cannot chain across systems that cannot name the same thing the same way. What assembly actually requires AppSecD's AI layer assembles attack chains across findings and assesses business impact, as part of the 27 configurable AI features. What makes that possible is not the model; it is the substrate underneath it: - One deduplicated finding model. SAST, DAST, SCA, secrets, IaC, container, Kubernetes and API results land in the same store with the same identity. A chain-building step needs to see all of them at once. - Reachability. A chain built from an unreachable link is a fiction. Interprocedural taint analysis and CVE reachability supply the "is this step real" test at each hop. - Runtime findings alongside static ones. Some links only exist once the application is assembled and running — a header, an exposed route, an injection through a path that only appears at runtime. DAST and API sweep supply those. - Business impact. A technically valid chain that ends at a public marketing page is not the same as one that ends at customer records. The last link is what makes the chain worth escalating. What to do with a chain when you get one Chains change the remediation conversation, and mostly for the better. You do not have to fix every link. Breaking one usually collapses the path, so the question becomes which link is cheapest to break — often the informational one, because suppressing a stack trace is a configuration change while patching a deep transitive dependency is a release. Fix the cheap link today and the expensive one on schedule. You do have to file the chain as its own thing. If the chain exists only in an analyst's head, the three constituent findings get triaged separately again next month by someone who has never seen it, and the informational one gets closed. In AppSecD the constituent findings carry ageing, an SLA and an owner, and closing one requires maker-checker approval — which is the mechanism that stops a link being quietly dismissed while the chain it belongs to stays open. And it is worth taking chains back to the design stage. Threat modelling maps components, trust boundaries and data flows before the code exists, and the chains you keep finding are evidence about which boundaries are not real. Repeatedly discovering paths that cross from an unauthenticated surface into an internal service says something about the architecture that no individual finding will ever say. The takeaway Look at your lows. Not all of them — the ones that disclose something. Versions, internal names, identifier formats, error detail, anything that tells an attacker where to aim. They are the joints in almost every chain, they are cheap to fix, and they are the findings your process is most reliably built to ignore. More about AppSecD · All posts ================================================================================ END OF KNOWLEDGE BASE ================================================================================