147 - The Evidence Gap

We track a single failure pattern across patching, supply chain security, SOC triage, and ransomware recovery: confusing a status label with proof. Using SonicWall SMA 1000 exploitation, an async API NPM compromise with valid provenance, and Fairlife’s production disruption, we lay out what “closure evidence” actually looks like when consequences are real. 
• the evidence gap between having a control and trusting its result 
• SonicWall SMA 1000 vulnerabilities, exploited-in-the-wild context, and why patching is not a compromise verdict 
• what to preserve and review after updating an internet-facing remote access appliance 
• async API supply chain compromise mechanics using GitHub Actions to publish to NPM 
• why OIDC provenance and build attestations prove lineage, not intent 
• scoping guidance that separates lock file exposure from module execution evidence 
• Fairlife ransomware disruption as a reminder that restored systems are not the same as restored production 
• DHS HSIN false positive dismissals and why closure confidence must match asset consequence 
• risk-based vulnerability management notes for Siemens RuggedCom ROCS 2, Microsoft ADFS, and Cisco Room OS 
• a practical model for designing deliberate closure evidence across vuln management, CI pipelines, SOC cases, and resilience testing 

One thing to do this week is run a bounded false positive quality review. 

Transcript

The Evidence Gap Explained

SPEAKER_00 0:08

This week's through line is the evidence gap, not the gap between knowing about a vulnerability and applying a patch. Not the gap between detecting an alert and opening a case. The more dangerous gap is between a control being present and a defender having enough evidence to trust the result. A Sonic wall appliance can report the new firmware and still require compromise review. A package can carry valid provenance and still contain malware. An alert can be closed as a false positive and still represent an intruder. A continuity plan can exist on paper and still fail to keep production running. Those are different environments, but the operating mistake is the same. Treating a status label as proof.

SonicWall SMA 1000 Exploitation Reality

SPEAKER_00 0:48

The first major signal comes from SonicWall's SMA 1000 remote access platform. SonicWall disclosed two vulnerabilities affecting SMA 1000 series appliances. Government advisories say both have been exploited in the wild. CVE 2026-15409 is an unauthenticated server-side request forgery flaw in the workplace interface. CVE 2026-15410 is an authenticated code injection flaw requiring administrative access to the appliance management console. The affected products include SMA 6210, SMA 7210, and SMA 8200 V systems running specified, 12.4.3 and 12.5.0 hotfix releases. SonicWall's remediation is to move to 12.4.3-03453, 12.5.0-02835 or later. CISA added CVE 202615 409 to its exploited vulnerability catalog and set a July 17th deadline for covered federal agencies. The patch instruction is straightforward. The judgment call is what happens after the version changes. An internet-facing remote access appliance is not just another server. It can broker access into the environment, sit beside authentication workflows, and expose administrative functions that defenders normally treat as trusted infrastructure. When exploitation is confirmed, a clean patch result answers only one question. Is the known flaw still present? It does not answer whether the flaw was already used. That means the completion evidence should include more than a screenshot of the new build. Preserve the relevant logs, review administrative changes, look for unusual requests originating from the appliance, unexpected outbound connections, configuration changes, and account activity that does not match the normal operating pattern. Determine whether the appliance was reachable during the exploitation window and whether available telemetry is good enough to support a confident conclusion. If the telemetry is incomplete, document that uncertainty. No evidence found and evidence proves no compromise are not interchangeable statements.

Async API Supply Chain Compromise

SPEAKER_00 2:56

The second major signal is the async API package compromise. Attackers push malicious changes into async API repositories, and then use the project's own legitimate GitHub Actions workflows to publish compromised packages to NPM. Five malicious versions were identified Generator version 3.3.1, Generator Helpers version 1.1.1, Generator Components version 0.7.1, and Specs versions 6.11.2 and 6.11.2 Alpha 1. The packages carried valid OIDC provenance. That is not a failure of the attestation. The provenance accurately showed that the authorized workflow produced the package. The problem was farther upstream. An attacker-controlled commit reached a branch and event that the workflow trusted enough to publish. Step Security reported that the malicious code executed when an affected module was loaded, not during package installation. That distinction matters for scoping. A lock file hit identifies potential exposure, but defenders also need build histories, runner logs, and application execution evidence to learn whether the module was actually invoked. The malicious versions were removed from NPM, so a fresh install may be clean while an existing lock file or cached artifact remains dangerous. There is also an important disagreement in the public analysis. Step Security says the attacker did not need to steal an NPM token to publish. The legitimate workflow used the project's OIDC trusted publisher integration. Unit 42 describes credential harvesting behavior associated with the compromise. The correct defender response is not to force those statements into a single simplified story. Preserve the distinction. The publication path itself can be explained by compromised repository access and a trusted workflow, while any secret exposure depends on what executed in runners or downstream environments. The broader lesson is that provenance proves lineage, not intent. Security teams have spent years improving artifact signing and build attestations, and that work is valuable. But the trust boundary cannot begin at the final build step. Every branch, tag, workflow dispatch, service account, and event capable of producing a release belongs inside the release security model. A useful review question is simple. Could one compromise push credential cause the authorized workflow to publish without an independent approval? If the answer is yes, the workflow can faithfully sign an attacker's work.

Fairlife Ransomware Meets Real Operations

SPEAKER_00 5:20

The third major signal is Fairlife's ransomware disruption. In a form 8K filed on July 16th, the Coca-Cola company said Fairlife identified unauthorized third-party access to part of its systems, including production-related systems, in connection with a ransomware event. The company activated incident response and business continuity procedures, notified law enforcement, and temporarily suspended Fairlife production in the United States. Canadian production was not reported affected, and the company said product quality and safety were not impacted. The investigation was still underway. The company did not claim a final scope, impact, or materiality determination, and there is no reason to fill those gaps with speculation. What is already clear is the operational consequence. A cyber event interrupted physical production. This is where recovery metrics often become misleading. Infrastructure teams may report restored hosts, recovered databases, or available backups. Those are useful milestones. They are not the business outcome. Production can remain stopped because identity services are unavailable, scheduling data is untrusted, quality systems cannot be validated, plant support interfaces are isolated, or recovery teams cannot prove that restored systems are clean enough to reconnect. The business capability returns only when the necessary chain of services parates safely together. For defenders, the practical work is to map the digital dependencies that can halt physical output. Which identity system must be available? Which manufacturing, quality, logistics, or vendor connections are required? What is the minimum clean environment? Which functions have a manual or degraded procedure and has anyone tested that procedure under realistic constraints? A recovery plan that lists systems is not the same as a recovery plan that proves production can restart.

Rapid Signals Across Vulnerabilities

SPEAKER_00 7:05

Now to the rapid signals. The first is a detection quality warning from the Department of Homeland Security. NextGov and FCW reported that personnel twice dismissed suspicious activity in the Homeland Security Information Network as false positives before attackers installed backdoors and stole credential data. The reporting is based on an internal incident readout. DHS confirmed an incident involving a specific unclassified legacy information sharing environment, said classified networks were not affected, and said the system remained operational. Attribution and the full scope remain unknown. The lesson is not that analysts should never close an alert. A SOC that refuses to close anything becomes unusable. The lesson is that closure confidence should match system consequence. On an identity-bearing or sensitive information sharing system, a false positive disposition should carry evidence strong enough for another analyst to reproduce the conclusion. The second cluster is vulnerability management. Unit 42 published a detailed analysis of three Siemens RuggedCom ROCS 2 vulnerabilities CVE 2025, 40947, CVE 2025, 40948, and CVE 2025 40949. The chain can expose files or support root-level command execution after authentication. Siemens lists affected ROCS 2 models below version 2.17.1 and recommends upgrading to 2.17.1 or later. There is no reported active exploitation, so this belongs in planned, risk-based remediation rather than an invented emergency. But these devices can operate in utility substations and traffic control environments, where access and maintenance constraints make delayed upgrades expensive. Microsoft also patched CVE 202656-155, an Active Directory Federation Services privilege escalation flaw that CISA lists as actively exploited. The flaw requires an authorized local attacker. That prerequisite should shape the hunt. It is a post-compromise escalation path, not a complete explanation for initial access. Patch the ADFS hosts, then ask what foothold could have existed before escalation. Cisco's July Room OS hardening release group six internally discovered vulnerabilities. Cisco says all Room OS configurations are affected, no workaround exists, and it is not aware of malicious use. The advisory includes deployment-specific fixed releases. This is a good example of routine exposure management done correctly. Inventory the devices, compare each deployment to the exact fixed release table, schedule the upgrade, and avoid turning a non-exploited advisory into a crisis headline.

Controls Mistaken For Conclusions

SPEAKER_00 9:49

Put the week together and a pattern emerges. SonicWall, Async API, Fairlife, and the DHS HSIN reporting all show controls being mistaken for conclusions. The SME 1000 version number can prove the patch was applied. It cannot prove the appliance was never used by an attacker. Async API provenance can prove the authorized workflow published the artifact. It cannot prove the triggering commit was legitimate. A sock disposition can prove that an analyst closed an alert. It cannot prove that the activity was benign unless the supporting evidence survives review. A continuity document can prove that recovery steps were written. It cannot prove that production can operate when the supporting digital chain is unavailable or untrusted. The defensive shift is to design closure evidence deliberately. For a vulnerability, that may be the fixed version plus exposure history, log preservation, and compromise assessment. For a release pipeline, it may be protected branches, independent approval, immutable workflow definitions, and attestation tied to a reviewed commit. For a SOC case, it may be the query, raw telemetry, alternative hypotheses considered, and second review sign-off. For resilience, it may be a timed exercise that restores a business capability under clean room constraints.

A Practical False Positive Review

SPEAKER_00 11:04

One thing to do this week is run a bounded false positive quality review. Pull the last 30 days of high severity alerts closed as false positives when the involved asset was internet facing, identity bearing, part of CIRCD, or capable of interrupting production. Do not reopen every alert. Select the cases where a mistaken disposition would have the highest consequence. Assign a second reviewer who was not the original closer. Check web server child processes, altered or deleted logs, scheduled tasks and services, hidden backdoors, credential file access, runner secret use, remote access appliance administrative changes, and unusual outbound requests. Prioritize SMA 1000 appliances, ADFS servers, CI runners, and production connected systems where those technologies exist. The evidence of completion should be concrete. The exported alert set or saved query, second review notes, reopened or escalated cases, detection tuning changes, assigned owners and dates, and assigned ticket. The goal is not to punish analysts, it is to test the reliability of the closure process and improve the conditions under which the team is willing to say benign. False positives are unavoidable. Permanent unauditable conclusions are not. A mature security program does not eliminate uncertainty by changing a status field. It records why a conclusion was reasonable, what evidence would contradict it, and who will reopen the question when the environment changes. The written InfoSec watch issue NUT 147 includes the exact CVE IDs, affected and fixed versions, source links, and the full defense checklist.

The One Question To Ask

SPEAKER_00 12:42

The week's final question is simple. What artifact proves your control worked, and what evidence would force you to stop trusting it?