Originally reported by eWeek, April 2018. This article is based on statements made by Wallarm CMO Renata Budko at the time of the product launch.
What Is Wallarm FAST?
In April 2018, cybersecurity company Wallarm announced the launch of its Framework for Automatic Security Testing (FAST), a new product designed to help development and security teams automatically generate and run security tests against running applications.
Unlike traditional static analysis tools that inspect source code without executing it, FAST targets running applications, generating HTTP-based test cases derived from existing functional tests and using fuzzing to probe for vulnerabilities and unexpected application behavior.
How FAST Works: IAST, Fuzzing, and Functional Test Reuse
Application security testing broadly falls into three categories:
- SAST (Static Application Security Testing) – analyses source code or binaries without executing the application.
- DAST (Dynamic Application Security Testing) – probes a running application from the outside, simulating an attacker.
- IAST (Interactive Application Security Testing) – instruments a running application to observe behavior during test execution, combining elements of both SAST and DAST.
According to Wallarm CMO Renata Budko, FAST sits closest to the IAST category: “FAST is not a SAST, it is more akin to an IAST tool. The idea is that it uses QA functional tests and a fuzzer as an inducer and analyzes the responses to detect vulnerabilities and anomalies.”
The core workflow is straightforward: FAST intercepts existing functional test traffic (for example, HTTP requests generated by a Selenium test suite), uses that traffic as a baseline, and then applies its fuzzing engine to generate a large volume of additional security-focused test cases. Application responses are then analyzed for signs of vulnerabilities or anomalous behavior.
The Fuzzing Engine
Fuzzing is a well-established security testing technique in which malformed, unexpected, or random inputs are injected into an application to observe how it responds. FAST includes a proprietary fuzzing engine built by Wallarm, not derived from open-source projects, according to Budko.
The fuzzer is policy-driven: “The fuzzer is governed by the policy which specifies what parameters of the payload or the header to fuzz, and how to tune up the fuzzing so that generated payloads are more relevant.” This policy-based approach allows teams to target fuzzing effort at the most security-sensitive parts of a request rather than applying brute-force mutation indiscriminately.
Language-Agnostic and API-First Design
Because FAST constructs tests as HTTP requests rather than language-level instrumentation, it is not tied to any specific programming language or framework. “FAST is not language specific, it can be used to test apps and micro-services written in any language,” Budko told eWeek. “It constructs tests as HTTP requests and applies fuzzing to the body and where applicable, the header of the request.”
All key FAST operations — test generation, policy management, test execution, and results retrieval — are exposed via APIs, making the tool straightforward to embed in automated workflows.
Integrating FAST into a DevOps Pipeline
The rise of DevOps has made continuous security testing — often called DevSecOps — a practical requirement for fast-moving development teams. FAST was designed with this context in mind.
Jenkins Integration
Wallarm’s stated primary integration target at launch was Jenkins, the widely used open-source CI/CD automation server. Budko described a typical use case: “We expect a typical use case to be a FAST test run to be launched from Jenkins as part of a build acceptance criteria sequence.”
In practical terms, this means a Jenkins pipeline stage could trigger FAST after a successful build, run security tests against a staging environment, and gate promotion to production on the results — treating security testing as a first-class step in the delivery pipeline.
Selenium Compatibility
Teams already using Selenium for browser-based functional testing of single-page applications (SPAs) can feed those existing test runs directly into FAST. Budko explained: “Selenium is very popular for automating HTTP tests for SPAs. These automated functional tests make ideal baselines for FAST to apply its multiplier and generate more security tests.”
This is a meaningful productivity argument: rather than requiring security engineers to write a separate, dedicated test suite, FAST reuses the work QA engineers have already done, extending its coverage for security purposes at relatively low incremental cost.
Docker-Based Deployment
FAST is delivered as a Docker container, meaning deployment requires a Docker-compatible container runtime. At launch, no cloud-provider-specific integrations were available for FAST itself, although the existing Wallarm Application Security Platform was certified on both AWS and Google Cloud Platform at the time.
FAST vs. the Wallarm Application Security Platform
It is worth distinguishing FAST from Wallarm’s existing platform. Prior to FAST, Wallarm sold an application security platform focused on runtime protection, including:
- Real-time attack mitigation
- Bot protection
- Web Application Firewall (WAF)
- Dynamic Application Security Testing (DAST) for vulnerability detection
FAST targets a different stage of the software lifecycle — the pre-production testing phase — placing it in the application security testing (AST) market rather than the runtime protection market. The two products are complementary rather than overlapping.
Company Background
At the time of the FAST announcement, Wallarm had been operating since 2013 and had raised a total of $2.9 million in funding. The company indicated plans to expand FAST into a broader product line aimed at larger development organizations.
Key Takeaways for DevOps and Security Teams
- Reuse existing QA tests: FAST amplifies Selenium and other functional test suites into security test coverage without requiring a separate authoring effort.
- Language-agnostic: Works at the HTTP layer, so it is compatible with any backend technology stack.
- CI/CD native: Full API coverage and Jenkins integration make it suitable for automated pipeline security gates.
- Docker-delivered: Simple to deploy in any environment that runs containers.
- Policy-controlled fuzzing: Lets teams tune relevance and scope of generated payloads rather than relying on generic mutation strategies.
Note: This article reflects Wallarm’s product capabilities and company status as of April 2018. Readers should consult current Wallarm documentation for up-to-date product information.