Skip to main content

Monitor for regressions

Set up monitoring on a project to catch security regressions: cases where a fixed vulnerability turns exploitable a second time.

Prerequisites​

  • An AISafe account with manager or higher role
  • A Project created for the repository or target
  • At least one completed assessment with findings on the project

What is a regression?​

A regression occurs when a vulnerability marked fixed turns exploitable once more. This can happen when:

  • A fix is reverted or circumvented by a subsequent code change
  • A dependency update reintroduces a vulnerability patched in a prior release
  • An infrastructure change exposes an attack vector mitigated in a prior release

Monitoring catches these, so you do not have to wait for the next scheduled scan or a real attacker to discover them.

Step 1: Open the project​

  1. Navigate to Projects in the AISafe dashboard.
  2. Open the project you want to monitor.

Step 2: Enable monitoring​

  1. Go to the Monitoring tab or settings section.
  2. Toggle Enable monitoring.
  3. Configure monitoring checks:
    • Select which findings to monitor (e.g. all critical and high findings)
    • Set the check cadence (how often to re-validate PoCs)
  4. Save the configuration.

Step 3: Set up regression alerts​

To receive a notification when AISafe detects a regression:

  1. Connect Slack and enable monitoring regression notifications.
  2. Or configure an outbound webhook in your dashboard so the monitoring.regression event reaches your own tooling.

After AISafe detects a regression, it:

  1. Raises a monitoring.regression event.
  2. Posts a Slack notification (if configured).
  3. Fires any matching outbound webhook subscriptions you have set up.

Step 4: Respond to regressions​

After you receive a regression alert:

  1. Open the finding in AISafe to see the regression details.
  2. The finding's status reverts to open (or AISafe creates a new finding, depending on configuration).
  3. Investigate the cause: check recent code changes, dependency updates, or infrastructure changes.
  4. Fix the regression and verify the fix.

If a target is not verified​

Monitoring tests the project's black-box targets, so every one of them must be verified for your organization (see Domain ownership). Turning monitoring on is refused while a target is unverified, and the message names the hosts. If a target stops being verified, for example after you add a new host to the project, monitoring pauses instead of failing every check, and it resumes on its own once every target is verified again.

If your plan changes​

If your plan stops including monitoring, monitoring is paused and shows Paused by plan. Its run history stays readable, nothing runs or is charged, and it resumes on its own when you upgrade. See Credits & billing.

Next steps​