"Continuous monitoring" can mean anything from a rescan every few minutes to a weekly batch job. Before you sign, ask the SCA vendor to state in writing what triggers a rescan, how soon after a new advisory you will be told, who is notified and how, and what happens when a scan fails. Vague answers are a signal.
Why the phrase needs a definition
A scan at build time is a snapshot. A package that was clean on Monday can have an advisory on Wednesday. Monitoring is supposed to close that gap, but the size of the gap depends on details that marketing language hides.
What to define
| Item | Question | What a clear answer looks like |
|---|---|---|
| Rescan trigger | What causes a rescan? | A new advisory, a scheduled interval, a new commit, or all of these |
| Scope | What gets rescanned? | Stored inventories of every connected project, not just recent builds |
| Timing | How soon after a source publishes does my result change? | A stated target, with how it is measured |
| Notification | Who hears about it and how? | Named channels, severity filters, and routing per owner |
| Failure | What if a scan or data update fails? | An alert to you, not silence |
| History | Can I see when a finding first appeared? | A first seen date on each finding |
The timing question is the one that matters
There are several clocks between a flaw being disclosed and you acting on it: the source publishes, the vendor ingests, your inventory is rechecked, and your team is notified. Ask the vendor which of these they control and what they will commit to. The ones they do not control, such as the source's own publishing time, are worth knowing about too.
Ask about inventory-based rescanning
The efficient way to monitor is to store the component inventory for each project and check it against new advisories as they arrive, without needing a new build. Ask whether that is how the tool works. If it only rescans when code changes, then dormant but deployed services will not be monitored.
Keep evidence
Ask for a record showing the last successful check for each project. That record answers the auditor's question of whether monitoring was operating on a given date.
A short test
In the trial, pick a project you will not touch for the whole week. See whether any finding appears or changes during the week, whether you are notified, and whether the record shows when the tool last checked.
A worked example: following one advisory
Say an advisory is published at 09:00 against a widely used library. Here are the clocks that run after that.
- 09:00, the source publishes the record.
- The vendor's ingestion picks it up. This may be minutes or hours, depending on how often it polls each source.
- The vendor matches the record against stored inventories. With stored inventories this is fast. If it needs a rebuild of your project, it can take days.
- The tool creates findings and applies your routing rules.
- A notification is sent to the owner, through chat, email, or a ticket.
- A person reads it and acts.
You can ask the vendor to commit to steps two through five, and you control step six. The sum of the clocks is your real exposure window. If the vendor cannot say what happens at each step, you do not know your window.
Step by step: turn "continuous" into a written term
- List the six clocks above and ask the vendor to fill in what they control and what they expect.
- Ask for a target for step two and for steps three to five together, stated as a measured target, such as "most records ingested within a stated period".
- Ask how they measure it and whether you can see the measurement.
- Ask what notification channels exist and how severity filters work.
- Ask what you will see if ingestion fails, and how soon you will be told.
- Ask for a last checked time on each project that you can export.
- Record the answers in the order form, the security addendum, or an email you keep.
- Re-test at least once during the first quarter by following a real advisory.
Notification routing
Notifications are only useful if they reach someone who can act. Check that you can route by repository or service owner, by severity, and by whether a finding is reachable or known to be exploited. Check that there is a way to snooze or acknowledge, so repeated reminders do not become noise.
Scheduled scans versus event driven checks
Some tools rescan on a schedule, some on new advisories, some on new commits. Event driven checks on stored inventories are usually fastest. Scheduled scans are simpler and may be enough for lower risk systems. Match the design to the risk, and put the interval in the contract or runbook.
What good evidence looks like
For audits, keep a record showing the last successful check for each project, and a log of notifications sent and acknowledged. Together they show that monitoring ran and that someone responded.
Edge cases
Dormant services that nobody touches are the ones most at risk of missing a new advisory. Services deployed from artifacts built elsewhere may have no repository link. Ask how the tool handles each, and whether asset discovery can find services that were never registered.
Try it yourself
Click through it at your own pace, or open it full screen.
Look for what causes a re-check and how a new finding reaches an owner.
Quick check
Is a nightly scan continuous monitoring?
It can be, if the gap is acceptable for your risk. The point is to know the interval and agree it, rather than assume.
Do I need to rebuild to catch a new advisory?
Not if the tool stores your inventory and rechecks it. Ask the vendor to confirm that behavior.
What is a reasonable way to test monitoring in a trial?
Pick a project you will not change, watch it for a week, and follow one new advisory from publication to notification. Record the delays at each step.
Last reviewed: 19 October 2026.
