Scan Logs and Trace History

Purpose

This article explains how CMSSPM records scan activity, what scan logs and trace history represent, and how they can be used to understand what happened during and between scans. The goal is to give administrators a clear sense of how the plugin tracks operations over time, not just the latest dashboard snapshot.

What scan logs are

Scan logs are records of scan activity. They capture information about when scans ran and what the plugin did, such as:

• when a scan started and finished,
• which areas or categories were included,
• whether the scan completed successfully or encountered problems,
• any notable events that occurred while checks were running.

These logs give you a basic operational history that can help answer questions like “When was this site last scanned?” or “Did the last scan complete successfully?”

What trace history is

Trace history focuses more on what changed across scans rather than just when they ran. In practical terms, this can include:

• how findings evolved over time (for example, new, resolved, or mitigated),
• when status changes occurred, such as moving a finding from fail to pass or marking it as mitigated,
• key scoring changes associated with scans or actions.

This makes it easier to see whether the site is improving, staying stable, or regressing, and to connect that back to specific actions or scans.

Why logs and history matter

Scan logs and trace history are useful for both operational and accountability reasons. They help you:

• verify that scans are running as expected,
• identify when issues first appeared,
• correlate changes in configuration or infrastructure with changes in findings,
• provide a record for internal reviews, audits, or security discussions.

Without this kind of history, it would be harder to explain why the current posture looks the way it does or to demonstrate improvement over time.

How they relate to findings and scoring

Logs and traces are closely tied to findings and scoring. In general:

• scan logs show when the plugin collected data,
• trace history shows how findings and statuses changed,
• the dashboard and scoring model show what the current state looks like.

Together, they provide a fuller picture: you can see not only that a finding exists and how it impacts the score, but also when it first appeared, when it was addressed, and how that affected the overall posture.

Using them in practice

A practical way to use scan logs and trace history is:

1. Look at scan logs when you suspect a problem with timing, completion, or scheduling.
2. Review trace history when you want to understand when a particular finding changed, or why a score looks different between two points in time.
3. Use both views to support conversations with other teams, document remediation work, or verify that planned changes had the expected effect.

This keeps CMSSPM useful not just as a point-in-time scanner, but as a tool for tracking and explaining security posture over time.

Would you like a separate, more technical article that calls out specific fields or columns you plan to expose in your scan log and trace views (for example, timestamps, user IDs, and scan identifiers)?