Security Boundary — Not a Pentest

Not a pentest

Two panels separating static review from authorization-required active testing. — The security boundary: static review is engine work; active testing needs separate authorization and scope.

The security boundary: static review is engine work; active testing needs separate authorization and scope.

A static security review is security analysis over source, configuration and output files without touching the target system. WebTrustEngine's security layer stays within this definition and has four blocks: secret scan (key/password/token leakage), exposed files (.env, backups, .git, config exposure), client-side risky patterns (eval, document.write, dangerous sinks) and server-side SAST classifications (SQLi/command/traversal/deserialization/SSRF/XXE markers).

SCA/CVE logic accompanies these: risky ranges of known library versions are flagged; but no 'this version is exploitable' claim is made — the flag binds to an update recipe. CSP/HSTS readiness and OWASP mapping put findings into a shared language.

When is it not a pentest? Always — in this product. No active payloads, no live port scans, no authentication-bypass attempts, no exploit generation. Any DAST-class behaviour requires written authorization, ownership verification and a separate scope document. This legal and ethical boundary is not a weakness; it is trust discipline: the client knows exactly what they bought and what must be ordered separately.

secret scan
exposed files
JS sink patterns
SCA/CVE flags
CSP/HSTS readiness
OWASP mapping
DAST = authorization + scope

What the engine does: Runs a static security review over source.

What it doesn't: No exploitation/port scans/payloads; not a pentest.

What the output is: Risky-pattern report + recipes + OWASP mapping.

For decision-makers: A visible dashboard of silent risks.

For technical teams: The SAST↔DAST line holds in contract language too.

Where manual verification steps in

The manual verification boundary: the engine's automated area versus human judgment.

Manual verification is the engine's honesty layer: some areas cannot be automated and are not presented as if they were. Legal claims (compliance statements, copyright text), certain accessibility decisions (contrast context, adequacy of media description), cultural context and brand voice, content accuracy (figures, titles, claims), changes requiring client approval, and steps requiring security authorization live here.

Its operation is clear: the item is flagged, the rationale written, and it is routed to a reviewer/decision-maker; the engine never auto-PASSes these items. This design choice also has marketing value: against products claiming 'we automated everything', the product that states plainly what requires human judgment is more credible to an enterprise buyer.

legal · accessibility context
cultural context · brand voice
reality check · client approval
security authorization

What the engine does: Flags and routes items requiring human judgment.

What it doesn't: Never auto-PASSes these items.

What the output is: Manual-item list + rationale + routing.

For decision-makers: The credible limit of automation claims.

For technical teams: The reviewer flow is a formal part of the process.

Scope at a glance

Scope

Static security review over source and configuration files: secret leaks, exposed files, risky client code and server-side signals.

Out of scope

Active exploitation, penetration testing, live-system intervention and tests that require authorization.

Evidence delivered

Pattern-based findings with file and line references, severity class and the recommended next step.

When is extra authorization needed?

Live testing, penetration testing or any step touching production systems requires separate written authorization.

COMPARISON

Two tables, two boundaries

SAST	DAST
Static source/file analysis — the engine does this; no code is executed.	Active requests against a running system — written authorisation only, outside engine scope.

Header/file	Approach
`CSP`	Recipes are produced; duplicate policies are never created.
`HSTS`	HTTPS redirect + header readiness.
`X-Content-Type-Options / frame-ancestors`	Static readiness; the live grade comes from SecurityHeaders.
`security.txt`	Published once an approved security contact channel is defined; on in-scope sites it is verified live under /.well-known.

TWO WORLDS SAST and DAST: two worlds, one honest sentence

Static analysis (SAST) looks at sources: files, patterns, configurations. Dynamic testing (DAST) fires requests at a running system: it pushes inputs and provokes responses. WebTrustEngine lives in the first world and pins that with a single sentence: no check executes code, no check sends a request at a target.

The corporate value of the split is authorisation. Static review of a file root you own is always legitimate; active testing is legitimate only under written authorisation and belongs to specialist teams operating under it. The engine never blurs that line — on the contrary, the report states that each of the 68 security patterns is in the 'detects, never exploits' class.

THE PERMISSION GATE Tests that require authorisation: the list is public

Port scans, vulnerability scans, authentication brute-forcing, load and stress tests, social-engineering exercises — all are out of scope, and reports phrase this not as 'not performed' but as 'by definition not this product's job'. If a vendor tells you 'we scanned it', the first question is the date on the written authorisation; the second is which class the scan belonged to.

THE HEADER FAMILY CSP, HSTS and relatives: recipe discipline

A Content Security Policy written wrongly does not protect a site; it breaks it. The engine therefore never 'guesses smartly' at CSP: it reads the existing policy, never generates a conflicting second one, and always presents change as a single applicable recipe. HSTS gets the same discipline: no permanent header is proposed before the redirect chain is verified, because a wrong HSTS rollback is among the most expensive mistakes.

The rest of the family — content-type lock, framing limits, referrer policy, permissions policy — is flagged as static readiness, with the live grade left to SecurityHeaders. The recipe's job is not to collect the grade but to make it collectable.

THE EXTERNAL ROLE External tools as referees, not rivals

SSL Labs, SecurityHeaders and their kin are referees in this model, not competitors. The engine's output is never 'my grade'; it is 'this is the state in which you step in front of the referee'. That framing also makes the gap between internal report and external grade meaningful: if they differ, either an intermediate layer is flattening a header or a recipe was partially applied — both findable, provable problems.

FROM THE FIELD

What the security boundary looks like in practice

The boundary earns its own page because security is where inflated claims do the most damage. The engine's position is strict and symmetrical: everything it states about security comes from static analysis of files it was given, and nothing it states implies an attack was attempted. It reads source and configuration the way a careful reviewer would — it never sends a request to a running system, never authenticates, never fuzzes a form.

That single restriction draws the SAST/DAST line cleanly. Static application testing over the delivered files: inside scope, evidenced, repeatable. Dynamic testing against production: outside scope, and legitimate only under written authorisation naming targets, windows and exclusions. The engine will happily prepare the ground for such a test — its classified findings make an efficient starting map — but the test itself belongs to professionals hired for it. Headers follow the same discipline: CSP, HSTS and their siblings are produced as recipes and verified as readiness; the live grade belongs to SecurityHeaders, and the engine never pre-announces it.

FOUR PATTERNS

Four examples from the static pattern set

To make the 68 patterns concrete, four conceptual examples. Embedded secret: an API-key-shaped string forgotten inside a JavaScript file. Evidence is the path and line context; the action is revoking and removing — the engine never tries the key, it classifies its presence. Mixed content: an image or script called over http:// inside an HTTPS page; usually a SafeFix candidate. Stale library reference: a script URL carrying a known-old version number — the engine reports the version sighting and leaves the upgrade decision to the team that knows the change risk; it does not shout "vulnerable". Exposed backup trace: a .bak/.old/archive filename pattern left in public. Evidence is the filename; the action is a removal recipe.

All four share the same shape: file-derived evidence, sober classification, actionable next step — without a single request fired at a live system.

THE AUTHORISED PATH

The legitimate road to active testing

Where static review ends, active testing begins — through one gate only: written authorisation naming scope, window and exclusions. Even then the work belongs to penetration-testing professionals; the engine's role is to hand them its classified findings as an efficient starting map. The sentence "we performed a pentest" is never constructed on any surface of this brand — and because it never is, what the static layer does say can be trusted.

READING FINDINGS

How to read a security finding without panic

A static security finding is an observation, not a verdict. Read it in three moves: what file, what pattern, what class. A "conditional" item means the risk depends on context only your team knows; an "external" item means the fix lives on a platform, not in the files. Treating every line as an emergency wastes the map; treating the map as a checklist, in class order, is what it was built for.