Project Lightwell narrows vulnerability-to-protection gaps across software

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Palo Alto Networks's announcement: Palo Alto Networks-led collaboration with IBM and Red Hat links vulnerability discovery to immediate network-level protection and downstream software remediation across multiple environment types.

Why it matters: It matters because security and identity teams have to govern the interval between discovery and protection as a live risk window, especially when remediation cannot keep pace with AI-assisted discovery.

Context

Vulnerability discovery is now moving faster than many defenders can validate, deploy, and operationalise protections. In practice, that creates a governance gap between the moment a flaw becomes known and the moment exposed systems are actually protected.

For IAM and NHI programmes, the issue is not only patching cadence. The broader problem is how quickly organisations can narrow exposure windows across software, infrastructure, and any identity path that depends on those systems for access control or trust.

Project Lightwell is being positioned as a shield-and-fix workflow, but the operational question for practitioners is whether protection can be made available before remediation is fully ready. That is the pressure point this collaboration is trying to address.

Key questions

Q: How should teams reduce the gap between vulnerability discovery and protection?

A: Teams should treat the gap as a response-control problem, not just a patching problem. The practical fix is to combine rapid containment controls, such as virtual patching or traffic blocking, with a validated remediation path so exposed systems are protected before the permanent fix is live.

Q: Why do AI-driven vulnerability findings create more operational risk for large programmes?

A: They increase risk because large programmes already have longer approval paths, more dependencies, and more systems that must change together. When discovery spikes, those dependencies turn into delay. Even strong detection does not help if ownership, testing, and deployment cannot keep pace with incoming issues, so the programme absorbs exposure faster than it removes it.

Q: What breaks when organisations rely on patching without identity containment?

A: Patch programs reduce exploit opportunities, but they do not stop a threat actor who already has valid access. If credentials are compromised, the attacker can still move laterally, query systems, and abuse over-permissioned accounts. Containment is what limits the damage after the first foothold, so patching alone leaves a critical gap.

Q: How should security teams use virtual patching without delaying real remediation?

A: Use virtual patching as a compensating control, not as the final fix. The goal is to block exploit traffic quickly while engineering completes code remediation, testing, and release. Track each rule as a temporary control with explicit ownership, review dates, and a linked remediation ticket so containment does not become permanent drift.

How it works in practice

Why vulnerability discovery now outpaces remediation

AI-driven discovery changes the shape of vulnerability operations by compressing the time between flaw identification and adversary awareness. When exposure can be identified at scale in codebases, commercial products, and operational environments, traditional patch queues become a lagging control. The security question shifts from whether a patch exists to whether a protection path can be deployed before exploitation begins. That is why virtual patching is relevant: it attempts to reduce exposure at the network layer while software teams validate a fix. The result is a split workflow, where protection and remediation no longer have to wait on each other.

Practical implication: Treat discovery-to-protection time as a control metric, not just patch completion time.

How virtual patching and software remediation work together

Virtual patching blocks known exploit attempts before an official code fix is available, usually by enforcing network-layer protections around vulnerable traffic patterns. Software remediation addresses the underlying defect in the application, package, or platform after testing and deployment validation. Used together, they create a temporary containment layer and a permanent correction layer. That distinction matters for identity-heavy environments because many access and trust services depend on software components that cannot be interrupted casually. The architecture is therefore about sequencing, not substitution: network protection can buy time, but only validated remediation closes the exposure path.

Practical implication: Use network protections as an interim containment control, not as a reason to defer fix validation.

Why broad coverage changes governance across software estates

The article’s scope matters because it spans open source software, commercial applications, OT, and healthcare technologies. Those environments have very different operational tolerances, yet they all face the same governance issue: inconsistent vulnerability handling creates uneven protection windows. In hybrid estates, some assets can be patched quickly while others require extended validation, compensating controls, or change coordination. That makes exposure management a cross-domain discipline rather than a single team activity. The practical challenge is aligning security operations, application owners, and platform teams around one response model that can act before remediation is complete.

Practical implication: Define a single vulnerability-to-protection workflow that works across software, OT, and regulated environments.

NHI Mgmt Group analysis

Exposure-window management is now the primary governance problem in vulnerability response. The article shows that discovery speed is no longer the only issue, because protection can lag even when the flaw is known. That changes the control objective from patch completion to time-bounded exposure reduction. Practitioners should treat the interval between validated discovery and enforceable protection as a measurable governance gap.

Shield-and-fix workflows are becoming the new operating model for complex estates. Network-level protection and software remediation serve different control purposes, and the article makes clear that neither is sufficient alone. This is especially relevant where change windows are slow or validation is mandatory, because compensating protection must carry the risk until remediation is safe. The implication is that vulnerability governance now spans both operational containment and long-term correction.

Identity and access teams cannot separate software exposure from trust exposure. When core platforms or applications are vulnerable, the systems that issue, validate, or broker access inherit that exposure. That is why vulnerability governance increasingly overlaps with IAM, PAM, and NHI programme ownership in practice. The field needs to recognise that access assurance depends on the resilience of the software estate beneath it.

AI accelerates the asymmetry between discovery and defence. The article’s central message is not just that attackers move faster, but that defenders need a different response architecture when discovery is machine-accelerated. Traditional patch queues assume a slower threat cycle than the one now in play. Practitioners should plan for continuous protective controls that can operate before remediation is finalised.

Validated discovery must now be paired with immediate enforceable control. The named concept here is the vulnerability-to-protection gap, and it is the gap that matters operationally. If organisations can discover a flaw but cannot protect against it quickly, the security outcome is still failure. The practitioner conclusion is that governance must reward time-to-protection, not only time-to-fix.

From our research library:

• The average time to mitigate a leaked secret is 36 hours, highlighting the operational burden of manual remediation processes, according to the 2024 State of Secrets Management Survey.
• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to the State of Secrets in AppSec.

What this signals

Vulnerability-to-protection timing is becoming a control metric. Security leaders should stop measuring only how fast patches are applied and start measuring how quickly exposed systems become protected after a flaw is validated. That shift matters because AI-assisted discovery narrows the safe window faster than traditional remediation cycles can respond.

The governance model has to separate temporary protection from permanent repair. Organisations that treat virtual patching as a substitute for remediation will accumulate hidden exposure debt. The better model is to use compensating controls to buy time, then validate and deploy fixes on a separate track.

Exposure windows now cut across identity, software, and platform teams. If access services, applications, or operating environments remain vulnerable, the blast radius extends beyond the software owner. Practitioners should expect vulnerability management to sit closer to IAM, PAM, and NHI governance than many current operating models assume.

For practitioners

• Measure vulnerability-to-protection time Track the elapsed time from validated discovery to the first enforceable protection across critical software, not just the time to final patch approval.
• Separate containment from remediation Assign network-level blocking, validation, and code repair to distinct owners so interim protections can be deployed while fixes are tested.
• Map slow-change assets first Prioritise OT, healthcare, and other regulated environments where patch latency is structurally higher and compensating controls matter most.
• Define protection thresholds for exposed software Set escalation criteria for when a flaw must trigger immediate virtual patching, even if the permanent remediation path is still in progress.

Key takeaways

• The article frames vulnerability response as a race to close the interval between discovery and enforceable protection, not just to finish patching.
• Its core evidence is that AI is accelerating flaw discovery faster than many organisations can safely remediate exposed systems.
• The practical implication is to pair network-level containment with validated remediation so exposure windows shrink before exploitation arrives.

Key terms

• Vulnerability-to-Protection Gap: The time between when a vulnerability is validated and when a system is actually protected from exploitation. In practice, this is the risk window that matters most when remediation is delayed, validation is slow, or compensating controls must carry the exposure.
• 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.
• Shield-and-Fix Workflow: An operating model that pairs immediate protective controls with later software remediation. The shield limits active exploitation risk now, while the fix addresses the underlying defect after validation and deployment approval.
• Exposure Window: The period in which a credential, session, or privilege grant can be exploited before it is revoked or expires. Shorter windows help, but they do not solve the deeper question of whether the access remains justified for the full time it is active.

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 building or maturing an IAM programme, it is worth exploring.