DEV Community: Eldor Zufarov

The Death of "Code Freeze": Why Autonomous Agents Require Continuous Deterministic Security

Eldor Zufarov — Fri, 19 Jun 2026 12:00:00 +0000

When your pipeline executes at machine speed, a scheduled security event is already too late

For decades, the Code Freeze was the engineering organization's most reliable security boundary.

The logic was simple and the execution was deterministic: before a major release, a compliance audit, or a holiday weekend, all non-essential mutations to the codebase were blocked. Humans stepped away from the main branch. Production configurations were locked. The infrastructure stabilized into a known, auditable state.

It worked because the threat model matched the operational model. Humans made changes. Humans could be told to stop making changes. The freeze held because the only things capable of making state mutations were also capable of receiving and following a policy.

That threat model no longer describes the environment most organizations are running.

The Pipeline Does Not Wait

On March 14, 2025, a threat actor compromised the tj-actions/changed-files GitHub Action — a dependency used in over 23,000 repositories across the GitHub ecosystem. The attacker did not send a phishing email. He did not wait for a developer to make a mistake during business hours. He modified existing version tags in the tj-actions/changed-files repository to reference a malicious commit containing code designed to execute one specific function: dump CI/CD secrets from workflow logs.

From that moment, no human action was required. Every time an affected organization's pipeline triggered — on a commit, on a pull request, on a scheduled run — the malicious code executed automatically, silently, within the trusted CI/CD environment. It harvested API keys, GitHub Personal Access Tokens, npm tokens, and private RSA keys, writing them into workflow logs where they could be retrieved.

CISA added CVE-2025-30066 to its Known Exploited Vulnerabilities catalog on March 18, 2025 — four days after the compromise began. In those four days, 23,000+ repositories had executed the malicious payload autonomously, without any human at a keyboard making a decision that a security policy could have intercepted.

The attack was not sophisticated. It was structurally inevitable given the architecture: a trusted dependency, a mutable tag, an autonomous pipeline, and no gate between the dependency change and production execution.

This is what it looks like when the threat operates at pipeline speed and security operates at human speed.

From Automated Pipelines to Agentic Autonomy

The tj-actions incident occurred in an environment where automation was still relatively constrained — fixed scripts, predictable triggers, human-readable logs. The next version of this problem is already in production.

According to Gartner, by 2026 more than 80% of enterprises will have deployed some form of autonomous AI agents in production environments. These agents are not generating autocomplete suggestions. According to the AIUC-1 Consortium briefing published in early 2026 with input from CISOs at Confluent, Elastic, UiPath, and Deutsche Börse, enterprise AI deployments have shifted from pilot programs to production systems handling customer data, executing business transactions, and integrating directly with core infrastructure.

In DevOps specifically, agents are now triaging incidents, opening pull requests for routine fixes, scaling infrastructure, and in mature deployments, approving and executing low-risk deployments autonomously. Deloitte's Tech Trends data shows more than 25% of enterprises that piloted generative AI in 2025 graduated those pilots to production — with DevOps as one of the earliest beneficiaries because the work is well-instrumented and outcomes are measurable.

An agent tasked with reducing cloud compute latency does not check the change management calendar. An agent executing dependency drift remediation does not consult the code freeze policy. It operates within its objective function, at the speed of an API call, on production state.

The Code Freeze was a policy written for humans. It has no mechanism to reach an agent.

Why GRC and Legacy Auditing Fail at Machine Speed

Most compliance programs are built on two assumptions that autonomous agents invalidate simultaneously.

The first is that meaningful state changes are made by humans who can be governed by policy. SOC 2 change management controls, EU Cyber Resilience Act requirements, ISO 27001 Annex A change management procedures — all of these are designed around human actors who can receive policy, understand it, and be held accountable for violating it. An agent executing within its mandate has no accountability surface that these frameworks address.

The second assumption is that audit evidence is collected after the fact and remains meaningful. Traditional compliance looks backward: signed PDF reports, Git history snapshots, system logs queued for quarterly review.

CISA's 2024 guidance on agentic AI systems stated explicitly that autonomous AI systems operating with persistent access to enterprise resources represent a new and expanding attack surface that existing endpoint and perimeter defenses were not designed to address. The specific challenge is ephemerality: an agent can spin up infrastructure, execute a task that introduces a vulnerable state, and tear down that infrastructure before a traditional compliance scan has triggered. The state change disappears. The log records that something happened. It does not record what was reachable during the window when the vulnerable state existed.

The Verizon 2025 DBIR documented a sharp rise in attacks targeting automated systems and API-connected workflows — the exact infrastructure that agentic deployments depend on. The attack surface expanded. The audit framework did not.

Standard telemetry also creates a specific blind spot at machine speed. Logs record what happened: Service B executed API Call X. They do not record why it happened in the context of the broader execution graph, or how that action connected to a vulnerability chain that was open for 340 milliseconds before the agent's next action closed it. The telemetry is accurate. It is also incomplete in exactly the way an attacker needs it to be incomplete.

The Architecture the Threat Model Requires

Closing the gap between machine-speed execution and meaningful security requires replacing the time-based model of the Code Freeze with a mathematics-based model applied continuously at the moment of mutation.

The organizing principle is straightforward: every state mutation — whether proposed by a human developer, a CI/CD pipeline, or an autonomous agent — must pass through a deterministic evaluation before it is applied to production state. Not after. Not on a quarterly schedule. Before, at the speed of the proposing system.

This requires two layers operating in sequence.

Layer 1: Deterministic Reachability Analysis

Before a mutation is applied, a graph engine evaluates its structural consequences against the current state of the system. The evaluation asks one question: does this change create a reachable path to a sensitive operation, a data store, or a trust boundary that the mutation's proposer is not authorized to reach?

Because this evaluation is deterministic — it does not require probabilistic AI reasoning, only graph traversal against a defined policy model — it can execute in sub-50ms, matching the speed of automated pipelines without introducing operational drag. A change that passes this gate is allowed to proceed. A change that fails is blocked with a cryptographic record of the rejection and the specific reachability condition that caused it.

This is what the tj-actions attack required to be stopped at the architectural level: not a faster human reviewer, not a better log aggregator, but a gate that evaluated whether a modified dependency tag was allowed to reach production credential storage before the pipeline executed the first affected workflow run.

Layer 2: Immutable Audit State

When a mutation passes the reachability gate and is applied, the system generates a tamper-evident record of that specific transition. Not a flat log file that can be modified retroactively by a compromised agent. An append-only structured log where each entry contains the cryptographic hash of the previous state, creating a chain where any retroactive alteration breaks the validation sequence.

This matters for the specific failure mode that the tj-actions compromise and the broader agentic threat both create: a compromised system component that attempts to cover its execution footprint by altering its own audit trail. Hash-chained telemetry makes this structurally impossible. The log does not just record what happened. It proves that what it records was not altered after the fact.

The compliance artifact is no longer a quarterly report generated from potentially-stale evidence. The running infrastructure is the cryptographic audit proof, generated continuously, tamper-evident by construction.

The Structural Observation

The tj-actions incident makes one thing clear that was previously abstract: the threat does not respect the Code Freeze schedule. It does not wait for a developer to commit during business hours. It executes when the pipeline executes — which is whenever the pipeline decides to execute, which is not a decision any human in the organization made in the 340 milliseconds the malicious payload ran.

OWASP's 2025 LLM Top 10 ranked prompt injection at the top of the list for AI systems — reflecting the same structural problem at the AI agent layer. An agent that ingests untrusted content is an attack surface. An agent with write access to production state and no deterministic gate between its intent and its execution is not a productivity tool. It is a potential attack vector waiting for the right injected instruction.

The Code Freeze was an attempt to solve the state mutation problem with time — by creating periods when nothing could change. The graph gate solves it with math — by evaluating every proposed change against the current system state before it is applied.

One of those approaches scales to machine speed. The other does not.

Organizations that understand this distinction will build security gates into the execution fabric of their systems, continuously, at the speed of whatever is proposing changes. Organizations that do not will continue writing Code Freeze policies that autonomous agents are constitutionally incapable of reading — and will continue discovering, in post-incident reviews, that something changed at 2:47 AM on a Saturday and nobody was there to stop it because the policy assumed somebody had to be.

Stop attempting to freeze your code.

Build a system that is secure by design, under continuous deterministic audit, every millisecond of the day.

Why Security Should Be Modeled as a Graph

Eldor Zufarov — Wed, 17 Jun 2026 12:00:00 +0000

The difference between what scanners count and what attackers traverse

A security scanner reports four findings.

An exposed credential. An SSRF vulnerability. A weak IAM policy. An internal service with no egress filtering.

Four findings. Four tickets. Four remediation tasks assigned to four different engineers across two sprints.

Now look at the same environment through the attacker's eye.

He does not see four findings. He sees one path.

Credential → Cloud Access → SSRF → Metadata Service → IAM Token → Internal Service → Exfiltration.

One objective. One chain. One compromise.

The scanner and the attacker are analyzing the same environment. They are arriving at fundamentally different conclusions about what it means.

That gap — between the list the scanner produces and the path the attacker traverses — is where most security programs lose the battle before it starts.

The Problem Is the Model

In March and April 2025, Wiz researchers documented active exploitation of CVE-2025-51591, an SSRF vulnerability in Pandoc, the widely used document conversion tool. The attack was not complicated. An attacker submitted HTML documents containing iframe elements whose source attributes pointed at the AWS EC2 Instance Metadata Service endpoint at 169.254.169.254. Because Pandoc rendered iframes server-side, the request originated from within the server — bypassing perimeter controls, reaching the internal metadata endpoint, and returning temporary IAM credentials.

Viewed as individual observations, three separate things were present in the affected environments: a document processing function that rendered untrusted HTML, an accessible IMDSv1 endpoint, and IAM roles with excessive scope attached to the EC2 instances. Each was a manageable finding in isolation. A CVSS score, a ticket, a remediation task.

Viewed as a graph, they were a single reachable path: SSRF via Pandoc → IMDS at 169.254.169.254 → IAM credentials → whatever those credentials could reach in the cloud environment.

Mandiant confirmed in-the-wild exploitation attempts running across multiple weeks. The attack did not require a novel technique. It required connecting three nodes that no single tool had been asked to evaluate together.

That is the model problem in concrete form.

The List Problem

Modern cybersecurity is organized around lists.

Vulnerability lists. Alert lists. Asset inventories. Compliance checklists. Risk registers. Severity-sorted findings queues.

The underlying assumption is intuitive: if we understand every component individually, we understand the system.

For inventory management, that assumption works. For security, it fails structurally — because security is not determined by the existence of components. It is determined by the relationships between them.

A credential is rarely dangerous in isolation. An API endpoint is rarely dangerous in isolation. A database is rarely dangerous in isolation. Risk emerges when relationships connect those components into a sequence an attacker can traverse.

Lists describe what exists. They are poor at describing what is connected. And connectivity — not the presence of individual findings — is what determines whether an attacker reaches his objective.

The Pandoc case illustrates this precisely. Organizations running IMDSv1 had a known configuration risk. Organizations using Pandoc to process user-supplied documents had a known attack surface. In most environments, neither condition had been escalated to critical priority in isolation. The combination was the vulnerability. The combination was invisible to any tool evaluating the conditions separately.

Systems Are Defined by Relationships

Every complex system is ultimately a network of dependencies.

Applications depend on identities. Identities depend on permissions. Permissions depend on trust relationships. Services depend on data flows. Assets depend on access controls.

The security posture of an environment emerges from these interactions — not from individual components examined one at a time.

This is why two environments with the same vulnerability count can have radically different risk profiles. The vulnerabilities may be identical. The relationships are not. An exposed credential in an environment with strict network segmentation and minimal IAM scope presents a different risk than the same credential in an environment where that identity has read access to every S3 bucket in the account.

The number of findings says nothing about this. The graph does.

SonicWall's 2025 Cyber Threat Report documented a 452% increase in SSRF attacks from 2023 to 2024, driven in part by automated tooling that maps internal network reachability at scale. The attackers are not manually probing individual endpoints. They are running graph traversal algorithms against target environments — mapping what is reachable from each foothold before deciding which path to take. The defenders, in most organizations, are still counting findings.

Attackers Already Think in Graphs

Attackers rarely ask: how many vulnerabilities exist?

They ask: what can I reach from here?

Every intrusion follows a version of the same process. Initial access creates new reachability. New reachability reveals new permissions. New permissions extend the graph. Eventually a path emerges between the attacker's starting position and a target worth reaching.

The F5 Labs analysis of a coordinated SSRF campaign running between March 13 and March 25, 2025 documented this methodology in operational detail. The attackers rotated six different query parameter names — dest, file, redirect, target, URI, URL — probing for SSRF conditions across EC2-hosted applications. They targeted four specific IMDS subpaths. They operated from IPs across two countries, maintaining operational tempo across twelve days. They were not evaluating individual findings. They were mapping reachability systematically across a target population, looking for environments where the path from the external SSRF entry point to the internal credential store was open and traversable end to end.

The attack succeeds because a path exists. Not because a finding exists.

Why Severity Misleads

This also explains why vulnerability severity frequently fails to represent actual risk.

Consider a critical-severity vulnerability affecting an isolated service with no meaningful connectivity to sensitive assets. The finding is severe. The reachable impact is bounded.

Now consider a medium-severity input validation weakness in a service that accepts user-supplied URLs and forwards them server-side. The finding appears less severe. If the server has access to the cloud metadata endpoint and carries an over-permissioned IAM role, the resulting path may reach every data store in the environment.

This is not a failure of severity scoring. Severity and risk are measuring different things.

Severity describes properties of a node — the technical characteristics of a vulnerability in isolation. Risk emerges from the graph — from the relationships between that node and everything reachable from it given the actual configuration of the environment.

When organizations treat severity as a proxy for risk, prioritization reflects scanner output rather than attacker reality. Teams spend cycles on alarming-looking findings while the paths that actually lead somewhere go unexamined.

Reachability Is the Missing Metric

The most important security question is also the least frequently asked in most remediation workflows:

What becomes reachable if this weakness is exploited?

Not: what is the CVSS score? Not: how many findings are open? Not: is this a critical or a high?

But: from this node, what can an attacker reach next? And from there? And where does the chain end?

Reachability transforms isolated observations into meaningful risk assessment. An exposed credential matters because it reaches another system. A permission matters because it enables another action. A vulnerability matters because it opens another step in a traversal.

Without reachability, findings remain disconnected facts. With reachability, they become paths — and paths are what attackers use.

The Pandoc exploitation did not require a CVSS 10.0. It required SSRF reaching a metadata service that had not been locked down, returning credentials that had not been scoped to least privilege, in an environment where nobody had asked what the combination of those three conditions made possible.

What List-Based Security Gets Wrong

Lists encourage local optimization.

Organizations reduce vulnerability counts. Close tickets. Improve compliance scores. Increase scanner coverage. Generate cleaner dashboards. These activities have value. They do not necessarily reduce systemic risk.

An organization may eliminate hundreds of findings while leaving its most dangerous attack path completely intact — because the path is not a finding. It is a relationship between findings that no individual tool was asked to evaluate.

From the perspective of management metrics, security improved. From the perspective of an attacker running graph traversal against the environment, nothing changed.

This is why breaches often appear surprising in retrospect. The warning signs were present. They existed as disconnected observations in separate queues, rather than as a connected path visible to anyone responsible for the whole.

What Graph-Based Security Changes

Graph-based security begins with a different question.

Instead of: which findings are most severe? It asks: which paths lead to compromise?

Instead of focusing on individual weaknesses, it focuses on relationships, reachability, trust boundaries, permissions, identities, and dependencies. The goal is not to discover problems in isolation. It is to understand how problems interact — and specifically, whether their interaction creates a traversable path to something an attacker would value.

This shift changes prioritization fundamentally.

A low-severity finding that connects two high-value systems through a shared credential or a trust relationship may become the highest-priority issue in the environment. A critical finding in an isolated service with no meaningful connectivity may be deprioritized without consequence.

For the first time, remediation effort can be directed at what matters to an attacker rather than what looks worst on a scanner dashboard.

Starting the Shift

The mental model comes before the tooling. Tooling that implements attack path analysis exists and is increasingly mature. But the tooling is only useful if the team operating it has internalized why finding-centric prioritization fails — and what it is being replaced with.

A practical starting point: take the last three findings your team classified as low or medium severity. Do not put them in a spreadsheet. Put them on a whiteboard. Draw them as nodes.

Then draw edges between anything that shares a credential, a trust relationship, a permission boundary, a service dependency, or a data flow.

Look for a path.

Not a finding. A path.

If one appears — if the chain from the first node reaches something sensitive through the second and third — you have just discovered the central insight of graph-based security in your own environment. You have also discovered why the findings were deprioritized: evaluated individually, none of them warranted escalation. Evaluated as a graph, they form an exploitable chain that the scanner never surfaced.

Vulnerabilities do not compromise systems.

Paths do.

Your SOC 2 Report Is a Reconnaissance Document

Eldor Zufarov — Mon, 15 Jun 2026 12:00:00 +0000

How compliance attestation tells the attacker exactly where to look

The report arrived as a PDF attachment.

Forty-seven pages. Auditor letterhead. The Trust Services Criteria laid out in clean columns: Security, Availability, Processing Integrity, Confidentiality, Privacy. Control descriptions on the left. Auditor observations on the right. Every control marked as operating effectively during the coverage period.

The vendor's procurement team sent it over as part of the standard third-party risk review. The security team filed it as evidence of due diligence. The deal closed.

The attacker did not need to be in that email thread. The SOC 2 report was already public — available on the vendor's trust page, downloadable without authentication, shared proactively as a sales asset.

He had already read it.

What a SOC 2 Report Actually Describes

A SOC 2 Type II report attests that a set of controls were designed appropriately and operated effectively during a specific coverage period — typically six to twelve months ending several months before the report's issue date.

Read that sentence again with the attacker's eye.

A set of controls — not all controls. The controls selected for audit are defined by the organization being audited. Controls that were not included in scope were not evaluated. The report says nothing about them, which means the report says nothing about whether they exist, whether they work, or whether they represent a gap.

Operated effectively during a specific coverage period — past tense, bounded. The coverage period ended. The audit concluded. The report was issued. Time passed. The environment changed. New services were deployed. Configuration drifted. Personnel left and were replaced. The report attests to a snapshot. It makes no claim about the present.

Several months before the report's issue date — the gap between coverage period end and report publication is typically three to six months. The gap between publication and the report being shared in a vendor review is often another three to six months. The controls that the report attests to may be a year old by the time a prospective customer reads them.

This is not a defect in the SOC 2 framework. It is a structural property of point-in-time attestation applied to continuously changing systems. The framework was designed to provide assurance. The attacker uses it to identify boundaries.

The Map Inside the Document

A SOC 2 report does not just confirm that controls exist. It describes them. In detail.

The controls section of a typical SOC 2 report will tell a reader which identity provider is in use, how access reviews are conducted and at what frequency, what logging and monitoring tools are deployed, how encryption is implemented for data at rest and in transit, what the incident response process looks like, how change management is structured, and which third-party services are integrated into the production environment.

This is the information a security team needs to evaluate a vendor. It is also, precisely, the information an attacker needs to plan an engagement.

Consider what a SOC 2 report answers for an attacker that would otherwise require significant reconnaissance:

Which identity provider do they use? The report names it. The attacker now knows which platform's vulnerabilities and misconfigurations to research for this specific target.

Do they enforce MFA? The report describes the control. If the control states "MFA is required for access to production systems via the company's SSO provider," the attacker reads the boundary: SSO-enforced MFA. He then asks what is not behind SSO — legacy systems, service accounts, API keys, free-tier access paths, contractor accounts.

What does their logging cover? The control description will state which systems generate logs and what alerting is configured. The attacker reads what is not listed. Unmonitored systems are not described as unmonitored — they are simply absent.

How are third-party integrations managed? The vendor management control names the tools and platforms in production. Each named system is a node in the trust graph the attacker will attempt to traverse.

The SOC 2 report is not a vulnerability database. It is more useful than that. It is an architectural map of the security controls an organization decided to have audited — annotated with the specific tools, processes, and scope boundaries that those controls cover. The gap between "what the controls cover" and "the full attack surface" is not documented anywhere.

That gap is where the attacker operates.

The Scope Boundary Is the Target

In May 2026, Instructure — the company behind Canvas LMS, used by 41% of higher education institutions in the United States — confirmed a breach affecting approximately 275 million students, teachers, and staff across 8,809 institutions worldwide. ShinyHunters claimed 3.65 terabytes of data including names, email addresses, student ID numbers, and private messages.

At the time of the breach, Instructure held ISO 27001 certification and SOC 2 attestation. On paper, an impressive compliance posture — exactly the kind that passes vendor risk assessments without friction.

The entry point was the Free-For-Teacher account program — a free-tier access path that shared infrastructure with paid institutional tenants. The program was not behind the same access controls as production institutional systems. It did not need to be, by the logic of the audit: free accounts are not part of the enterprise service. They are adjacent to it.

A security author covering the incident noted the structural problem precisely: none of the compliance frameworks required Instructure to disclose that the unverified free tier shared infrastructure with paid institutional tenants. The SOC 2 report described the institutional platform controls accurately. The free-tier access path was outside the scope boundary. The attacker found the boundary, stood on the other side of it, and walked into production from there.

ShinyHunters also disclosed something that received less attention than the breach itself: this was not their first access to Instructure's systems. A previous intrusion had been detected, patched, and closed without a thorough root cause investigation. The compliance controls had not flagged the first access. The compliance controls had not required the organization to determine how the first access had occurred. The attacker knew this, because he had been there.

Applying a patch to a known symptom without investigating the underlying access mechanism is a structural failure that no SOC 2 control is designed to catch — because SOC 2 does not audit the quality of incident response reasoning. It audits whether an incident response process exists and was followed.

When the Attestation Is the Attack Surface

The Delve AI case, which surfaced in late 2025 and continued generating fallout through early 2026, introduced a different dimension of the same problem.

A whistleblower writing as DeepDelver published an analysis alleging that Delve's AI platform was answering vendor security questionnaires on behalf of clients — attesting to controls, MDM systems, penetration tests, and backup restoration simulations that the platform had never verified existed. Textual analysis of reports associated with Delve clients found nearly identical boilerplate across hundreds of SOC 2 documents, including repeated grammatical errors and identical auditor conclusions across reports that should have reflected independent evaluations.

Clients were making affirmative security representations to their enterprise customers based on AI-generated questionnaire responses. The compliance artifact was technically produced. It did not describe reality.

This is an extreme case. But it illustrates the terminal point of a spectrum that begins with standard SOC 2 practice: the artifact attests to what was measured. What was measured was selected in advance. What was not selected was not measured and is not in the document — and is therefore also not in the risk assessment of anyone who relied on the document.

The difference between Delve and a standard SOC 2 engagement is a matter of degree. In both cases, the person relying on the attestation is trusting a description of a subset of controls, prepared by or for the organization being evaluated, bounded by decisions made before the evaluation began.

What the Report Cannot Tell You — and What That Reveals

The controls listed in a SOC 2 report are not a complete inventory of what a vendor's security program covers. They are the controls that were included in the audit scope. The decision about what to include in scope is made by the organization being audited, in consultation with the auditor, before the audit begins.

This means a SOC 2 report is defined, structurally, by what the organization was confident enough to put under audit.

What is absent from the scope is not described as absent. It is simply not present. A reader who does not know what to look for will see a well-organized set of controls and conclude that the organization has mature security practices. A reader who knows what a complete security program looks like will notice which controls are missing, which scope boundaries are drawn narrowly, and which statements are carefully worded to cover the specific evidence available rather than the broader capability.

The attacker is the second type of reader.

Every scope boundary in a SOC 2 report is a statement about what the organization chose to audit. It is also, implicitly, a statement about what the organization chose not to audit. The attacker reads both statements. The procurement team typically reads only the first.

The Procurement Paradox

The SOC 2 framework exists, in large part, to enable efficient vendor risk assessment. Rather than each enterprise customer conducting its own audit of every vendor, the SOC 2 report provides a standardized attestation that can be shared across customers, reducing duplicated evaluation effort.

This creates a structural paradox.

The value of the SOC 2 report as a procurement tool depends on its being widely shared. Vendors are therefore incentivized to make their SOC 2 reports easily accessible — posted on trust pages, sent proactively in sales processes, downloadable without friction. Wide distribution is the mechanism that makes the framework work.

Wide distribution is also what makes the report available to anyone who wants to use it as reconnaissance.

The attacker does not need to social-engineer his way to the SOC 2 report. He downloads it from the vendor's website, reads it as carefully as any enterprise security team would, and identifies the same information any enterprise security team would identify — the controls in scope, the tools named, the boundaries described.

Then he focuses on what is outside those boundaries.

This is not a hypothetical attack pattern. It is a description of how the Canvas breach unfolded: a well-documented compliance posture, a scope boundary that did not cover the free-tier access program, and an attacker who found the gap between the compliance description and the actual architecture.

How Attackers Read What Defenders File

The SOC 2 report is not the only compliance document with this property. It is the most widely shared instance of a general pattern.

Every compliance framework produces artifacts — reports, certifications, audit letters, self-assessments — that describe an organization's security controls in standardized language. The standardization is what makes the artifacts useful for their intended purpose: comparison, evaluation, regulatory demonstration.

The standardization is also what makes the artifacts useful for the attacker. A reader who has internalized a framework's control structure can read a compliance artifact and immediately understand which controls are included, how they are implemented, and where the scope ends.

SEC Form 8-K filings, which public companies are required to submit following material cybersecurity incidents, describe the breach, the affected systems, the detection timeline, and the initial response. They are public documents. An attacker who reads them systematically across an industry learns which response procedures companies actually execute, how long detection takes, which systems were not covered by existing monitoring, and what the organization's incident response process revealed about its security architecture.

The Coinbase Form 8-K filed in May 2025, describing the insider threat mechanism that cost the company between $180 million and $400 million, was read by every attacker researching the financial services sector. Coinbase had no choice but to file it. The disclosure requirement exists to protect investors. It also extends the attacker's reconnaissance capability into the internal architecture of every public company that has had a material incident.

Compliance is not the problem. The problem is treating compliance artifacts as evidence of security rather than as what they actually are: structured descriptions of a subset of controls, accurate as of a point in time, bounded by scope decisions made before the audit began.

A Different Way to Read Your Own Reports

The implication is not that organizations should stop pursuing SOC 2 compliance. The implication is that compliance should be read the way an attacker reads it — before he does.

Three questions, applied to your own compliance artifacts before they are shared externally:

What does this document tell a reader about where our controls end? Not what it says about the controls themselves — what it reveals, by omission or by explicit scope definition, about the boundaries of what was audited. Every scope boundary is a signal. The Canvas breach entered through a program that the compliance framework had no reason to evaluate. An attacker read the scope boundary as an invitation to look at what was outside it.

What has changed since the coverage period ended? The report attests to a point in time. The delta between the attested state and the current state — new services, configuration changes, new access programs, new integrations — is the gap between what your compliance document says and what your actual attack surface is. The attacker does not assume that delta is small.

What would an attacker learn from the systems and tools named in this document? The report names your identity provider, your logging platform, your cloud infrastructure. Each named system has known vulnerabilities, known misconfigurations, and known attack paths. Reading the document as a list of targets, rather than a list of controls, reveals a different picture of what you have described to the world.

The organizations that treat this as a routine exercise will find gaps they did not know they had — because the gaps are not in what the report says. They are in the difference between what the report describes and what exists.

The Structural Observation

A SOC 2 report describes a perimeter. The perimeter is defined by scope decisions made before the audit began, using evidence collected during a coverage period that ended before the report was issued, for a system that has continued to change since the evidence was collected.

The attacker does not attack the perimeter. He maps it from the publicly available document and looks for what is on the other side.

The Canvas breach happened at the boundary between the audited institutional platform and the unaudited free-tier access program. The Delve case showed that the attestation itself can be fabricated, leaving the document intact while the reality it describes does not exist. The Coinbase 8-K showed that mandatory disclosure turns every material breach into a detailed reconnaissance asset for the next attacker in the same sector.

In each case, the compliance artifact was not wrong. It described what it described. And what it described was not the full picture — by design, by structure, and by the nature of point-in-time attestation applied to continuously evolving systems.

The question is not whether your SOC 2 report is accurate.

The question is whether the attacker who downloaded it this morning found the same gaps you did — or different ones.

When Chain Analysis Fails: Three Boundaries You Cannot Cross

Eldor Zufarov — Tue, 09 Jun 2026 17:50:55 +0000

Chain analysis is the best tool we've gained in recent years. It turns a list of vulnerabilities into a map of attacks. It shows how LOW and MEDIUM findings together become CRITICAL. It closes the gap between what defenders see and what attackers build.

But every model has limits.

If you don't know them, you'll end up with a false sense of security. Worse — you'll start making decisions based on an incomplete picture.

This article covers three scenarios where chain analysis does not give you an answer. Not because it's bad. Because it's static analysis, and attacks often happen in dynamics.

Boundary 1. The Chain Exists — But It Doesn't Connect at Runtime

Chain analysis finds paths in code. It sees that a token flows into an eval(), and the result of that eval() flows into a shell_exec(). Correct. Chain built.

Problem: at runtime, there may be defenses between those steps that static analysis cannot see.

Examples:

A check like if (user.role != 'admin') { return; } before the dangerous operation
A variable that passes validation in one thread but not another (a race condition static can't detect)
A value that comes from a database, not from user input — but static analysis cannot prove that

Chain analysis will say: "path exists." In reality, the path is blocked.

What to do about it?

Chain analysis should estimate probability, not assert "exploitable." Flags like EXPLOITABLE, TRACED, STATIC_SAFE, UNKNOWN are honest admissions that static analysis has limits.

And crucially: chain analysis is not a replacement for runtime testing. It's a filter. It says: "look here." Not "this will definitely be compromised."

Boundary 2. The Chain Exists — But Privileges Prevent Completion

A classic example from real audits.

Chain analysis builds a path: user input → API request → command execution on the server. Everything lines up. CRITICAL.

But the context missing from analysis: the API endpoint requires the system_admin role. The user has viewer. The privilege check exists in the code. It's just in a different file. Static analysis didn't trace that far.

Result: the chain exists. Exploitation is impossible.

Why is this dangerous?

Because if you trust chain analysis as truth, you'll start fixing things that don't need fixing. You'll burn engineering hours closing a path that was never open.

What to do about it?

Chain analysis needs to be able to read access policies. Not just code. Roles, permission matrices, middleware. Without that, any path through an admin endpoint will look CRITICAL.

But the honest answer: static analysis will never be perfect at this task. Because access policies often live at runtime — in databases, configuration files, external systems.

So you need a hybrid model: static builds candidates. Runtime confirms or rejects.

Boundary 3. No Chain in Code. But an Attack Still Happened.

This is the most painful boundary.

You scanned everything. Chain analysis found nothing. The posture index is high. The gate is green. A week later — incident.

What happened?

The attack left no traces in your code. Because it happened outside your repository.

Examples:

Supply chain: a dependency with no known CVE, but its maintainer was compromised. Code didn't change. Chain analysis sees no threat.
Social engineering: a developer received an email from "IT support" asking to install an update. They did. Nothing in code.
Configuration: an S3 bucket is open. The code never mentions that bucket. Chain analysis doesn't see it.
CI/CD pipeline: a GitHub Actions token leaked. The attacker ran their own workflow. The repository code never changed.

Chain analysis analyzes your code. Attacks often happen outside your code.

What to do about it?

Chain analysis is a necessary layer — but not sufficient.

It needs neighbors:

SCA (dependency scanning) — even without known CVEs, based on behavior
CI/CD analyzer — because pipelines are code that executes code
Infrastructure as Code scanning — configuration is attack surface
Secrets detection — not just in code, but in logs, env, history

And most importantly: chain analysis must be able to correlate signals across layers. A leaked CI token + an open S3 bucket + a dependency with suspicious updates — that's a chain. But it doesn't live inside src/.

What This Means for Your Security Program

Three takeaways you cannot ignore.

1. Chain analysis does not replace runtime. It narrows the suspect list.

Mistake: "We have no chains → we are secure."
Truth: "We have no visible static chains → we don't know about runtime."

Runtime testing, fuzzing, penetration testing are still required. Chain analysis doesn't make them unnecessary. It makes them more targeted.

2. Chain analysis must be honest about uncertainty.

The best chain analysis is one that says "I don't know" instead of inventing an answer.

Flags like TRACED (path traced but exploitability unknown), UNKNOWN (insufficient information) — these are not weaknesses. They are engineering honesty.

False certainty is more dangerous than no analysis.

3. If the attack left no traces in code — chain analysis won't help.

This is not a problem with chain analysis. It's a problem with assuming all security lives in the repository.

Attacks through CI/CD, dependencies, configuration, people — they are just as dangerous. And they don't look like eval($_GET['input']).

Your security program must include:

Pipeline security (who can run what)
Dependency integrity (not just CVEs, but behavior)
Secrets detection and rotation (everywhere, not just in code)
Infrastructure drift detection (configuration that diverged from declared)

Chain analysis is a compass. But a compass doesn't show obstacles. It shows direction.

Conclusion

Chain analysis is the best tool for one class of problem: finding paths in code that connect multiple vulnerabilities into a single attack.

It is not the best tool for:

proving a path does not exist (because static can't know runtime)
detecting attacks outside code (because they're not there)

If you build a security program on chain analysis alone — you've built a house without walls or a roof. You have a compass. You don't have protection from the wind.

Chain analysis should be the core — not the entire program.

And a core without a shell is just a pretty rock.

The Anatomy of Sabotage: Why Developers Bypass Security Controls and How to Fix It

Eldor Zufarov — Mon, 08 Jun 2026 14:00:41 +0000

The most vulnerable component in your DevSecOps pipeline is not an unpatched library or an exposed API endpoint. It is the psychological friction between your security team and your developers.

In 2026, organizations pour millions into complex enterprise security scanners, continuous integration compliance suites, and automated ticketing platforms. Yet, on the ground, a silent and pervasive form of operational sabotage is taking place: developers are systematically bypassing security controls.

They use --no-verify. They comment out linting steps in local configurations. They ignore automated security emails, and they treat security Jira tickets as noise to be aggressively bulk-closed before a sprint ends.

This isn't happening because software engineers are malicious or reckless. It is happening because traditional security architectures treat developers as adversaries to be policed rather than as high-throughput engines to be accelerated.

To build truly resilient systems, we must stop trying to patch human behavior with corporate policy. Instead, we must re-engineer our security gates to match the physics of the modern development workflow.

The Economics of Developer Frustration

Developers are measured by a single, unyielding metric: velocity. Their career progression, performance reviews, and daily cognitive rewards depend on shipping functional code to production.

Traditional application security (AppSec) tools operate in direct opposition to this metric. Consider the anatomy of a standard post-commit security failure:

A developer spends three days engineering a feature, runs local tests, pushes the code, and opens a Pull Request.
Two hours later, a heavy, centralized Static Application Security Testing (SAST) scanner running in the CI/CD pipeline completes its nightly run.
The scanner flags 42 security violations.
The developer is forced to context-switch, drop their current task, and spend hours digging through a dense, flat list of findings.
Upon closer inspection, 41 of those findings are false positives—such as flags inside dead code blocks, standard configuration templates, or test suites.

This cycle creates acute alert fatigue. When security tools behave like the boy who cried wolf, developers stop looking at the alerts. They start looking for the bypass switch. The deployment of a heavy security control without strict context awareness is an implicit invitation for engineering sabotage.

The Fatal Flaw of Post-Commit CI Security

Relying entirely on post-commit CI/CD pipelines to enforce security boundaries is an architectural anti-pattern. By the time code reaches a shared repository or a pipeline runner, the structural damage is already done:

The Exposure of Secret History: If a developer accidentally commits an active private token, that credential is now permanently baked into the immutable history of the Git repository. Even if a CI job fails the build ten minutes later, the secret has already hit the central server. It must be rotated immediately—a manual, high-friction operational cost.
The Context Dissipation: The moment a developer pushes code, their brain begins to flush the context of that specific feature to prepare for the next task. Forcing them to return to that code hours or days later to fix an abstract security finding destroys cognitive efficiency.

Security cannot be treated as a post-processing filter. It must be integrated into the state mutation of the repository itself—at the exact millisecond creation occurs.

The Solution: Designing a Zero-Friction Commit Gate

To eliminate the incentive for sabotage, a security gate must be architected around three unyielding technical requirements: sub-second execution, graph-level reachability, and deterministic validation.

Instead of scanning entire repositories looking for abstract syntax violations, the control must operate as a highly optimized, local pre-commit gate.

  Developer Types: git commit
            │
            ▼
┌──────────────────────────────────────┐
│  Local Pre-Commit Security Gate      │
│                                      │
│  1. Scan ONLY mutated files (Diff)   │ ──► [ Execution: <200ms ]
│  2. Map changes onto Graph Engine    │ ──► [ Reachability Verified? ]
│  3. Restricted AI Context Check      │ ──► [ False Positive Filter ]
└──────────────────────────────────────┘
            │
            ├──► [ Violations Found ] ──► Reject Commit (Instant Feedback)
            │
            └──► [ Clear ] ─────────────► Write to Git History

1. Delta-Only Graph Mapping

A local pre-commit gate must never perform a full-scan of the codebase. It must isolate the exact diff of the staged files. The gate translates these local changes into execution graph alterations and checks them against a cached map of the wider codebase. It evaluates reachability: does this specific, new code block physically connect an untrusted user input to a critical system sink? If no mathematical path exists, the commit proceeds instantly.

2. Eliminating the "Black Box"

If a local gate blocks a commit, it must provide instant, crystal-clear cryptographic telemetry directly in the terminal interface. It cannot simply say "Security Policy Violation." It must output the precise structural path of the vulnerability chain so the developer can patch it without leaving their IDE.

$ git commit -m "feat: integrate legacy parsing logic"
[Security Gate] Validating staged alterations...
[ERROR] COMMIT REJECTED: Structural Vulnerability Chain Detected.

Detailed Path:
  ↳ src/controllers/upload.js (Line 42) -> User input accepted
  ↳ src/utils/xmlProcessor.js (Line 12)  -> Vulnerable standard parser utilized
  ↳ [CRITICAL] Remote Code Execution Sink reached.

Remediation: Upgrade parser to defused wrapper or sanitize input at entry point.
Time elapsed: 142ms.

3. The Fail-Safe Fallback

To maintain absolute architectural integrity, local gates must be paired with an identical, automated fallback mirror in the remote CI environment. If a developer uses --no-verify or manually alters their local hooks, the remote pipeline catches the evasion attempt, blocks the merge, and logs the structural bypass. The local gate provides speed; the remote mirror provides enforcement.

Conclusion: Engineering Peace, Not Policy

Developers do not hate security; they hate impediment. When security teams deploy tools that assume developer incompetence, they receive friction and sabotage in return.

The solution to securing modern software lifecycles is not more mandatory training modules or longer compliance checklists. The solution is superior engineering. By implementing fast, deterministic, pre-commit graph gates, you transform security from an erratic, post-facto police force into an immediate, trusted compilation lint.

Stop fighting your engineering teams with administrative policy. Arm them with unyielding, sub-second architectural guardrails.

Security Without Evidence Is Faith

Eldor Zufarov — Sat, 06 Jun 2026 14:07:20 +0000

Imagine a security team presenting the following statement to the board:
"We believe our environment is secure."

Most executives would immediately ask:
"Why?"

The security team responds:
"We passed our compliance audit."

Would that be sufficient evidence?
Probably not.

So they continue:
"We have no critical vulnerabilities."

Still not convincing.

They add:
"We deployed security tooling across the environment."

Better.
But something still feels missing.
The problem is simple.
None of those statements directly prove that the environment is secure.
Yet cybersecurity is full of similar claims.

Every day organizations make decisions based on assumptions that are treated as evidence.
And the difference between assumptions and evidence may be one of the most overlooked problems in the entire industry.

Security Has an Evidence Problem

Most engineering disciplines rely on evidence.
A bridge is not considered safe because an engineer believes it is safe.
It is considered safe because calculations, stress testing, inspections, and measurements support that conclusion.
Medicine operates the same way.
Doctors do not prescribe treatment based solely on confidence.
They rely on tests, diagnostics, and observable results.
Evidence comes before conclusions.
Cybersecurity often reverses the process.
Conclusions frequently come first.
Evidence is collected afterward.

Organizations commonly claim:

We are secure because we passed an audit.
We are secure because we have security tools.
We are secure because we follow best practices.
We are secure because we have no critical findings.

These statements may all be true.
The problem is that none of them necessarily demonstrate resistance to compromise.
And resistance to compromise is ultimately what security is supposed to measure.

The Dangerous Substitutes for Evidence

Over time, cybersecurity has developed several proxies that are often mistaken for proof.

Compliance

Compliance demonstrates that controls exist.

It does not prove that those controls are effective.

A company can satisfy every requirement of a framework while still exposing attack paths that auditors never evaluate.

Compliance provides evidence of adherence.

Not evidence of security.

Vulnerability Counts

A vulnerability report tells us weaknesses exist.
It does not tell us whether those weaknesses can be combined into a viable attack path.
Five hundred isolated findings may represent less risk than three interconnected weaknesses.
Counting findings is not the same as measuring compromise potential.

Security Tool Coverage

Organizations frequently measure security maturity by the number of deployed tools.

More scanners.
More sensors.
More alerts.
More visibility.

Yet attackers are rarely stopped by tool inventories.
They are stopped by controls that successfully disrupt attack progression.
Coverage is not evidence.
Effectiveness is evidence.

Expert Opinion

Perhaps the most dangerous substitute is confidence itself.
An experienced engineer may believe an environment is secure.
That belief may even be reasonable.
But expertise does not eliminate uncertainty.
Evidence exists precisely because confidence alone is insufficient.
Without evidence, confidence becomes faith.

What Attackers Understand Better Than Defenders

Attackers rarely care about security narratives.
They care about outcomes.

An attacker does not ask:

Is this company compliant?
Does this company have a SIEM?
How many findings were closed this quarter?

An attacker asks:

Can I get access?
Can I move laterally?
Can I escalate privileges?
Can I reach valuable assets?

Notice the difference.
Security teams often evaluate programs.
Attackers evaluate systems.
Programs can appear healthy while systems remain vulnerable.
This distinction explains why organizations are sometimes surprised by breaches despite positive security metrics.
The metrics were measuring the wrong thing.

What Real Security Evidence Looks Like

Evidence should reduce uncertainty.
That principle sounds obvious.
Yet it fundamentally changes how security is evaluated.

Useful evidence answers questions such as:

Can an attacker reach this asset?
Can exposed credentials be abused?
Does privilege escalation remain possible?
Does segmentation actually prevent movement?
Can controls interrupt realistic attack paths?

Notice that these questions focus on outcomes rather than artifacts.
They measure what an attacker can achieve rather than what security teams have implemented.
That distinction is critical.
Because attackers exploit reality.
Not documentation.

The Difference Between Security and Security Theater

Security theater occurs when activities are mistaken for outcomes.
The organization feels safer.
The metrics look better.
The reports become more impressive.
Yet the probability of compromise remains unchanged.
This phenomenon is not unique to cybersecurity.
Every mature field eventually learns to distinguish indicators from evidence.
Cybersecurity is still undergoing that transition.
Many organizations remain focused on proving effort.
Far fewer are focused on proving effectiveness.
But effort and effectiveness are not the same thing.

The Future of Security Is Evidence-Based Security

The next evolution of cybersecurity will not be defined by larger dashboards or additional tooling.
It will be defined by stronger evidence.

Future security programs will increasingly ask:

What do we know?
How do we know it?
What evidence supports that conclusion?
What uncertainty remains?

These questions sound philosophical.
They are actually operational.
Because every security decision ultimately depends on confidence.
And confidence without evidence is dangerous.
The organizations that adapt fastest will not necessarily be the ones with the most tools.
They will be the ones capable of distinguishing assumptions from facts.
Signals from proof.
Visibility from understanding.
And activity from actual security.

Conclusion

Cybersecurity often presents itself as a technical discipline.
In reality, it is also a discipline of evidence.

Every vulnerability report.
Every audit.
Every alert.
Every assessment.

Ultimately serves a single purpose:
Reducing uncertainty about what an attacker can do.

That means the most important question in security is not:
"How many findings do we have?"

Nor:
"Did we pass the audit?"

Nor even:
"What tools are deployed?"

The most important question is:
"What evidence supports our belief that this system is secure?"

Because security without evidence is not security.
It is faith.

The Attacker Lives Between Your Tools

Eldor Zufarov — Fri, 05 Jun 2026 11:21:52 +0000

Why your SAST, DAST, and SCA each see a clean report — and you still get breached

Every tool passed.

The SAST scan completed without critical findings. The SCA report showed no exploitable CVEs in production dependencies. The DAST run flagged three medium-severity issues, all triaged and accepted. The security dashboard was green. The compliance checkbox was ticked.

Then the breach happened anyway.

Not through a vulnerability any of the tools were looking for. Through the space between them.

The Architecture of Blindness

The modern application security stack was not designed as a system. It was assembled as a collection of independent instruments, each optimized for a specific layer, each reporting findings in isolation, each defining its own perimeter — and stopping at the edge of it.

SAST analyzes source code before it runs. It sees what developers wrote. It does not see what the application becomes at runtime — how components interact under load, how configuration transforms behavior, how infrastructure shapes the attack surface of code that looked clean in review.

DAST tests a running application from the outside. It sees how the application responds to crafted inputs. It does not see the source code that produced those responses, the dependency chain that assembled the runtime, or the infrastructure layer that routes requests before they reach the application.

SCA catalogs third-party components and maps them against known vulnerability databases. It sees what libraries are present. It does not see whether the vulnerable function in a flagged library is actually reachable from the application's execution path — which is why the average SCA report generates enough noise that teams learn to filter it rather than act on it.

Each instrument is technically accurate within its domain. The problem is that attackers do not operate within domains. They operate in the space between them — the gaps that no single tool owns, the transitions that no single tool watches, the moments where one layer hands off to another and assumes the other layer has checked what it needs to check.

That assumption is the attack surface.

Five Dead Zones

The gaps are not theoretical. They are structural properties of how the tools are built. Understanding them precisely is the first step to building coverage that does not stop at instrument boundaries.

Dead Zone 1: The Source-to-Runtime Gap

A developer writes a function that handles file uploads. SAST analyzes it, finds no injection flaws, reports it clean. The function is deployed. At runtime, the application runs inside a container with a misconfigured temporary directory mounted world-writable. The clean function, in a misconfigured environment, becomes an arbitrary file write primitive.

SAST saw clean code. It will always see clean code, because the code is, in isolation, clean. The vulnerability does not exist in the source. It exists in the combination of the source and the environment it runs in — and SAST's entire model of analysis ends at the boundary of the source.

DAST might catch the resulting behavior — but only if it is pointed at the right endpoint with a payload that exercises this specific path, which requires knowing the path exists in the first place. The 2025 Verizon DBIR found vulnerability exploitation rose 34% as an initial access vector, now rivaling phishing as a primary entry method. A meaningful share of those exploited conditions were not undisclosed zero-days — they were known weaknesses sitting exactly at this boundary, where a tool that checks code cannot see environment, and a tool that checks environment was never told what the code does with it.

Dead Zone 2: The Dependency Reachability Gap

SCA reports a critical CVE in a logging library. The security team triages it: the vulnerable deserialization function exists in the library, but — based on a manual review of the codebase — it does not appear to be called. The finding is accepted as low priority. The patch is deferred.

What the manual review missed: a middleware component added three sprints ago calls the logging library's initialization routine, which under specific error conditions invokes the deserialization path. The call chain is four hops long and only activates on malformed input that the application receives from a specific API endpoint.

The attacker does not need to read the code. He needs to send the right malformed input to the right endpoint. The reachability was always there. The SCA tool reported the CVE. Nobody traced the path.

This gap is systemic. The OWASP Top 10 2025 ranks Software Supply Chain Failures at number three. The Verizon 2025 DBIR puts third-party involvement in breaches at around 30% and rising. Both data points reflect the same structural problem: teams know their dependencies have vulnerabilities. They do not know which ones are actually reachable from their specific execution context. The tools report presence. They do not report exposure.

Dead Zone 3: The Configuration Inheritance Gap

DAST tests the application in the staging environment. Staging is configured to mirror production, but with one difference the team made six months ago and has since forgotten: a Content Security Policy header that blocks inline script execution in production is relaxed in staging to simplify debugging. The DAST scan runs clean against staging, because in staging there is nothing to bypass. The production application — the one users actually reach — has a CSP gap that no scan has ever pointed at.

Unlike Dead Zone 1, where the gap is between code and the environment it runs in, this gap is between two environments that are assumed to be equivalent and are not. Nothing in the standard stack owns the question "does what we tested match what we shipped?"

The Blue Shield of California breach, disclosed in April 2025, shows how far this gap can extend when nobody is assigned to it. Between April 2021 and January 2024 — nearly three years — a Google Analytics configuration on Blue Shield's member portal transmitted protected health information for roughly 4.7 million members to Google's advertising platform. The company described it as the result of a website misconfiguration. No application vulnerability. No exploit. A configuration setting, present in production, that none of SAST, DAST, or SCA were ever positioned to evaluate — because none of them treat third-party tracking configuration as part of the security surface at all.

Dead Zone 4: The Patch Window Gap

In April 2025, a critical zero-day in SAP NetWeaver — CVE-2025-31324, an unauthenticated file upload flaw in the Visual Composer component, CVSS score 10.0 — was found being actively exploited in the wild before SAP had even confirmed it as a vulnerability. Researchers at ReliaQuest traced exploitation activity back to late March. By the time SAP issued an out-of-band emergency patch, the Shadowserver Foundation counted roughly 450 internet-facing instances still vulnerable, and attackers had already deployed JSP web shells to multiple compromised environments — establishing persistent access that the patch itself would not remove.

No SAST, DAST, or SCA tool in any of those organizations failed here. None of them are designed to know about a vulnerability before the vendor discloses it. The gap is not in detection. It is in the time between "a patch exists" and "the patch is applied, verified, and any pre-patch compromise is checked for" — and during that window, which for many organizations runs into weeks once change management, testing, and scheduling are factored in, the system is exposed regardless of what the scanners report, because the scanners are evaluating a version of the system that no longer matches reality.

This is the gap that turns "we have a patch" into a false sense of resolution. Applying the patch closes the vulnerability. It does not remove a web shell that was planted three weeks before the patch existed — and nothing in the standard stack checks for that, because checking for the consequences of a gap is a different task than checking for the gap itself.

Dead Zone 5: The Inter-Tool Correlation Gap

SAST flags an input validation issue in a data processing service — medium severity, accepted with a note to fix in the next sprint. SCA flags an outdated XML parsing library in the same service — low severity, the vulnerable function appears unused. DAST, running against a different endpoint of the same service, flags an information disclosure issue in error responses — low severity, no sensitive data visible in the test payload.

Three findings. Three separate reports. Three separate triage decisions. No single analyst sees all three in context.

An attacker sees the combination: unvalidated input, reaching an XML parser with a known deserialization flaw, in a service that leaks error details about its internal processing. Each finding individually is noise. Together they are an exploit chain. The SAST tool does not talk to the SCA tool. The SCA tool does not know what DAST found. The analyst who triaged the SAST finding has never seen the DAST report.

This is the pattern that a 2025 review of major breaches kept landing on: security responsibilities split across separate tools — patching here, endpoint protection there, identity management somewhere else — leave gaps that nobody is specifically watching, and those gaps are exactly where attackers operate with the most consistency. The blindness is not in any instrument. It is in the absence of a layer that reads all the instruments together.

Why the Standard Response Fails

The industry's answer to the inter-tool gap is, predictably, more tools.

Add an IAST agent to the runtime. Add a CSPM scanner for cloud configuration. Add an API security gateway. Add an ASPM platform to correlate findings across sources.

Each addition extends coverage in one dimension. Each addition also adds another boundary, another handoff, another assumption that the adjacent layer has checked what it needs to check. The stack grows. The dead zones migrate. The architecture of blindness is preserved at a higher level of complexity.

The more fundamental issue is that tool-centric security measures attack surfaces as a collection of domains, each with its own scanner, each reporting independently. The attacker does not see domains. He sees a system. He maps the transitions between layers because he knows that is where the assumptions live — and assumptions are not checked by any scanner.

Teams routinely defer or accept findings not because they are careless, but because every tool reports in isolation and every finding competes for the same remediation backlog without context on which findings, combined, actually matter. When the signal that determines real risk — the chain, not the individual finding — never reaches anyone, deferring individual findings is a locally rational response to a system that does not surface the global picture.

What Coverage Without Dead Zones Requires

Closing the gaps does not require more tools. It requires a different organizing principle.

Coverage must be defined by attack paths, not by tool domains. The question is not "does SAST cover this code path" or "does DAST test this endpoint." The question is: "can an attacker reach a sensitive operation by chaining findings from different tool domains?" If the answer to that question cannot be determined from the tooling in place, the coverage is incomplete regardless of how many tools are running.

This means attack path analysis cannot be reconstructed after the fact from individual tool reports. It has to be built into the analysis layer — a layer that ingests findings from SAST, DAST, SCA, infrastructure scanners, and configuration baselines simultaneously and looks for combinations that create reachable exploit chains, not just individual findings that exceed a severity threshold.

The patch window gap requires a different operational model than the vulnerability detection gap. Detection is a tooling problem. Remediation velocity is an organizational problem. As the SAP NetWeaver case shows, even an emergency patch released within days of disclosure does not close the exposure window retroactively — it stops new exploitation while leaving open the separate question of whether exploitation already happened during the window before the patch existed. Closing this gap means tracking "what is vulnerable," "what is exploitable right now given current configuration," and "what may already have been exploited during the exposure window" as three separate questions, each with its own urgency.

A vulnerability that exists in a library but is unreachable from any production execution path is a different risk than a vulnerability in a component that handles unauthenticated external input. The tools that report both as "critical" are not wrong. They are solving the wrong problem. The operational question is not "what is the CVSS score" but "what is the blast radius if this fires in production, given what I know about the call graph, the configuration, and the network topology."

Configuration must be treated as part of the attack surface, not as a precondition to security testing. The Blue Shield breach did not require a vulnerability at all — a configuration setting, unmonitored for nearly three years, was the entire incident. Configuration divergence between environments, missing security headers in production but not in staging, overpermissioned service accounts that DAST never touches — these are first-class attack surface elements that require first-class coverage, not afterthoughts left to whichever tool happens to have a checkbox for them.

The Structural Observation

Every dead zone in the standard security stack shares the same root cause: each tool owns its domain and assumes the adjacent tool owns its own domain, and nobody owns the boundary between them.

This is not a technology problem. It is an architectural problem — the same architectural problem that produces the alert-list-to-exploit-graph gap in runtime security, the same problem that produces compliance theater in awareness training. The instruments are optimized for their individual functions. The system has no function that is responsible for the space between instruments.

The attacker's advantage in both cases — Blue Shield and SAP NetWeaver — was not sophistication. In neither case did the attacker need to defeat a SAST scan, evade a DAST crawler, or find an unreachable CVE. One found a configuration nobody was watching. The other found a window between disclosure and remediation that no scanner is designed to close. Both were, in the language of the standard stack, "not a finding" — right up until they were the entire incident.

That soft spot is always in a dead zone.

The question is not whether your tools are good. They probably are, within their domains.

The question is who is responsible for the space between them — and whether that responsibility has a tool, a process, and an owner, or whether it is the one thing on the security team's map that is simply marked assumed covered.

The attacker has already checked whether that assumption is correct.

He is counting on the fact that you have not.

Determinism Over Degeneracy: Why Model Collapse Will Destroy "AI-First" Cyber Security

Eldor Zufarov — Thu, 04 Jun 2026 12:00:00 +0000

The cybersecurity industry is currently intoxicated by a dangerous illusion: the myth of the omnipotent AI security engineer. If you follow the marketing noise of 2026, the recipe for modern DevSecOps seems absurdly simple: take a Large Language Model (LLM), feed it your repository, and let it autonomously find bugs, triage alerts, and patch vulnerabilities.

We are told that autonomous AI attackers—like the hyped generative models optimized for offensive operations—can map infrastructure and generate zero-day exploits within hours. Consequently, the industry’s response has been to fight fire with fire: unleashing a wave of "AI-first" security scanners that analyze code probabilistically.

But this entire paradigm is heading toward a structural dead end.

As the internet and open-source repositories become flooded with synthetic, AI-generated code, we are approaching a systemic tipping point: Model Collapse. When AI begins to train on the output of other AI models, a process of "data inbreeding" occurs. For probabilistic security tools, this means inevitable degradation.

The future of cyber defense doesn’t belong to unconstrained, probabilistic "black boxes." It belongs to Deterministic Chain Analysis backed by restricted AI validation.

The Mechanics of Structural Asymmetry

To understand why AI-first security tools are doomed to fail in the near future, we must look at how autonomous AI attackers actually operate.

An AI attacker does not look at code the way a flat Static Application Security Testing (SAST) scanner does. It doesn't care about isolated, flat lists of violations. It looks for contextual reachability. It seeks out a series of low or medium-severity issues that can be linked into a catastrophic exploit chain.

Consider a real-world architectural failure:

A developer leaves an exposed configuration example or a hardcoded token in a quickstart template.
A secondary component utilizes an unpinned, outdated cryptographic library.
A third internal module uses a standard, vulnerable XML parser to handle external device responses.

In isolation, traditional flat scanners score these as "Low" or "Medium" priorities. They sit in the backlog for months. However, an autonomous attacker sees a clear, unobstructed path from initial information leakage to remote code execution (RCE).

When "AI-first" defensive scanners try to detect these chains, they do so probabilistically. They guess the context. And this is where the fatal flaw of LLMs exposes itself.

The Reality of Model Collapse: Data Inbreeding in InfoSec

Model Collapse occurs when an LLM loses its grasp on reality because its training data is contaminated by synthetic data. In software engineering and DevSecOps, this contamination is already happening. AI assistants are generating boilerplate code, templates, and CI/CD configurations at an unprecedented scale.

When AI-first scanners train on this increasingly degraded pool of open-source code, two things happen:

The Proliferation of Ghost Vulnerabilities: The models begin to hallucinate architectural patterns, generating false positives that overwhelm development teams. This escalates alert fatigue to a point of operational paralysis.
Blind Spots via Recursive Homogenization: As the training data becomes homogenized, the AI defensive models optimize for a narrow, average definition of "secure code." They completely lose the ability to see highly contextual, non-linear vulnerability chains that human architects—and specialized AI attackers—can exploit.

If your defensive strategy relies entirely on a probabilistic AI scanner, your security posture will degrade at the exact same rate as the model's training set. You are essentially delegating your perimeter defense to a copy of a copy.

The Solution: Two-Layered Deterministic Architecture

To survive the era of autonomous attacks and model degradation, we must invert the current design philosophy. We must shift from Probabilistic-First to Deterministic-First.

True system resilience requires a two-layered architectural blueprint that decouples core detection from the fluctuations of neural networks:

+---------------------------------------------------------+
| Layer 2: Restricted AI Validation (Context Filtering)    |
| (Eliminates False Positives, Translates Metrics)        |
+---------------------------------------------------------+
                           ^
                           | Validated Chains
                           |
+---------------------------------------------------------+
| Layer 1: Deterministic Graph Analysis (Chain Engine)    |
| (Mathematical Reachability, Strict Graph Theory)        |
+---------------------------------------------------------+
                           ^
                           | Code / Commits

Layer 1: The Deterministic Foundation (The Graph)

The core of your security analysis must be mathematical, rigid, and entirely independent of LLM whims. Using strict graph theory, the system must map out the actual execution paths and data flow of the application. It evaluates reachability: Can an untrusted input physically reach this vulnerable sink? If the mathematical path does not exist, there is no exploit chain. This layer is completely immune to Model Collapse because it relies on code execution logic, not training datasets.

Layer 2: Restricted AI Validation

Only after Layer 1 has mathematically proven the existence of a vulnerability chain should the data be passed to an LLM layer. Here, the AI does not discover the bug; it merely validates the context and filters out structural false positives (e.g., recognizing if an properly implemented obfuscation block or a custom crypto wrapper safely handles the input).

By restricting the AI to a verification role on a pre-computed graph, you eliminate the risk of model degradation affecting your core detection capability.

Moving Control to Commit-Time

Relying on post-commit CI/CD pipelines to catch these chains is a legacy mindset. By the time a vulnerability is flagged in a nightly CI build, the code is already in the repository history, the developer has switched tasks, and the tight window before automated exploitation has already begun.

True architectural resilience requires a Shift-Left Chain Enforcement mechanism. Security gates must run locally as a pre-commit hook. If a developer attempts to commit code that completes a dangerous vulnerability chain, the gate must block the commit in milliseconds.

$ git commit -m "feat: add quickstart automation script"
[Security Gate] Analyzing local graph alterations...
[ERROR] GATE OVERRIDE: Commit blocked. 
Detected Vulnerability Chain: CHAIN_0003 (Reachability: Verified)
Path: config/template.py -> internal/parser.py -> RCE Sink
Stops: 3 | Risk Score: 94.2/100
Use --no-verify at your own peril (Fallback CI enforcement active).

By enforcing strict, deterministic policies at the moment of creation, you decouple your organization’s survival from the unstable, collapsing landscape of commercial AI models.

Conclusion: The New Paradigm of Provable Security

The cybersecurity industry doesn't need more probabilistic "black box" platforms that issue 500-page PDF reports filled with 99% false positives. It needs foundational, rigid logic.

As autonomous agents continue to accelerate the speed of attacks, the winners of this paradigm shift will not be those who sell vague, AI-driven promises. The future belongs to those who build and engineer the deterministic infrastructure, the mathematical graphs, and the unyielding commit gates that make security provable and absolute.

Stop guessing your security posture with probabilistic models. Start proving it with deterministic architecture.

Your Security Awareness Training Is a Map for Attackers

Eldor Zufarov — Wed, 03 Jun 2026 12:00:00 +0000

How standardized behavior creates predictable targets — and what to do about it

The attacker did not break anything.

He read the training manual.

Not yours specifically. The industry's. The same curriculum running inside tens of thousands of organizations worldwide — the same modules, the same simulated phishing, the same rules of thumb delivered to employees who will behave, predictably, exactly as they were trained.

He read it. Then he built his attack around it.

The Paradox at the Center of Security Awareness

Security awareness training exists to make employees predictable in a good way: predictably skeptical, predictably cautious, predictably compliant.

The problem is that predictability in defense is a targeting system for offense.

When every employee in every organization trained on the same framework behaves the same way under the same conditions, the attacker does not need to study your organization. He needs to study the framework. The training does not just teach employees how to be safe. It teaches attackers what to expect — and more precisely, where trust is assumed rather than verified.

Every place a standard says employees should trust X, an attacker reads: here is your entry point.

What the Training Actually Teaches

Walk through any standard security awareness curriculum and read it the way an attacker would.

"Download software only from official sources."

Employees learn: GitHub is official. The vendor's documentation page is official. Microsoft's download portal is official.

The attacker learns: create presence on GitHub. Occupy the category of source the training has already marked as trusted. The employee's own training will do the authentication for him.

This is exactly what happened in the EtherRAT campaign. The attackers did not compromise GitHub. They created repositories that looked like what employees had been trained to expect at a trusted source. The platform's legitimacy transferred to the payload. The training pointed employees toward a category — the attacker moved into that category and waited.

"Verify that files are signed before running them."

Employees learn: a signed file is a safe file.

The attacker learns: get a signature. Code signing certificates are obtainable. A signature verifies identity, not intent. The training has taught the employee to stop at the signature — which means everything beyond the signature is, by design, invisible. The check is the blind spot.

"Be suspicious of unexpected emails from unknown senders."

Employees learn: known senders are safer than unknown ones.

The attacker learns: become a known sender first. Compromise a vendor. Compromise a partner. Send the payload from an address the target's inbox already trusts. The training has drawn a bright line. The attacker steps over it — using the line itself as guidance on where to position.

In each case, the training does not fail because it is wrong. It fails because it is right in a way that is fully legible to the attacker.

Cybersecurity Has a Measurement Problem

Eldor Zufarov — Tue, 02 Jun 2026 10:54:48 +0000

A company passes its compliance audit.

All critical vulnerabilities are patched.

The SIEM is green.

The dashboards look healthy.

The security team reports no major incidents.

Three weeks later, the company is breached.

How does that happen?

More importantly:

How does it keep happening?

The uncomfortable answer is that cybersecurity has spent decades improving visibility while largely failing to solve measurement.

We have become extremely good at collecting signals.

We are still surprisingly bad at determining what those signals actually mean.

And that distinction may be one of the most important problems in modern security.

The Security Industry Measures Everything Except Security

Imagine asking a doctor a simple question:

"Is the patient healthy?"

Instead of answering, the doctor hands you a report:

17 blood pressure alerts
43 heart rate alerts
8 temperature alerts
126 miscellaneous alerts

Would you know whether the patient is healthy?

No.

You would know how much data was collected.

You would not know what condition the patient is actually in.

Cybersecurity often operates the same way.

Organizations measure:

Number of vulnerabilities
Number of alerts
Number of findings
Number of incidents
Number of compliance controls

These numbers fill dashboards.

They drive reports.

They influence budgets.

Yet none of them directly answer the question executives actually care about:

How likely is it that an attacker can successfully compromise this environment?

That is not a visibility question.

It is a measurement question.

The Vulnerability Counting Trap

One of the most persistent assumptions in cybersecurity is that more vulnerabilities equal more risk.

At first glance, that seems logical.

But reality is rarely that simple.

Consider two environments.

Environment A

500 low-severity vulnerabilities
Strong segmentation
Limited privileges
No practical attack paths

Environment B

3 vulnerabilities
Exposed credentials
Reachable internal services
Direct privilege escalation path

Which environment would you rather defend?

Most dashboards would highlight Environment A.

Most attackers would choose Environment B.

The difference is critical.

Security findings are not independent events.

They interact.

Risk emerges from relationships.

The problem is not the number of weaknesses.

The problem is what those weaknesses allow an attacker to do when combined.

Why Attackers Win With Fewer Data Points

Most security programs see systems as collections of findings.

Attackers see systems as pathways.

A scanner might report:

Exposed secret
SSRF
Weak IAM policy
Internal service exposure

Four separate issues.

An attacker sees something very different:

Exposed Secret → Cloud Access → SSRF → Internal Service → Privilege Escalation

One attack path.

One compromise.

One successful breach.

The scanner is technically correct.

The attacker is operationally correct.

And operational reality is what matters.

The security team is looking at a list.

The attacker is looking at a graph.

Why CVSS Cannot Measure System Risk

This is where many organizations become trapped.

CVSS is valuable.

It provides useful information about individual vulnerabilities.

But CVSS was never designed to measure the risk of an entire system.

A vulnerability scored 9.8 may be effectively isolated.

A vulnerability scored 4.3 may become catastrophic when connected to exposed credentials, trust relationships, and reachable assets.

Attackers do not compromise organizations through CVSS scores.

They compromise organizations through attack paths.

Severity describes a weakness.

Risk describes a system.

Those are fundamentally different concepts.

Yet many vulnerability management programs treat them as interchangeable.

The result is predictable:

Teams spend enormous effort reducing scores while attackers focus on exploitability.

The Compliance Illusion

The same problem appears in compliance.

Organizations often assume that compliance is evidence of security.

It is not.

Compliance demonstrates adherence to a framework.

Security describes resistance to compromise.

Those concepts overlap.

They are not equivalent.

An organization can pass an audit and remain vulnerable.

An organization can satisfy every required control and still expose a viable attack chain.

Compliance answers:

"Did we implement the required controls?"

Attackers ask:

"Can I still get in?"

These are different questions.

Only one determines the outcome of an attack.

The Evidence Problem

At its core, cybersecurity suffers from an evidence problem.

The industry frequently substitutes proxies for proof.

We assume:

Findings indicate risk.
Alert volume indicates visibility.
Compliance indicates security.
Severity indicates impact.

Sometimes those assumptions are correct.

Often they are not.

The challenge is that most security metrics measure activity around security rather than security itself.

They tell us what we observed.

They rarely tell us what an attacker can actually achieve.

That gap between observation and reality is where many security programs fail.

Security Is a Measurement Science

Every mature engineering discipline eventually develops reliable measurement models.

Civil engineers calculate structural loads.

Manufacturers measure product quality.

Medicine uses diagnostics and laboratory evidence.

Cybersecurity remains heavily dependent on proxies.

The next phase of the industry will not be driven by collecting more data.

It will be driven by measuring reality more accurately.

That requires moving beyond isolated findings and toward:

Attack paths
Risk propagation
Trust relationships
Reachability analysis
Dependency mapping
Evidence-based risk assessment

Because security is not a list of vulnerabilities.

Security is not a compliance score.

Security is not a dashboard.

Security is an assessment of what an attacker can actually accomplish.

And until cybersecurity learns to measure that directly, organizations will continue to mistake visibility for understanding.

Conclusion

For years, cybersecurity has optimized its ability to observe systems.

The next challenge is learning how to measure them.

That distinction matters because attackers do not care how many findings exist.

They care whether those findings connect.

They do not care how many controls were implemented.

They care whether those controls stop them.

And they do not care what organizations believe about their security posture.

They care about reality.

Ultimately, security is not the number of vulnerabilities you find.

Security is the confidence you can justify with evidence.

Everything else is an assumption.

Audited a Popular Python Automation Project. The Biggest Risks Weren't What I Expected.

Eldor Zufarov — Fri, 22 May 2026 02:09:55 +0000

Audited a mature Python infrastructure automation codebase this week using Auditor Core v2.3.

Interesting observation: the highest-risk issues were not "classic vulnerabilities" like SQL injection or obvious RCE sinks.

The real exposure came from the combination of:

legacy XML parsing surfaces
dynamic module loading
subprocess-driven tooling
template rendering pipelines
large plugin ecosystems

Individually, many of these patterns look acceptable. Together, they create a high-complexity attack surface that becomes difficult to reason about over time.

One concrete example from the review — legacy XML parsing without hardened parser protections:

import xml.etree.ElementTree as ET

tree = ET.parse(config_file)

Another area relied on dynamic module loading:

module = importlib.import_module(plugin_name)

These two patterns appeared in the same codebase. The XML parser processes data coming from network devices. The module loader determines which driver handles that data. Neither is wrong in isolation. Together, they mean an attacker who influences device responses can potentially influence which code processes them.

What stood out most during the review:

Internal tooling and documentation pipelines frequently receive far less security scrutiny than production APIs — despite executing shell commands, processing structured input, and rendering templates.

This is exactly why isolated findings are no longer enough. Modern security audits need correlation, execution context, and architectural analysis — not just alert volume.

This review was done with Auditor Core v2.3 — deterministic scanning with chain analysis and SOC 2 / CIS Controls v8 / ISO 27001 mapping.

How does your team handle security review of internal tooling — docs pipelines, plugin loaders, build scripts? Or does it mostly fly under the radar until something breaks?

🔗 Learn more: datawizual.github.io

10 Python modules, one dangerous pattern: How I found 13 critical vulnerabilities in an SDK

Eldor Zufarov — Wed, 20 May 2026 07:36:51 +0000

TL;DR: Every core module of a popular firewall network device management SDK uses Python's unsafe XML parser. Here's what that means for production systems — and how to fix it in 10 lines.

Your SDK dependencies may be parsing untrusted XML without protection — and you wouldn't know until an incident.

I audited an open source Python SDK for firewall management. Auditor Core v2.3 flagged 13 critical findings across 10 production modules — all the same root cause.

Every core module uses Python's native xml.etree.ElementTree parser — the one Python's own documentation recommends replacing.

Affected: 10 core modules across the entire SDK — every file that handles XML parsing.

The library's purpose is to parse XML responses from live network devices. Any attacker-influenced response (MitM, compromised appliance, rogue endpoint) gets processed without XXE or Billion Laughs protection.

Second finding: hashlib.sha1() used for value hashing in production logic — with the comment documenting it explicitly in the source. SHA-1 has been broken since 2017.

Both were found using Auditor Core v2.3 — my deterministic security engine that combines SAST, SCA, secrets, and CI/CD analysis with AI validation.

What makes it different from running Bandit or Semgrep directly:

→ Findings are deduplicated and correlated across detectors (the SHA-1 issue was caught by 3 rules, reported once with full context)

→ Every finding maps to SOC 2 TSC, CIS Controls v8, and ISO 27001:2022

→ Code quality noise is separated from real vulnerabilities before report generation

→ PDF output is structured for cyber insurance underwriting and SOC 2 readiness

The fix is trivial: replace import xml.etree.ElementTree as ET with import defusedxml.ElementTree as ET in each module. Drop-in compatible.

The broader lesson: libraries defer security hardening of internal parsing, then ship that risk into hundreds of downstream projects.

I'm currently offering confidential audits for Python/TS backends — $490, 3-day turnaround, NDA, SOC 2 ready report. If your team hasn't reviewed its dependencies for unsafe XML parsing or weak crypto this year, let's talk.

DataWizual Labs Web-site
Email: eldorzufarov66@gmail.com