Updates

/methodology publishes the analytical framework behind ShieldScope in human-readable form. Not a specification dump — an interpretive layer for practitioners who want to understand how the platform reaches its conclusions.

The page covers what ShieldScope can and cannot observe, the full confidence model, scoring philosophy, severity definitions, how false positives are handled, and the evidence-first design principle that governs how findings are presented.

The page links to canonical technical specifications at github.com/ShieldScope/meta, where the confidence taxonomy, per-tool application matrix, scoring philosophy, and known limitations are published as versioned documents. The site page is the human-readable layer. The GitHub repo is the auditable technical spec.

The confidence model used across ShieldScope findings has been formalized into a five-tier taxonomy. The previous two-tier model (OBSERVED / HEURISTIC) was replaced because it couldn't express a distinction that matters operationally: the difference between a finding calculated deterministically from data and one that extends beyond what the data directly supports.

The five tiers:

• OBSERVED — directly visible in retrieved data, independently verifiable without computation
• DERIVED — calculated deterministically from observed data (the raw evidence is observed; the conclusion requires ShieldScope's processing to reach)
• HEURISTIC — pattern-based, false positives expected and declared per finding
• INFERRED — contextual conclusion from incomplete visibility
• INDETERMINATE — data retrieved, but the evidence does not support a stable conclusion (contradictory or unresolvable results)

A key structural decision: retrieval failures (timeouts, unreachable endpoints, rate limits) are classified as scan states, not confidence tiers. When no analysis occurs, no confidence label applies. INDETERMINATE is distinct — it means analysis ran and produced contradictory results, not that the check wasn't attempted.

For findings involving multiple reasoning steps, the headline confidence reflects the weakest tier in the chain. The full chain is shown in finding detail so the point of uncertainty is visible rather than hidden behind the strongest step.

The full specification, including a per-tool application matrix covering triggers, prohibited usages, and edge cases, is published at github.com/ShieldScope/meta.

The /sandbox File tab adds file triage to ShieldScope's static analysis toolkit. Upload any file for immediate hash generation, MIME type identification, and structural analysis — with no execution, no detonation, and no third-party lookups.

• Hashes: SHA-256 and MD5 computed from raw file bytes — not the filename, not the browser-reported type.
• MIME detection: Type is identified from magic bytes in file content, never from the declared extension or browser MIME type. This is what makes extension mismatch detection meaningful — if ShieldScope trusted the extension, it couldn't detect the discrepancy.
• Extension mismatch: Severity is calibrated to risk direction. A PE executable named .pdf is HIGH — the primary social engineering scenario. A PDF named .txt is LOW — structurally inconsistent but not a typical attack pattern. Equal-severity treatment of unequal risks misleads analysts.
• Double extensions: Filenames like invoice.pdf.exe use the outermost extension to determine how the OS opens the file. The inner .pdf is cosmetic. ShieldScope detects the pattern when the visible extension is a benign document type and the actual extension is an executable or script.
• Unicode homoglyphs: Cyrillic lookalikes, fullwidth punctuation, and Unicode dot substitutes (U+2024 ONE DOT LEADER) are normalized before extension extraction. A filename that renders identically to invoice.pdf but uses a different character as the extension separator does not evade the analysis.
• PDF structure: The document byte stream is scanned for /JavaScript and /JS actions (code executed on open), /Launch directives (external file/application execution), and /EmbeddedFile streams. None of these require rendering the PDF.
• Office macro detection: Open XML files (.docx, .xlsx) are ZIP archives. ShieldScope inspects the archive index for vbaProject.bin, which confirms embedded VBA macros without executing them.
• Archive inspection: ZIP entries are listed and classified — executables, scripts, macro-enabled documents, nested archives. Recursive extraction is not performed. Capped at 100 entries and 50 MB uncompressed.
• PE metadata: Windows PE executables are parsed for architecture, compile timestamp, subsystem, and import count estimate from the PE header.

What it does not do: ShieldScope does not execute files, detonate them in a sandbox, submit them to antivirus engines, or store them after analysis. There are no "safe" or "malware" verdicts. The output is structural triage, not an antivirus scan.

Every email finding in /sandbox now carries an explicit confidence label: OBSERVED or HEURISTIC.

OBSERVED means the finding is based on direct, verifiable evidence — a header value present in the email source, an authentication result that explicitly failed, or a structural element with no ambiguity.

HEURISTIC means the finding fires on a pattern common in malicious email but not exclusive to it. A Reply-To address on a different domain than the From address is genuinely suspicious — and present in some legitimate bulk sender configurations. A URL with a brand keyword in a non-canonical domain is a strong phishing signal — and also fires when someone pastes a URL that mentions a brand name without impersonating it.

This distinction was added because presenting all findings at equal weight implies a certainty that isn't warranted for heuristic indicators. Collapsing observed evidence and probabilistic patterns into a generic "finding" trains analysts to either over-trust automated outputs or to dismiss the tool when it produces expected-but-wrong positives. The confidence chip is the tool disclosing its own reasoning.

Also in this update: the NEUTRAL risk level. CLEAN is reserved for emails where at least one authentication mechanism passes and no suspicious indicators are found. When no suspicious indicators are observed but authentication is absent or unverifiable, the result is NEUTRAL — absence of findings does not confirm legitimacy.

Three pages added to support the trust infrastructure the tool needs to be taken seriously by security professionals.

/about documents who built ShieldScope, the detection philosophy, and what the tool deliberately does not do. Security tooling without a declared operator and methodology has a credibility problem — users cannot assess expertise, conflicts of interest, or data handling intent.

/security establishes responsible disclosure policy, publishes a contact channel for security researchers, and adds a /.well-known/security.txt endpoint compliant with RFC 9116. ShieldScope analyzes the security posture of other sites — it should hold itself to the same standard.

/guide provides methodology documentation for each tool: how scoring works, what each indicator means, what the limitations are, and what the tool is not designed to do. A finding that users cannot interpret or verify is not useful — it is noise.

/exposure performs passive reconnaissance against a target domain from the defender's perspective. It discovers subdomains through certificate transparency log enumeration and common hostname brute-force, checks service availability on standard ports, assesses TLS posture, and flags infrastructure patterns that present elevated risk — exposed admin interfaces, non-standard service ports, outdated TLS configurations.

All discovery is passive. ShieldScope does not interact with discovered services beyond checking connectivity, does not probe for vulnerabilities, and does not authenticate against anything. The output represents observable infrastructure state — what any external party can see with public tools.

This constraint is intentional. Passive reconnaissance is appropriate for owners verifying their own exposure. Active probing requires explicit authorization scope — out of scope for a public-facing tool.

ShieldScope launched with five analysis tools, all operating on publicly available data or data submitted by the user. No scan history is retained. No user accounts are required.

• /headers — HTTP security header analysis. Grades presence and configuration quality for CSP, HSTS, X-Frame-Options, and related headers. The grade reflects whether headers are hardened, not just technically present.
• /mail — Email authentication posture for a domain. Checks SPF, DKIM, and DMARC DNS records. Email authentication is the foundational layer for phishing resistance; this tool exposes the current state without requiring access to actual email.
• /url — Passive URL analysis. Redirect chain tracing, domain age, SSL validity, WHOIS data, and deception detection — typosquatting patterns, brand lookalikes, misleading subdomains.
• /password — Password entropy analysis and breach exposure check. Strength evaluation is client-side. Breach check uses the Have I Been Pwned k-anonymity API — the password itself is never transmitted.
• /sandbox — Launched with URL and script analysis (PowerShell, JavaScript, Batch, VBScript). Static analysis only at every stage — the script is read, never executed.