TABLE OF CONTENTS
- Related Systems
- Process
- Step 1 - Gaining access to and logging on to SonarQube from within AWS Workspaces.
- Step 2 - Identifying security hotspots from within SonarQube projects.
- Step 3 - Examining security hotspots from within SonarQube projects.
- Step 4 - Transcribing the specific security hotspots into JIRA.
- Step 5 - Determining Risk Likelihood and Risk Consequence.
- Step 6 - Determining the priority of the JIRA ticket based on the risk rating.
- Step 7 - Finalisation recommendations.
Description
SonarQube is a product that allows developers to write cleaner and safer code. It undertakes continuous inspection of code quality and does static code analysis providing a detailed report of bugs, code smells, vulnerabilities, code duplications.
TeleResult has adopted its use of the product to improve the code quality and security capability of the two critical business applications TeleControl (TC) and TeleOrder (TO).
Related Systems
Nil
Process
The TeleResult instance of SonarQube sits within the AWS workspaces environment ensuring that as a critical application it is protected from unauthorised access.
Logons to the TeleResult AWS Workspaces environment is strictly controlled and will only be provided after Management approval is granted.
As a workflow, the TC and TO security issues identified by SonarQube are managed using JIRA. In this way, an analysis of their impact and level of criticality can be measured and priority allocated.
SonarQube is used to identify critical TC and TO security issues. | è | Security issues with a SonarQube rating of High and Medium are transcribed into JIRA. | è | The Sprint Priorities weekly meeting is used to examine tickets raised from the SonarQube security issues report. |
Step 1 - Gaining access to and logging on to SonarQube from within AWS Workspaces.
Like AWS Workspaces, access to SonarQube is strictly controlled. To be provided with the logon credentials for SonarQube, the person must be a member of the Dashlane Infrastructure - Full Rights group.
After successfully logging on to AWS Workspaces, to gain access to SonarQube you will need to use an internet browser and go to the following link: https://sonarqube.teleresult.com.au.
The logon to SonarQube will then be presented.
The logon credentials are in Dashlane for authorised staff.
Initially after successfully logging on to SonarQube, you will see the following top-level menus:
By clicking on the “Projects” menu, the following will be displayed:
There are currently the following six projects listed, which are:
- TeleControl (TC)
- TeleControl - Importer
- TeleControl - Importer - Launcher
- TeleOrder (TO)
- Teleservice-API
- Teleview-App
Step 2 - Identifying security hotspots from within SonarQube projects.
To examine the security profile more deeply for TC or TC, click on the hyperlinked title for each application.
In the example below, I have clicked on TeleOrder and have been presented with the sub menu below:
I have then clicked on Security Hotspots from the sub menu and on the left-hand side of the next screen, a series of security hotspots will be listed.
The 69 security hotspots identified in the screen shown above are assessed in terms of their review priority which can either be HIGH, MEDIUM, or LOW.
The plan at this stage is to only identify the security hotspots that are rated as High or Medium and transfer these into JIRA for further analysis.
Step 3 - Examining security hotspots from within SonarQube projects.
Following on with the example above, you will see that one security hotspot has been rated as High, namely the one with a category of Cross-Site Request Forgery (CSRF)
By clicking into that specific security hotspot, the following detail will be displayed:
By scrolling to the bottom of the page below the identified code, three tabs will be shown:
What’s the risk? | Are you at risk? | How can you fix it? |
Each tab has important information that will need to be transcribed into the corresponding JIRA ticket related to this security hotspot.
Step 4 - Transcribing the specific security hotspots into JIRA.
After having logged into JIRA using this link, you will be presented with a project list that will include both TeleResult and Teckcraft.
Click on “TeleResult” and then “Create” to create a new issue:
The following screen will then appear allowing the required information from SonarQube to be transcribed.
The “Summary” description will be in the form shown in the example below:
SonarQube Vulnerability – Cross-Site Request Forgery (CSRF).
In this issue, the Cross-Site Request Forgery (CSRF) is the same as was identified in SonarQube.
The next step is to move further down in the “Create issue” form to “Description” at which point you will transcribe the information from SonarQube.
As shown in the actual description for issue TR-830, the text from the three areas of the TeleOrder Cross-Site Request Forgery (CSRF) in SonarQube are listed in the Description field.
It is recommended that headings and formatting be used to differentiate each risk category more clearly.
The only other area to complete for the newly created issue is to nominate labels and enter them individually in the “Labels” field.
 | The “Labels” field has a list of dropdown choices with a tab selected after each choice. The first entry will be the initials of the person creating the issue (i.e., GM for Geoff Mullins) followed by SonarQube (tab) followed by either TeleOrder or TeleControl (tab) and finally followed by security (tab). Set Epic = Legacy (TR-1319) The example below has this format. |
After that, it is a case clicking on “Create” to allow JIRA to create the issue. As long as there are no problems identified by JIRA, the ticket will be successfully created and the URL specific to the ticket will be displayed on the bottom left-hand corner.
For example, the URL for the CSRF is https://teckcraft.atlassian.net/browse/TR-830
Step 5 - Determining Risk Likelihood and Risk Consequence.
It is very important that all risks identified in SonarQube for TeleControl and TeleOrder are assessed for Risk Likelihood and Risk Consequence using the matrix shown below as defined in ISMS Clause 6.1.1 - Risk Assessment and Risk Treatment Methodology.pdf
The responsibility for determining the risk likelihood and consequence is with the Head of Development.
Once the JIRA ticket has been created, add note to ticket for the Head of Development (eg @Fadi) to assess. The purpose of the request is to advise that an assessment needs to be made, and the ticket updated accordingly.
The Head of Development will complete the Risk Likelihood and Risk Consequence fields
Once updated a Risk Assessment values needs to be determined and the ticket updated.
Step 6 - Determining the priority of the JIRA ticket based on the risk rating.
Depending on the Risk Assessment, the JIRA Ticket priority needs to be set as follows.
Risk Assessment | JIRA Ticket priority |
| Low | Lowest |
| Low Medium | Low |
| Medium | Medium |
| Medium Hi | High |
| High | Highest |
If Ticket priority is < High advise manager compliance who will close the ticket and updated associated ISMS logs, as it does not require mitigation
Step 7 - Finalisation recommendations.
It is important to cross reference any relevant information between the JIRA ticket and the specific security hotspot in SonarQube. Therefore, once the JIRA URL has been allocated, copy it to the Activity area on the specific security hotspot.
It will also be a benefit to the Sprint Priorities Team if any security related information specific to the ISMS documentation can be included.
Both of these recommendations are displayed in the image below:
