From PHP vulnerabilities to supply-chain compromises, security teams are being forced to make difficult decisions about patching, exposure, and business continuity. Here’s the response from security leaders on critical incidents and the learnings on the front lines.
Some days in cybersecurity are busier than others, and then there are days when everything seems to go wrong at once…like October 21.
Critical vulnerabilities, reports of compromised customer data, exposed credentials, supply-chain attacks, and security teams scrambling to understand which threats actually affect their environments.
The recent wave of security incidents involving PHP2Shell, GitLab, LiteLLM, Railway, and reported banking-sector exposures has brought a familiar challenge into sharp focus: when everything appears urgent, how do security teams decide what to fix first?
For some organizations, it has meant working through the night to patch vulnerable applications. For others, the bigger challenge has been figuring out whether their third-party vendors are exposed, or whether they can take the systems they depend on offline (and whether that would actually solve, or even help solve, the issue).
To understand what this looks like in practice, we brought together security leaders from the 403 Circle community for an impromptu discussion, hosted by Astra.
What emerged wasn’t another conversation about vulnerability scores or alarming headlines. It was a practical look at the decisions CISOs make under pressure, the gaps they’re discovering, and the security fundamentals that still matter.
Here are the biggest takeaways.
1. Patching is urgent. But knowing what to patch is the real challenge.
When a critical vulnerability becomes public, the immediate response seems obvious: identify affected systems and patch them.
In reality, that process is rarely straightforward.
A cybersecurity operations leader at a large pharmaceutical organization described how the PHP vulnerability kept the team working through the night.
With multiple websites running on vulnerable PHP versions, remediation became an immediate priority, but identifying vulnerable systems was only the beginning.
The organization also had to navigate Kubernetes clusters, container dependencies, and the time required for updated images to become available.
Moreover, even after patches were released, supporting components weren’t necessarily ready at the same time.
The team prioritized its internet-facing systems and eventually considered those assets remediated.
Internal systems and additional investigation remained ongoing.
This revealed an important distinction: a patch being available doesn’t mean an organization can deploy it immediately.
Modern applications depend on interconnected components, i.e., updating one layer may require changes across containers, runtimes, and supporting infrastructure.
For security teams, this creates three immediate questions:
- Do we know exactly which applications and services are running the affected software?
- Can we identify vulnerable versions across containers, clusters, and dependencies?
- Can we prioritize internet-facing assets without losing visibility into the rest of the environment?
In simple terms, vulnerability response begins long before a patch is released.
Organizations that already understand their technology stack are better positioned to respond when a critical vulnerability emerges.
2. What happens when you can’t take a vulnerable system offline?
One of the most interesting moments in the discussion came when the pharmaceutical security leader explained why shutting down affected websites wasn’t a realistic option.
Some of the organization’s applications supported access to patient-related information.
Taking them offline could have serious operational consequences.
The team therefore had to balance two competing priorities: reducing security exposure and maintaining essential services.
Rather than shutting everything down immediately, the organization relied on internal scanning tools, detection capabilities, and forensic investigation while continuing remediation.
The team also developed detections based on emerging exploitation techniques to help identify potential compromise.
Security decisions don’t happen in isolation from business operations.
A system can be vulnerable and still be too critical to disconnect without careful consideration.
The question becomes less about whether to respond and more about how to reduce risk while preserving essential services.
That may involve prioritizing exposed assets, strengthening monitoring, implementing temporary mitigations, accelerating patch testing, and defining clear escalation criteria.
Importantly, maintaining availability should never be mistaken for accepting an unmitigated critical risk. Decisions need to reflect actual exposure, exploitation evidence, and business impact.
3. Your organization may be patched. But what about your vendors?
While some participants focused on their own infrastructure, others faced a different problem: third-party exposure.
One security leader shared that several partners using PHP were still trying to understand where their vulnerabilities existed and how to remediate them. Some vendors had proactively communicated that investigations were underway. Others provided incomplete updates or were less forthcoming.
The challenge wasn’t simply determining whether a vendor used vulnerable software. It was understanding what that vulnerability could mean for the organization relying on that vendor.
- Had the vendor patched its systems?
- Was there evidence of compromise?
- What access did the vendor have to internal environments?
- How quickly could the organization get reliable answers?
As Astra’s co-founder and CTO, Ananda Krishna, pointed out during the discussion, reviewing vendors is as important as reviewing internal systems because the access granted to those vendors may also be at risk.
The security leader explained that the team was monitoring and reviewing its partners, but had not yet isolated them because the impact remained inconclusive.
Based on its assessment at the time, it had not identified any critical assets, or “crown jewels,” as affected, but it did bring third-party risk management back into focus.
Vendor reviews can establish a baseline, but they cannot tell an organization everything it needs to know during an active incident.
When a critical vulnerability emerges, security teams need to quickly identify which vendors may be affected, understand the access they hold, and decide whether to restrict that access while the investigation continues.
That means bringing vendor access into the incident response process from the start, rather than waiting for a vendor assessment or a confirmed compromise.
An organization needs to account for the systems it controls directly and the external relationships that could expose them; i.e., the incident response plan cannot stop at the organization’s own infrastructure.
4. A vulnerability doesn’t automatically mean a breach. But patching doesn’t prove you’re safe.
Another important theme was the difference between vulnerability remediation and compromise investigation.
The pharmaceutical leader described how the organization had deployed patches and built additional detections using newly available information about exploitation techniques.
Yet one question remained unanswered: Had anyone exploited the vulnerability before the patches were applied?
That required a separate forensic investigation, a distinction worth emphasizing: patching closes a known vulnerability, but it doesn’t automatically prove the vulnerability was never exploited.
Similarly, detecting vulnerable software doesn’t prove that an attacker has successfully accessed the environment.
Security teams need to answer both questions independently.
Exposure assessment: Where are we vulnerable, and how quickly can we remediate?
Compromise assessment: Is there evidence that an attacker has already exploited the vulnerability?
The discussion also highlighted another emerging risk: unreliable or malicious proof-of-concept exploits circulating during major security events.
Security professionals investigating a vulnerability may encounter unverified tools or scripts that introduce additional risks.
This makes trusted intelligence, validated detection logic, and controlled testing particularly important.
The takeaway is simple: remediation and investigation must happen together.
A green vulnerability dashboard is encouraging, but it shouldn’t be the only measure of incident resolution.
5. The biggest security lesson might be the least exciting one: fundamentals still matter.
As the conversation shifted toward prevention, an interesting question emerged.
Could organizations have done something differently to avoid the disruption?
One participant argued that some software vulnerabilities can exist for years before anyone discovers or publicly discloses them.
The discovery itself may be new, but the underlying weakness may not be.
His recommendation was refreshingly straightforward: get the basics right.
- Network segmentation.
- Appropriate use of DMZs.
- Restricting unnecessary access.
- Consistent patching.
- Strong visibility into exposed systems.
These aren’t new security concepts, but they can make an enormous difference when a critical vulnerability becomes public.
An organization with strong asset inventory, controlled network access, and established remediation workflows may still face a serious threat.
The difference is that it has a clearer starting point.
Rather than spending the first several hours discovering where vulnerable software exists, the team can focus on validating exposure and executing its response plan.
Another participant described dealing with unrelated Nginx and Node.js upgrade challenges, including unsupported versions and missing upstream fixes.
It was a reminder that even when a headline vulnerability doesn’t affect an organization, technical debt and lifecycle management remain ongoing security concerns.
The takeaway?
You cannot prevent every vulnerability from being discovered. But you can reduce the disruption it causes.
6. AI could make vulnerability discovery faster. Are defenders ready?
Toward the end of the discussion, participants explored AI’s role in vulnerability discovery and exploitation.
Some observed that AI-assisted code analysis is changing how researchers identify potential weaknesses in applications and open-source components.
Tasks that once required substantial manual investigation may increasingly be supported by automated analysis.
Ananda Krishna shared that Astra’s experience with agentic penetration testing has shown how AI-assisted approaches can surface vulnerabilities that still require human validation.
The broader concern, however, was that attackers may benefit from similar capabilities.
If vulnerability discovery becomes faster, the time between disclosure and potential exploitation could become increasingly difficult for defenders to manage.
That said, the discussion also highlighted an opportunity, as the same technological advances can support defensive workflows, including vulnerability discovery, exposure assessment, and security testing.
Does this eliminate the need for experienced security professionals? No, but it makes their ability to validate findings, prioritize risk, and make informed decisions even more important.
The question for organizations is no longer simply whether AI will influence cybersecurity.
It’s whether their defensive processes can keep pace with increasingly automated discovery and attack techniques.
What CISOs can take away from this discussion
Across the conversation, five practical priorities stood out.
1. Know your environment before the next emergency.
Maintain accurate visibility into applications, runtimes, software versions, containers, and internet-facing assets. Don’t start discovery when a critical advisory is published.
2. Prioritize based on exposure and business impact.
A critical vulnerability score is an important signal, but effective prioritization also considers exploitability, system exposure, asset sensitivity, and operational dependencies.
3. Include vendors in incident response.
Establish clear communication channels, review third-party access, and require timely updates when critical vulnerabilities affect external services.
4. Treat patching and forensics as separate responsibilities.
Deploy fixes quickly, but keep investigating whether attackers exploited vulnerable systems before remediation.
5. Invest in security fundamentals and repeatable workflows.
Segmentation, access controls, lifecycle management, monitoring, and rehearsed response processes help organizations respond more consistently under pressure.
Questions from the community
Q: Should organizations immediately take vulnerable applications offline?
Not necessarily in every situation. The decision depends on exposure, exploitability, available mitigations, business criticality, and evidence of active compromise. When shutdown isn’t immediately feasible, organizations need compensating controls, close monitoring, and an accelerated remediation plan.
Q: How can security teams assess third-party exposure during a widespread incident?
Start by identifying affected vendors and their access to organizational systems. Request remediation status, exposure assessments, and, where relevant, evidence of compromise. Escalate when vendors cannot provide sufficient assurance.
Q: Is applying a patch enough to consider an incident resolved?
No. A patch addresses the vulnerability, but organizations may still need to review logs, investigate suspicious activity, validate controls, and determine whether compromise occurred before remediation.
Q: Can organizations realistically avoid the next major vulnerability crisis?
They cannot eliminate every newly discovered vulnerability. However, better asset visibility, reduced attack surfaces, sound architecture, and established response procedures can significantly improve their ability to manage the next event.
The real takeaway: Cyber resilience is built before the crisis.
The most striking part of the discussion wasn’t how many incidents made headlines.
It was how differently organizations were experiencing them.
One security team was working through the night to patch vulnerable applications.
Another was waiting for clarity from its third-party vendors.
Others were navigating unsupported software versions, investigating potential exposure, or trying to distinguish credible intelligence from noise.
All with different environments and challenges, yet coexisting in one shared reality.
Cybersecurity teams are increasingly expected to make high-stakes decisions with incomplete information and very little time.
While new tools and technologies can accelerate detection and remediation, resilience still depends on preparation, visibility, collaboration, and sound judgment.
That’s also why we brought the 403 Circle community together.
Sometimes, the most useful thing security leaders can do during a difficult week is compare experiences, ask questions, and learn from what others are seeing.
Because the next critical vulnerability is only a matter of time, is your organization better prepared for when it arrives?
Continue the conversation with 403 Circle
403 Circle is Astra’s community for CISOs and cybersecurity leaders to exchange perspectives, discuss emerging threats, and learn from peers navigating similar security challenges.
If you’re working through recent vulnerabilities, reviewing third-party exposure, or rethinking your incident response strategy, we’d love to have you in the conversation.
Join the 403 Circle community and connect with security leaders facing the same challenges.
This article is based on a community discussion hosted by Astra. We anonymized participant experiences in accordance with the session’s Chatham House Rule. Incident references and technical claims discussed during the session reflect the information available to participants at the time and should be verified against official advisories before publication.
