Security & Behavior

Analyst Toolkit

What the code really does once it is running

The defense an application declares and the behavior it actually exhibits, side by side. Runtime scripting, content security policy, subresource integrity, browser permissions, and the published vulnerabilities in components you inherited rather than chose.

A page loads one analytics script, that script loads three more from elsewhere, and one of those constructs and executes code that never appears in any file you could inspect. None of it is visible in a contract, an inventory, or a review of your own repository. This section traces the chain, names the weaknesses in what was declared, and credits what was configured well.

Integrated Reports

  • Security Findings

    Configuration issues drawn from content security policies, integrity declarations and standard security headers, each with a severity and an explanation of why it matters. This is the 'is this site set up properly' report, and it is written to be actionable: each finding says what to do about it, not merely that something is missing.

  • Runtime Scripting

    Which script loaded which other script, by what means, and the evidence for each link, as a flow diagram and a full detail table. The deepest technical report in the product, and where a chain that never appears in any file you could inspect becomes visible.

  • Content Security Policy

    A content security policy is the instruction set a site gives the browser about what it is allowed to load and run, the single most effective defense against injected code. Every policy found is inventoried with its directives in full, the weaknesses that matter are flagged, and what is done well is credited as a positive rather than left as an omission.

  • Subresource Integrity

    Subresource integrity is a fingerprint attached to an externally loaded file: the browser checks the file against it and refuses to run a mismatch. It is the specific defense against a supplier's file being altered, by the supplier or by an attacker who has reached them. Many supply chain compromises consist of a legitimate file being quietly replaced, and this report gives a direct answer to which of your external files are unverified.

  • Permissions

    What the application asks the browser for on its own behalf and its suppliers', from camera and microphone to location and clipboard, with third-party requests highlighted. A supplier's script asking for the microphone is a materially different fact from your own application asking for it, and this report separates the two.

  • Cyber Vulnerabilities

    Known weaknesses in the third-party software the application depends on. SCVue identifies the libraries and versions in the chain, matches them against published vulnerability data, and reports what is affected and the version that resolves it. Results roll up, so the answer to are we exposed to this can be given for a whole portfolio, not one application at a time.

One capture is enough to start

Capture a session in the browser, import it, and read what comes back. A free community account is available immediately.