XUNIA Security Platform v1: Zyra command center and planning API - #73
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 4a7bbcdf1c
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| const excluded = (manifest.exclusions || []).some((item) => targetMatches(item, target)); | ||
| if (excluded) continue; |
There was a problem hiding this comment.
Propagate nested exclusions into generated plans
When a parent URL is targeted and a child path is excluded, such as target https://host with exclusion https://host/billing, this comparison tests whether the exclusion contains the parent and therefore returns false. The plan still gives the worker the unrestricted parent URL, and the API response carries no exclusions, so scanners that crawl from that target can enter the explicitly excluded subtree.
Useful? React with 👍 / 👎.
| function normalized(target: EngagementTarget): string { | ||
| return target.value.trim().toLowerCase().replace(/\/$/, ""); | ||
| } |
There was a problem hiding this comment.
Preserve URL path casing during scope checks
For URL targets, lowercasing the entire value also lowercases the path, even though URL paths can be case-sensitive. An authorization for https://host/TenantA therefore authorizes https://host/tenanta/..., which can identify a different resource; parse URLs and normalize only case-insensitive components such as the scheme and hostname.
Useful? React with 👍 / 👎.
| return { | ||
| engagementId: manifest.engagementId, | ||
| mode: manifest.mode, | ||
| authorizationReference: manifest.authorizationReference, | ||
| destructiveActions: "DENIED", |
There was a problem hiding this comment.
Preserve the authorization expiry in generated plans
If a plan is created shortly before endsAt and queued until afterward, the returned plan remains indistinguishable from an in-window plan because the authorization window is checked only during construction and then discarded. Since the planning API returns only this plan to the delegated worker, include the expiry so execution can revalidate the authorization window immediately before running.
Useful? React with 👍 / 👎.
| }); | ||
| }); | ||
|
|
||
| app.post("/api/xunia/security/plan", requireAuth, (req: Request, res: Response) => { |
There was a problem hiding this comment.
Restrict plan creation to privileged operator roles
When these plans are consumed by the delegated security worker, any authenticated account—including a viewer—can currently mint PENTEST or SIMULATE plans because this route applies only requireAuth. Existing pentest creation and run endpoints in server/routes.ts require owner/admin roles, so this endpoint should enforce the same authorization boundary before producing a worker-consumable plan.
Useful? React with 👍 / 👎.
| const manifest = req.body as SecurityEngagementManifest; | ||
| const plan = buildSecurityPlan(manifest); |
There was a problem hiding this comment.
Validate the manifest at the API boundary
The type assertion performs no runtime validation, so an otherwise valid request with mode: "UNKNOWN" receives a 201 response: assertEngagementAuthorized never checks the mode and riskAllowed falls through to true. Invalid target types and empty target values can likewise reach plan steps, so parse the request with a runtime schema before building the plan.
Useful? React with 👍 / 👎.
| <Route path="/dashboard">{() => <ProtectedRoute component={Dashboard} />}</Route> | ||
| <Route path="/command-center">{() => <ProtectedRoute component={CommandCenterPage} />}</Route> | ||
| <Route path="/zyra-eyes">{() => <ProtectedRoute component={ZyraEyesPage} />}</Route> | ||
| <Route path="/xunia-security">{() => <ProtectedRoute component={XuniaSecurityPage} />}</Route> |
There was a problem hiding this comment.
Add the command center to application navigation
Registering this protected route does not make the new command center discoverable: a repo-wide search of client/src/components/Layout.tsx, which defines both desktop and mobile navigation from navGroups, finds no /xunia-security entry or other link to this route. Users can reach the feature only by manually entering its URL.
Useful? React with 👍 / 👎.
Integrated Zyra security control plane
Adds the visible and authenticated control plane for governed security assessment and authorized pentesting.
Included
/xunia-securityThis PR plans authorized actions only; bounded execution is delegated to the scoped worker layer in gpt-doug-llm.