Skip to main content

November

· 4 min read

NG Production Release Update - APIsec_cloud_7.11.2.0 ( November 06, 2026 )​

Detection identifiers for findings​

Each finding in scan results now includes a detection identifier that correlates the finding to its detection. This helps CI/CD gating, so a pipeline can map scan findings to their detections and gate a build on that correlation.

Preferred agent available over the API​

You can now read the default hosted agent configured for an instance using API credentials. Automated workflows can discover which agent an instance uses without going through the interface.

Owner and Attacker attribution in authorization test logs​

Broken Object Level Authorization test logs now label each executed step with the identity that performed it, owner or attacker. When you review how an authorization test was carried out, you can see which role made each request, making the evidence behind a BOLA result easier to follow and validate.

Fixes and improvements:​

  • Vulnerability attribution: Findings now stay tied to the endpoint whose own request produced the evidence, so a result is no longer attributed to an endpoint that was only reached while priming another.
  • Credential masking in logs: Credentials used in custom authentication chains are masked by value across scan and test records, including request headers, request bodies, step URLs, stored outcomes, and activity history.
  • BOLA scope detection: A genuine BOLA finding is retained even when the attacked endpoint falls outside the configured scan scope.
  • Scan status accuracy: A stopped scan consistently reports an Aborted status, including when final summary processing runs.
  • Security Hub count timeliness: Unique-endpoint and Security Hub counts refresh promptly after a scan completes, restoring the expected update behavior.
  • Security Hub for low-activity tenants: Tenants with no recent activity no longer show all-zero Security Hub counts.
  • Security Hub report delivery: A tenant-scoped Security Hub report is delivered tenant-wide when the first recipient cannot be resolved, instead of stopping without notice.
  • Re-Scan reliability: The Re-Scan action stays responsive after the scan-scope confirmation dialog is opened and closed.

NG Production Release Update - APIsec_cloud_7.11.1.0 ( November 02, 2026 )​

False-positive re-verification​

Revoking a false positive now starts a scoped re-verification scan for that finding. If the vulnerability still reproduces, it creates a new active finding so nothing is silently lost. If it is genuinely gone, the finding is dismissed. If it cannot be revalidated, for example when the credential is rejected, or the target cannot be reached, the finding is kept and the scan reports that outcome rather than clearing it. Scan details now show the re-verified result accurately.

Scans fail closed on unreachable or untested targets​

When a target cannot be reached, or its tests cannot execute, the scan reports an errored or failed result and now carries summary counts instead of a clean pass for work that never ran. A clean result now reflects tests that actually ran against the API, so you can block a release on real coverage instead of a false green, and read the counts with confidence.

Other improvements:​

  • Findings resolve when a test permanently no longer applies: When an endpoint changes so a test can no longer apply to it, for example, it no longer requires authentication, the related unenforced-credential, RBAC, and JWT findings resolve on the next scan, so your open findings reflect the API as it is now without manual cleanup.
  • BOLA tests skip instead of falsely passing when the owner is denied: When the resource owner cannot reach its own resource, the attacker has nothing to reach, so the test is recorded as skipped with a reason rather than a pass, which keeps your results from showing a false clean on an endpoint that was never actually tested.
  • GraphQL request editing and query generation: You can edit GraphQL requests in the scan editor, and generated queries are built from the endpoint's schema, so your GraphQL endpoints scan with less manual setup.
  • Setup steps in multi-step scans (priming): Setup steps now send the endpoint's configured headers and take the created resource ID from the response, so they complete in more cases, and a step that cannot be wired is skipped with a reason instead of running against a half-created resource.
  • Hosted-agent results up to 100 MB: Results over 20 MB were previously rejected on upload and dropped, so those findings did not reach the platform.