Integration error report and export
Halo Security shows an error icon when an integration is missing required information, setup is incomplete, or a key needs to be rotated. Administrators need one place to see all integrations that require attention and the specific errors to resolve. Requested feature Add a report that lists integrations with an error icon. For each integration, show its name, the error or setup issue, and the action needed to resolve it. Allow administrators to download the report as a CSV or PDF.
Integration with Grafana
Add a native integration between Halo Security and Grafana so organizations can visualize security findings, monitor risk trends, create alerts, and combine Halo Security data with existing operational dashboards. Business Need Security teams often review Halo Security findings separately from the operational data monitored in Grafana. This limits cross-team visibility and makes it harder to correlate security risk with infrastructure, applications, clients, and service performance. The integration should make Halo Security data available in Grafana without requiring manual exports or custom data pipelines.
Integration with ConnectWise
Add a native integration between Halo Security and ConnectWise to automate issue-ticketing workflows. Security findings in Halo Security should create and maintain corresponding ConnectWise service tickets, reducing manual entry and ensuring remediation work is tracked through completion. Business Need Teams currently have to transfer security findings into ConnectWise manually. This creates delays, duplicate effort, inconsistent ticket details, and limited visibility into whether vulnerabilities have been remediated.
Add “Mitigated” as a Third Acknowledgement Reason for Issues
We would like the ability to acknowledge an issue using a third reason in addition to the current Acceptable Risk and False Positive options. Today, when we acknowledge an issue, we have to classify it as either something we accept as risk or something we believe is a false positive. However, there are cases where the finding is not a false positive, and we are not simply accepting the risk. Instead, we have reviewed the issue and put compensating controls or other mitigations in place to reduce the actual exposure. We would like a new acknowledgement reason such as “Mitigated” to represent this scenario. This would allow us to clearly distinguish between: -False Positive, the finding is not valid or not exploitable. -Acceptable Risk, we understand the risk and are choosing to accept it. -Mitigated, the finding may still appear in scans, but controls are in place to reduce or address the risk.
Add API endpoints to list and trigger automations
We would like API support for automations so we can integrate them into our own workflows and orchestration processes. Specifically, it would be helpful to have: An endpoint to list all automations available in our account An endpoint to trigger an existing automation through the API Clear documentation explaining how automation related API functionality works
Centralized Client ID / Secret Management for Integrations (Admin Only)
Customers need a way to centrally manage integration credentials (Client IDs and Client Secrets). Today, when a credential such as an Azure Client Secret is rotated, it must be manually updated in every integration where it is used. This becomes difficult when the same Azure application is used across multiple integrations, as there is currently no easy way to identify which integrations share the same Client ID. Proposed Enhancement: Add a centralized credential management section within the Company Settings page of the platform. Location: https://app.halosecurity.com/user/account/company/ This new section would allow administrators to securely store and manage Client IDs and Client Secrets used by integrations. When configuring or editing integrations, users would be able to select an existing credential from this centralized list instead of manually entering the Client ID and secret each time. Access Control: This section should only be visible within the Company Settings page. Access should be restricted to Admin users only. Client Secrets should remain masked/encrypted in the UI. Key Benefits: Simplifies credential rotation (e.g., Azure client secret rotation). Eliminates the need to manually update credentials across multiple integrations. Reduces configuration errors when secrets are rotated. Provides visibility into which credentials are being reused. Additional Suggested Capability: Provide a simple export or table view showing: Integration Name Associated Client ID This would allow administrators to quickly identify which integrations rely on a specific Azure application when credentials are rotated. Example Use Case: A customer recently rotated a secret on an Azure application used across 15 integrations. Because the platform does not show Client IDs in a centralized way or allow credential reuse, the team had to manually open and update each integration individually. A centralized credential store would allow the secret to be updated once and automatically applied to all integrations using that credential.
Add Export Option for Tags
URL: https://app.halosecurity.com/user/security/tags/list?targets=all Add the ability to export the list by filtered results.
Add Adjustable Columns (Including Tags) to Domains Page
Enable adjustable columns on the Domains (Seeds) page to allow users to display associated tags, making it easier to correlate domains with discovery automation and asset grouping. Page / Area Affected Domains (Seeds) page https://app.halosecurity.com/user/settings/seeds/domains/ Problem Statement Users can create automation rules that apply tags to domains and their discovered assets. However, there is currently no way to see which tags are associated with which domains directly on the Domains page. This makes it difficult to: Verify automation behavior Quickly understand domain-to-tag relationships Manage discovery and scoping at scale Proposed Enhancement Add adjustable/configurable columns to the Domains page, similar to other list views in the platform, including (at minimum): Tags (multi-value column) (Optional, future) Discovery status, asset counts, last discovered date Users should be able to: Enable/disable columns Add a Tags column to view which tags are associated with each domain User Value / Impact Faster validation of discovery automation Clearer mapping between domains and asset groups Reduced manual cross-checking between domains, targets, and tags Better scalability for customers with large discovery footprints
Track and Display “First Detected Date” for Identified Technologies
The current Technology section lists technologies, versions, risk ratings, and CVEs per target, but does not record when a specific technology was first detected. As a result, it can be hard to determine whether a technology is newly introduced or has been present for some time.
Add "First Seen Date" for Discovered Hostnames/Subdomains in Dashboard & CSV Exports
Currently, domain discovery displays active hostnames/subdomains but does not indicate when each asset was first observed as publicly accessible. It would be nice to have the visibility into when a domain or subdomain was initially discovered. This would help with tracking changes in asset exposure over time, identifying newly emerged or reappearing infrastructure, and supporting incident response.
Integration with TeamDynamix
Enable a native integration between Halo Security and TeamDynamix to automatically create, update, and track tickets based on vulnerability and asset findings in Halo Security. This integration will streamline incident response, reduce manual effort, improve SLA compliance, and enhance cross-team collaboration by syncing security events with existing ITSM workflows in TeamDynamix. Use Case / Problem Statement: Security teams using Halo Security currently identify vulnerabilities and risks across their external attack surface. However, translating those findings into actionable, tracked tasks in TeamDynamix requires manual ticket creation and updates. This creates delays, increases the risk of miscommunication, and causes security findings to slip through internal processes or SLA requirements. Proposed Solution: Develop a bi-directional integration between Halo Security and TeamDynamix that includes: Automated Ticket Creation: When new critical or high vulnerabilities are discovered (configurable thresholds), automatically open a ticket in TeamDynamix with relevant context (affected asset, risk score, CVE, remediation steps, severity, reporter). Ticket Updates & Sync: Sync status changes from TeamDynamix back to Halo Security — e.g., when a ticket is acknowledged, in progress, or fixed — so Halo Security reflects current remediation state in dashboards and reporting. Field Mapping & Customization: Allow admins to map Halo fields to TeamDynamix fields (priority, category, assignment group, due dates, custom fields) and set rules for auto-updates. Comment & Attachment Sync: Pass comments in both directions to preserve context and audit trails. Trigger & Threshold Controls: Configurable triggers: by severity, asset criticality, vulnerability age, or custom tags to control when a ticket is created or updated. Benefits: Operational Efficiency: Reduces manual ticketing effort and frees security analysts to focus on remediation rather than administrative tasks. Improved Visibility: Development, operations, and IT teams get security findings directly in their workflows with appropriate context for faster remediation. Better SLA & Compliance Tracking: Automatically ensuring vulnerabilities enter formal remediation workflows with tracking and notifications improves accountability and SLA adherence. Consistent Audit Trails: Two-way sync preserves audit logs and remediation evidence across tools. Custom Workflows: Align security findings with existing TeamDynamix workflow rules and approval processes. Optional Advanced Enhancements: Bulk Ticket Operations for handling multiple findings at once. Dashboards & Metrics in TeamDynamix showing security metrics (e.g., open vulnerabilities by severity). Role-Based Permissions to control what data flows between systems. Example Workflow: Halo Security discovers a new critical vulnerability on a client-facing as
Jira Integration at Partner (Parent) Account Level
As a partner managing multiple child accounts, we would like the ability to configure the Jira integration at the parent account level. Currently, the integration must be set up individually per child account, which can complicate centralized issue tracking. This feature would allow events and scan findings from child accounts to generate Jira tickets through a single integration configured on the parent account. This would be a valuable addition for resellers and MSSPs who require unified alerting and ticket management across their customer base.
Align Target Risk Meter Color With Severity Context
Update the Target Risk Meter color logic so that targets with only low-severity findings (e.g., Severity 3) are visually represented as low risk, with a color that reflects minor exposure rather than a misleading “perfect/fully healthy” state. Current Behavior A target with a Severity 3 vulnerability (example: TLS 1.1 enabled) may have an overall risk score of 100. Based on current thresholds: Low risk: 0–299 Medium risk: 300–599 High risk: 600+ The target is marked green on the risk meter, visually implying no meaningful risk, even though an actionable vulnerability exists. Problem The current green risk meter conflates “low risk” with “no risk.” Customers interpret a fully green meter as “nothing to address,” which reduces visibility of: Minor but actionable hygiene issues (TLS 1.1, weak ciphers, minor headers, legacy protocols). This causes confusion when: An issue list clearly shows open vulnerabilities But the target visually appears “perfect” Requested Enhancement Red - High Risk Target Orange - Medium Risk Target Yellow - Low Risk Target Green or another color - Fully Clean Target
Integration with GitHub Issues
Please upvote this request if you are interested in connecting GitHub to Halo Security.
Screenshots in tickets
When submiting a ticket through “Open Ticket” there is no option to add screenshots or post more comments :) In here: https://app.halosecurity.com/user/support/ticket?id=xxxxxx
Add Timestamp Column within Event Summary
URL: https://app.halosecurity.com/user/security/events/list Currently, you have to click into an event to figure out the timestamp of the event or hover over the date to know the time that the alert occured. We need a column available for a timestamp.
Integration with Salesforce Commerce Cloud
Description: Requesting a native integration between Halo Security and Salesforce Commerce Cloud (SFCC) to automatically ingest assets, URLs, and environments associated with SFCC stores. The integration should enable users to authenticate via API credentials or OAuth, detect staging and production storefront endpoints, and continuously monitor for exposed assets, misconfigurations, and vulnerabilities tied to SFCC deployments. Business Justification: Automating discovery and risk monitoring for SFCC domains would streamline onboarding, reduce manual target creation, and provide better visibility into managed SaaS environments that host critical public-facing applications. Requested Capabilities: Secure connection via SFCC API (Client ID/Secret or OAuth) Automated discovery of storefronts, sandboxes, and production URLs Tagging of discovered assets by organization and environment
Integration with Meraki
For environments using Meraki-managed networks, public IPs and routes can change due to DHCP, uplink failover, or SD-WAN policies. Currently, such changes must be manually synced into Halo. With a Meraki API integration, Halo could automatically stay up to date on this.
Integration with Linear Issue Tracking
Description: Request to add a native integration between Halo Security and Linear (https://linear.app/) to streamline vulnerability management workflows. When Halo Security detects a new issue or vulnerability, the integration should automatically create a corresponding Linear issue with key details (target, severity, summary, remediation notes, and a link back to the Halo finding). Status updates and closures in Halo should sync back to Linear, ensuring both systems stay in sync. Use Case: Customers and internal teams using Linear for engineering and security operations can manage vulnerabilities directly from their existing workflow without manual duplication or exports from Halo. Requirements: Create Linear tickets automatically from new Halo issues based on configurable severity or tag filters Sync issue status, notes, and remediation updates bi-directionally Allow mapping of fields between Halo and Linear (e.g., severity → priority) Support linking back to the Halo Security finding from Linear Include authentication and workspace configuration options within the Halo Integrations settings Value / Impact: Eliminates manual ticket creation for vulnerability triage Reduces missed issues and improves remediation tracking Increases Halo’s integration coverage and appeal for teams already using Linear
Include Event Details in Alert Emails
I created some new Event Rules which send emails if a condition is met/triggered. Would it be possible to included the following in those emails to get some more information, more efficiently? Subject Event Rule I created Both Target full name and nickname I’ve given some targets that are more important to us nicknames so I can locate them in the list easier, but since we have targets with very similar/repeating domains, it would be nice to see the exact domain AND nickname rather than primarily being the nickname.