Continuous monitoring
Secure at launch is not secure next month.
New vulnerabilities are published every day against packages you already ship. Sentrasec keeps checking your applications after release and tells you what needs to change when the world around them does.
A scan is a snapshot
A scan tells you what was vulnerable on the day it ran. The next day a new advisory lands against a library you depend on, and yesterday’s clean result is out of date, though nothing in your code changed.
Teams that scan only at release find these issues at the next release, or when someone else does. For products built quickly, with dependencies added at the same pace, the gap grows fast.
Monitoring closes that gap: the same checks, run again on a schedule, against current data, with the result sent to where your team already works.
What keeps running after release
Scheduled scans
Set a schedule per application and scan type. Each run uses the same scanners as a manual scan, so a scheduled result and a clicked result cannot disagree.
Current vulnerability data
Dependency scans check your packages against vulnerability data as it stands at scan time, so newly published advisories show up on the next run.
Alerts where you work
New findings, failed scans and state changes can be sent to Slack, Microsoft Teams, email or a signed webhook, per project.
Fixes stay fixed
When a fix commit reaches your default branch, Sentrasec re-tests the finding. If it comes back, the finding is reopened rather than left closed.
How it works, step by step
01
Connect the app
Add the repository, and the URL of the running application for DAST.
02
Set a schedule
Choose which scans run and how often. Any schedule can also be run on demand.
03
Route alerts
Send each project’s alerts to the Slack or Teams channel, inbox or webhook that owns it.
04
Act on what changed
New findings are triaged like any other, and the ones that need action arrive with a plan.
What it does not do
- A newly published advisory is picked up on the next scheduled scan, not the moment it is published.
- Monitoring covers the applications and scan types you schedule. It is not runtime protection and does not block traffic.
- Alerts carry the finding, not your source code.
Questions
How often should I scan?
Daily dependency scans are a sensible default for products in active development. Code scans also run on demand, from the CLI and from your coding agent.
Will I be flooded with alerts?
Alerts are per project and per event type, and every new finding is triaged first, so you can route only what needs action to the people who own it.
Does it work for applications we no longer actively develop?
Yes. Older applications are often the most exposed to new advisories, because nobody is updating their dependencies. A schedule keeps checking them.
See it on your own code
Bring a repository or a release you are about to ship. We will scan it, triage the findings and show you where it stands for security and compliance.