Request demo

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

vpn-legacy.acme.example

  1. Severity
    Critical
  2. Issue type
    Remote desktop exposed

    Remediation guidance attached:

  3. Asset
    vpn-legacy.acme.example · 203.0.113.24
  4. Evidence
    3389/tcp open

    What the scan observed:

  5. Classifications
    CWE-284, OWASP Top 10 2021, PCI DSS 4.0
  6. State
    newly_detected, then unresolved, then marked_as_resolved, then rescan, then verified_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.

SeverityCritical, High, Medium, Low or Information
Issue typeA named check with its description, category and remediation guidance
AssetThe domain, subdomain or IP address it was found on
EvidenceWhat the scan observed on the asset, stored with the issue
StateWhere the issue stands now, with the history of how it got there
ClassificationsOWASP Top 10 2021, PCI DSS 4.0 and 3.2, HIPAA, CWE, CAPEC and WASC
CVE contextFor 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 resolved
  • risk accepted
  • ignored
  • marked 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-resolved
  • search:accept-risk
  • search:mark-false-positive
  • search:ignore
  • search:revert

Filter

  1. must type.category.name eq SSL/TLS
  2. must asset.domain_asset.name eq 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

Mark resolved by filter
# 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.

Questions About Remediation

What is the difference between marked as resolved and verified resolved?

marked_as_resolved records that your team believes the issue is fixed. verified_resolved 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.