View security insights
After connecting your Data Center instance to Portfolio insights and completing the prerequisites, we'll start generating security insights. Once the connection is established, it will take at least two hours before initial security insights can be generated.
How it works
Security insights evaluates your Data Center instance configuration against a set of security best practices. Each practice is modeled as a security check that can either pass or fail. The results are combined into a single Security score, the percentage of checks that pass, giving you a clear, at-a-glance view of your instance's security posture.
Security scoring
Every security check evaluates a specific aspect of your instance, from vulnerability management and access controls to system hardening. Each check results in one of two outcomes:
Status | Meaning | Score contribution |
|---|---|---|
Pass | The check meets the recommended security standard | 1 |
Fail | The check does not meet the recommended security standard | 0 |
The Security score is then calculated as:
Security score = Passed checks ÷ Total checks × 100
The result is a value between 0 and 100, where 100 indicates all security checks are passing and 0 indicates none are.
Data collection
Security data is collected on your Data Center instance and uploaded every 2 hours. The dashboard displays the most recently received results, resulting in a slight delay. The history chart shows each day's final score in UTC.
How recommendations work
When a security check fails, we show specific recommendations on how to resolve the issue. Each recommendation includes a description of the problem, step-by-step remediation actions, and links to relevant documentation. Recommendations are tailored to the product you're running (Jira or Confluence), so you always see the most relevant guidance for your instance.
Before you begin
Make sure you've completed the required prerequisites to establish the connection.
View security insights
To view security insights:
Under Portfolio insights, select the Instance health page.
Select any Jira or Confluence Data Center instance.
In the right-hand panel, select View insights. You'll be moved to the instance view where you can switch between different tabs.
Select the Security tab. You'll see the security dashboard with your Security score, score history, and security checks grouped by category.
Security score
The Security score is shown as a donut chart displaying the percentage of security checks that pass. Next to the score, you'll see a summary of how many checks passed out of the total, and how many issues need attention.
Preview | |
Timeframe | The score reflects the most recent data upload from your instance. |
Data aggregation | Your instance uploads security metrics every 2 hours. The score is recalculated each time new data arrives. |
Data mutability | The score shown is confirmed and won't change retroactively. |
Security health over time
The history chart shows how your Security score has changed over time, allowing you to track whether your security posture is improving or degrading.
7-day trend
The 7-day trend allows you to see weekly patterns, identify the impact of configuration changes, and verify whether remediation actions have improved your score.
Preview | |
Timeframe | Last 7 days. |
Data aggregation | Each data point represents the final score for that day in UTC. |
Data mutability | The view shows historical and confirmed data that will not change. |
Security checks
Security checks are grouped into five categories. Each category contains individual checks that evaluate a specific security aspect of your instance. Failing checks include inline details (such as the count of affected items) and expandable recommendations with step-by-step remediation actions.
Select any security check to open a side panel with more details, including a description of the check, why it matters, metadata about the current state, and recommended actions to resolve the issue.
Security alerts and vulnerabilities
These checks evaluate whether your instance is protected against known security threats and whether you're actively monitoring for new ones.
Check | Description |
|---|---|
Known vulnerabilities mitigated | Checks whether your product version has known security vulnerabilities. Upgrade to the latest version to mitigate all known issues. |
Security alerts reviewed | Checks whether security alerts are being reviewed regularly. Unaddressed alerts may indicate active exploitation or misconfiguration. |
System configuration
These checks evaluate whether the operating system and infrastructure hosting your instance follow security hardening best practices.
Check | Description |
|---|---|
Application running as a non-root OS user | Checks that the application runs under a dedicated, non-root operating system user to limit the blast radius of a potential compromise. |
Config files with encrypted secrets | Checks whether sensitive values (such as database passwords) in configuration files are encrypted rather than stored in plain text. |
Product database user has minimal permissions | Checks that the database user used by the product has only the permissions it needs, reducing the risk of unauthorized data access or modification. |
Secure email configuration | Checks that outgoing email is configured to use a secure protocol (TLS/SSL) and authentication, preventing credential interception or email spoofing. |
File permissions | Checks that critical files and directories have appropriate permissions, preventing unauthorized users from reading or modifying configuration or data files. |
Tomcat configuration | Checks whether the embedded Tomcat server is configured securely, including proper connector settings, disabled unnecessary features, and secure defaults. |
XML database backup disabled | Checks that automatic XML database backups are disabled in production. XML backups are intended for migration purposes and can expose sensitive data if left enabled. |
Application configuration
These checks evaluate whether your application settings follow security best practices, covering authentication, access controls, and auditing.
Check | Description |
|---|---|
Strong passwords | Checks that a strong password policy is enforced, preventing attackers from guessing or brute-forcing credentials. |
Single Sign-On (SSO) | Checks that SSO is configured with a trusted identity provider, reducing the risk of credential sprawl and enabling centralized authentication policies. |
Multi-Factor Authentication (MFA) | Checks that MFA is enabled to add an extra layer of protection beyond passwords. |
WebSudo for admin actions | Checks that WebSudo is enabled, requiring administrators to re-authenticate before performing sensitive administrative operations. |
CAPTCHA on login | Checks that CAPTCHA is enabled on the login page to protect against automated brute-force attacks. |
No weak login methods | Checks that basic authentication over HTTP headers is disabled, preventing credentials from being transmitted in an easily interceptable format. |
Comprehensive audit logging | Checks that audit logging is enabled and has sufficient coverage, providing a tamper-resistant record of user actions for investigation and compliance. |
No publicly accessible content | Checks that no content is publicly accessible to unauthenticated users, preventing unintended data exposure. |
Attachments upload | Checks that attachment uploads are restricted to trusted file types, reducing the risk of malicious file uploads. |
Access management
These checks evaluate whether user and admin accounts are properly managed and permissions follow the principle of least privilege.
Check | Description |
|---|---|
No inactive admin accounts | Checks for dormant admin accounts that are disabled, haven't logged in for 60+ days, or have never logged in. These are high-value targets for attackers. |
No inactive user accounts | Checks for dormant user accounts that are disabled, haven't logged in for 90+ days, or have never logged in. |
Rate limiting | Checks that rate limiting is configured for all users, preventing any single actor from overwhelming shared resources or enabling denial-of-service attacks. |
No public registration | Checks that public user signup is disabled, preventing unverified users from creating accounts without administrator approval. |
Self-signup groups have minimal rights | Checks that default groups for self-signup users have minimal permissions, ensuring they cannot perform destructive actions or access sensitive data. |
JSM customers have minimal permissions | Checks that JSM customer accounts are restricted from accessing Jira features, ensuring they can only interact through the service desk portal. |
No internal directory users | Checks that users are managed in an external directory (e.g., LDAP, Active Directory) to centralize identity management and enforce consistent security policies. |
Apps and integrations
These checks evaluate whether your installed apps and application links follow security best practices.
Check | Description |
|---|---|
Version support | Checks whether your product version is still within its supported lifecycle. Unsupported versions no longer receive security fixes. |
No inactive app links | Checks for inactive or broken application links that could be exploited to impersonate trusted applications or redirect traffic to uncontrolled systems. |
Up-to-date apps | Checks that all installed apps are updated to the latest version, as older versions may contain known vulnerabilities. |
New custom apps | Checks for recently installed custom (non-Marketplace) apps that haven't been reviewed, as they may introduce security risks. |
Security check details
When you select a security check from the list, a side panel opens with detailed information about the check.
Preview |
The side panel includes the following sections:
Description
An explanation of what the check evaluates and why it matters for security. This helps you understand the risk associated with a failing check.
Current status
Shows whether the check is currently passing or failing. Passing checks display "This check is passing. No action needed." Failing checks show relevant metadata, such as the count of affected items (e.g., "3 inactive admin users" or "2 outdated apps").
Recommended actions
Step-by-step guidance on how to resolve a failing check. Actions are tailored to the specific product (Jira or Confluence) and often include navigation paths within the administration interface. Where applicable, links to relevant Atlassian documentation are provided.
Resources
Links to Atlassian documentation with more context about the security topic covered by the check.
Missing data notifications
In some cases, individual security checks may show an error state instead of a pass/fail result. This happens when a specific metric couldn't be evaluated — for example, if the data required to assess that check wasn't available or couldn't be processed.
Preview |
When a check is in an error state, it won't contribute to the overall Security score. If the problem persists after a few hours, contact Atlassian Support.
Was this helpful?