A Finding is a vulnerability or exploit identified by a tester across your infrastructure, tracked from discovery through remediation.
Quick Links
- Location
- Managing Remediation
- Commenting and Collaboration
- Integrations to Support Remediation
- Sprocket Platform Public API
Location
To view findings, select Open Findings or All Findings under Findings in the left navigation. [1]
By default, findings are sorted by Severity (descending). Use the filter bar [2] and column headers [3] to narrow and reorder results.
Filters
| Filter | Description |
|---|---|
| Status | Whether a finding is open or closed |
| In Project | The engagement the finding belongs to, such as External Pentest, Internal Pentest, or Web Application Testing |
| State is | The current remediation status of the finding. Options include Pending Fix, In Progress, Retest Ready, Risk Accepted, and Fixed |
| Severity | The criticality level assigned by the tester. Options include Critical, High, Medium, Low, and Informational |
| Tag | Framework classifications including MITRE ATT&CK, OWASP and PCI |
| Assigned To | The organization member responsible for remediating the finding |
| Time Period | Filters findings by the date they were published to you |
| Asset Custom Tag | Filters by custom tags applied to associated assets |
Sort
Click a column header to sort by Severity, Published, or Last Updated. [3]
Export
To export a list of findings, click the Download icon button, then select your preferred file type from the menu. [1]
Note: Finding age is measured from the date the finding was published to you, including in exports and the Public API.
Severity Levels
Every finding is assigned a severity level by your Sprocket testing team. Severity reflects the criticality of the vulnerability and the likelihood of successful exploitation.
🟣 Critical
- Description: Requires immediate remediation. Represents the highest level of risk to the organization.
- Impact: Exploitation results in full compromise of the target, unauthorized access to sensitive data, or complete loss of confidentiality, integrity, or availability. Can enable further compromise of connected systems or resources.
- Attack Characteristics: Exploitable without authentication or special privileges, and requires no interaction from another party. May have publicly available exploits or evidence of active exploitation.
- Exploitation Likelihood: High
🔴 High
- Description: Should be prioritized for remediation in the near term.
- Impact: Exploitation results in significant unauthorized access, data exposure, or disruption of service. Can be chained with lower-severity findings to escalate to critical-level impact.
- Attack Characteristics: Exploitable but may require some level of authenticated access, a specific configuration state, or interaction from another party to trigger.
- Exploitation Likelihood: High
🟠 Medium
- Description: Should be addressed in a reasonable timeframe but does not require immediate action.
- Impact: Limited direct impact in isolation, but frequently chainable with other vulnerabilities to significantly elevate risk. May expose sensitive information or enable partial unauthorized access.
- Attack Characteristics: Exploitation typically requires multiple preconditions, elevated privileges, or actions from another party that are not guaranteed.
- Exploitation Likelihood: Medium
🔵 Low
- Description: **Remediation can be scheduled and prioritized against other business needs.
- Impact: Minimal standalone impact. Unlikely to be exploited in isolation, though may contribute to an attack chain in a highly targeted scenario.
- Attack Characteristics: Exploitation requires significant preconditions or a low-probability sequence of events to succeed.
- Exploitation Likelihood: Low
⚪ Informational
- Description: **No exploitable vulnerability identified.
- Impact: No direct risk. Findings provide contextual observations, defense-in-depth recommendations, or best practice guidance that may reduce attack surface over time.
- Attack Characteristics: Not applicable.
- Exploitation Likelihood: None
Managing Remediation
Your team can update the state of a finding to communicate remediation progress. The available options depend on the current State of the finding. You can move a finding from Pending Fix to In Progress, then to Retest Ready once you believe the vulnerability has been addressed. You can also move a finding backward at any point.
Tip: The progress bar at the top of a finding shows its current State across four stages: Pending Fix, In Progress, Retest Ready, and Resolved. The current State is highlighted. You can also see the State of any finding from the Findings table.
| State | When to Use |
|---|---|
| Pending Fix | The finding has not yet been addressed, the default state for findings |
| In Progress | Your team is actively working on remediation |
| Retest Ready | You believe the vulnerability has been fixed and are requesting a retest |
| Risk Accepted | Your organization has accepted the risk. Set by your Sprocket team |
| Fixed | The fix has been verified by a Sprocket tester |
Note: Risk Accepted and Fixed must be set by a member of the Sprocket Security testing team.
Updating State
State can be updated in two ways: standalone or alongside a comment.
To update State without a comment
- Click into the detail view of the finding.
- Click the ... menu in the upper right corner of the finding.
- Hover over Update State.
- Select your desired state from the menu. [1]
To update State with a comment
- Click into the detail view of the finding.
- Scroll to the bottom of the finding detail page.
- Enter your comment.
- Click the arrow to the right of the Comment button.
- Hover over Comment & Update State.
- Select your desired state. [1]
Validating Fixes
Once a finding is marked Retest Ready, your Sprocket testing team is automatically notified and will begin retesting. No further action is required from your team.
Note: There is no in-platform indicator that a retest is in progress. Your Sprocket tester will follow up with results directly.
Assigning Findings
Findings can be assigned to any point of contact on the associated project, allowing your team to track ownership through remediation.
To assign a finding:
- Click into the detail view of the finding.
- Click the ... menu in the upper right corner of the finding. [1]
- Hover over Assign User. [2]
- Select a user from the dropdown. [3]
Commenting and Collaboration
Comments on findings are the primary way to communicate with your Sprocket testing team about a specific vulnerability, including questions about the finding or remediation guidance.
To comment on a finding:
- Click into the detail view of the finding.
- Scroll to the bottom of the finding detail page.
- Enter your comment in the comment box.
- Click Comment to submit. [1]
Tip: To request a retest, updating a finding's State to Retest Ready is the preferred method. See Updating State.
Integrations to Support Remediation
Findings can be synced with your organization's issue tracking tools to support existing remediation workflows. Sprocket integrates with Jira Cloud and ServiceNow.
For setup instructions, see Integrations.
Sprocket Platform Public API
The Sprocket Platform Public API allows you to retrieve findings programmatically, with filtering and pagination support. Use it to build internal dashboards or analytics pipelines without manual exports.
The documentation below includes instructions for:
- generating API Credentials in Platform
- viewing, updating and commenting on published findings
- viewing discovered attack surface assets
- viewing automated attacks against your environment and viewing a list of assets per attack