What's New in SpartanX: August 2026 Release
This release makes the platform's testing deeper and its output easier to act on. The headline is a combined static and dynamic testing workflow that now covers source code, mobile binaries, and live APIs in a single engagement. Alongside it: a new notifications system, automatic report generation at the end of an engagement, audit-ready branded reports, source code upload without a repository connection, a Linear integration, and a faster real-time view of engagements in flight.
Combined SAST and DAST workflows
Improved. You can now run static analysis and dynamic validation as one workflow instead of two disconnected exercises. SpartanX runs full SAST across your source code, then takes what it found and validates it at runtime against the asset actually running, so the finding you receive carries evidence of exploitation rather than a line number and a severity guess. Static analysis tells you a vulnerability may exist. This workflow tells you whether an adversary can reach it.
Coverage now spans three asset types in the same engagement:
Web and API: full SAST on the source, then runtime validation of each finding through Targeted Attack Validation.
Android: static analysis of the application binary, dynamic testing against the running app in emulation, and dynamic testing of the API endpoints the app calls.
iOS: static analysis of the application binary, plus dynamic testing of the API endpoints the app calls.
Android support includes multi-part .xapk containers, so split application packages can be submitted as they come off the build.
The practical effect is that a mobile application and the backend it depends on stop being two separate assessments. The same engagement reads the code, runs the app, exercises the API, and reports one connected picture of what is exploitable.
Targeted Attack Validation over NodeX
Improved. TAV can now take the output of your existing scanners and revalidate those findings against targets that live inside your private network, reached through the NodeX connector.
This matters if your scanners produce more findings than your team can triage by hand, which is most teams. Instead of working down a list of maybe-exploitable results, you load the scan output and SpartanX attacks the targets it names, returning a verdict on each finding with the evidence behind it. Because the work runs over NodeX, internal assets that were never reachable from outside your perimeter are now in scope for that validation.
Upload source code as a ZIP archive
New. Connecting a repository is no longer the only way to get code into the platform. You can now upload a .zip of your source directly from the asset menu, and SpartanX creates a code asset from it that is immediately available for SAST and combined SAST and DAST engagements.
This is for the cases where a repository connection is not practical: code that lives outside your connected provider, a specific release snapshot you want assessed, or a codebase governed by access rules that make a standing integration difficult. Uploaded archives are inspected before they are accepted, and archives that are malformed or structurally unsafe are rejected rather than processed. Once accepted, the code asset behaves like any other, including the context it contributes to findings elsewhere in the engagement.
Notifications system
New. SpartanX now tells you when something happens instead of waiting for you to check.
Notifications are organized as a catalog of rules covering engagements, playbooks, infrastructure, and system events, delivered by email to the workspace addresses you select. Three rules are enabled by default: Engagement Completed, NodeX Disconnected, and Credit Balance Low. Rules are configured per workspace, and enabling, disabling, and channel configuration are restricted to the Security Manager role, so notification settings cannot be changed by anyone who happens to have access to the workspace.
Scheduled reports
New. You can now decide, when you set up an engagement, which reports should be produced the moment it finishes. Those reports generate on their own and arrive by email through the notifications system, with no one needing to notice the status change and start the job.
The C-Level report is selected by default. You can add others from the report catalog or remove the default entirely if you would rather generate everything by hand. Nothing about the on-demand report path changes; this simply removes the gap between an engagement completing and someone reading the result.
Branded and co-branded reports
New. PDF export now offers three tiers, chosen at the point of export:
Unbranded: no logos or branding, for internal circulation.
Branded: SpartanX branding, assessment name, and timestamp.
Audit-Ready: a co-branded evidence pack built for auditors.
The Audit-Ready tier is the significant one. It carries both your organization and SpartanX on the cover, drawn from a new Organization Details section in your settings, along with the assessment period, report ID and version, scope summary, the methodologies and frameworks referenced (OWASP, PTES, NIST SP 800-115, MITRE ATT&CK), an independence and attestation statement, and a signatory block. It is designed to be handed to an auditor and accepted as evidence on its own.
The security content is identical across all three tiers. Branding changes the cover, the headers and footers, and the metadata block. Findings, severity ratings, exploit evidence, and remediation guidance never vary by tier.
Linear integration
New. Teams running on Linear can now push findings straight into their tracker, at parity with the existing Jira integration.
Connect Linear over OAuth from the integrations page, map your teams, projects, workflow states, and labels, then select any number of vulnerabilities and create Linear issues in one action. Severity maps to Linear's priority scale automatically, and issues land in the target team's backlog with a link back to the finding in SpartanX. Playbooks for creating, searching, syncing, and SLA tracking ship alongside it, so the same automation you have for Jira is available for Linear.
Real-time engagement dashboard
Improved. The engagement view now updates live. Vulnerability counts, severity breakdowns, and charts move as the engagement runs, with no page reload, and plan-level progress shows each asset in scope as its own step so you can see exactly where an engagement is rather than watching a single bar creep forward. Vulnerability counts in plans update in real time as well. Panels you hide stay hidden the next time you open the view.
Also in the platform: Autonomous Action Runtime Management
Already available. AARM is not new in this release, but it governs everything described above, and it is worth restating what is enforcing the boundaries while these agents work.
SpartanX enforces guardrails at five layers: a non-overridable prohibition on destructive and irreversible operations embedded in every agent skill; an adversarial review of the plan before execution; Dynamic Runtime Guardrails that intercept and evaluate every action against the engagement's accumulated context; Aegis, a deterministic, rule-based egress gateway with no language model in it; and real-time trajectory steering that keeps the rules of engagement in front of the agent as it works.
The level of enforcement is your decision, set per engagement at launch, with three positions ranging from runtime guardrails disabled for non-production environments to full runtime enforcement plus the Aegis egress gateway, which is the posture we recommend for production and regulated environments. Skill constraints, adversarial plan review, and trajectory steering are in force at every position and cannot be turned off. Where an action cannot be confidently classified as safe, it is not taken.
The full implementation, including what we deliberately did not build and what our guardrails cost you in findings and in time, is documented in AARM Is No Longer a Specification.
Fixes and security improvements
This release also includes a range of bug fixes, performance improvements, and security hardening across the platform.
