The following token value is used as an example throughout this chapter:
A sample project named fast-examples-rails is available on Wallarm’s GitHub. Its purpose is to demonstrate how to perform FAST integration into existing CI/CD processes. In this example, FAST node will be used in CI mode.
This document contains the following pieces of information:
- An explanation of how the sample application works.
- A detailed step-by-step description of a FAST integration. The explanation will closely follow the steps described earlier.
- A demo of the FAST integration in action.
The sample application is a web application that allows you to post something to a blog and then manage the blog posts.
The application was written in Ruby on Rails and is shipped as a Docker container.
RSpec executes a few integration tests for the following scenarios:
- Navigating to the page with posts.
- Creating a new post.
- Updating an existing post.
- Deleting an existing post.
Capybara and Selenium help to convert these tests into a set of HTTP requests to the application.
The aforementioned integration tests are described in the
Here you will find an overview of FAST integration with RSpec and CircleCI for the sample project.
We can point a Selenium server to a proxy server with the
HTTP_PROXY environment variable. Thus, HTTP requests to the application will be proxied. Usage of this proxying mechanism allows passing the requests issued by the integration tests through the FAST node into the existing testing flow with minimal intervention:
A CircleCI job is built with all the aforementioned facts in mind. The job comprises the following steps (see the
You need to obtain a token and pass its value into the CircleCI project via the
TOKENenvironment variable. After a new CI job is in place, the variable’s value is passed to the Docker container, where the job is executed.
In this stage a few Docker containers are to be built for a set of services. The containers are placed in a shared Docker network, therefore they could communicate with each other using the IP addresses as well as the containers’ names.
The following services are built (see the
app-test: a service for the target application and the test tool.
A Docker image for the service comprises the following components:
The target application (reachable via HTTP at
The RSpec test tool, combined with Capybara.
Capybara: configured to send HTTP requests to the target application
app-test:3000with the use of the Selenium server
fast: a service for the FAST node.
The node is reachable via HTTP at
The token is passed to the service’s container by the
WALLARM_API_TOKEN=$TOKENenvironment variable. The token is required for the proper FAST operation.
selenium: a service for the Selenium server. Capybara, from the
app-testcontainer, uses this server for its operation.
HTTP_PROXY=http://fast:8080environment variable is passed to the service’s container to enable requests proxying through the FAST node.
This service is reachable via HTTP at
All services form the following relationships:
Due to the aforementioned relationships and FAST operation modes, the services should be deployed in a strict order.
When the FAST node operates in recording mode, that order is:
When the FAST node operates in testing mode, that order is:
Note that the
seleniumservice is not required for testing mode; therefore, it is not necessary to run this service.
Starting services in recording mode.
seleniumservices are deployed sequentially by issuing the
docker-compose up -d fast seleniumcommand.
Upon successful deployment of the Selenium server and the FAST node, it is time to deploy the
app-testservice and execute the RSpec tests. To do so, the following command is issued:
docker-compose run --name app-test --service-ports app-test bundle exec rspec spec/features/posts_spec.rb.
Traffic flow is shown in this image:
After the RSpec integration tests are complete and the FAST node has recorded all required baseline requests, switch the FAST node's operation mode to test the target application for vulnerabilities.
Starting services in testing mode.
app-testservice by issuing the
docker-compose up -d app-testcommand.
Next, run a FAST node in testing node by issuing the following command:
docker-compose run -e CI_MODE=testing -e TEST_RUN_URI=http://app-test:3000 fast
Traffic flow is shown in this image:
The testing result is obtained and the FAST node is terminated along with the CircleCI job.
The RSpec process’s exit code is passed to the
docker-compose runprocess, and then to the CircleCI.
The described CircleCI job closely follows the steps listed earlier:
- Create a FAST node in the Wallarm cloud and copy the provided token.
- Copy the fast-examples-rails sample project files into your own GitHub repository.
- Add your GitHub repository to the CircleCI (press the “Follow Project” button in CircleCI) so that the CI job fires up every time you change the content of the repository. A repository is called “a project” in CircleCI terminology.
TOKENenvironment variable to your CircleCI project. You can do this in the settings of the project. Pass the FAST token as a value of this variable:
Push something to the repository to start the CI job. Make sure that the RSpec integration tests are successfully finished (see the console output of the job):
The FAST node has finished baseline requests recording by now.
Make sure that the test run is executing.
This means that the FAST node is operational and is in testing mode.
You should see the CI job status in the messages in the CircleCI console. These messages are similar to the ones described here.
You can explore the job log on the CircleCI website:
You could explore the vulnerabilities in detail on the Wallarm portal. For example, you could take a look at the completed test run to find out that a few XSS vulnerabilities were found in the sample application:
FAST has strong capabilities for integration into existing CI/CD processes as well as for finding vulnerabilities in the application even when the integration tests pass without any errors.