Run a monthly dependency patch window with an offshore maintenance team

Is the handoff ready?

Use these checks before access expands or the first ticket begins.

Set a patch window the client can approve

A dependency patch window needs a fixed day, a start time, and a named approver on the client side. Publish the window at least one week ahead so product and support can plan around it. The offshore team should know which repositories are in scope and which are excluded. Put the calendar event in both the client and offshore time zones. Link the runbook and the approval ticket from that same event.

Keep the window short enough that a failed patch does not block the next business day. Two hours is usually enough for a small set of patch upgrades on one service. If the team needs more time, split the work across two windows instead of one long outage. Record the exact start and end in the ticket. Confirm the approver will be reachable for the first hour of the window.

Separate security patches from routine upgrades

A security advisory with a known exploit should not wait for the monthly window. Give the team a separate fast path with a named security owner and a shorter review. Routine minor upgrades can follow the monthly schedule. Classify every candidate before the meeting so urgent items do not sit behind cosmetic work. Publish the classification rule where both teams can read it.

Record the advisory identifier, the affected package, and the version that fixes it. That record lets a reviewer confirm the patch addresses the reported issue rather than a nearby release. If the advisory has no fix, record the mitigation and the date to check again. Do not upgrade unrelated packages in the same change. A security patch that also refactors code is harder to review and harder to roll back.

Test on a copy that matches production

Patch testing should run on an environment that uses the same runtime, database major version, and build flags as production. A test on a developer laptop can pass while the production image fails. Compare the two configuration files before the window opens. Record any difference and who accepted it. The comparison should include environment variables that affect the patched library.

Run the smoke path that support uses for customer issues, not only the unit suite. Check login, the main transaction, and the admin action that depends on the patched package. Capture the results with timestamps and the build digest. If the path fails, stop and use the rollback plan. A green unit suite does not prove that the deployed artifact is safe.

Keep a rollback path for every upgrade

Every patch needs a rollback step that the on-call engineer can run without the original author. Record the previous lockfile, the image tag, and the command that restores them. Test the restore on a staging copy before the window. A rollback that exists only in a document has not been tested. Store the tested command beside the patch ticket.

Decide in advance which patches cannot be rolled back because they include a data migration. For those, require a forward fix plan and a longer monitoring window. Do not let a routine patch pull in a schema change without a separate review. Write the decision in the patch ticket. The reviewer should be able to see whether recovery means a redeploy or a data repair.

Schedule the work across time zones

The offshore engineer who applies the patch should overlap with the client reviewer for the first hour. That overlap lets the team confirm the build and the smoke result before the reviewer signs off. Publish the on-call names for both sides. A window with no overlap turns a small failure into a morning queue. Include a backup reviewer for holidays and leave.

Hand the window to the next shift with a short note that lists the patches applied, the results, and any open issue. The note should link the tickets rather than repeat the details. Ask the next shift to confirm the smoke check again after the monitoring period. Record the confirmation time. The handoff is complete when the next engineer can explain what changed without calling the original pair.

Review the patch log monthly

At the end of each month, review every patch applied, deferred, and skipped. A deferred patch needs a reason and a new date, not a blank entry. Look for packages that repeatedly require emergency work. That pattern may point to an outdated framework rather than a process problem. Bring the raw entries to the review instead of a summary slide.

Report the number of patches applied, the number of rollbacks, and the time the team spent on the window. Compare the result with the previous month and with the security advisories that arrived. Choose one change to the process and set a date to check it. Keep the log where the client can read it. The goal is a predictable window that the business can trust.

Keep the advisory feed current

Subscribe to the security feeds for the runtimes, frameworks, and services the team actually operates. A generic newsletter misses the package that matters and adds noise the team learns to ignore. Assign one engineer to review the feed each week and flag items for the next window. Record the review date even when the result is no action. An empty review is evidence that someone looked.

Check transitive dependencies as well as direct ones. A package the team never imports can still enter the build through a framework or a tool. Use the lockfile and the software bill of materials to find those paths. If the tooling cannot produce a bill of materials, record that gap and the plan to close it. An advisory you cannot map to a package is an advisory you cannot act on.

Frequently asked questions

Sources

1. NIST Secure Software Development Framework

   Secure development and dependency practices used here.

2. GitHub Docs, about protected branches

   Review and merge controls referenced in the window.

3. CISA Secure by Design

   Guidance on accountable patching and controlled releases.