Notifications & Webhooks

Notifiers can alert you via email, Slack, or Teams when new vulnerabilities are detected, a noncompliant package is discovered, and when other package-related events occur. You can also configure webhooks to send these alerts, trigger automation workflows, externally audit certain events, etc.

Creating a Notifier

To create a notifier, navigate to Admin > Notifiers & Webhooks, then click "Create Notifier".

After selecting the Event type (such as New Vulnerability Detected or Package Promoted) and then Action (such as Send an email or Custom webhook), you'll be presented with additional relevant options. You can also specify Conditions to determine whether the notifier should run on all feeds, for specific packages, etc.

Prerequisite Configuration

Before configuring an Email, Slack, or Teams notification, you may need to make some configuration changes.

Once the prerequisite configuration is complete, you'll be able to use notifiers.

Notifications & Event Types

Package Events

These occur immediately after a package is added, removed, or changed on a feed.

These events are nearly the same as the audit events (under Admin > Event Log), except audit events will include cached packages.

If for some reason you'd like to also send notifications for cached packages, just let us know via the support channel. It's easy to change, but we'd like to document why to use them.

SCA Events

These occur immediately after a noncompliant or vulnerable package is added to a feed or issues are created in a noncompliant build. SCA events can also occur during the continuous (generally overnight) scanning of packages and builds

Conditionally Send Notifications

The "Conditions" tab of a notifier allows you to control whether a notification will be dispatched (sent).

When "Run on feed" is selected, notifications will only be dispatched for events that occur on the feed. Note that when selecting a feed for events that don't relate to feeds (such as Issues Opened on Build), a notification will never be dispatched.

You can also select "Run conditionally", which will allow you to further control if a notification is dispatched.

• Always run is the default, and will run when the feed condition matches
• Never run disables the notifier and is a convenient alternative to deleting them
• Package matches will limit dispatch to a package name or package version
• Vulnerability score will limit dispatch if the vulnerability score is at least as high
• Advanced expression allows you to use OtterScript and variables to control dispatch

To learn more about how to use OtterScript with advanced expressions, see Variables under Creating Custom Webhooks.

Custom Webhooks

ProGet's custom webhooks allow you to control nearly all aspects of the dispatched request.

By default, the Request Type (i.e. HTTP Method) will be POST, and the Headers will be Content-Type: application/json. The Content (i.e. Body or Payload) will depend on the event type, and can written using an OtterScript expression. See Creating Custom Webhooks to see these defaults

Default Content: Issues Opened on Build

$ToJson(%(
    issues: @BuildIssues,
    buildNumber: $BuildNumber,
    releaseNumber: $ReleaseNumber,
    projectName: $ProjectName
))

{
  "issues": [ 
    {"Sequence": "1", "Detail":"Noncompliant package (PGV-892418)" }, 
    {"Sequence":"4", "Detail":"Noncompliant package (MIT License)"} ],
  "buildNumber": "25.4.2",
  "releaseNumber": "v25-Q4",
  "projectName": "XAPUtil.Web" 
}

Default Content: Noncompliant Package Detected

$ToJson(%(
    package: $PackageId,
    version: $PackageVersion,
    result: $PackageComplianceResult,
    details: $PackageComplianceDetails,
    feed: $FeedName
))

{
  "package": "MyCorp.CoolUtils",
  "version": "3.2.0-pre.1",
  "result": "Noncompliant",
  "details": "Vulnerability (PGV-2358804); Package is Unlisted",
  "feed": "internal-utils"
}

Default Content: New Vulnerability Detected

$ToJson(%(
    packages: @AffectedPackages,
    vulnerabilityId: $VulnerabilityId,
    summary: $VulnerabilitySummary,
    severity: $VulnerabilitySeverity,
    score: $VulnerabilityScore
))

{
  "packages": [ {"Name": "nuget:Newtonsoft.Json", "AffectedVersions":"< 13.0.1." } ]
  "vulnerabilityId": "PGV-2245804",
  "summary": "Improper Handling of Exceptional Conditions in Newtonsoft.Json",
  "severity": "High",
  "score": "7.5"
}

Default Content: Package Events

$ToJson(%(
    package: $PackageId,
    version: $PackageVersion,
    event: $WebhookEvent,
    user: $UserName,
    feed: $FeedName
))  

{
  "package": "MyCorp.CoolUtils",
  "version": "3.2.0-pre.1",
  "event": "Promoted",
  "user": "API",
  "feed": "internal-utils"
}

Troubleshooting

To help with troubleshooting, ProGet stores history about the last 50 dispatch results for each notifier. You can see these under Admin > Notifiers > View Logs.

Dispatch Mechanisms

Understanding how notifications are dispatched may help troubleshoot errors related to network issues, firewalls, etc.

Notifications may be dispatched from either the ProGet Web Application or the ProGet Service, depending on how the event occurred. For example, promoting a package can only be done from the Web Application (i.e. UI or API), so a notification will always be dispatched from the Web. However, a Package Add may occur from the Web Application or also the Service, since the drop path monitor can also add packages.

ProGet 2023 and earlier

ProGet 2023 and earlier versions have a webhooks feature that behaves similarly.

• Everything is basically a "Custom webhook", and emails are not supported
• There is no dispatch history, but you can view errors by navigating to Administration> Diagnostics Center and filtering to show only webhook messages
• Slack and teams messages are supported but more complicated (see Connecting to Slack (archive.org))

See the Webhooks (archive.org) documentation to learn more.

There was also a Webhooks Management API (archive.org) that has been discontinued.