Reference · built on requestOperator by FibricIT & reliability

Patch Window

Groups open vulnerability findings by asset, checks the change calendar, and proposes a patch batch with a maintenance window for approval.

Request accessPricing ↗

About

Findings arrive faster than windows open. Patch Window reads open findings from Tenable Vulnerability Management exports and GitHub Dependabot alerts, the asset inventory from ServiceNow and Jamf Pro, and the change calendar in ServiceNow, where the schedule and conflict endpoints say when a window is free.

It groups findings by the asset and the fix they share, a package version or an OS build, and proposes one batch per window: which assets, which fixes, which change request, and which PagerDuty maintenance window to open so alerts do not page during it. A change manager approves in ServiceNow. The receipt records the findings each batch covered and the ones it left out, with the reason.

This is a reference listing. It documents what Fibric would read from Patch Window and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Vulnerabilities from Tenable Vulnerability Management through POST /vulns/export, filtered by severity, state OPEN or REOPENED, and last_found, delivered in chunks by export_uuid
  • Dependabot alerts through GET /orgs/{org}/dependabot/alerts, with state, severity, scope runtime or development, and security_vulnerability.first_patched_version
  • Computer inventory in Jamf Pro through GET /v1/computers-inventory, with the OPERATING_SYSTEM and APPLICATIONS sections
  • Change requests through GET /sn_chg_rest/change in ServiceNow, and free periods from GET /sn_chg_rest/change/{sys_id}/schedule and /conflict
  • Configuration items tied to each change, so a batch touches the assets the change already names
  • Maintenance windows in PagerDuty through GET /maintenance_windows, so a window already planned is reused

Proposed actions

  • Target capability: propose a patch batch, assets, findings, and fix version per package or OS build, as one normal change through POST /sn_chg_rest/change/normal
  • Target capability: propose a standard change from a published template through POST /sn_chg_rest/change/standard/{sys_id} where the batch matches one
  • Target capability: propose a PagerDuty maintenance window through POST /maintenance_windows for the services in the batch, matching the change window
  • Target capability: propose a Managed Software Update Plan through POST /v1/managed-software-updates/plans for Jamf Pro devices behind the target OS build
  • Target capability: propose a Jira issue per Dependabot alert in the batch, carrying first_patched_version and the repository, for the owning team

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Turn a scan into one change request

    Critical and high findings from the latest Tenable export are grouped by host and fix. The operator proposes a normal change with the assets as configuration items, the first free window from the schedule endpoint, and a conflict check attached.

    With ServiceNow, PagerDuty

  • Batch Dependabot alerts by package across repositories

    Open runtime alerts sharing a package get one proposed batch with first_patched_version, a Jira issue per repository, and a standard change from your dependency-update template.

    With GitHub, Jira, ServiceNow

  • Bring Macs onto the target build in one window

    Computers whose OPERATING_SYSTEM section reads below the build you set get a proposed Managed Software Update Plan, scheduled inside the approved change window, with a PagerDuty maintenance window on the device services.

    With Jamf Pro, PagerDuty

Requirements

  • Tenable Vulnerability Management API keys, sent as X-ApiKeys with accessKey and secretKey, or a GitHub token with access to security alerts on the repositories
  • A ServiceNow user with change_manager, itil, or admin for creating change requests, and the Change Management API available on the instance
  • Jamf Pro client credentials with inventory read and, for update plans, the managed software update privilege
  • A PagerDuty API token with services.write, if maintenance windows are to be proposed
Authentication
Reads findings, inventory, and the calendar with the scanner, code hosting, MDM, and ITSM grants you attach. Change requests are created as the ServiceNow user you assign, which needs itil or change_manager.

Limits

  • Tenable exports are asynchronous, and duplicate exports cannot run at once. A chunk holds 50 to 5,000 assets. Fresh findings appear after the next scan.
  • Jamf Pro collects inventory once a day per device unless a policy asks sooner, so a device patched today may still read as behind.
  • It proposes batches and windows. It never runs a patch, pushes an MDM command, or closes a finding. A change still goes through ServiceNow approval.
  • Dependabot alerts cover the dependency manifests GitHub can read. Vendored or compiled dependencies are not in that list and need the scanner.

Access and pricing

Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Patch Window ↗

Questions and answers

What does a change manager approve?
One batch per window: the asset list, the finding ids and their severities, the fix per asset, the proposed window with its conflict check, and the maintenance window that covers it. Assets can be removed and the window moved before the change is created.
What record is left?
A receipt per batch: the export or alert ids it drew from, the change request number, the maintenance window id, who approved, and the findings left out with the reason. After the window, the next export shows which findings moved to FIXED.
Does it patch anything itself?
No. It proposes the batch, the change, the window, and, for Jamf Pro, an update plan you approve. The patch is run by your tooling under the change. Closing a finding is left to the scanner's next result.
Ask about Patch Window

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This operator is developed, published, and supported by Fibric. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy