Remediation
Every Finding Comes With Evidence and a Fix Path.
A finding your team has to re-investigate is a finding that waits. Each issue arrives with what the scan observed, the remediation guidance for its issue type and the asset it sits on.
From there it moves through its states, from newly detected to verified resolved, which the platform records once a rescan no longer finds the signal.
Remote desktop exposed
Issue
-
SeverityCritical
-
Issue typeRemote desktop exposed
Remediation guidance attached:
-
Assetvpn-legacy.acme.example · 203.0.113.24
-
Evidence3389/tcp open
What the scan observed:
-
ClassificationsCWE-284, OWASP Top 10 2021, PCI DSS 4.0
-
State
newly_detected, thenunresolved, thenmarked_as_resolved, then rescan, thenverified_resolved(current state)
Verified resolvedafter the rescan
What Your Team Sees in Each Issue.
Whoever picks up an issue should be able to act on it without running the scan again.
| Severity | Critical, High, Medium, Low or Information |
|---|---|
| Issue type | A named check with its description, category and remediation guidance |
| Asset | The domain, subdomain or IP address it was found on |
| Evidence | What the scan observed on the asset, stored with the issue |
| State | Where the issue stands now, with the history of how it got there |
| Classifications | OWASP Top 10 2021, PCI DSS 4.0 and 3.2, HIPAA, CWE, CAPEC and WASC |
| CVE context | For vulnerabilities: CVSS, EPSS and CISA KEV, including the KEV due date and required action |
Each Decision Gets Its Own State, Because Open and Closed Lose Information.
A two-state tracker cannot tell a fixed issue from an accepted risk, or a false positive from a check that does not apply. The platform keeps each decision on record, and a revert returns an issue to its previous active state. A resolved signal that shows up again reopens the issue as reappeared.
Found
Open
The team can decide
Each scan checks
newly detected
orreappeared
unresolved
checked again on every scan
optional, kept on record
marked as resolvedrisk acceptedignoredmarked as false positive
verified resolved
the signal is gone: no one has to mark itnot applicablewhen a scan cannot tell
Work the Queue by Filter.
Issue actions run in bulk too. Send the filter body you use to search issues, by state, severity, type, category, asset or date, and the change applies to all matching issues.
The API refuses a change the current state does not allow (error 30004), so a bulk request cannot move an issue somewhere the lifecycle forbids. Vulnerabilities on assets take the same actions.
search:mark-resolvedsearch:accept-risksearch:mark-false-positivesearch:ignoresearch:revert
Filter
-
must
type.category.nameeq SSL/TLS -
must
asset.domain_asset.nameeq acme.example
-
Expired certificate
shop.acme.example
marked_as_resolved
-
Open port 3389 (not selected)
vpn.acme.example
unresolved
-
Expired certificate
mail.acme.example
marked_as_resolved
-
Expired certificate
old.acme.example
verified_resolvedrefused, error 30004
-
Expired certificate (not selected)
cdn.acme-group.example
unresolved
Request
POST /v1/easm/issues/search:mark-resolved
# Every issue that matches filter.json
curl -X POST \
"https://api.deepinfo.com/v1/easm/issues/search:mark-resolved" \
-H "apikey: YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d @filter.json
Findings Reach the People Who Fix Them.
Notify
Rules per Owner
Tag assets by owner or business unit, then write notification rules on new and reappeared issues, scoped by asset, severity or tag. Delivery is instant or an hourly, daily, weekly or monthly digest.
Report
A PDF per Audience
Issue overview and issue detail reports for the people doing the work, weekly progress and executive summary for the people tracking it. On demand or scheduled.
Export
CSV, JSON and API
Any issue search exports in full, and issues, with their state histories, are available through the API for the tools your team already runs.
Measure
Time Open, Time to Fix
Issue statistics report the average time issues stay open and the average time to fix, next to counts per severity, state and type.
Query This Data Through the API
The subdomains, DNS records, certificates, ports and technologies this module finds come from Deepinfo’s own index. Your developers can query it through the API.
Questions About Remediation
What is the difference between marked as resolved and verified resolved?
marked_ records that your team believes the issue is fixed. verified_ records that a later scan no longer finds it, and a scan sets it on its own whether or not anyone marked the issue first. Keeping the two apart shows which of your team’s fixes are confirmed and which are still waiting for a scan.
Can we close an issue without fixing it?
Yes. Accept the risk, ignore it, or mark it as a false positive. The issue leaves the active queue but keeps its state history, and a revert puts it back where it was.
Which states does our team set, and which does the platform set?
Your team sets marked as resolved, risk accepted, ignored and false positive. The platform sets the active states (newly detected, unresolved and reappeared) and the two closing states it confirms itself: verified resolved and not applicable.
What happens when a fixed issue comes back?
It reopens as reappeared instead of arriving as a new, unrelated issue, so the earlier decisions stay visible. A notification rule on reappeared issues can alert the owner.
Can a bulk change touch issues it shouldn’t?
Only issues the filter matches, and an empty filter matches all of them. Run the filter as a search first, check the result, then send the same body to the action.
Can issues flow into the tools we already use?
Issue searches export as CSV or JSON, and each issue and its state history is available through the EASM API, so the hand-off can be scripted. See integrations for what is supported today.
Follow a Finding From Detected to Verified.
Book a walk-through and we’ll take real findings on your domain through the lifecycle.