Project Lightwell narrows vulnerability-to-protection gaps across software

At a glance

What this is: A Palo Alto Networks, IBM and Red Hat collaboration aims to shorten the gap between vulnerability discovery and protection by combining virtual patching with remediation workflows.

Why it matters: It matters because identity and access teams increasingly inherit the blast radius of vulnerable software, especially where secrets, service accounts and privileged integrations sit behind exposed applications.

👉 Read Palo Alto Networks' analysis of Project Lightwell and vulnerability protection

Context

AI-driven vulnerability discovery is reducing the time defenders have to react, which turns exposure management into a governance problem as much as a patching problem. When flaws can be identified and weaponised in minutes, the control question becomes whether an organisation can protect dependent identities, services and integrations before exploitation begins.

For identity and access teams, this matters because vulnerability response now intersects with NHI governance, secrets handling and privileged access paths. A network-level shield can buy time, but it does not remove the underlying need to know which service accounts, API keys and workload identities sit behind the vulnerable path, or how quickly they can be adjusted when systems change.

Key questions

Q: How should security teams respond when vulnerability discovery outpaces patching?

A: They should split the response into containment and repair. Containment reduces the immediate exploit window through network controls, configuration hardening or isolation, while repair addresses the underlying software flaw. The priority is to protect the systems most likely to be reached before change can be safely deployed, especially where service identities and external dependencies expand the blast radius.

Q: When should organisations use virtual patching instead of waiting for a code fix?

A: Use virtual patching when the exposure window is too short for normal patch cycles and the vulnerable service is externally reachable or business-critical. It is most useful as a temporary compensating control while testing, validating and scheduling the real fix. The control should be time-bound and tracked to closure.

Q: What do security teams get wrong about vulnerability management in complex environments?

A: They often treat the software flaw as the whole problem. In practice, the risk also depends on deployment topology, third-party dependencies, privileged identities and how quickly the environment can absorb a fix without disruption. Effective vulnerability management is therefore a coordination problem across architecture, operations and identity governance.

Q: Which controls matter most for reducing exposure across software supply chains?

A: The most effective controls combine accurate inventory, rapid containment, validated remediation and ownership for every critical dependency. Teams should also map which non-human identities and secrets are tied to vulnerable applications, because exploit impact is often driven by what the software can reach, not just by the code defect itself.

How it works in practice

Why virtual patching changes the defence timeline

Virtual patching is a compensating control that blocks exploit attempts at the network or gateway layer before a software fix is deployed. It does not repair the code, but it can interrupt known exploit paths while teams validate remediation. That matters when discovery outpaces patch cycles, because defenders need a control that activates faster than application release and change-management processes normally allow. In practice, virtual patching works best as a temporary containment layer, not as a substitute for durable software repair.

Practical implication: Treat virtual patching as a time-buying control and tie it to a dated remediation plan rather than letting it become permanent risk acceptance.

How remediation workflows reduce exposure in complex estates

Remediation workflows connect vulnerability intelligence to testing, validation and deployment so fixes can move across multiple environments without being stalled by manual handoffs. In heterogeneous estates, the challenge is not just identifying the flaw. It is deciding which system versions, platform dependencies and operational constraints determine whether a fix can be applied safely. Where open source, commercial applications and OT are all in scope, remediation has to be staged to avoid breaking production while still shrinking the exposure window.

Practical implication: Build a prioritised remediation path that distinguishes emergency containment from safe fix deployment across different asset classes.

Supply-chain vulnerability management now includes identity dependencies

Software vulnerabilities are increasingly a supply-chain issue because exploitation often depends on trusted integrations, embedded components and downstream dependencies that organisations do not fully inventory. That creates an identity dimension: exposed software rarely exists alone, and the credentials, tokens and service relationships attached to it can widen blast radius when compromise occurs. The technical problem is therefore not only code weakness, but the trust chain surrounding the application.

Practical implication: Map which workloads, service accounts and secrets depend on externally sourced software so exposure decisions include identity blast radius, not just code severity.

NHI Mgmt Group analysis

Exposure windows are now the control problem, not just patch speed. The article reflects a broader shift in security economics: AI compresses the time between discovery and exploitation, so defenders lose the luxury of slow remediation cycles. That makes the length of the exposure window the key variable practitioners must manage across software, identity and operational control planes.

Supply-chain resilience increasingly depends on identity-aware containment. Vulnerable software is rarely isolated. It is coupled to service accounts, API tokens, deployment credentials and privileged automation that can turn a software flaw into a wider access event. The identity programme therefore has to understand which non-human identities sit behind vulnerable services, because the exploit path often follows the trust path.

Virtual patching is a compensating control, not a governance model. It can reduce immediate risk, but it does not resolve inventory gaps, dependency blind spots or accountability for who owns remediation. In practice, organisations that rely on network-level shielding without asset and identity governance are only moving the problem sideways.

Software remediation and vulnerability intelligence are converging into one operating model. The collaboration signals where the market is going: security teams are being pushed toward integrated detection, containment and fix workflows rather than siloed product buying. Practitioners should expect vulnerability management, network defence and identity governance to be treated as one risk system, not three separate programmes.

Identity blast radius is the concept teams should borrow from this discussion. The important question is not only whether a vulnerability exists, but what identities, permissions and downstream services would be reachable if it were exploited. That framing gives CISOs and IAM leads a more usable way to prioritise remediation work.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, according to NHI Mgmt Group research.
• Use NHI Lifecycle Management Guide to connect remediation timelines to credential rotation, offboarding and access review workflows.

What this signals

The operational signal is clear: vulnerability response is converging with identity governance because compromised software usually exposes a path to credentials, not just code. The teams that will cope best are those that can trace which service accounts and secrets sit behind exposed applications and which of those identities can be moved, revoked or isolated quickly.

Identity blast radius: this is the right concept for practitioners to adopt when prioritising exposure management. It asks a simple question with large consequences: if this flaw is exploited, what identities and downstream systems become reachable before containment lands?

As AI accelerates vulnerability discovery, defenders need a combined view of patch status, access paths and privilege scope. NIST SP 800-207 Zero Trust Architecture remains relevant here because the control objective is still to limit implicit trust while exposure is being reduced.

For practitioners

• Prioritise exposure windows, not just CVSS scores Rank vulnerabilities by how long they remain exploitable in your environment, then align remediation effort to the systems that can be exploited before patching completes.
• Inventory the identity chain behind vulnerable services Identify the service accounts, API keys, workload identities and deployment credentials attached to each exposed application so containment decisions reflect real blast radius.
• Use virtual patching as a bridge to repair Deploy network-level blocking where patching is delayed, but set an explicit expiry for the compensating control and track it through change management.
• Link remediation to ownership and validation Assign one accountable owner for each high-risk flaw, require proof of test validation before closure, and track whether dependent identities or integrations were affected.

Key takeaways

• AI-assisted discovery is shrinking the defender's reaction time, which makes exposure window management a first-class control objective.
• Software vulnerabilities become materially worse when they sit behind privileged identities, secrets and automated access paths.
• Teams should treat virtual patching as a bridge to verified remediation, not as a substitute for ownership or closure.

Key terms

• Virtual Patching: Virtual patching is a compensating control that blocks known exploit attempts without changing the vulnerable code itself. It usually sits at the network, gateway or application protection layer and is used to reduce exposure while a permanent software fix is tested and deployed.
• Exposure Window: The exposure window is the period between vulnerability discovery and effective protection. In practice, it is the time attackers have to weaponise a flaw before containment, remediation or compensating controls reduce reachability.
• Identity Blast Radius: Identity blast radius is the set of systems, data and services that become reachable if a credential, token or privileged service identity is abused. It helps practitioners assess how a software flaw turns into operational access risk.
• Compensating Control: A compensating control is a measure used to reduce risk when the primary control, such as a software fix, cannot be applied immediately. It does not eliminate the root cause, but it can limit exploitation and buy time for safer remediation.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Palo Alto Networks: IBM, Red Hat and Palo Alto Networks expand Project Lightwell to help organizations respond to software vulnerabilities. Read the original.