SecOps2Shell
A Critical Vulnerability in the Human Control Plane
Every system has a breaking point. Ours has been marked as a stretch goal.
SATIRE — SecOps2Shell is a fictional vulnerability. The organization, dialogue and incident timeline below are invented. The technical and workforce research cited at the end is real.
At 08:03, the first critical vulnerability arrived.
It had a CVE, a logo, a dedicated website and a paragraph explaining that everything was potentially affected. The security team had twelve minutes to establish whether “everything” included anything they actually owned.
At 08:07, someone forwarded it with “Are we exposed?”
At 08:09, someone else forwarded the same advisory with “Please prioritize.” By 08:14, it had reached five channels, acquired three owners and become two separate incidents. The vulnerability was spreading through the organization considerably faster than the exploit.
Then the second critical vulnerability arrived.
By lunchtime, the team was investigating a cloud identity issue, checking an edge appliance, chasing a vulnerable library through container images and trying to determine whether a retired application had been retired technically or only in a presentation.
The dashboard remained green. It measured tickets closed.
Nobody had added a field for how much of the team was left.
Advisory summary
Identifier: S2S-FICTION-001 — fictional, not a CVE.
Affected component: The gap between organizational demand and human capacity.
Severity: Critical. The team requested High, but that required a justification.
Prerequisites: An unbounded work queue, overlapping responsibilities and the belief that committed people can always find another hour.
Potential impact: Delayed remediation, weaker verification, lost expertise and an expanding opportunity for attackers to obtain a shell.
Patch status: Available. Requires management participation.
1. Initial access through a perfectly reasonable question
“Can you just check whether we are affected?” is a reasonable question.
The problem begins when five versions of it launch five workstreams, each with its own deadline, and nobody can see the combined load.
In our fictional organization, the CISO’s original request was clear: establish exposure, identify the highest risks and provide a realistic response plan. As it travelled down the forwarding chain, the context disappeared and the urgency increased. By the time it reached the on-call engineer, it had been compressed to “ASAP.”
This is a remarkably efficient communications protocol. It preserves anxiety while discarding information.
The vulnerability management team was already validating scanner findings. Application Security was identifying affected dependencies. Infrastructure was planning changes. The SOC was checking for exploitation. Each team had useful work to do; each also received requests to confirm what all the other teams were doing.
Everyone owned a piece of the response. Nobody owned the interruption rate.
2. Technical root cause
SecOps2Shell is an unbounded work queue attached to a finite human execution environment.
The architecture assumes that new advisories, investigations, emergency changes, audit requests and status updates can arrive indefinitely without displacing anything already in progress.
When incoming work exceeds sustainable capacity, something waits. That is a property of the system. Adding the word “critical” changes the label on the queue; it does not add capacity to the people processing it.
Unfortunately, our fictional capacity model contains an undocumented overflow mechanism: the evening.
If the evening fills up, the system retries against the weekend. After a successful retry, the extra work is recorded as evidence that the original staffing model was sufficient.
We have effectively implemented human autoscaling. Every new instance is the same person reopening their laptop.
There is a second defect: technical severity has been promoted into a universal scheduling policy. A vulnerability in an exposed service with evidence of exploitation competes for attention with a severe finding in a configuration the organization does not use. Both have a red badge. Both have a deadline. One has a more persistent group chat.
Real prioritization needs context. CISA’s SSVC approach supports decisions about vulnerability response using factors such as exploitation and impact, rather than treating a score as a complete response plan.
In the fictional environment, that decision tree has been optimized to a single branch: “Has someone senior asked about it?”
3. Proof of concept
No exploit code is required. The following fictional trace reproduces the condition:
08:03 Critical advisory received.
08:14 Duplicate workstreams created in five channels.
09:10 Engineer begins validating actual exposure.
09:13 Engineer joins meeting to explain validation progress.
10:00 New priority accepted. Existing priorities unchanged.
12:30 Lunch moved to the next available maintenance window.
15:40 Status requested because remediation is taking longer.
18:20 Team completes work using unplanned overtime.
18:25 Capacity model marked “validated”.
The most important line is the last one.
The organization has mistaken a temporary act of commitment for a repeatable operating model. Next week’s plan will now include this week’s sacrifice, but without naming it.
Meanwhile, the actual route to a shell becomes less theatrical and more plausible. A patch waits behind duplicated assessment work. An emergency permission remains because its cleanup task has no protected time. A rushed change receives less verification than it needs.
None of these outcomes is inevitable. Each is a reason to treat capacity as part of security engineering.
An attacker does not need to understand the organizational chart to benefit from the work falling between its boxes.
4. The automation patch
Subscribe to Friend of Medium to remove upgrade prompts from your unlocked stories.
Get KNYI’s stories in your inbox
Join Medium for free to get updates from this writer.
At this point, someone suggests AI.
This is a good suggestion. A well-designed assistant can remove repetitive work: consolidate advisories, retrieve asset context, assemble evidence and draft updates that people would otherwise write several times.
In our fictional deployment, however, the first success metric is “summaries generated.” The agent produces a polished paragraph for every finding. The analysts now have the same queue, with better grammar.
Phase two adds automatic ticket creation. Throughput increases immediately, although mostly at the end of the process that was already moving too quickly.
Phase three promises autonomous remediation. Its first task is to inspect one repository. Its service identity receives write access across the organization, with enough permissions to pursue a broader career.
The CISO asks whether it is read-only. The answer is yes. Unfortunately, that describes the demonstration reviewed three weeks earlier.
There is a real engineering concern underneath this joke. OWASP identifies excessive functionality, permissions and autonomy as causes of excessive agency in LLM systems, and recommends narrow capabilities and authorization enforced by downstream systems.
Automation deserves a better success criterion: how much repetitive work it safely removes, how much human review it still requires, and whether the team gets any of that capacity back.
If every hour saved is immediately replaced with two hours of new commitments, the automation has improved the business case more than the working day.
5. The missing telemetry
At first, the team is simply busy.
People help each other. Someone stays late so a colleague can leave. The person who understands the legacy service takes another call because explaining it from the beginning would take longer.
These are generous acts. They deserve appreciation. They also need a recovery period.
In this story, the recovery period keeps moving to the right.
The engineer who used to ask the awkward, useful question starts accepting the first plausible answer. A colleague stops suggesting improvements because every suggestion has a habit of becoming another assignment. The on-call analyst checks their phone during dinner even when someone else has the shift.
Eventually, the team still attends every meeting, answers every message and closes every ticket it can. From a distance, the service looks available.
Up close, the curiosity is quieter. Patience is shorter. The spare attention that used to catch the unusual detail has already been spent explaining why six urgent requests cannot all be first.
Burnout enters this story without an outage banner. It becomes visible in what people no longer have the energy to contribute.
Workforce research gives this concern substance. In ISC2’s 2025 study, 48% of respondents reported exhaustion from keeping up with threats and emerging technologies, and 47% said they often felt overwhelmed by their workload. ISACA’s 2026 research also identified excessive work and unrealistic expectations among the leading sources of stress. These figures describe reported strain, not inevitable outcomes.
Our fictional organization has plenty of monitoring. It knows when a server has been above its capacity threshold for ten minutes.
The human equivalent has been above threshold for three quarters and has just received a thank-you message.
6. A note for the people managing the people
The CISO is in the same picture.
There is a board asking for assurance, a business asking for speed, a budget with limits and a threat landscape that does not negotiate. Managers can be absorbing pressure from above while trying to protect the team below. Some are doing both after an equally long day.
That pressure makes leadership choices more consequential.
When a new emergency arrives, somebody with authority must decide what moves. When demand keeps exceeding capacity, somebody must change the scope, improve the process, obtain the skills or people required, or explicitly accept the work that will remain undone.
If those decisions stay unresolved, the team makes them anyway. Quietly. In the space between the workday and the rest of their lives.
That is an expensive place to hide a business decision.
Taking care of security teams means making those decisions visible and sharing responsibility for them. It means being able to say, “This matters, and here is what we are stopping so you can do it properly.”
It also means asking a better question than “Can everyone make one more push?”
“What would have to change so that the next response does not require one?”
7. Recommended remediation
The patch is compatible with existing leadership structures. It does require changes to default settings.
Make priority a decision with a consequence. Establish one agreed view of urgent work. When a new item becomes first, name what moves down and who accepts the resulting risk. Record the exposure, the decision, the owner and when the decision will be revisited. An additional priority without a trade-off is an additional demand.
Give the response a clear route through the teams. Agree who assesses relevance, who owns the affected service, who deploys the fix and who investigates possible exploitation. Keep one evidence record and a shared update cadence. Five teams should be able to collaborate without performing the same assessment five times.
Plan for incidents before they borrow time from people. Include on-call coverage, handovers, leave, training and recovery after exceptional work in the capacity plan. Give critical services enough shared knowledge that someone can take a day off without becoming a remote dependency. Recovery should not be the only commitment in the calendar that everybody else can move.
Make automation earn back time. Measure work removed and outcomes verified. Give agents the permissions their tasks require, and preserve human attention for decisions where it adds value. A faster ticket generator is an unusual treatment for an overloaded queue.
Protect the ability to raise a concern. “We cannot complete all of this safely with the capacity available” should begin a management decision. Make it possible to report that early, while choices still exist.
Measure whether the operating model is sustainable. Alongside remediation and response metrics, review repeated after-hours work, interrupted leave, deferred training, recurring ownership gaps and preventable rework. Discuss these with the team; the purpose is to repair the conditions creating overload.
The release notes contain one particularly useful change:
Fixed: employee commitment was being treated as unlimited capacity.
8. Verification
The patch is working when an important advisory arrives and the team knows what to do without renegotiating its entire life.
The relevant owners can establish exposure. The most consequential work gets attention first. Updates come from a shared record. People finishing an overnight response can hand over and recover. Management can explain both what is being addressed and what has been deliberately deferred.
There will still be difficult weeks. Security work includes real emergencies.
The test is whether an emergency has an end.
Final impact assessment
There are two kinds of shells in this story.
One is the access an attacker hopes to gain on a system. The other is how a capable person can end up feeling after months of urgency without recovery: a shell of themselves.
People deserve recovery in their own right. A functioning security program depends on it, too.
Management has a responsibility to protect that capacity. If we keep using exhaustion to bridge the gap between demand and resources, we leave more opportunities for attackers while asking our people to keep paying the difference.
The next critical vulnerability will arrive. It will probably have a logo.
Let us make sure the people responding to it still have something left.
This satire explores common industry pressures. It does not describe my employer, colleagues, systems or any specific incident.
