Overview
It's a significant risk in Jira – any user can post access keys, passwords, and many other kinds of sensitive information in plain text, right into an issue description or comment. They can also easily include sensitive information in files attached to issues!
Jira has no built-in mechanism to detect content that contains sensitive credentials that could fall into the wrong hands, and typical workflows make this an all-too-easy omission, even by well intentioned users.
This poses an enormous security risk, as access to such information could lead to privilege escalation, either by malicious users who have network access to the Jira instance, or by an external attacker who has bridged the perimeter security. Just imagine what someone could do with a password to a network device, an AWS access key, or financial account information.
To help prevent such situations, Security for Jira integrates directly with Jira, providing tools to automatically detect attempts to improperly store sensitive information, accidental or otherwise.
Scanning projects from the Soteri Dashboard
Scans may be triggered for projects individually or all at once if you are a Jira administrator or any user granted explicit app access. The easiest way to do either is via the Soteri Dashboard, which contains all projects you can administer.
To reach the Soteri Dashboard, click the padlock icon in the top-right toolbar in Jira:
Then, to trigger a scan, you can either click the arrow icon next to the project and select “Scan”:
Or, if you are a Jira administrator or any user granted explicit app access, click the “Scan All” button:
Learn more about the Soteri Dashboard.
Viewing scan results in the Security Analysis
The Security Analysis page allows you to view the results of a scan. To view a project’s Security Analysis, you may either click the project’s name in the Soteri Dashboard:
Or, click the padlock icon labelled “Security Analysis” while viewing a project you can administer in Jira:
From the Security Analysis page, you can view and disposition scan findings for that particular project, including hiding false positives. You may also trigger a scan by using the “Scan Project” button:
Learn more about the Security Analysis page.
What can Security for Jira Scan?
Currently, Security for Jira scans the following parts of an issue:
Descriptions
Comments
Attachments - see Scanning Files Attached to Issues for more information on supported file types.
Note that issue summaries (titles) and custom fields are not yet scanned.
Supported secrets and Keys
Here is the list of vulnerabilities that are currently detected by Soteri's built-in scanning rules.
IT Services
Rule Name | Description |
---|---|
| AWS Identity and Access Management Client IDs uniquely reference users, access keys. These unique IDs can provide access to your AWS instance by allowing users to get keys. |
| AWS Marketplace Web Service API Keys allow programmatic interfaces to Amazon Seller stores. |
| AWS Secret Access Keys allow for authenticated AWS CLI, SDK, and API access. |
| Azure Access Keys provide access to all data stored in Microsoft Azure. |
| Dynatrace Client Secrets allow for access to your Dynatrace instance API. |
| Elliptical Curve Private Keys - We detect many common SSH Private Key formats. |
| Facebook Application IDs |
| Facebook Application Secrets |
| Generic API Key - Contains logic to detect generic API Keys. |
| Generic Passwords - Contains logic to detect generic passwords. Note that this rule may generate many false positives, and is disabled by default. |
| Generic Secrets - Contains logic to detect generic secrets. |
| Github Authentication Tokens - This rule detects classic Github Authentication Tokens for personal use (both “classic” and “fine-grained”), as well as for Github Application OAuth. |
| Google API Keys |
| Google OAuth URLs |
| Google OAuth Tokens |
| Heroku API Keys |
| LinkedIn Client IDs |
| LinkedIn Client Secrets |
| Mailchimp API Key |
| Mailgun API Key |
| Generic Password in URL - Contains logic to detect passwords embedded in URLs |
| |
| PGP Private Keys |
| PKSC8 Private Keys - We detect many common SSH Private Key formats. |
| Python Package Index (PyPI) Upload Tokens allow verified publishing of python package to the global repository. |
| We detect many common SSH Private Key formats. |
| |
| Shopify Partner API access Tokens provide access to the a given store's API. |
| Shopify API Secrets give access to all aspects of the general Shopify API – this rule contains logic to detect Shared Secrets and Access Tokens for regular, Custom, and Private applications. |
| Slack API Tokens give access to various API features. |
| Slack Webhooks are secret URLs which give similar access as API Tokens. |
| Square Access Tokens |
| Square OAuth Secrets |
| Generic SSH Private Key - We detect many common SSH Private Key formats. |
| Public Key-half of key-based authentication. Weak public keys can be brute-force cracked by modern computers, and can represent equal vulnerability to the private-key half of the pair. Since properly-generated public keys are not a threat, this rule is disabled by default. |
| Trojan Source detects left-to-right and right-to-left unicode control characters which can be used to obscure malicious code. For more information, see the Trojan Source paper and CVE-2021-42574 in the NIST Database. Note: the homoglyph attack described in this paper, and tracked as CVE-2021-42694 in the NIST Database, is not detected by this rule, as it can generate a lot of false positives for non-English languages. See “Mitigating Trojan Source Attacks” for Soteri’s recommendations if you’re interested in detecting potential homoglyph attacks. |
| Stripe API Key |
| Twilio Account ID - part of the Twilio API |
| Twilio API Key - part of the Twilio API |
| Twitter Client ID |
| Twitter Secret Key |
Financial
Rule Name | Description |
---|---|
| Detects bank account information like routing numbers, etc. which may accompany more sensitive information. |
| Detects credit card numbers. |
| Detects United States Social Security Numbers. |
Enabling and disabling built-in rules is an audited event.