Before
Security staff had to open each incident, inspect linked Jira issues or Confluence pages, infer the responsible person, and switch to directory searches. They also had to verify access, choose which link to share, draft email and Teams messages, and update the incident record manually. If ownership could not be confirmed, they had to document that outcome themselves.
How it works
- Read the secret incident and its linked Jira issue or Confluence page to establish the exposure context and likely owner.
- Resolve and validate the owner through account and directory checks, then determine whether to use a dashboard link or a share link.
- Notify the owner through email and Teams, record the incident activity, tag the incident, or document that no owner was found.
Workflow details
- Trigger: A GitGuardian secret incident starts the workflow with its incident ID and optional occurrence or reopening context.
- Investigation: The flow reads the incident and its Jira or Confluence source, then identifies the likely owner from a page’s last editor, a Jira comment author, the issue reporter, or the recorded source author.
- Validation: It retrieves the person’s email, checks the directory for an active identity, and verifies whether that person has access to the incident platform.
- Notification routing: Members receive a dashboard link, while non-members receive a time-limited share link with feedback access. The workflow prepares a contextual email and Teams message, including the secret type, location, severity, validity, and required remediation actions.
- Closure: The notification is sent, a note is added to the incident, and the incident is tagged as notified. Reopened incidents receive a reminder; when no owner is found, the workflow records an explicit missing-owner outcome. The configured demonstration uses simulated connector responses.
What changed
Owner identification, identity validation, access checking, link selection, notification preparation, and incident updates now occur in one triggered workflow. Confirmed owners receive a tailored handoff through email and Teams, while unresolved ownership produces an explicit owner-not-found record instead of an untracked handoff.
Work removed
Opening linked records one by one; identifying owners from page edits, comments, reporters, or source authors; retrieving email and directory details; checking active status and incident access; choosing the appropriate incident link; drafting email and Teams messages; and adding incident notes or notification tags.
Expected outcome
Each triggered incident ends with a recorded notified, reminded, or owner-not-found outcome, making the ownership handoff and next action explicit.
