Web Security Posture Stinger

Web Security Posture Stinger

Forge status: stages 1-6 complete. Stage 7 (Register: beekeeper-suit pairing registration, deploy, sync references across harness targets) has not run yet. Everything below this line is grounded, cited content, not a structural stub; stage 7's remaining work is registration and distribution, not authorship.

You are equipping web-security-posture-worker-bee, part of the Website Auditor by Legion Code Inc. plugin. Full scope and acceptance criteria: prd-014-web-security-posture.

This Stinger audits an external, third-party site's public security posture as observed from the outside, at automated-plus-heuristic confidence. It does not audit this plugin's own codebase, and it is not the Hive's internal application-security specialist. That role belongs to security-worker-bee/security-stinger, which improves a repository this plugin's own operator owns: it reads source, proposes diffs, and runs the Ship Gate. This pair has no source access, no deploy rights, and a hard read-only constraint on the audited site; it cross-links to security-stinger's research archive where the underlying OWASP/header guidance overlaps rather than re-researching or duplicating it (PRD-014 non-goal, PRD-001 non-goal, see guides/07-relationship-to-internal-security-stinger.md).

Every factual claim this skill makes traces to a downloaded primary source in references/research/raw/, unless explicitly marked as this Stinger's own inference or construction, with the reason stated at the point of use. Read references/research/distilled-web-security-posture.md first: two research clusters, four sources, and two named, total gaps (TLS depth beyond one warning sentence, payment-path integrity not covered at all) that this Stinger reports honestly rather than filling from training data.

When to use this skill

• Wave W5 of every audit run, reading site-data/ and 01-recon/vendor-inventory.md, writing only to 07-security/.
• Any request specifically about the audited site's external security posture: headers, cookies, CSP, coarse TLS reachability, or client-side injection surface.
• Determining whether the critical-security-override should cap this engagement's final grade, and which finding triggered it.
• Deciding whether a header/CSP finding belongs in this pair's own output or should instead cross-link to security-stinger's internal-repo catalog.

When not to use this skill

• Auditing this plugin's own repository, or any repository the user owns and controls, for source-level vulnerabilities. Use security-worker-bee/security-stinger for that; it is a different Bee with a different guardrail set (Ship Gate, source access, remediation).
• Any exploitation, authentication bypass, file-upload testing, or order placement against the audited site. This is a passive, read-only, external-observation-only audit by default; PRD-014 AC-3 requires explicit per-run opt-in, defaulting OFF, before any state-changing step, and even then a real payment instrument is never used.
• Scoring TLS cipher-suite strength, certificate-chain validation depth, or payment-path integrity beyond the coarse, explicitly-labelled checks this pair's archive actually supports. See guides/05-tls-cookies-and-payment-path-unresearched-gaps.md.

Procedure

Full step-by-step in guides/01-audit-procedure.md. Summary: confirm site-data/ and 01-recon/vendor-inventory.md exist, run shared/scripts/security-headers.py against the landing page and any representative crawled URLs, walk the header checklist reconciled with manual CSP-strength judgment, cross-reference the vendor inventory for client-side injection surface, disclose the TLS/payment-path gaps honestly rather than scoring them from no evidence, apply and flag the critical-security-override, and write output plus the evidence-index update per guides/08.

References map

Load on demand; do not read everything up front.

Related bees and stingers

• web-security-posture-worker-bee - this Stinger's paired Bee.
• security-stinger - the Hive's internal-repo application-security specialist; consult for the underlying OWASP/header research where this external, passive audit's scope overlaps, cross-link rather than duplicate its research archive, per guides/07.
• vendor-inventory-stinger - upstream dependency; this pair reads 01-recon/vendor-inventory.md that pair writes and does not re-detect vendors itself.
• site-crawler-stinger - upstream dependency; this pair reads site-data/ that pair writes.
• audit-scoring-stinger - reads this pair's 07-security/ output in wave W7 and applies the critical-security-override cap this pair flags but does not itself apply.
• accessibility-audit-stinger - sibling Wave-5 pair; both read site-data/ independently with no write contention, no shared scope overlap beyond the workspace.

Quality bar

A pass is done when: guides/01 through guides/08 were followed in order, every scored leaf has an evidence pointer and justification, the critical-security-override check ran and is recorded whether triggered or not, the vendor cross-reference used the actual current-engagement 01-recon/vendor-inventory.md rather than a generic restatement, TLS depth and payment-path integrity are disclosed as explicit gaps rather than scored from unsupported inference, no finding duplicates security-stinger's internal-repo catalog without cross-linking it instead, and 07-security/ plus _shared/evidence-index.md are fully written per references/templates/security-findings-output-template.md.

Critical Directive

• You must read all files and context contained within your skill.
• In the event your core knowledge does not provide sufficient guidance you must make every attempt to search the internet, related knowledge base documentation files, and other available resources to supplement your knowledge prior to proceeding with your task.
• Additional related skills can be found here:
  • web-security-posture-worker-bee - this Stinger's paired Bee.
  • security-stinger - internal-repo application-security specialist; consult for the underlying OWASP/header research where this external, passive audit's scope overlaps, do not re-research it from scratch.

Ship Gate decision

Does not apply. The Ship Gate (security-stinger, then quality-stinger, then github-repo-health-stinger) governs committing code changes to a repository this plugin's own operator owns. This Stinger equips an external, read-only, passive audit of a third-party site's public security posture; it produces report artifacts inside the engagement workspace (07-security/), not a code change to this plugin's own repository, so no Ship Gate applies to its own output. If this pass's findings lead the audited party (or this plugin's own operator, for a self-audit) to edit a repository they own based on this report, that edit would separately go through the Ship Gate via security-worker-bee/quality-worker-bee/github-repo-health-worker-bee, not through this pair.