Continuous Security Monitoring for Websites

AURIX SHIELD Monitor extends security scanning beyond a single point-in-time scan. Instead of manually starting every scan, a verified target can be placed under continuous monitoring so AURIX SHIELD can run security checks according to the configured monitoring schedule and track how the target's security state changes over time.

The monitoring workflow is built around: Verify Target → Monitor → Schedule Scan → Compare Findings → Track Changes

Open Monitor

Use the Monitor workspace to manage monitored targets, monitoring state, schedules, and security history. Monitor is the continuous security workflow inside AURIX SHIELD. A monitored target is associated with a security scanning workflow that can run automatically according to its configured schedule. Monitor connects:

• Verified targets
• Monitoring state
• Scheduled scans
• Monitoring runs
• Security findings
• Finding comparison
• Scan history
• Notification preferences

This allows users to continue tracking security after an initial scan. A normal scan provides a point-in-time security result. Monitoring adds repeated security analysis over time. The difference can be represented as:

Single Scan

Target → Scan → Findings

Continuous Monitoring

Target → Schedule → Scan → Compare → Track → Repeat

This makes monitoring useful for products that change after the initial security review. Monitoring is designed around verified targets. A target must have the appropriate target configuration before it can participate in the monitoring workflow.

Verification helps ensure that the monitored target is an authorized security target rather than an arbitrary destination. Once a target is ready for monitoring, its monitoring state and schedule can be managed through the Monitor workspace.

Monitoring Status

A monitored target has a monitoring state. The monitoring workflow can represent states such as:

• Active
• Paused
• Baseline Pending
• In Progress
• Failed
• Completed

These states describe the current condition of the monitoring workflow. They should not be confused with the severity or resolution state of individual security findings.

Active Monitoring

When monitoring is enabled, the target remains eligible for scheduled security scans. The monitoring system uses the configured schedule to determine when the next monitoring scan should run. An active target can therefore continue receiving security analysis without requiring the user to manually start every scan.

Pausing Monitoring

Monitoring can be paused for a target. Pausing monitoring disables the active monitoring state without deleting the target's existing monitoring information. This allows users to temporarily stop automatic monitoring while retaining the target and its security history. Monitoring can subsequently be resumed.

Resuming Monitoring

When monitoring is resumed, the target becomes active again according to its configured monitoring schedule. The existing target and monitoring context remain associated with the target. Pause and resume therefore control the monitoring state rather than creating an entirely new monitored target.

Monitoring Schedules

A monitored target can have a configured schedule. The current production monitoring frequencies are:

• Daily
• Every 12 hours
• Every 6 hours
• Weekly

The schedule is combined with: This allows a monitoring schedule to be interpreted using the target's configured local timezone. A monitoring target can have a configured scheduled_time. This determines the intended local time for scheduled monitoring activity.

The scheduled time works together with the target's configured timezone rather than being interpreted as a universal fixed clock time.

Timezone

Monitoring schedules use an IANA timezone. This allows scheduled security scans to follow the configured local timezone of the monitored target. For example, a schedule configured for a particular local time remains tied to the selected timezone rather than relying on an assumed global timezone.

Automatic Monitoring Workflow

The monitoring workflow can be understood as: Verified Target → Monitoring Enabled → Schedule → Monitoring Run → Scan → Finding Comparison → Updated Security State

Verified Target

The target is authorized and ready for monitoring.

Monitoring Enabled

The target's monitoring state is active.

Schedule

The configured frequency, time, and timezone determine when monitoring should run.

Monitoring Run

A monitoring run records the execution of the scheduled security workflow.

Scan

The existing scanning infrastructure performs the security analysis.

Finding Comparison

The current results are compared with previously tracked findings.

Updated Security State

The monitoring history reflects what changed during the run.

Monitoring Runs

Each monitoring execution is represented as a monitoring run. A monitoring run can be associated with:

• The monitored target
• Scan information
• Run status
• Security findings
• Comparison results
• Monitoring history

This allows users to understand not only the current state but also how the security state changed over time. Monitor does not represent a completely separate security scanner. Scheduled monitoring uses the existing AURIX SHIELD scanning workflow.

This means monitoring can reuse the established security detection and finding infrastructure rather than maintaining a separate detection system. The relationship is: Monitor → Scheduled Scan → Security Engine → Findings

Finding Comparison

Monitoring becomes useful when the results of one run can be compared with previous security findings. AURIX SHIELD can track finding changes including:

• NEW
• EXISTING
• REAPPEARED
• RESOLVED
• CHANGED

These states describe how the current security state relates to previously tracked findings. A NEW finding represents a security issue detected during the current scan that was not previously present in the tracked finding state. A new finding therefore represents a newly observed security condition.

EXISTING Findings

An EXISTING finding represents a previously known security issue that remains detected during the current monitoring scan. This allows persistent issues to remain connected across multiple monitoring runs.

REAPPEARED Findings

A REAPPEARED finding represents a previously resolved security issue that has been detected again. This is important for monitoring because a security issue can return after previously disappearing from scan results.

RESOLVED Findings

A RESOLVED finding represents a previously tracked issue that is no longer detected in the relevant scan comparison. A resolved finding is part of the security history and can potentially reappear in a later scan.

CHANGED Findings

A CHANGED finding represents a tracked security issue whose relevant detection information has changed between scans. This allows monitoring to capture changes rather than treating every scan as simply “found” or “not found.”

Monitoring History

Monitoring history allows users to understand security activity over time. Historical information can help answer questions such as:

• When was the target scanned?
• What was detected?
• Did a new finding appear?
• Did an existing finding remain?
• Was a previous finding resolved?
• Did a resolved finding reappear?
• Did a tracked finding change?

This creates a continuous security timeline rather than a collection of unrelated scans. A failed scan or monitoring run must not be interpreted as a clean security result. A failed execution means the security analysis did not successfully produce a valid result. Therefore: Failed ≠ No Issues

The monitoring system should preserve the failed state rather than incorrectly treating the target as having zero security findings. This distinction is important for trustworthy security monitoring.

Monitoring and Security Findings

Monitor does not replace the persistent finding system. Instead: Monitoring Run → Scan Results → Persistent Findings → Comparison The same security findings can therefore be tracked across multiple monitoring runs. This allows the platform to maintain continuity between individual security analyses.

Monitoring and Fix & Verify

Monitoring and Fix & Verify serve different purposes. Monitor detects and tracks changes over time. Fix & Verify determines whether a specific security finding remains detected after remediation. The broader workflow is: Monitor → Finding → Fix → Verify → Monitor Again This allows a verified remediation to become part of the continuing security history.

Monitoring and Ask AURIX

Monitoring findings can provide context for Ask AURIX. AURIX AI can use security information such as:

• Finding
• Severity
• Scanner
• Repository or target
• File where applicable
• Evidence
• Security state

This allows users to investigate security changes conversationally. See the AURIX AI documentation.

Notification Preferences

AURIX SHIELD supports notification preferences for monitored security workflows. Notification configuration is associated with the user's monitoring/security context. Notifications are intended to surface relevant security changes rather than treating every successful monitoring run as an alert.

The exact notification behavior depends on the configured notification preferences and the monitoring result.

When Monitoring Should Notify

Monitoring is designed around meaningful security changes. For example, a monitoring result can distinguish between:

• A newly detected issue
• A previously known issue
• A resolved issue
• A reappeared issue
• A changed issue

This allows notification logic to focus on security events rather than simply reporting that a scheduled scan executed. Monitor is therefore an extension of the scanning workflow rather than a replacement for it. Continuous Monitoring is part of the AURIX SHIELD Pro experience. Pro also includes:

• Automated Scheduled Scans
• Change Tracking
• Monitoring & Scan History

See the Pricing documentation for the current plan comparison. The purpose of Monitor is to continuously track the security state of an authorized target over time.

The complete monitoring workflow is: Verify → Enable → Schedule → Scan → Compare → Track → Repeat

Verify

Ensure the target is authorized for monitoring.

Enable

Turn monitoring on for the target.

Schedule

Configure frequency, time, and timezone.

Scan

Run the security analysis through the existing scanner infrastructure.

Compare

Compare the current results against tracked findings.

Track

Persist the resulting security state and monitoring history.

Repeat

Continue according to the configured monitoring schedule.

When to Use Monitor

Monitoring is useful when:

• A website changes frequently.
• New deployments happen regularly.
• Security posture needs to be checked automatically.
• Previously discovered findings need to be tracked over time.
• Security changes need to be identified without manually starting scans.
• A team wants historical security visibility.

For one-time security analysis, use the Scan documentation.

Frequently Asked Questions

Explore AURIX SHIELD

• Product Documentation
• Security Engine
• AURIX AI
• GitHub Security
• Pricing
• Scan
• Fix
• Ask AURIX