Example of FAST Integration into CI/CD

Chapter Conventions

The following token value is used as an example throughout this chapter: token_Qwe12345.

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:

  1. An explanation of how the sample application works.
  2. A detailed step-by-step description of a FAST integration. The explanation will closely follow the steps described earlier.
  3. A demo of the FAST integration in action.

How the Sample Application Works

The sample application is a web application that allows you to post something to a blog and then manage the blog posts.

The sample application

The application was written in Ruby on Rails and is shipped as a Docker container.

Also, RSpec integration tests were created for the application. RSpec employs Capybara to interact with the web application; Capybara uses Selenium to send HTTP requests to the application:

Testing flow

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.

Tests Location

The aforementioned integration tests are described in the spec/features/posts_spec.rb file.

How FAST Integrates with RSpec and CircleCI

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:

Testing flow with FAST

A CircleCI job is built with all the aforementioned facts in mind. The job comprises the following steps (see the .circleci/config.yml file):

  1. Necessary preparations:

    You need to obtain a token and pass its value into the CircleCI project via the TOKEN environment variable. After a new CI job is in place, the variable’s value is passed to the Docker container, where the job is executed.

    Pass the token into the CircleCI

  2. Build services

    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 docker-compose.yaml file):

    • 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 app-test:3000 after deployment).

      • The RSpec test tool, combined with Capybara.

      • Capybara: configured to send HTTP requests to the target application app-test:3000 with the use of the Selenium server selenium:4444 (see the spec/support/capybara_settings.rb file).

    • fast: a service for the FAST node.

      The node is reachable via HTTP at fast:8080 after deployment.

      The token is passed to the service’s container by the WALLARM_API_TOKEN=$TOKEN environment variable. The token is required for the proper FAST operation.

    • selenium: a service for the Selenium server. Capybara, from the app-test container, uses this server for its operation.

      The HTTP_PROXY=http://fast:8080 environment variable is passed to the service’s container to enable requests proxying through the FAST node.

      This service is reachable via HTTP at selenium:4444 after deployment.

    All services form the following relationships:

    Relationships between services

    Important Information

    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:

    1. fast,
    2. selenium,
    3. app-test.

    When the FAST node operates in testing mode, that order is:

    1. app-test,
    2. fast.

    Note that the selenium service is not required for testing mode; therefore, it is not necessary to run this service.

  3. Starting services in recording mode.

    The fast and selenium services are deployed sequentially by issuing the docker-compose up -d fast selenium command.

    Upon successful deployment of the Selenium server and the FAST node, it is time to deploy the app-test service 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:

    HTTP traffic flow in the recording node

    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.

  4. Starting services in testing mode.

    Run the app-test service by issuing the docker-compose up -d app-test command.

    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:

    HTTP traffic flow in the testing node

  5. 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 run process, and then to the CircleCI.

    The job result in CircleCI

The described CircleCI job closely follows the steps listed earlier:

CircleCI job in detail

Demo of FAST Integration

  1. Create a FAST node in the Wallarm cloud and copy the provided token.
  2. Copy the fast-examples-rails sample project files into your own GitHub repository.
  3. 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.
  4. Add a TOKEN environment 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:

    Pass the token into the project

  5. 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):

    RSpec tests are passed

    The FAST node has finished baseline requests recording by now.

  6. Make sure that the test run is executing.

    You could log in to the Wallarm portal using your Wallarm account and navigate to the “Testruns” tab in order to observe the process of testing the application against vulnerabilities in real time:

    Test run execution

    This means that the FAST node is operational and is in testing mode.

  7. 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:

    The completion of the CI job

    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:

    A detailed information about the vulnerability

Conclusion

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.

results matching ""

    No results matching ""