When a container gets SIGTERM, a well behaved app stops accepting new work, finishes current requests, and exits before the grace period ends. Security cares because shutdown decides what happens to in-flight requests, queued jobs and open connections, and whether a killed process leaves partial state behind.
What the sources say
Twelve-factor calls processes disposable: they can be started or stopped at a moment's notice. On SIGTERM a web process stops listening on its port, lets current requests finish, then exits. A worker returns its current job to the queue. The methodology expects jobs to be reentrant, usually through transactions or idempotent operations, and expects the app to survive sudden death too.
Kubernetes documents the platform side. When a pod is deleted, it records a grace period, runs any preStop hook, and sends a termination signal to the main process in each container. After the grace period, a KILL signal goes to whatever remains. The default grace period for a manual delete is 30 seconds. If a readiness probe fails, the pod's address is removed from the matching EndpointSlices.
Security angles on shutdown
- Half finished writes. If a request is cut off mid transaction you can end up with inconsistent state, such as a payment recorded but an entitlement not granted. Transactions and idempotent handlers prevent this, and they also make replay attacks easier to reason about.
- Replayed jobs. A job returned to the queue will run again. If it is not idempotent, a rolling deploy can double charge or double send. Treat that as a correctness bug with a security cost.
- Long lived connections. WebSockets and streams hold sessions open. If a user was removed or a token revoked, a connection that survives a deploy might outlive the revocation. Close connections during drain and re-check authorization on reconnect.
- Secrets in memory and on disk. Temporary files holding sensitive data should be removed in a shutdown path and also by startup cleanup, because a KILL will skip your handlers.
- Grace period too long. A very long terminationGracePeriodSeconds lets an old, possibly vulnerable version keep serving after a security fix is rolled out. Keep it as short as your longest legitimate request.
Roll out a fix and know it is gone
For a vulnerability fix, shutdown behavior is how you know the old version has stopped. Check that the old pods are actually terminated, not just that new ones are healthy. Long grace periods, stuck preStop hooks and pods that ignore SIGTERM all extend exposure. Many images run a shell as PID 1 that does not forward signals, so the app never sees SIGTERM and waits for the KILL. Run the app directly as the container's main process or use a small init program.
Checklist
- App handles SIGTERM, stops accepting new work and drains.
- preStop hook, if any, finishes inside the grace period.
- Jobs are idempotent or transactional.
- Long connections are closed during drain.
- Grace period matches real request duration.
- After a security release, verify old pods are gone.
Quick check
What is the default grace period in Kubernetes?
The Kubernetes pod lifecycle documentation uses 30 seconds as the default grace period for a manual delete. You can change it with terminationGracePeriodSeconds.
Why does my app ignore SIGTERM?
Often the container's main process is a shell that does not pass the signal on. Run the app as the main process or use an init program that forwards signals.
Does graceful shutdown affect vulnerability fixes?
Yes. If old pods linger because of long grace periods or stuck hooks, the vulnerable version keeps serving traffic after you think the fix is out.
Where Safeguard fits
Safeguard's dependency scanning and policy gates help you prove which version of a component is in a release, and autonomous remediation can open a fix pull request for a vulnerable dependency; it is off by default and every category starts on Manual. See the free scan.
Sources
Last reviewed: 19 October 2026.
