Get risk alerts after download
Get an email or a webhook event when a package your builds downloaded gets a new vulnerability or malware report, up to 30 days after its last download.
Rules decide when a package is requested. A vulnerability or malware report published later reaches your next install, while builds that already have the package keep it. Risk alerts tell you about those packages.
Every day the firewall looks up each package version it served in the last 30 days in the latest advisory and malware data. The lookup uses the name and version, so nothing is downloaded again. An alert can come weeks after the download.
It covers every version the firewall served, including versions an exception let through. No rule is needed.
This guide uses the dashboard. Observations are also in the API.
What counts as new
A version's first check is its baseline. It runs shortly after the firewall first serves the version and alerts nobody, so risks that were already known when the package was served never produce an alert. Those show in the vulnerability summary on the Observations page and on the package page.
Every later daily check compares with the previous one. These changes are new:
| Change | Applies to |
|---|---|
| A vulnerability that was not reported before | Vulnerabilities |
| A vulnerability whose CVSS score rose into critical (9.0 and above) | Vulnerabilities |
| A vulnerability added to a known-exploited catalog | Vulnerabilities |
| A vulnerability that moved into the 5% most likely to be exploited (EPSS percentile 0.95 or higher) | Vulnerabilities |
| A malware report that was not there before | Malware |
A change stays new for 7 days. Internal packages and container images are not monitored.
Choose who gets the email
One team receives a summary email each day the check finds something new. Pick the team that acts on it, such as security or platform.
- Open Teams and create a team for the recipients, or use an existing one. Every member gets the email.
- Open Settings in the main menu.
- Under Observation risk alerts, select the team.
Changing the setting needs ns:update. Select Nobody to stop the emails. New risks are still found and shown in the dashboard without a team.
The email lists how many risks of each kind were found, the 20 most severe, and a link to the Observations page filtered to new risks.
Send alerts to your own tools
To open tickets or post to a chat channel, subscribe a webhook to observation.risk.detected. On the webhook form it is New risks in served packages, in the Observed package risks group. See Receive webhook events.
You get one event per package version, listing the findings that changed since the last notification and every firewall that served the version. If the webhook is limited to some firewalls, it gets the event when any of those served the package. The payload is in the webhooks reference.
Review what was found
Open Observations and set Risks to New in the last 7 days. The email links to this view.
The first column shows each version's monitoring state:
- Not monitored: an internal package or an image, a version not served in the last 30 days, or a version still waiting for its baseline. Hover for the reason.
- Monitored daily: checked every day, nothing new in the last 7 days.
- New findings in the last 7 days: red for malware, a known-exploited vulnerability, or a critical one, amber otherwise.
Select a version to open its package page. The Observations card there has a timeline: when each firewall first served the version, when monitoring started, and each change since, linked to its advisory or malware report.
Act on the finding
Builds that already have the package keep it until the dependency is upgraded. Upgrade it in the affected projects, using the fixed versions on the package page. To automate this, have your webhook receiver act on observation.risk.detected, for example by opening an issue or a pull request in the affected repositories.
To keep the version out of new installs, make sure a rule covers it, such as Block vulnerable packages or Block malware.
Troubleshooting
Alerts are for changes after the baseline. Vulnerabilities known when the version was first served are part of the baseline. A version that was not served for 30 days gets a new baseline the next time it is served.
- No team is selected under Observation risk alerts in Settings.
- The team has no members.
- The daily check found nothing new. The email is sent only on days with new risks.
Hover over the mark for the reason. Internal packages and container images are never monitored. A version last served more than 30 days ago is no longer monitored. A version served for the first time waits for its baseline.
Related
- Concept: Observability, Prevention model
- How-to: Receive webhook events, Research advisories and malware, Manage access
- Reference: Observations, Webhooks, Advisory sources
Enforce license policy
Block package downloads by license, with named license sets as deny or allow lists and a rule for unknown licenses.
Integrate with repository managers
Deploy the firewall together with Artifactory, Nexus, GitLab, GitHub Packages, Azure Artifacts, or AWS CodeArtifact, between them and the public registries, between developers and them, or on both sides.