Before
Responders likely had to review the honeytoken alert, retrieve the token and event details, search the triggering IP in device inventory, look up the associated user, and request clarification manually. They also had to switch between investigation tools, assess unknown IPs externally, coordinate remediation decisions, and keep the incident thread updated by hand.
How it works
- Receive the honeytoken trigger, retrieve the relevant token and event data, and post an interactive alert with investigation or closure options.
- Investigate the triggering IP through device inventory and user clarification when possible, or enrich it with external threat and network information when no device match is found.
- Present remediation choices in the incident thread, execute the approved reset or recreate action, and update the thread with the final status and audit details.
Workflow details
- Trigger and initial notification: A GitGuardian honeytoken trigger webhook starts the workflow. The flow retrieves the affected honeytoken, extracts the token name, triggering IP address, user agent, and event time, formats the timestamp, and posts an interactive alert to the responsible Slack channel with options to investigate or close the case.
- Internal ownership investigation: When investigation is selected, the triggering IP address is searched against Jamf computer inventory. If a matching device is found, the associated user's Slack profile is identified and the user receives an interactive request for an explanation. Their response is added to the incident thread, where the team can choose whether to issue a warning.
- External IP enrichment: When no matching device is found, the IP address is assessed through VirusTotal. The workflow evaluates whether the address is associated with the configured network and whether it has malicious findings, then adds the resulting network, hostname, country, ownership, and analysis context to the Slack incident thread with an appropriate status.
- Human-approved remediation: After the investigation, responders can close the case, reset the existing honeytoken, or recreate it. Recreating revokes the triggered honeytoken and creates a replacement, while the reset path resets the existing token. These actions are initiated through interactive Slack choices rather than executed without human approval.
- Incident documentation and completion: The original Slack notification is updated throughout the process with actors, responses, investigation results, timestamps, status, and final outcome. The workflow concludes with a cleared or closed incident record and a notification confirming the selected remediation when a token is reset or recreated.
What changed
The alert now becomes an interactive Slack case as soon as the webhook arrives. Internal ownership checks, user lookup, external IP enrichment, status updates, timestamp formatting, and incident documentation happen automatically, while investigators retain the decision to investigate, warn, close, reset, or recreate the honeytoken.
Work removed
Manually extracting alert details, searching device inventory for the triggering IP, looking up the associated user, sending clarification requests, reviewing and reposting responses, checking unknown IPs through external analysis, assembling incident updates, and performing the repetitive reset, revoke, or replacement-token coordination.
Expected outcome
The configured workflow can remove approximately six or more recurring lookup, coordination, and documentation actions from each eligible alert, based on its automated investigation and remediation stages; this is a conservative design estimate, not a measured customer result.
