> For the complete documentation index, see [llms.txt](https://docs.snyk.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.snyk.io/agent-security/evo-by-snyk/continuous-offensive-security-cos/scans/monitor-and-manage-scans.md). # Monitor and Manage Scans How to monitor scan progress and manage scan activity across your Continuous Offensive Security targets The scans and jobs view gives you access to every scan performed across Evo, in one place. Where a target shows you the scan history for that one application, this view shows all activity regardless of which target it belongs to. {% hint style="info" %} Starting and canceling a scan requires a Tenant role with full Evo access. To learn more, visit [Access and authentication](/agent-security/evo-by-snyk/access-and-authentication.md). {% endhint %} ### What the view shows | Column | What it tells you | | ------------- | ----------------------------------------------- | | **Status** | Whether the job is running, queued, or canceled | | **Type** | What kind of job it is | | **Initiator** | Who or what started it | | **Target** | Which target the scan is running against | | **Progress** | How far the scan has advanced | ### When to use it Use the target's own scan list when you are working on one application. Use scans and jobs when your question spans targets: | Question | Why this view answers it | | --------------------------------------------------- | -------------------------------------------------------------------------------- | | What is running across the whole program right now? | Shows every running scan at once, rather than checking targets one at a time | | Who started this scan? | The initiator tells you whether a person triggered it or it came from automation | | Why has my scan not started yet? | A queued status means it is accepted and waiting, not failed | | What has been canceled recently, and by whom? | Cancellations across all targets, with their initiator | | Is scan activity concentrated on one target? | Shows the distribution of activity across the portfolio | ### Reading the initiator The initiator identifies what started the job. This is the fastest way to answer questions about unexpected activity: a scan you did not expect is usually explained by either a colleague or an automated trigger, and the initiator tells you which without having to ask. It is also what makes shared ownership workable. When several people manage the same set of targets, the initiator is the record of who ran what. ### Reading the status | Status | Meaning | | ------------ | -------------------------------------------------------------------------------- | | **Running** | Executing now. Open the scan for per-stage progress | | **Queued** | Accepted and waiting to start. No action needed | | **Canceled** | Stopped before completion. Confirmed findings are preserved, coverage is partial | A queued scan has not failed. It has been accepted and will start on its own. One common cause of a queued scan is the target already having a scan running, since a target can only run one scan at a time. ### Scans and other Evo jobs This view covers jobs across Evo, not only Snyk Continuous Offensive Security scans. Snyk Continuous Offensive Security scans appear here alongside other Evo activity, which gives you a single place to see everything Evo is doing on your behalf. Use the target and type information to tell them apart. ## Monitor scan progress Scans take time, so it is worth knowing how to read progress while one runs. Doing so lets you catch a misconfigured target early instead of discovering it hours later from a report with nothing in it. ### Where to look | View | What it gives you | | -------------------- | -------------------------------------------------------------------------------------------- | | **Scan detail** | Per-stage progress for one scan: recon counts, attack counts, findings so far, report status | | **Target scan list** | Every scan for one target, with status and outcome. See Interpret scan results | | **Targets list** | Which of your targets have a scan running right now. See Manage targets | | **Scans and jobs** | Every scan across Evo, with status, initiator, target, and progress | ### Progress reported during a scan The scan detail view reports progress per stage. | Metric | Stage | How to read it | | ----------------------------- | --------------------- | ------------------------------------------------------------------------------------------------------ | | **Pages and endpoints found** | Recon | The size of the discovered attack surface. Compare against what you know your application to contain | | **Attacks performed** | Attack and validation | How much of the discovered surface has been tested, including attacks in progress and attacks finished | | **Findings so far** | Attack and validation | Confirmed, exploited vulnerabilities. This count only includes attacks that succeeded | | **Report generated** | Reporting | Whether the downloadable report is ready | ### What is visible while a scan runs Progress reporting during a scan is deliberately high level. You can see how far the scan has advanced, how many findings have been confirmed, and at what severity. You cannot yet open a finding to read its steps, proof of work, or remediation guidance. That means triage begins when the scan completes. What in-flight progress is for is a different job: confirming the scan is configured correctly and working, early enough to cancel and fix the target if it is not. Given a scan takes a few hours, that check is worth making rather than discovering a misconfiguration at the end. ### Reading the numbers on a first scan On a first scan of a target you have no baseline, so use your own knowledge of the application. Check the recon count first. This is the highest-value early signal, because attacks only ever cover what recon discovered. | Recon result | What it suggests | | -------------------------------------------------- | ------------------------------------------------------- | | Roughly the surface you expect | Configuration is working. Let the scan proceed | | Far fewer pages and endpoints than expected | Something is blocking discovery. Check the causes below | | Only your login page, or a handful of public pages | Authentication is almost certainly failing | When recon looks too small, check in this order: 1. **Authentication.** The most common cause, and it fails quietly: agents never get past the login page and no error tells you so. Verify the credentials, and for two-factor accounts verify the secret or seed rather than a code. See Configure authentication. 2. **Identity provider scope.** If login redirects to a third-party provider that is not in scope, the redirect is rejected at the proxy and authentication cannot complete. 3. **Application scope.** An API or service on a hostname you did not add to the scope is rejected at the proxy, so nothing behind it is discovered. This is the most common reason a front end scans fine but produces no serious findings. See Define the target scope. 4. **Firewall or WAF blocking.** If a firewall starts rate limiting or blocking scan traffic, discovery stalls. Configure a header the firewall allows, or allow the scanner IP addresses. See Add a target and Scanner IP addresses. If any of these apply, cancel the scan, fix the target configuration, and start again. There is no value in letting a scan run for hours against a surface it cannot reach. ### Reading the numbers on a repeat scan Once a target has scan history, compare against the previous scan rather than against intuition. | Observation | What it suggests | | -------------------------------- | --------------------------------------------------------------------------------------------- | | Recon count similar to last scan | Configuration is still valid | | Recon count dropped sharply | Credentials expired, a host moved, or the application changed. Check authentication and scope | | Recon count rose sharply | New surface was deployed. Worth confirming the new hosts are all in scope | | Fewer findings than last scan | Fixes are landing, or coverage dropped. Check the recon count to tell which | | More findings than last scan | New surface, new vulnerabilities, or previously blocked surface now reachable | A drop in findings is only good news if the recon count held steady. If both dropped, coverage fell rather than security improving. ### Duration Every completed scan records its duration, visible in the target's scan list. After a few scans of the same target you will have a dependable expectation for it. A scan running well beyond its usual duration is worth checking, most often for a firewall throttling traffic. ## Actions on scans Two actions are available on a scan: cancel it, and download its report. Both are available from the target's scan list and from the scan detail view. Canceling stops a running scan. Findings already confirmed are preserved. A canceled scan is not a discarded scan. Every finding agents had validated before cancellation remains available on the target, with its full detail and evidence intact, because each finding was already proven at the moment it was reported. What you lose is coverage. The remaining attack surface is not tested, and if the scan had not reached the reporting stage, there is no downloadable report for it. Situations to consider when to stop a scan: | Situation | Why cancel | | ------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- | | Recon found far less than expected | The target configuration is wrong. Fix it and rescan rather than letting hours run against unreachable surface | | The scan is affecting the environment | Someone needs the environment stable, or scan traffic is causing problems | | You started it against the wrong target | Stop it before it sends attack traffic where it should not go | | A critical finding needs immediate attention | Cancel, act on what you have, and rescan after the fix | | The scan is running far beyond its usual duration | Investigate before letting it continue | You can cancel a running scan directly from the targets list without opening the target, which is convenient when you are working across several targets. See[ Manage targets](/agent-security/evo-by-snyk/continuous-offensive-security-cos/targets/manage-targets.md). Canceled scans remain in the target's scan history with a canceled status. This ensures the history accurately records all executed scans. Treat findings from canceled scans as valid, but consider their coverage partial. A canceled scan does not indicate that untested areas are secure. ### Download the report The report is generated during the reporting stage, at the end of a scan. Once generated, download it from the scan as a PDF. The report contains more detail than the UI list view. It is the artifact to hand to an auditor, attach to a compliance review, or send to a team that does not use Evo. Historical reports remain available. Reports stay downloadable on past scans, so you can retrieve the report for an earlier assessment without rescanning. The scan detail view shows whether the report has been generated. If a scan has findings but no report, either reporting has not finished or the scan was canceled before reaching that stage. See Reports for what the report contains. {% hint style="info" %} Download the reports you need before deleting a target. Deleting a target removes its scan history, including the ability to regenerate historical reports. See Manage targets. {% endhint %} ### Scan statuses | Status | Meaning | | ------------- | --------------------------------------------------------------------------------------------------- | | **Queued** | The scan is accepted and waiting to start | | **Running** | The scan is executing. Progress is visible per stage | | **Completed** | The scan finished all three stages. The report is available | | **Canceled** | The scan was stopped before completion. Confirmed findings are preserved; coverage is partial | | **Failed** | The scan could not complete. Check the target configuration, starting with authentication and scope | --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.snyk.io/agent-security/evo-by-snyk/continuous-offensive-security-cos/scans/monitor-and-manage-scans.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.