TL;DR

  • Scanning everything every time creates noise fast.
  • New and changed services are usually the highest-value scan targets.
  • Selective inputs improve runtime and make findings easier to review.

The naive version

The obvious way to run template scanning is to point it at every currently live service on a schedule and let it go. That works, but it burns a lot of time on services that did not change and probably will not produce new results.

I wanted the scan stage to behave more like a follow-up action than a bulk ritual.

The better trigger

The most useful scan targets usually come from the probe diff:

  • newly discovered live URLs
  • known URLs with changed status
  • known URLs with changed titles
  • known URLs with changed technology hints

Those changes are often better indicators than raw volume.

Why selective scanning improved the pipeline

Runtime stayed bounded

Once I limited the default scan input to fresh deltas, the scan stage stopped drifting into long and unpredictable runs.

Findings became easier to trust

A smaller target set means the output is easier to interpret. I can connect a new finding to a recent service change instead of wondering whether it was buried in the system for weeks.

Noise dropped

Repeatedly re-scanning unchanged services tends to create operational fatigue. Even when findings are technically valid, they become less useful if they arrive without context.

What still deserves a full scan

Selective scanning should not be the only mode. A periodic full pass still has value because:

  • templates change
  • coverage improves over time
  • an unchanged service can still become newly detectable

The practical compromise is:

  • delta-driven scans by default
  • occasional full scans on a slower schedule

That gives me both freshness and broader coverage.

I also narrowed template intent

Another useful refinement was to focus on checks that fit the target class. Login-related checks belong on pages that actually look like login or admin surfaces. Broadly blasting them across everything is a poor use of time and a good way to produce junk.

The bigger lesson is that scan scope should reflect prior context, not just tool capability.

Takeaway

The scan stage became more valuable once I stopped treating all live hosts equally. If your probing layer already tells you what changed, let that information drive where deeper checks run next.

Public reference repo

The sanitized reference repository for this series is here: jenkins-recon. It contains the public-facing example scan inputs, filtering ideas, and review-friendly output structure behind this write-up.