How Do I Install Edgescan for Jira Data Center?

4. Using Synchronisation Features

4.1 Manual Sync Functionality

To manually synchronise vulnerabilities:

1. Navigate to the project

2. Select "Edgescan Settings" from the left sidebar navigation

3. Click the "Sync Now" button to start the synchronisation process

4.2 Automatic Synchronisation

Configure automatic synchronisation:

1. Navigate to the project

2. Select "Edgescan Settings" from the left sidebar navigation

3. Click the "Enable Auto-sync" button to toggle automatic synchronisation on

4. When enabled, the plugin will automatically run synchronisation every 5 minutes

5. The synchronisation runs asynchronously in the background, allowing you to continue working in Jira without interruption

Additionally, the plugin runs a background label sync job hourly to ensure status labels are updated for moved tickets and tickets in projects not tracking their assets.

4.3 When to Use "Sync Now"

Use manual synchronisation in these scenarios:

• After configuration changes

• When immediate updates are needed (rather than waiting for the 5-minute auto-sync)

• After modifying tracked assets

• For troubleshooting and verification purposes

4.4 Understanding Synchronisation Behaviours

During synchronisation, the plugin performs the following actions:

• Creates Jira issues for new vulnerabilities

• Updates existing issues when vulnerability details change

• Transitions issues when vulnerabilities are closed in Edgescan

• Adds comments explaining vulnerability status changes

• Updates status labels (Open/Closed) on issues

• Handles moved issues between Jira projects

• Manages out-of-scope issues per your configuration

4.5 Best Practices for Synchronisation

For optimal performance:

• Schedule major configuration changes during low-activity periods

• Allow sufficient time for initial synchronisation of large asset sets

• Verify configurations before synchronising large projects

• Check synchronisation results in the project's issue list

5. Working with Vulnerability Issues

5.1 Understanding Issue Format and Fields

Vulnerability issues created by the plugin include these key elements:

• Summary: Vulnerability name

• Description:

  • Asset details with link

  • Link to view vulnerability in Edgescan

  • Technical details (location, layer, CVSS data)

  • Status and dates (including SLA due date when applicable)

  • CWEs (Common Weakness Enumeration references, when available)

  • Tags (associated with the vulnerability, when available)

  • Retest link with expiration notice

• Type: Configurable

• Priority: Based on configured risk mapping (e.g., Medium)

• Labels: EdgescanVulnerabilityStatus:Open or Closed

• Epic Link: Associated with configured epic when enabled

• Assignee: Set according to configuration

5.2 Status Transitions

Vulnerability issues transition through different statuses based on their life cycle:

1. Created with the configured "Status on Create"

2. Manually transitioned by users during remediation

3. Automatically transitioned to the configured "Status on Close" when closed in Edgescan

5.3 Viewing Vulnerability Details

Each issue includes links to view detailed information:

1. The issue description contains a direct link to the vulnerability in Edgescan

2. If configured, retest links may be available for issues that require verification

5.4 Working with Moved Tickets

The plugin handles moved vulnerability issues with specific behaviours:

• Link maintenance: Issues moved to another project maintain their link to the Edgescan vulnerability

• Database updates: The system automatically detects moved tickets and updates internal records

• Status labels: Labels (EdgescanVulnerabilityStatus:Open/Closed) continue to be updated hourly even if the new project doesn't track the asset

• Workflow status transitions: For actual status transitions to occur, the new project must:

  • Have Edgescan integration enabled

  • Track the specific asset associated with the vulnerability

  • Have appropriate status transition configuration

  • Run a synchronisation operation that processes the vulnerability

• Deletion protection: Issues moved to other projects are protected from deletion even when the original project stops tracking the asset

• Assignee preservation: When status transitions occur, the plugin attempts to preserve the original assignee

This implementation ensures that moved tickets maintain their relationship with Edgescan vulnerabilities while respecting each project's configuration.

6. Frequently Asked Questions

6.1 Common Questions

Q: Which user creates the Jira issues?
A: Issues are created by:

• The "edgescan-plugin" system user during automatic synchronisation

• The logged-in user (like Admin) during manual synchronisation via the "Sync Now" button

The edgescan-plugin is a system user automatically created during plugin installation with administrative permissions. This special user performs numerous automated actions including:

• Updating vulnerability status when closed in Edgescan

• Adding comments about vulnerability status changes

• Applying and updating status labels (Open/Closed)

• Transitioning issues through workflow states

• Deleting out-of-scope issues when configured

• Adding issues to epics when configured

• Performing background label synchronisation for moved tickets (runs hourly)

In all cases, "Edgescan Plugin" appears as the Reporter field on issues, though the activity history will show who actually created or triggered actions on each issue.

Q: What happens if I delete an issue created by the plugin?
A: The plugin maintains a database linking Jira issues to Edgescan vulnerabilities. When an issue is deleted, the plugin retains this database record. During subsequent synchronisations, the plugin will detect that the issue no longer exists but will not recreate it, as the current implementation treats deleted issues as if they might have been moved to another project. To have the vulnerability tracked again in Jira, you would need to remove the link from the plugin's database via administrative tools.

Q: What exactly happens when I move an issue to another project?
A: When you move an issue to another project:

1. The plugin detects that the issue has been moved

2. It updates its internal database to reflect the new project location

3. Status labels will continue to be updated for the issue, even in its new project

4. If the original project disables tracking of the related asset, the moved issue will not be deleted

5. For actual workflow status transitions to occur, the new project must both track the asset and run a sync operation

6. All synchronisation operations will use the new project's configuration settings, not the original project's settings

Q: Can I have multiple projects tracking the same asset?
A: Yes, multiple projects can track the same asset. Each project will have its own issues for the asset's vulnerabilities.

When multiple projects track the same asset:

• Each project creates and maintains its own separate Jira issues

• Each project applies its own risk mappings, issue types, and project-specific settings

• Updates to vulnerability status in Edgescan will be reflected in all linked projects during their respective syncs

• Deleting an issue in one project won't affect issues in other projects

• Moving an issue between projects is tracked by the plugin, preventing duplicate issues

6.2 Troubleshooting Tips

Issue: Synchronisation not creating expected issues

• Verify API token has correct permissions

• Confirm the asset is correctly selected in project configuration

Issue: Status not updating on closed vulnerabilities

• Verify the workflow allows transition to the configured "Status on Close"

  • Check for both direct transitions and global transitions in your workflow

  • Ensure there are no validation rules blocking the transition (required fields, etc.)

• Check that the issue hasn't been manually moved to a status that blocks transitions

  • When status transitions fail, the plugin will still add a comment indicating the vulnerability is closed

  • The plugin attempts to find all possible transition paths but can't override workflow restrictions

• Confirm the project has Edgescan integration enabled if the issue was moved between projects

Issue: Issues being created without expected fields

• Review Epic, assignee, and other configuration settings

  • Check that Epic Link custom field is properly installed and available

  • Verify correct Epic key format is being used

• Verify that any referenced users or issues (like Epics) exist and are accessible

  • Confirm users haven't been deactivated or renamed

  • Confirm Epics haven't been deleted or moved to different projects

• Check project configuration for any required fields

  • Some fields may be required by your Jira workflow that aren't being set by the plugin

6.3 Expected Behaviours

• First synchronisation after configuration may take longer, especially for large assets (due to initial retrieval of all vulnerabilities). When using the "Sync Now" button for a first-time sync of large assets, the operation will process in real-time and the page will appear to be loading until completion. Upon completion, you'll see a confirmation message with the number of vulnerabilities found

• Issues in "Done" status will not be deleted even if their asset is no longer tracked

• When the original project stops tracking an asset, moved issues continue to receive label updates but not workflow transitions (this preserves the integrity of issues in their new projects)