Skip to content

feedback(rollout): Dial-WTF/PeerSpeak follow-up priorities from #33 #51

Description

@jeremyjs

Follow-up to #33. Now that PR #34 + cli-v0.2.3 have landed (G1 baseline, G2 partial, G3 cache, G4 action UX, plus #30 default ignores), here is the prioritized list of remaining work that would most accelerate Dial-WTF/PeerSpeak#1365 as a downstream consumer. Most items reference existing trackers; this is a single place to see PeerSpeak's ranking of them.

Top 3 asks if you only have time for three

1. #32 — publish CLI to public npm

Why: highest-leverage ask by a wide margin. PeerSpeak (Dial-WTF org) consuming @decoperations/owasp-wtf from GitHub Packages today requires a cross-org PAT with read:packages, a secret to rotate, and an .npmrc dance. Publishing to public npm reduces that to npx owasp-wtf with zero auth, zero secrets, zero org coupling. Removes the only structural friction in adoption.

Effort: ~2 hours (npm org + token + semantic-release wiring). PeerSpeak impact: removes the only setup friction.

2. --changed-workspaces --base origin/main (deferred half of G2)

Why: PeerSpeak's entire gate chain is change-aware via scripts/ci/compute-scope.ts. Without native change-aware scanning, we have to shell-glue the workspace list into repeated --workspace flags from our scope computer, doubling the surface area to maintain. Native --changed-workspaces aligns OWASP.WTF with our model and lets us delete shell glue.

Effort: 1–2 days (git-diff plumbing). PeerSpeak impact: lets the Security gate consume the same scope JSON every other gate uses.

3. Phase 2 milestone in GitHub with ETA

Why: PeerSpeak#1365 lists "OWASP.WTF Phase 2 complete" as a precondition for flipping the Security gate to branch-protection-required. Today "Phase 2" lives only in ROADMAP.md prose — no GitHub milestone, no API-queryable date. A milestone with the open Phase-2-relevant issues (#15, #17, #30, #31, #32, #36, #6) backfilled and a soft due date lets us plan against it.

Effort: 30 minutes. PeerSpeak impact: lets us write a real timeline in our own planning.

Next tier (significantly improves PeerSpeak adoption, not blocking)

4. #36 — triage and patch 21 self-scan vulnerabilities

Not a feature ask — but PeerSpeak's Security gate inheriting OWASP.WTF's own dep posture is awkward to merge-require if 21 known A06 vulnerabilities live in the tool's supply chain. Closing #36 is a credibility multiplier for every downstream adopter.

5. SECURITY.md with disclosure SLA

Once OWASP.WTF becomes a required PR gate at PeerSpeak, any CVE in its bundled scanners (gitleaks / semgrep / trivy / syft / grype) directly affects our merge availability. A documented disclosure policy + patch SLA lets us decide whether to keep the gate required or temporarily downgrade during a disclosure window. ~1 hour of writing.

6. Machine-readable fix-plan output

Today SECURITY_FIX_PLAN.md is markdown prose. For PeerSpeak's AI SWE agents to apply remediations autonomously rather than just read them, we need structured output: file path, line range, suggested replacement, reasoning. JSON is enough; SARIF fixes[] (despite the #24 history) is the ideal final shape. This is the difference between OWASP.WTF being an advisory voice and being a closed-loop autofix participant.

Effort: 2–3 days. PeerSpeak impact: unlocks an autonomous fix loop for AI agents that currently has to parse markdown.

Next-tier features tracked separately

Existing issue PeerSpeak relevance
#6 — per-PR canary releases Lets PeerSpeak validate integration against pre-stable builds without using @main
#31 — A10 SSRF native rule PeerSpeak has wallet / RPC / external API calls; SSRF coverage matters
#17 — SARIF schema validation Increases the value of the SARIF code-scanning output PeerSpeak will rely on
G5 (in #33) — Next.js / React rule pack PeerSpeak is Next.js end-to-end; AST-aware checks for server actions, NEXT_PUBLIC_* secret leakage, server-only imports in client components would significantly raise signal over the current regex rules

What this is not

PeerSpeak can adopt cli-v0.2.3 today as a non-blocking observer of the Security gate. The above is the order in which incremental work would compound on that base, ranked by what would let us flip the gate to branch-protection-required, then to autonomous fix-loop participant.

Happy to file any of the new asks (#3 milestone, #5 SECURITY.md, #6 machine-readable fix-plan) as separate issues if that fits your triage flow better.

Metadata

Metadata

Assignees

No one assigned

    Labels

    blockedBlocked — see commentenhancementNew feature or requestrisk:highHigh risk — requires human approval

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions