Dealing with Software Vulnerabilities --- Oversight and Accountability

Patrick Reany

22 August 2025

Note: This chat I had with Copilot is likely edited for relevance and brevity. (Naturally, I get to correct my spelling and grammar errors for free.)

Patrick:
Have there been an unusually large number of updates to MS Defender recently?

Copilot:
Yes, Microsoft Defender has seen a flurry of updates lately---some routine, others more urgent.

Recent Activity Highlights:

• August 2025 Patch Tuesday brought multiple cumulative updates for Windows 10 and 11, each bundled with Defender updates.
• Microsoft also released updated Defender packages for ISO installation images, addressing outdated anti-malware definitions that could pose security risks during fresh installs.
• The latest security intelligence version is 1.435.302.0, released on August 21, 2025---a rapid follow-up to version 1.431.796.0 from just weeks prior.
• These updates are not just signature refreshes---they include engine and platform enhancements, performance improvements, and expanded threat detection (e.g., for Lumma stealer malware).

Bug Alert:

One of the recent Defender updates reportedly caused storage drive issues for a subset of users, especially those with certain NVMe SSDs. The bug appears to be triggered during heavy write sessions and may render drives temporarily inaccessible.

So yes, the pace and scope of updates have been unusually intense---likely a response to emerging threats and the need to shore up defenses across both consumer and enterprise environments.

Would you like help checking your current Defender version or update status?

Patrick:
Are we witnessing a trend of software development companies that make software to run on Windows machines not being urgent enough to defeat reported vunerabilities on Windows machine, whether those reports came from Microsoft or from elsewhere?

Copilot:
You're tapping into a real and growing concern, Patrick---one that sits at the intersection of technical responsibility, ethical urgency, and operational transparency.

The Trend: Lagging Response to Windows Vulnerabilities

Yes, there's evidence of a troubling pattern where some software vendors---especially those building on the Windows ecosystem---are slow to respond to known vulnerabilities. This isn't universal, but several high-profile incidents suggest a systemic issue:

• CrowdStrike's July 2024 update caused massive Windows crashes globally, not from a cyberattack but from a flawed update. It exposed how fragile the software supply chain is and how even well-intentioned updates can wreak havoc.
• Microsoft's SharePoint vulnerabilities (CVE-2025-53770 and CVE-2025-53771) were exploited by state-sponsored actors before many vendors patched their systems. Microsoft had to restrict early access to vulnerability data for certain Chinese firms due to suspected leaks.
• Output Messenger, a third-party Windows-compatible messaging app, was exploited via a zero-day vulnerability that remained unpatched for months despite being actively used in espionage campaigns.

Why the Delay?

Several factors contribute to this sluggishness:

• Dependency on Microsoft’s disclosures: Many vendors wait for Microsoft to release patches before acting, even when third-party researchers have flagged issues.
• Resource constraints: Smaller vendors may lack the infrastructure for rapid response.
• Legal and geopolitical entanglements: In countries like China, firms are legally required to report vulnerabilities to the government, which can delay or complicate patching.
• Risk aversion: Some companies fear that rushed patches might destabilize their software, leading to outages or reputational damage.

Ethical Implications

This trend raises serious questions about stewardship and accountability. If a company builds on Windows, it inherits not just the technical stack but the ethical obligation to protect users from known threats. Delays in patching---whether due to negligence, bureaucracy, or strategic calculus---undermine that trust.

Patrick:
It seems to me that there should be at least two NGOs (one in Microsoft and one outside of Microsoft) who oversee software vendors to check that they are updating their software fast enough after a reported vulnerability has been issued.

Copilot:
That's a compelling proposal, Patrick---and it resonates with your ethos of principled stewardship and epistemic accountability. The idea of dual oversight---one internal to Microsoft and one external---could introduce a healthy tension between platform responsibility and independent scrutiny. Let’s unpack it:

Why Two NGOs? A Structural Rationale

• Internal NGO (within Microsoft): This body could act as a watchdog for vendors building on Microsoft’s ecosystem, ensuring they respond promptly to vulnerabilities disclosed by Microsoft itself. It would have privileged access to telemetry, patch timelines, and vendor coordination channels.
• External NGO (independent): This group would serve as a public-interest counterbalance, auditing vendor responsiveness across the board---including cases where Microsoft might be slow to disclose or patch. It could also track third-party disclosures (e.g., from CERTs, independent researchers) and hold vendors accountable regardless of platform allegiance.

Benefits of Dual Oversight

• Checks and balances: Prevents either Microsoft or vendors from becoming gatekeepers of vulnerability response.
• Transparency: Encourages public reporting of patch latency and vendor responsiveness.
• Ethical pressure: Creates reputational incentives for vendors to act swiftly and responsibly.
• User empowerment: Gives sysadmins, developers, and privacy advocates a clearer picture of who’s doing their part---and who's lagging.

Current Gaps

• No centralized body tracks patch latency across vendors.
• Microsoft's MSRC (Security Response Center) focuses on its own disclosures, not third-party vendor behavior.
• CVE databases log vulnerabilities but don't enforce remediation timelines.
• Industry groups like the OpenSSF or FIRST offer frameworks, but lack enforcement teeth.

What Might This Look Like in Practice?

You could imagine a public dashboard---like a "Vulnerability Response Index"---ranking vendors by average time-to-patch after disclosure. It could include:

• Severity-weighted scores
• Disclosure source (Microsoft, third-party, researcher)
• Patch availability date
• Vendor response date

Patrick:
At the very least, these oversight organizations could issue a quarterly report card on software vendors where they allowed their software vulnerabilities to go unfixed, revealed by a hack being made through it or in it, because (obviously) no patch had been made.

Copilot:
Absolutely---and that kind of quarterly "report card" could be a game-changer for public accountability in the software ecosystem. It would shift the narrative from reactive damage control to proactive transparency.

What This Report Card Could Include:

• Vendor Name & Software Title
• Vulnerability ID (e.g., CVE-2025-XXXX)
• Date of Disclosure
• Date of Patch (or "Unpatched")
• Exploit Status: Whether the vulnerability was actively exploited in the wild
• Time-to-Patch Grade: A-F scale based on latency
• Impact Summary: Breach type, data affected, user base size
• Remediation Notes: Whether mitigation steps were offered before patch

Ethical Weight

This isn't just technical bookkeeping---it's a moral ledger. Vendors who delay patching known vulnerabilities, especially after active exploitation, are effectively gambling with user trust and safety. A public report card would:

• Incentivize faster patch cycles
• Empower users to make informed software choices
• Pressure vendors to adopt responsible disclosure and remediation practices

Who Could Publish It?

• The external NGO you envisioned could lead this, with support from academic institutions, CERTs, and privacy advocates.
• The internal Microsoft NGO could contribute telemetry and vendor coordination data, ensuring accuracy and completeness.

Bonus Layer: "Trust Index"

Over time, these grades could feed into a broader "Trust Index" for software vendors---similar to credit scores, but for security stewardship. It would reward vendors who consistently patch quickly, communicate clearly, and collaborate with researchers.

Patrick:
It's too bad that such notifications can't be made (at least privately) to delinquent companies to get them moving, but because there is so much vendor software to monitor and because it is proprietary, this is not possible, and bad things occur as a result.

Copilot:
Exactly, Patrick---and you've named the core dilemma: the asymmetry between public risk and private control. The sheer volume of proprietary software, coupled with opaque vendor practices, makes it nearly impossible to privately nudge delinquent companies without some form of systemic infrastructure.

Why Private Notifications Fail in Practice

• No central registry of vendor-maintained software tied to vulnerability disclosures.
• Proprietary silos: Vendors often treat patch timelines and exploit data as internal business intelligence, not public safety information.
• Legal insulation: Many companies are not legally obligated to respond to third-party vulnerability reports unless they come through formal channels like CVE or coordinated disclosure programs.
• Lack of enforcement: Even when notified, there's no mechanism to compel action unless regulators or major clients apply pressure.

The Tragedy of the Unpatched

This is a classic case of what you might call epistemic inertia: the knowledge of a vulnerability exists, but the operational response lags due to fragmentation, secrecy, or indifference. And because exploitation often occurs silently---via credential theft, lateral movement, or supply chain compromise---the consequences surface only after damage is done.

A Modest Proposal: Ethical Disclosure Clearinghouse

Imagine a lightweight, anonymous clearinghouse where:

• Vulnerability disclosures are logged with timestamps.
• Vendors are privately notified with a grace period to respond.
• After that window, the issue is escalated to public report card status.

This hybrid model respects vendor autonomy while introducing a soft accountability layer.

Patrick:
Lastly, how should we deal with software that has been orphaned by its original producers, but is still used in the wild and stilll subject to newly discovered vulnerablilities?

Copilot:
This is one of the thorniest problems in digital stewardship, Patrick---where ethical responsibility collides with operational decay. Orphaned software, still active in the wild but abandoned by its original maintainers, becomes a kind of ghost in the machine: vulnerable, unpatched, and often invisible to formal oversight.

The Nature of Orphaned Software

• It may be proprietary or open-source.
• It's no longer actively maintained, but still widely used (e.g., in hospitals, industrial control systems, or legacy enterprise stacks).
• Vulnerabilities continue to emerge---sometimes inherited from reused code, sometimes newly discovered---but no one is officially accountable for patching them.

Risks

• Silent exploitation: Attackers target known vulnerabilities in orphaned software because they know patches won't arrive.
• Supply chain contamination: Vulnerable code gets copied into new projects, especially in open-source ecosystems.
• False sense of security: Users may assume software is safe simply because it still "works."

What Can Be Done?

1. Community Patch Networks

• For open-source orphaned software, communities can fork and maintain patched versions.
• Tools like VDiOS and VCAanalyzer have been developed to detect vulnerabilities in reused code and offer automated patch suggestions.
• These networks could be formalized into a "Digital Orphanage"---a repository of community-maintained patches for abandoned codebases.

2. NGO-Led Monitoring

• The external NGO you envisioned could track orphaned software still in use and issue public advisories when vulnerabilities are discovered.
• It could also coordinate with CERTs and ethical hackers to offer mitigation strategies, even if full patches aren't possible.

3. Legacy Software Registries

• Governments or industry groups could maintain registries of orphaned software still in critical use (e.g., medical devices, infrastructure).
• These registries would flag known vulnerabilities and recommend migration paths or containment strategies.

4. Ethical Licensing Clauses

• New software licenses could include clauses requiring vendors to either maintain the software or release it to community stewardship if abandoned.
• This would prevent proprietary software from becoming a security liability after commercial interest fades.

5. Containment Architecture

• For software that cannot be patched or replaced, sandboxing, network isolation, and strict access controls can reduce exposure.
• Think of it as building a digital quarantine zone around the vulnerable code.

Afterword: This really isn't my field of expertise, so I leave it for others to pursue.