The REST API Static Security Testing plugin lets you add an automatic static application security testing (SAST) task to your CI/CD pipelines. The task checks your OpenAPI files for their quality and security from a simple Git push to your project repository when the CI/CD pipeline runs.
The plugin is powered by 42Crunch API Security Audit. Security Audit performs a static analysis of the API definition that includes more than 200 checks on best practices and potential vulnerabilities on how the API defines authentication, authorization, transport, and data coming in and going out. For more details on the checks, see API Security Encyclopedia.
As a result of the security testing, your APIs get an audit score, with 100 points meaning the most secure, best defined API. By default, the threshold score for the build task to pass is 75 points for each audited API, but you can change the minimum score in the settings of the pipeline task.
API contracts must follow the OpenAPI Specification (OAS) (formely Swagger). Both OAS v2 and v3, and both JSON and YAML formats are supported.
- Install the plugin.
- Add the build step to the job.
- Add new
42Crunch API Token
credential. - Create an API token in 42Crunch platform and copy its value into the credential.
- Save the job configuration and run the job.
- Click the links in the task output for detailed reports.
For more details, see the full documentation.
By default, the task locates all OpenAPI files in your project and submits them for static security testing. You can include or exclude specific paths from the discovery phase can omit the discovery phase completely by adding a task configuration file 42c-conf.yaml
in the root of your repository and specifying rules for the discovery phase. For more details, see the documentation.
All discovered APIs are uploaded to an API collection in 42Crunch Platform. This collection is created at the first run of the task, and is tied to the repository name and branch name it was created from. During the subsequent task runs, the APIs in the collection are kept in sync with the changes in your repository.
To be able to correctly match new API collections to your source control, the task must know what repository and branch the API files it discovers come from. For this, the task uses the parameters repositoryName
and branchName
. By default, repositoryName
uses the environment variable ${GIT_URL}
and branchName
the variable ${GIT_LOCAL_BRANCH}
. If you are using Jenkinsfile to configure the task on your pipeline, you must explicitly specify the parameters and values in your configuration.
In most cases, these default variables are correctly populated, but depending on other plugins you use in your Jenkins configuration, you may have to change the values to match the environment variables these other plugins use so that the task gets the correct repository and branch names.
You can add a task configuration file 42c-conf.yaml
in the root of your repository, and to fine-tune the success/failure criteria. For example, you can choose on whether to accept invalid API contracts, or define a cut-off on a certain level of issue severity.
For more details, see the documentation.
The plugin is maintained by support@42crunch.com. If you run into an issue, or have a question not answered here, you can create a support ticket at support.42crunch.com.
If you're reporting an issue, do include:
- The version of the Jenkins plugin
- Relevant logs and error messages
- Steps to reproduce the issue