A frequently asked question from customers is, "Why didn't FAST find a vulnerability when it definitely exists in the application?" We began to explore the logs and look for the reasons for this behavior. In most cases, the answer is simple: FAST failed to path authentication.

And we took the first steps in solving this problem.

The first move was to highlight the problems of authentication themselves. Now, the Wallarm Console displays the new "Auth failed" status if FAST was unable to test due to an authentication error.

The second move was to add a simple authentication method. What does that mean? Now, you can provide the FAST node with the test client credentials and specify the query parameters they need to substitute. These credentials will be used when executing test queries. Such a mechanism will avoid the use of an expired token, QA credentials, etc.

Read more about the FAST authentication process on our docs portal

We are continuing to simplify security testing automation in your CI/CD pipelines. Many users have requested to have FAST work with several CI pipelines simultaneously. We’re glad to announce that such support was added in the latest version of FAST.

You no longer need to run multiple instances of the FAST node for each CI pipeline. Instead, the only instance of the FAST node can now be used in multiple pipelines. It greatly simplifies tool deployment and makes the whole testing architecture more elegant.

Just specify an additional parameter BUILD_ID in the configuration of your project in the CI/CD system. For example if you work in Jenkins, add -e BUILD_ID = $ {env.BUILD_ID} into the command that launches FAST.

The parameter should be unique for each build so that the FAST node can associate any given requests with the necessary Test Run. Note that support for parallel pipelines works with both modes: recording baselines and running security tests.

Don’t have FAST but want to try it out? Send us a note!

We released an important FAST update. You can now disable any tests for the static files and with that significantly improve test performance.

Traffic of automated tests and manual testing of QA engineers typically contains HTTP requests to the static files (such as images, js, CSS). By default, FAST records baselines for all the requests and for the static files too. Most often, running tests against static files doesn't make sense. So skipping these tests can give you speed boost and allow testing to finish much faster.

In the TestRun settings, you can now enable option "Skip following files extensions" and choose which files to consider as static. They be excluded for the further testing.

The vital part of FAST's philosophy is making security testing automation easier, especially within CI/CD pipelines. It'll be simpler with the new feature — Reuse Test Record.

You can now rerun existing security tests that you created earlier, without recording a new Test Record. It may be especially convenient when the methods and variables of your API haven't changed, and it doesn't make sense to record new test baselines. You can just run the Test Run using the existing Test Record. For instance, after the new build of the application.

In FAST Console, you can try the action "Create similar Test Run". Note: you can reuse only Test Records that have more than one baseline and are not in Recording state.