Halp
Summary Report
Report created on July 15, 2024
Report date range: April 01, 2024 - June 30, 2024
Prepared by: Ben Howe, bhowe@atlassian.com

CONFIDENTIAL INFORMATION • Do not share outside of organization

Atlassian | Summary Report

Table of contents
Executive summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Reporting and methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Targets and scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Findings Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Risk and priority key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Submissions over time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Submissions signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Bug types overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Closing Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

CONFIDENTIAL INFORMATION

1Atlassian | Summary Report

Executive summary
Atlassian engaged Bugcrowd, Inc. to perform a Bug Bounty Program, commonly known as a crowd-sourced
penetration test.
A Bug Bounty Program is a cutting-edge approach to an application assessment or penetration test. Traditional
penetration tests use only one or two personnel to test an entire scope of work, while a Bug Bounty leverages acrowd of security researchers. This increases the probability of discovering esoteric issues that automated testing
cannot find and that traditional vulnerability assessments may miss in the same testing period.
The purpose of this program was to identify security vulnerabilities in the targets listed in the targets and scopesection. Once identified, each vulnerability was rated for technical impact defined in the findings summary section of
the report.
This report shows testing for Halp's targets during the period of: 04/01/2024 – 06/30/2024.
For this Bug Bounty Program, submissions were received from 8 unique researchers.
The continuation of this document summarizes the findings, analysis, and recommendations from the Bug Bounty
Program performed by Bugcrowd for Atlassian.
This report is a summary of the information available. All details of the engagement's findings — comments, code,
and any tester provided remediation information — can be found in the Bugcrowd platform(https://tracker.bugcrowd.com) (https://tracker.bugcrowd.com)

CONFIDENTIAL INFORMATION

2

Atlassian | Summary Report

Reporting and methodology
BackgroundThe strength of crowdsourced testing lies in multiple researchers, the pay-for-results model, and the varied
methodologies that the researchers implement. To this end, researchers are encouraged to use their own individual
methodologies on Bug Bounty Engagements.
The workflow of every penetration test can be divided into the following four phases:

Bugcrowd researchers who perform web application testing and vulnerability assessment usually subscribe to avariety of methodologies following the highlighted workflow, including the following:

CONFIDENTIAL INFORMATION

3

Atlassian | Summary Report

Targets and scope
Scope
Prior to the Ongoing program launching, Bugcrowd worked with Halp to define the Rules of Engagement, commonly
known as the program brief, which includes the scope of work. The following targets were considered explicitly inscope for testing:
Halp application for SlackHalp application for Microsoft Teams
Atlassian Assist - Cloud - https://marketplace.atlassian.com/apps/1220442/atlassian-assist?hosting=cloudAtlassian Assist- Server - https://marketplace.atlassian.com/apps/1220442/atlassian-assist?hosting=server
Confluence Slack Automation Integration by Halp - Cloud https://marketplace.atlassian.com/apps/1222365/confluence-slack-automation-integration-by-halp?hosting=cloud
Halp Answers for Confluence in Slack - Cloud - https://marketplace.atlassian.com/apps/1222365/halp-answersfor-confluence-in-slack?hosting=cloudAtlassian Assist - DataCenter - https://marketplace.atlassian.com/apps/1220442/atlassian-assist?
hosting=datacenterAll details of the program scope and full program can be reviewed in the program settings.

CONFIDENTIAL INFORMATION

4

Atlassian | Summary Report

Findings Summary
The following chart shows all valid assessment findings from the program by technical severity.
1.1
1
0.9

Number of submissions

0.8
0.7
0.6
0.5
0.4
0.3
0.2
0.1
0
Critical

CONFIDENTIAL INFORMATION

SevereModerate

Low

Informational

5

Atlassian | Summary Report

Risk and priority key
The following key is used to explain how Bugcrowd rates valid vulnerability submissions and their technical severity.
As a trusted advisor Bugcrowd also provides common "next steps" for program owners per severity category.
Technical severity
Critical

P1

Example vulnerability types
Remote Code Execution

Critical severity submissions (also known as "P1" or "Priority 1") are submissions that are escalated to

Vertical Authentication Bypass

Bugcrowd as soon as they are validated. These issues warrant the highest security consideration and

XML External Entities Injection

should be addressed immediately. Commonly, submissions marked as Critical can cause financial

SQL Injection

theft, unavailability of services, large-scale account compromise, etc.

SevereP2

Insecure Direct Object Reference for a critical
function
Lateral authentication bypass

High severity submissions (also known as "P2" or "Priority 2") are vulnerability submissions thatStored Cross-Site Scripting

should be slated for fix in the very near future. These issues still warrant prudent consideration but are

Cross-Site Request Forgery for a critical function

often not availability or "breach level" submissions. Commonly, submissions marked as High can

Insecure Direct Object Reference for an importantcause account compromise (with user interaction), sensitive information leakage, etc.

functionInternal Server-Side Request Forgery

Moderate

P3

Reflected Cross-Site Scripting with limited impact

Medium severity submissions (also known as "P3" or "Priority 3") are vulnerability submissions thatshould be slated for fix in the major release cycle. These vulnerabilities can commonly impact single
users but require user interaction to trigger or only disclose moderately sensitive information.

Cross-Site Request Forgery for an importantfunction
Insecure Direct Object Reference for an
unimportant function

Low

P4

Cross-Site Scripting with limited impact

Low severity submissions (also known as "P4" or "Priority 4") are vulnerability submissions that should
be considered for fix within the next six months. These vulnerabilities represent the least danger toCross-Site Request Forgery for an unimportantfunction

confidentiality, integrity, and availability.

External Server-Side Request Forgery

Informational

Lack of code obfuscation

P5

Informational submissions (also known as "P5" or "Priority 5") are vulnerability submissions that are
valid but out-of-scope or are "won’t fix" issues, such as best practices.

Autocomplete enabled
Non-exploitable SSL issues

Bugcrowd’s Vulnerability Rating Taxonomy
More detailed information regarding our vulnerability classification can be found at: https://bugcrowd.com/vulnerability-ratingtaxonomy (https://bugcrowd.com/vulnerability-rating-taxonomy)

CONFIDENTIAL INFORMATION

6

Atlassian | Summary Report

Appendix
Included in this appendix are auxiliary metrics and insights into the Bug Bounty Program. This includes information
regarding submissions over time, payouts and prevalent issue types.

Submissions over time
The timeline below shows submissions received and validated by the Bugcrowd team:validated
received
4
3.5
3
2.5
2
1.5
1
0.5
0
04-02

04-09

04-16

04-23

04-30

05-07

05-14

05-21

05-28

Submissions signal
A total of 10 submissions were received, with 1 unique valid issues discovered. Bugcrowd identified 1 informational
submissions, 1 duplicate submissions, removed 8 invalid submissions, and is processing 0 submissions. The ratio of
unique valid submissions to noise was 10%.
Submission Outcome

Count

Valid

1

Informational

1

Invalid8

Duplicate1

Processing

0

Total

10

CONFIDENTIAL INFORMATION

Ratio of Unique Valid Submissions to Noise

100%
75%
50%
25%

10%

0%
0

7

Atlassian | Summary Report

Bug types overview
This distribution across bug types for the Bug Bounty Program only includes unique and valid submissions.
Average On-Demand Program

Other
Cross-Site Scripting (XSS)
Server Security Misconfiguration
Broken Access Control (BAC)
Broken Authentication and Session Management
Cross-Site Request Forgery (CSRF)
Sensitive Data ExposureServer-Side Injection
Unvalidated Redirects and Forwards
Mobile Security Misconfiguration
Application-Level Denial-of-Service (DoS)
Insufficient Security Configurability
Insecure Direct Object References (IDOR)
Using Components with Known Vulnerabilities
Missing Function Level Access Control
Insecure OS/Firmware
Insecure Data Storage
Automotive Security Misconfiguration
Insecure Data Transport
Broken Cryptography
Client-Side Injection
Privacy Concerns
External Behavior
Lack of Binary Hardening
Network Security Misconfiguration
Indicators of Compromise

CONFIDENTIAL INFORMATION

8

Atlassian | Summary Report

Bugcrowd Inc.
300 California St
Suite 220 San Francisco, CA 94104(888)361-9734
July 15 2024

Closing Statement
Introduction
This report shows testing of Halp between the dates of 04/01/2024 - 06/30/2024. During this time, 8 researchers
from Bugcrowd submitted a total of 10 vulnerability submissions against Bugcrowd’s targets. The purpose of thisassessment was to identify security issues that could adversely affect the integrity of Bugcrowd. Testing focused on
the following:
1. Halp application for Slack
2. Halp application for Microsoft Teams
3. Atlassian Assist - Cloud - https://marketplace.atlassian.com/apps/1220442/atlassian-assist?
hosting=cloud
4. Atlassian Assist- Server - https://marketplace.atlassian.com/apps/1220442/atlassian-assist?
hosting=server
5. Confluence Slack Automation Integration by Halp - Cloud https://marketplace.atlassian.com/apps/1222365/confluence-slack-automation-integration-by-halp?
hosting=cloud
6. Halp Answers for Confluence in Slack - Cloud - https://marketplace.atlassian.com/apps/1222365/halpanswers-for-confluence-in-slack?hosting=cloud
7. Atlassian Assist - DataCenter - https://marketplace.atlassian.com/apps/1220442/atlassian-assist?
hosting=datacenter
The assessment was performed under the guidelines provided in the statement of work between Halp andBugcrowd. This letter provides a high-level overview of the testing performed, and the result of that testing.

CONFIDENTIAL INFORMATION

9Atlassian | Summary Report

Halp Program Overview
An Halp Program is a novel approach to a penetration test. Traditional penetration tests use only one or two
researchers to test an entire scope of work, while an Ongoing program leverages a crowd of security researchers.
This increases the probability of discovering esoteric issues that automated testing cannot find and that traditional
vulnerability assessments may miss, in the same testing period.
It is important to note that this document represents a point-in-time evaluation of security posture. Security threats
and attacker techniques evolve rapidly, and the results of this assessment are not intended to represent an
endorsement of the adequacy of current security measures against future threats. This document contains
information in summary form and is therefore intended for general guidance only; it is not intended as a substitute fordetailed research or the exercise of professional judgment. The information presented here should not be construed
as professional advice or service.

Testing Methods
This security assessment leveraged researchers that used a combination of proprietary, public, automated, andmanual test techniques throughout the assessment. Commonly tested vulnerabilities include code injection, crosssite request forgery, cross-site scripting, insecure storage of sensitive data, authorization/authentication
vulnerabilities, business logic vulnerabilities, and more.

Summary of Findings
During the Engagement, Bugcrowd discovered the following:Technical Severity

Count

Criticalvulnerabilities

0

Severevulnerabilities

0

ModerateLowvulnerabilities

vulnerabilities

Informational

vulnerability

CONFIDENTIAL INFORMATION

0

0

1

10