Integrating Acunetix with GitLab for CI/CD

You can integrate your Acunetix Premium account with GitLab for issue management and for CI/CD purposes. This article shows how to configure your GitLab account and how to integrate with it in Acunetix Premium for CI/CD. If you want to know how to integrate with GitLab for issue management, read the article Step-by-step configuration with GitLab.

Integrating Acunetix with GitLab for continuous integration and deployment is a 2-step process.

Step 1: Prepare your Acunetix target information

• Log in to your Acunetix installation.
• Go to your list of targets and click on the target you wish to work with.
  
• Retrieve the target ID from the URL.
  
• Go to your Profile page and retrieve your API key.

Step 2: Configure GitLab to integrate with Acunetix

• Log in to your GitLab account.
• Go to your list of projects and click on the project you wish to work with.
  
• Click on the Set up CI/CD button.
  
• This will require you to create a YML file; edit this file to have the following contents:

  ScanJob:
    script: |-
      curl -k -i --request POST --url "https://online.acunetix.com/api/v1/scans" --header "X-Auth: [APIKEY]" --header "content-type: application/json" --data '{"profile_id":"11111111-1111-1111-1111-111111111111","schedule":{"disable":false,"start_date":null,"time_sensitive":false},"user_authorized_to_scan":"yes","target_id":"[Target ID]"}'
  

• Replace the 3 highlighted fields:
  • To set the correct X-Auth value, replace the [API KEY] text with the API key you retrieved in Step 1.
  • The suggested value for profile_id is 11111111-1111-1111-1111-111111111111 – this default value is for a full scan. If you wish to specify a different scan profile, you can set one of the following values:
    • For the online version of Acunetix:
      • Full scan: 11111111-1111-1111-1111-111111111111
      • High-risk vulnerabilities: 11111111-1111-1111-1111-111111111112
      • SQL injection vulnerabilities: 11111111-1111-1111-1111-111111111113
      • Weak passwords: 11111111-1111-1111-1111-111111111115
      • Cross-site scripting vulnerabilities: 11111111-1111-1111-1111-111111111116
      • Crawl only: 11111111-1111-1111-1111-111111111117
      • Malware scan: 11111111-1111-1111-1111-111111111120
      • Full web and network scan: 11111111-1111-1111-1111-211111111111
      • Network scan: 11111111-1111-1111-1111-211111111112
      • Network scan (safe checks): 11111111-1111-1111-1111-211111111113
      • Network scan quick: 11111111-1111-1111-1111-211111111114
    • For the on-premises version of Acunetix:
      • Full scan: 11111111-1111-1111-1111-111111111111
      • High risk: 11111111-1111-1111-1111-111111111112
      • SQL injection vulnerabilities: 11111111-1111-1111-1111-111111111113
      • Weak passwords: 11111111-1111-1111-1111-111111111115
      • Cross-site scripting vulnerabilities: 11111111-1111-1111-1111-111111111116
      • Crawl only: 11111111-1111-1111-1111-111111111117
      • High/medium risk: 11111111-1111-1111-1111-111111111119
      • Malware scan: 11111111-1111-1111-1111-111111111120
    • Or alternatively use the scan profile ID of any custom scan profiles you may have created; you can retrieve the scan profile ID of custom scan profiles programmatically via the Acunetix API or by navigating to the custom scan profile, and checking the URL:
      
• To set the correct target_id value, replace the [Target ID] text with the target ID you retrieved in Step 1.
• Click on the Commit changes button to save your settings.
  
• This will trigger a manual run of the pipeline, and therefore add an immediate scan request to Acunetix:
  
• All future commits will now also trigger a scan request to Acunetix.

Checking scan results

The Scans page lists all scans performed. By default, the most recently triggered scan will show at the top of the list.

• Click on the scan triggered by your GitLab pipeline to go to the scan summary.
  
• The scan summary page gives you a birds-eye view of the vulnerability of your web application in the Scan Information tab.
  
• For a more detailed list of issues that you need to work on, click on the Vulnerabilities tab. In this example, the first item listed is a directory traversal vulnerability.
  

Resolving vulnerabilities

In the list of vulnerabilities, click on the vulnerability you wish to investigate. This will provide more details about the vulnerability in question.

The important details of the vulnerability are listed in sections.

• The vulnerable URL and any vulnerable parameter passed to the URL
• The details of the payload sent to the URL to expose the vulnerability
• Where available, additional details that constitute proof of exploit
• A description of the vulnerability
• A summary of the possible ways an attacker can gain privileged access to the web application
• A generic description of the correct way to write source code to fix such vulnerabilities

If necessary, you can also expand the HTTP Request and HTTP Response sections. This will provide extra detail of the HTML exchange between the web application and the scanner, allowing a developer to view the result of the vulnerability when successfully exploited.

Stay secure

Keep in mind that performing a one-time scan on your target is not sufficient, even if your web application is in code freeze. As time goes by, new vulnerabilities are discovered, resulting in the need to remain vigilant.

In view of this, even if your web application is considered stable, you should still perform periodic scans outside your SDLC, preferably in a staging environment, to ensure your web application, which was previously considered secure, has not become vulnerable to some newly discovered vulnerabilities.

One simple way to help you to keep your web applications safe is to set up a recurrent scan. Any vulnerabilities discovered during any of the scheduled scans will be notified via email for you to take action and remediate.

THE AUTHOR

Kevin Attard Compagno
Technical Writer
LinkedIn

Kevin Attard Compagno is a Technical Writer working for Acunetix. A technical writer, translator, and general IT buff for over 30 years, Kevin used to run Technical Support teams and create training documents and other material for in-house technical staff.