Example of FAST Integration into CI/CD

Chapter conventions

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

A sample project fast-examples-rails is available on the Wallarm’s GitHub. It’s purpose is to demonstrate how to perform FAST integration into existing CI/CD processes.

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 in a blog and then manage the blog posts.

The sample application

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

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

Testing flow

RSpec executes a few integration tests to test 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 the FAST integration with RSpec and CircleCI for the sample project.

RSpec supports pre-test and post-test hooks:

config.before :context, type: :feature do
    # Actions to take before the RSpec tests’ execution
  end
    # RSpec tests’ execution
  config.after :context, type: :feature do
    # Actions to take after the RSpec tests’ execution
  end

Practically, it means that it is possible to augment the steps RSpec takes to test the application with the steps involving FAST security testing.

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 proxying mechanism allows to pass the requests, issued by the integration tests, through the FAST node with the minimal intervention into the existing testing flow:

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 to a shared Docker network, therefore they could communicate with each using the IP addresses as well as 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 (it is reachable via HTTP at app-test:3000 after deployment).

      • The RSpec test tool, combined with Capybara. The tool contains all of the functions required to run the FAST security tests.

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

      The token is passed into the service’s container by the WALLARM_API_TOKEN=$TOKEN environment variable. The token is used by the functions, which are described in the config.before and config.after sections (see the spec/support/fast-helper.rb file), to perform manipulations with a test run.

    • fast: a service for the FAST node.

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

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

      Note on baseline requests

      The provided example do not employ the ALLOWED_HOSTS environment variable. Therefore, the FAST node recognizes all incoming requests as the baseline ones.

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

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

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

    All services form following relations between them:

    Relations between services

  3. Due to the aforementioned relations, the services should be deployed in a strict order as follows:

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

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

  4. Upon successful deployment of Selenium server and 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.

    Test and HTTP traffic flows are shown in the image:

    Test and HTTP traffics flows

    In accordance with the test run execution order, RSpec tests include all steps that are required to run the FAST security tests (see the spec/support/fast_hooks.rb file):

    1. A test run is created prior to the execution of the RSpec tests.

      Then the API call is issued to check if the FAST node is ready to record the baseline requests. The existing tests’ execution process is not started until the node is ready.

      Test policy in use

      This example uses the default test policy.

    2. RSpec tests are executed.

    3. The following actions are performed after the RSpec tests are done:
      1. The baseline requests recording process is stopped;
      2. The test run state is being monitored periodically:
        • If FAST security tests are completed successfully (the test run’s state is state: passed), an exit code 0 is returned to the RSpec.
        • If FAST security tests are completed unsuccessfully (some vulnerabilities were detected and the test run’s state is state: failed), an exit code 1 is returned to the RSpec.
  5. The testing result is obtained:

    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 the 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 CI job fires up every time you change the content of the repository. A repository is called “a project” in the 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 finished with success (see the console output of the job):

    RSpec tests are passed

  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

  7. You should see the CI job status reported as “Failed” after the testing process finishes:

    The completion of the CI job

    Given that there is the Wallarm demo application under the test, the failed CI job represents the fact that FAST detected some vulnerabilities in the application (the message “FAST tests have failed” should appear in the build log files). The failure is not invoked by any build-related technical issues in this case.

    Error message

    The “FAST tests have failed” error message is produced by the wait_test_run_finish method,that is located in the spec/support/fast_helper.rb file, before the termination with the exit code 1.

  8. There is no information about detected vulnerabilities displayed in the CircleCI console during the testing process.

    You could explore the vulnerabilities in detail on the Wallarm portal. To do this, navigate to the link to the test run. The link is displayed as a part of the FAST informational message in the CircleCI console.

    This link should look like this one: https://us1.my.wallarm.com/testing/testruns/test_run_id

    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

At this point, it was demonstrated that FAST has strong capabilities of integration into existing CI/CD processes as well as finding vulnerabilities in the application even when the integration tests are passed without any errors.

results matching ""

    No results matching ""