@pensar/apex 2.0.1 → 2.0.2-canary.9e4e15cf

package/build/{cli-w2st266h.js → cli-jh6k2m9z.js}

@@ -2,13 +2,13 @@ import {
   OffensiveSecurityAgent,
   isMemoryEnabled,
   readPlan
-} from "./cli-zpdmnz8c.js";
+} from "./cli-qdh225p7.js";
 import {
   createLogger,
   init_lazyLogger,
   init_structured,
   scopedLogger
-} from "./cli-z1dapp7v.js";
+} from "./cli-dk63pna5.js";
 import {
   exports_external1 as exports_external,
   init_zod
@@ -170,6 +170,27 @@ var SECTION_CREDENTIAL_DISCOVERY = `Credential & Secret Discovery:
   - Mention the public identifiers only as supporting context, not as additional secrets
 - When validating an exposed key, verify what access it actually grants. A key that returns 200 on a single endpoint is less severe than a key that provides access to user data, admin functions, or billing APIs.
 - Title findings precisely: "Exposed Backend API Key" is better than "Hardcoded API Keys and AWS Infrastructure Configuration" which conflates secret and non-secret data.`;
+var SECTION_FINDING_QUALITY = `Finding Framing, Titles & Remediation:
+
+Lead with the strongest demonstrated impact:
+- The title and the FIRST sentence of the description must state the strongest impact you actually PROVED, not the weakest observable symptom. If your POC reads file/record contents belonging to another tenant, the finding is "unauthorized cross-tenant data access" / IDOR — NOT "enumeration" or "status-code oracle", even if an oracle is how you first noticed it. Frame around the data you accessed, then mention the oracle/mechanism as the technique.
+- Do not bury a high-impact result inside a low-impact framing. If you can access content, your evidence must show the content you accessed (and that the test identity should not have access to it), not merely that an ID exists.
+
+Title hygiene:
+- A title names the vulnerability class + the affected component or root cause (e.g. "Authorization Bypass Leaks Page Content for All /dev Routes via RSC 307 Body"). 
+- When the root cause is systemic (one shared layout, middleware, or helper affecting many routes), title it for the systemic cause, NOT a single example route. Do not title a class-wide issue after one instance like "/dev/colors" when the body says "any /dev page".
+- No editorial asides or comparisons in titles (e.g. drop "(Distinct from the Egnyte Callback)"). The title must be consistent with the scope stated in the description.
+
+Prove the access-model delta (authorization / IDOR / data-exposure findings):
+- Explicitly state the access model: which identity/role you tested as, and what that identity should vs should not be able to see.
+- Prove the boundary was actually crossed: show that the data returned belongs to a DIFFERENT tenant/user, or is admin-only data a member should not see. A 200 response or a bypassed redirect is NOT sufficient on its own — demonstrate that the exposed data is sensitive and out-of-scope for the test identity.
+- If you bypassed an authorization boundary but the data returned is non-sensitive or plausibly same-tenant/expected-visible, say so plainly in the evidence and impact. This is still a boundary failure worth reporting, but do not overstate the confidentiality impact — let the CVSS reflect what was actually exposed.
+- When you cannot confirm whether exposed data is cross-tenant vs same-tenant, state the uncertainty rather than assuming the worst case.
+
+Remediation quality:
+- Give specific, root-cause remediation — not generic "add an authorization check".
+- For authorization failures, emphasize enforcing the check AT the data-access boundary (in the data-fetching function / handler), not relying solely on layout-, middleware-, or routing-level protection that streaming, prefetch, or direct calls can bypass. Name the anti-pattern when present.
+- OAuth state / CSRF / PKCE: the core requirement is a state value that is unguessable (high-entropy random), bound to the user/session that initiated the flow, single-use, and validated on return — or PKCE as an equivalent fix. Frame these as the primary remediation. HMAC-signing or encrypting the state is valid defense-in-depth, but do NOT present "lacks cryptographic signature" as the core issue when an unguessable, properly-bound, validated state (or PKCE) resolves it.`;
 var SECTION_SECURITY_HEADERS_CORS = `Security Headers & CORS:
 - Do NOT recommend X-XSS-Protection — it is deprecated by all major browsers (Chrome, Firefox, Edge). Recommend Content-Security-Policy instead.
 - CORS analysis must account for the endpoint's authentication model:
@@ -239,6 +260,8 @@ ${SECTION_CREDENTIAL_DISCOVERY}
 
 ${SECTION_SECURITY_HEADERS_CORS}
 
+${SECTION_FINDING_QUALITY}
+
 ${SECTION_STATE_CHECKPOINTING}`;
 var PENTEST_SYSTEM_PROMPT_EXFIL = `You are an expert penetration tester performing a targeted security assessment with the goal of demonstrating full exploit impact.
 
@@ -283,6 +306,8 @@ ${SECTION_CREDENTIAL_DISCOVERY}
 
 ${SECTION_SECURITY_HEADERS_CORS}
 
+${SECTION_FINDING_QUALITY}
+
 ${SECTION_STATE_CHECKPOINTING}`;
 var PENTEST_SYSTEM_PROMPT_TASK_DRIVEN = `You are an expert penetration tester performing a targeted security assessment.
 
@@ -321,6 +346,8 @@ ${SECTION_CREDENTIAL_DISCOVERY}
 
 ${SECTION_SECURITY_HEADERS_CORS}
 
+${SECTION_FINDING_QUALITY}
+
 ${SECTION_STATE_CHECKPOINTING}`;
 var PENTEST_SYSTEM_PROMPT_TASK_DRIVEN_EXFIL = `You are an expert penetration tester performing a targeted security assessment with the goal of demonstrating full exploit impact.
 
@@ -359,6 +386,8 @@ ${SECTION_CREDENTIAL_DISCOVERY}
 
 ${SECTION_SECURITY_HEADERS_CORS}
 
+${SECTION_FINDING_QUALITY}
+
 ${SECTION_STATE_CHECKPOINTING}`;
 function buildPentestSystemPrompt(session, role = "orchestrator") {
   if (role === "orchestrator") {

package/build/{cli-88bhxzr1.js → cli-kj5vjbnd.js}

@@ -1,7 +1,7 @@
 import {
   getCurrentVersion,
   init_installation
-} from "./cli-0yptvbbm.js";
+} from "./cli-0t1j4jh4.js";
 import {
   __esm
 } from "./cli-8rxa073f.js";

package/build/{cli-eptabm2j.js → cli-kxpba6jy.js}

@@ -3,7 +3,7 @@ import {
   init,
   init_config,
   update
-} from "./cli-88bhxzr1.js";
+} from "./cli-kj5vjbnd.js";
 import {
   __esm
 } from "./cli-8rxa073f.js";

package/build/{cli-1f5zzrxj.js → cli-nc2yvszh.js}

@@ -3,7 +3,7 @@ import {
   init_lazyLogger,
   init_structured,
   scopedLogger
-} from "./cli-z1dapp7v.js";
+} from "./cli-dk63pna5.js";
 
 // src/core/integrations/wandb/client.ts
 init_structured();

package/build/{cli-8g5cwvbm.js → cli-p904s2yj.js}

@@ -1,7 +1,7 @@
 import {
   config,
   init_config
-} from "./cli-eptabm2j.js";
+} from "./cli-kxpba6jy.js";
 import {
   __esm
 } from "./cli-8rxa073f.js";

package/build/{cli-fa7nrded.js → cli-ppq4kh08.js}

@@ -1,9 +1,9 @@
 import {
   OffensiveSecurityAgent
-} from "./cli-zpdmnz8c.js";
+} from "./cli-qdh225p7.js";
 import {
   detectOSAndEnhancePrompt
-} from "./cli-cc13ydyx.js";
+} from "./cli-w1nb1y6h.js";
 import {
   createLogger,
   hasToolCall,
@@ -11,7 +11,7 @@ import {
   init_lazyLogger,
   init_structured,
   scopedLogger
-} from "./cli-z1dapp7v.js";
+} from "./cli-dk63pna5.js";
 
 // src/core/agents/specialized/authenticationAgent/agent.ts
 init_dist();