In today's fast-moving cybersecurity landscape, threat analysts must move beyond basic, binary reputation scores to successfully defend against modern, highly adaptive web threats. Traditional URL analysis has been redefined by the launch of URL Scanning 2.0, an update that significantly expands VirusTotal's URL analysis capabilities by introducing automated visits with a full browser instance and deeper historical visibility.
Instead of relying on static reputation scores alone, URL Scanning 2.0 enriches reports with "under-the-hood" headless browser telemetry, including the DOM, full-page screenshots, web technologies, and network request logs. Crucially, it introduces historical analysis pivoting, giving analysts the ability to track how a page has changed over time.
URL Scanning 2.0
To successfully defend against modern, highly adaptive web threats, threat analysts must move beyond basic, binary reputation scores. With the debut of URL Scanning 2.0, VirusTotal introduces robust headless browser integration that captures how a page behaves dynamically in a clean sandbox environment.
Every scan now generates rich, granular telemetry that provides a blueprint of the target page's execution:
- Headless Browser Data: Full-page visual screenshots, full DOM (Document Object Model) trees, and web technologies (e.g., Cloudflare, PHP, HTTP/3).
- Page and Network Statistics: Highly detailed counters of individual network requests, encrypted HTTPS transactions, unique contacted domains/subdomains, and serving IP address mappings with geographic tracking.
- Anti-Phishing Fingerprints: Automatic identification of brands, cloned-website tags, password input fields, tracker IDs, and favicon dhashes.
- Historical Pivoting: A timeline containing historical analyses of a URL with its corresponding risk score, allowing analysts to track exactly how its metadata and content have shifted over time.
Access Levels in VirusTotal
Public Access (Free for VirusTotal Users) The core enhancements of the URL Scanning 2.0 engine are available to everyone. For the latest scan, analysts can access rich telemetry generated by headless browser execution, including visual screenshots, extracted JavaScript globals, console messages, and a list of all loaded network resources.
VirusTotal Premium Customers For paid VirusTotal customers, the platform unlocks deeper retrospective capabilities and exclusive data fields. Analysts have the ability to pivot to and review the full historical analyses of a URL as it was observed at specific points in time, and access advanced telemetry like the full DOM captures of the execution. Furthermore, premium access unlocks advanced infrastructure relationships, allowing users to pivot on contacted domains, IPs, and downloaded files.
Note: The aforementioned Google Threat Intelligence and Automatic Brand Identification features are exclusively available to Google Threat Intelligence customers.
Investigating a Phishing Case
Initially, when an analyst navigates to the mentioned URL to view the report generated by VirusTotal, they would see something similar to the following with the new URL Scanning features:
At the top of the interface, we can see that the URL has been scanned three times. This means there are three distinct reports for the same URL, each potentially containing different information that could be highly useful for an analyst. In the top right corner, we can view these past analyses by clicking on "History".
This is where the new historical analysis pivoting comes into play: it allows analysts to travel back through a URL's timeline with point-in-time snapshots.
By clicking on "History", we can view all the historical analyses for that URL, including response codes, detections, screenshots, and other metadata. You can also apply filters to narrow down the timeline and view only the historical records you are interested in, based on specific response codes, URL actions, and other criteria.
In this case, if we click on the initial historical analysis performed on July 6, 2026 (as shown in the screenshot above), we can examine its specific information across the "Summary", "Details", and "Detection" tabs. A key feature of URL Scanning 2.0 is that the information within these report tabs will dynamically re-render to match the exact historical state of the snapshot you select.
As observed in the history timeline, after clicking on this specific analysis included a live screenshot and other relevant metadata, indicating the scan occurred while the website was fully operational and actively distributed. The previous screenshot gives us a clear view of how the phishing page was visually structured.
Furthermore, diving into the "Details" tab reveals other interesting technical artifacts from the campaign. These details are incredibly useful for pivoting and identifying new malicious URLs that share similar characteristics.
Among the wealth of information generated by URL Scanning 2.0, analysts will find HTTP transactions, detected JavaScript variables, console messages, external outbound links, and other critical metadata. These key technical markers serve as pivotable and searchable attributes, allowing teams to conduct advanced footprint hunting and instantly find other malicious URLs exhibiting the exact same technical fingerprint.
Furthermore, every snapshot taken during each analysis provides the complete Document Object Model (DOM) tree captured by the full browser instances. It allows you to inspect the exact structure of the page as it was dynamically rendered to the victim, exposing elements that static scans might miss. As can be seen in the following image, having direct access to this point-in-time DOM data empowers analysts to dig deep into the page's architecture.
Advanced Threat Hunting: Scaling the Investigation
Let's scale our investigation using VirusTotal Intelligence queries based on the artifacts discovered via URL Scanning 2.0.
During the analysis of the financial phishing site, we discovered that the page relied on static assets hosted on a third-party domain: jiaoyisuo.thai2570[.]com. We can pivot on this finding using an advanced query:
VT Query
entity:url (outgoing_link:jiaoyisuo.thai2570.com OR content:jiaoyisuo.thai2570.com)
The results demonstrate a multi-brand operation, including fake cryptocurrency exchange portals and typosquatting domains for other financial services. By further pivoting on the hosting domain with entity:domain "thai2570.com", analysts can map out a highly segmented subdomain tree used for hosting assets, capturing payments, and backend control panels.
Conclusion
URL Scanning 2.0 represents a paradigm shift in how security analysts investigate web-based threats. Investigations are no longer limited to static verdicts. By surfacing powerful metadata directly inside the workflow—such as historical DOM captures, live screenshots, and pivotable technical identifiers—analysts can now turn a single indicator into a comprehensive infrastructure map.
Log in to VirusTotal to explore the new URL Scanning 2.0 features today, and consider upgrading to VirusTotal Premium to unlock the full power of historical pivoting and advanced threat hunting.
Customers have access to models that are continuously getting better with each new generation bringing larger context windows, stronger reasoning, and lower token costs. Getting the strongest AI-powered security will come from tools that combine the most relevant models with deep knowledge of a customer’s specific environment.
AWS Continuum for code vulnerabilities (Preview) is built to be that tool to help secure your code at machine speed. Today, we’re announcing our work with Anthropic and OpenAI that extends AWS Continuum directly into the developer workflows where code is being written: Anthropic Claude Code, OpenAI Codex, and Kiro. Developers can use these integrations to discover vulnerabilities, contextually prioritize, validate, and remediate, within their existing workflows.
Models are getting smarter
AI models are advancing rapidly. Each generation brings new capabilities, and different models excel at different tasks. The latest frontier models can now identify vulnerabilities and reason through multi-step attack paths that would take a human security team weeks to trace manually.
This is a genuine breakthrough in detection, but it creates a new challenge for your security teams: more findings, more complexity, and the need to determine which ones matter most in your environment and how to address them. The next challenge customers face is building the correct harness and orchestration to turn these models into a single interface that goes from detection through remediation. This is what we set out to do when creating Continuum, which brings together many different models and uses the model that’s most effective for each part of the process.
We also partner with the Frontier Model Forum, an industry consortium developing shared safety standards, evaluation methods, and benchmarking to ensure we can evaluate these models effectively together. We’re also working with model providers on shared security performance benchmarking to make sure we’re using the best model for each task within Continuum and our other AWS security products.
The harness
An AI harness is the orchestration layer that wraps around a model to connect it to tools, guardrails, memory, and workflows, so it delivers outcomes. Think of the model as the engine and the harness as everything around it. You need both to have a high-performance car.
Harnesses are becoming increasingly complex. Teams are stitching together multiple models, agents that call agents, and dynamic workflows, and are dealing with constant change driven by innovations in models, agent frameworks, and tool integrations.
As a result of that complexity, customers are implementing shadow infrastructure to manage integration layers across models and tools. Every time the landscape shifts, security and governance controls potentially break, forcing teams to go back to revisit them and make updates.
These challenges extend beyond the model. They arise in the orchestration required to connect different models and developer environments with tools, context, controls, and workflows across a customer’s environment. At AWS, we see managing that complexity as heavy lifting that AWS should solve. We treat the harness as infrastructure and with the same rigor we apply to identity, discovery, policy enforcement, observability, and compliance of the core infrastructure at AWS.
Enter Continuum
AWS Continuum for code vulnerabilities discovers vulnerabilities, prioritizes them within the context of a customer’s business, validates them in a sandbox, and provides remediation at machine speed. Under the hood, Continuum is an agent-team loop architecture. A sophisticated harness that orchestrates all of it: selecting the right model, connecting to a customer environment, and delivering secure code that’s been validated in context. You never need to think about how the orchestration works, or what changed in the latest release.
Anthropic and OpenAI collaborations
We are working with Anthropic and OpenAI to bring Continuum into the developer workflows where code is being written.
How it will work:
Within Claude Code, Codex, and Kiro coding environments, on-demand vulnerability scans identify potential issues and send findings to Continuum. Continuum prioritizes them within the context of the customer’s AWS environment (configurations, AWS Identity and Access Management (IAM) policies, network topology, and exposure surfaces) and validates them in a sandbox. It then returns prioritized, contextual intelligence back to the coding assistant, which adjusts its recommendations accordingly.
This collapses what was traditionally a multi-step, multi-team process (write, scan, triage, prioritize, fix, rescan) into a single outcome: the code suggestion itself. Two modes, one outcome:
For existing code: Use Continuum for code vulnerabilities from AWS to discover, prioritize, validate, and remediate across your environment.
For greenfield code: Use the Continuum plugin within Codex, Claude Code, or Kiro to get security-validated suggestions in your development environment.
Early design partners are already seeing results.
“AWS Continuum connects source code with enterprise knowledge, allowing teams to accurately pinpoint security vulnerabilities and verify that flagged issues are truly meaningful. This shortens what really matters: timeline to fix serious vulnerabilities.” – Mike Johnson, CISO, Rivian
Next
AWS Continuum for code vulnerabilities is available in preview through AWS. Sign up to request access at AWS Continuum.
Continuum integrated into Claude Code, Codex, and Kiro workflows are coming soon.
If you have feedback about this post, submit comments in the Comments section below.
OpenAI has revealed Astra, an unreleased model designed to tackle complex, long-running tasks, after an internal version produced ten significant advances in mathematics and theoretical computer science. [...]
OpenAI says it has reduced the price of two GPT-5.6 models, cutting Luna's API price by 80% and Terra's by 20% as it works to make its models more efficient. [...]
A Chinese-speaking threat actor is using the DeepSeek AI model and the open-source Hermes Agent to conduct autonomous cyberattacks on exposed servers with limited human involvement. [...]
Noteworthy stories that might have slipped under the radar: parcel delivery company OnTrac hacked, Adobe patches, UK Department for Education loses 607,000 records.
When the AI Act comes into force, AI companies will be required to make clear to consumers with labels or digital watermarks that chatbots or imagery are generated with AI.
What OpenAI’s and Anthropic’s testing incidents really teach defenders In the past two weeks, two of the world’s leading AI labs have disclosed the same unsettling result. During their own safety testing, their most capable models reached real companies’ systems. First OpenAI, whose models broke into Hugging Face. Then Anthropic, whose models reached three more organizations. Read the disclosures closely. Two facts carry the weight. First, the safeguards were not defeated. They were switched off by design. OpenAI ran the models with reduced cyber refusals and safety classifiers disabled, to measure raw capability on a cyber benchmark. A model doing […]
AI coding agents are part of the developer toolchain. Tools like Kiro and Claude Code generate features, tests, and code refactors from natural-language prompts. A single agent can open dozens of pull requests (PRs) across your repositories in an afternoon. That productivity comes with a trade-off: agents optimize for task completion at machine speed with no understanding of your organization’s risk.
Through protocols like the Model Context Protocol (MCP), agents also reach beyond the integrated development environment (IDE) to call APIs, query databases, and modify infrastructure and even entire environments, expanding the scope of resources your application security team defends.
This post lays out an application security (AppSec) control framework for AI coding agents. Two pillars organize the framework: author-time controls shape what the agent produces in the IDE; build-time controls verify and gate what reaches production. Your existing secure software development lifecycle (SDLC) controls still apply and are critical to a defense-in-depth security strategy. The framework shows where to layer additional guardrails so AppSec scales with agent-driven development. The framework is tool-agnostic and cloud-agnostic. Throughout, we use AWS services—Kiro in the IDE and AWS CodePipeline in the build—as a running example that you can adapt to your own toolchain.
Risks
Each of the following risks includes a treatment summary. The control framework section later in this post provides implementation details. The risks are ordered by severity with the highest impact risks first.
R001. Prompt and context injection
Agents read untrusted content, such as issue descriptions, web pages, MCP responses, and README files in third-party packages. Text from outside parties can redirect the agent to disclose secrets, open unauthorized PRs, or invoke tools without user consent. This risk, known as prompt injection, is the top risk in the OWASP Top 10 for LLM Applications. Any agent that reads content from outside parties is exposed, with or without MCP, so connecting tools widens the scope of impact.
Treatment: Treat non-developer input as untrusted. A large language model (LLM) can’t reliably separate instructions from data in a single context window, so architect for it: keep the agent that orchestrates trusted actions separate from the one exposed to untrusted content and grant the exposed agent only read-only, least-privilege access. Require human approval for irreversible actions. Use version-control steering files to prevent silent tampering.
R002. Inadvertent data disclosure and overly permissive configurations
Agents optimize for getting work done. Left unchecked, the code they generate can default to wildcard identity and access management policies, open security groups, and unencrypted storage, or embed sensitive values in code rather than referencing a secrets manager. Most coding agents now include safety mechanisms that make these outcomes less likely, but they remain imperfect, so you still need controls to account for the possibility.
Treatment: Security requirements in a steering document, plus policy-as-code scanning (Checkov, cfn-nag) in the IDE and pipeline. See Context as a security control.
R003. Uncontrolled changes reaching production
Ungated code reaching production isn’t new, but AI agents amplify it. Machine-speed generation can propagate a flawed pattern across repositories before it’s identified.
Treatment: Branch protection rules requiring PR approval (a human-in-the-loop checkpoint), pre-commit hooks for security checks, and sandboxed agent runs that prevent direct pushes to protected branches. The right balance between human review and automated speed depends on the risk profile of the change. For many low-risk paths, automated checks alone might suffice, while higher-risk changes warrant a human checkpoint.
R004. Supply chain risks
Agents don’t always distinguish current best practices from outdated patterns. They might recommend deprecated packages, reference library versions with new Common Vulnerabilities and Exposures (CVEs), and hallucinate package names that don’t exist, which can introduce risks of dependency confusion issues.
Treatment: Software Composition Analysis (SCA) in the pipeline (for example, Amazon Inspector code scanning or Dependabot) to flag vulnerable or unexpected dependencies. For additional control, resolve against a scoped registry like AWS CodeArtifact. Even without a fully curated registry, lockfile validation and allow-listing critical packages reduce exposure.
R005. Uncontrolled external access
Through MCP and tool integrations, agents query databases, call APIs, and modify infrastructure. Without constraints on which tools and data an agent can reach, a single misconfigured integration provides unintended access to sensitive resources.
Treatment: Scope MCP servers to least-privilege tools and resources, enforce authn or authz on external connections, and audit tool invocations. The control point is the configuration file. Review it the same way you review AWS Identity and Access Management (IAM) policies.
R006. Hallucinations and incorrect code
Agents produce plausible-looking output. Code that compiles, passes linting, and looks reasonable can still be functionally wrong: misusing APIs, introducing subtle logic errors, or implementing security-sensitive operations incorrectly. Code that passes continuous integration (CI) but is wrong slips through review; code that fails to build is caught immediately.
Treatment: Layer deterministic verification (static application security testing (SAST), unit tests) with non-deterministic review (LLM-assisted screening against the specification). Neither catches everything alone.
R007. Scope creep
Given a bug-fix prompt, an agent might also refactor surrounding code, disable an unreliable test, or reorganize imports. Unrequested changes introduce regressions and complicate review.
Treatment: A reviewed specification document that defines what must change and what must not, paired with a targeted review of the proposed changes. See Specifications as scope boundaries.
The preceding risks share a common thread: agents produce output faster than humans can review it, and they lack context to self-correct.
The following framework addresses this gap. It organizes controls into two pillars: author-time (pre-generation and post-generation of code) and build-time (in the pipeline, before code reaches production). Author-time controls shape what the agent produces. Build-time controls verify it. Neither is sufficient alone; together they reduce the volume and severity of issues that reach human reviewers.
Deterministic compared to non-deterministic mitigations
Deterministic mitigations[D] produce the same result every time. Linters, SAST scanners, secrets detection, and policy-as-code match patterns against rules and define security invariants: no critical findings, no hardcoded secrets, and no wildcard IAM policies. Use them when the condition can be expressed as a rule. Organizations already have these and must continue enforcing them.
Non-deterministic mitigations [ND] use model judgment. They include steering documents, LLM-as-judge review, specification compliance checks, and scope-creep detection, and they evaluate intent rather than patterns. They catch novel issues that rules miss, but are probabilistic. Use them when evaluation requires context or reasoning across files. This is the new layer that AI-generated code demands, because agents produce code that can pass every deterministic check yet remain functionally wrong.
Human review[H] provides the final layer for the risk-based decisions neither tool type can make. Apply it where judgment is needed, not everywhere: routing every change to a person invites consent fatigue, where reviewers approve by reflex and the control loses its value. The default reflex is to route everything back to a human, but that isn’t always the right response—reserve human judgment for the decisions that genuinely need it.
The control framework
The framework organizes controls into two pillars. Author-time controls (Pillar 1) shape what the agent produces in the IDE, before code is generated and just after. Build-time controls (Pillar 2) verify and gate that output in the pipeline, before it reaches production. The controls within each pillar are tagged deterministic [D], non-deterministic [ND], or human [H].
Pillar 1: Author-time controls (pre- and post-generation of code)
Author-time controls work inside the IDE, where the developer and agent still hold full context. They shape the prompt and the generated output before it ever reaches a pull request. The following controls apply at this stage.
Context as a security control [ND]
Control statement: Encode security invariants as natural-language constraints in a steering document that every developer environment consumes at session start. Addresses R002. Many AI coding agent risks share one root cause: the agent lacks the security context an experienced developer carries implicitly. Your security team sets the policies, such as Amazon Simple Storage Service (Amazon S3) buckets require encryption, API gateways require mutual TLS, and credentials must come from AWS Secrets Manager. Developers don’t always have these requirements available when they’re building. They build what works, not what’s compliant. An AI agent amplifies this gap because it defaults to whatever pattern dominated its training data, with no awareness of your organization’s security posture.
A key mitigation is steering. Security teams write these invariants once as natural-language guidance in a steering document, then distribute them as shareable resources that developers consume in their IDE. The agent loads the file at session start and treats the contents as standing requirements:
IAM policies must follow least-privilege principles; no wildcard Amazon Resource Names (ARNs).
No hardcoded credentials in source code; use a secrets manager.
Security groups must not allow unrestricted inbound access.
This shifts security left, before code generation begins. Steering biases generation toward secure defaults; it doesn’t guarantee them. Treat it as a strong default, paired with the following deterministic gates that block non-compliant code from merging. Security teams define the rules once and every developer environment inherits them automatically. Steering reduces the volume of issues that reach the pipeline, though it doesn’t replace downstream scanning.
How to write effective steering rules: Keep each rule specific and testable, scope it to a concrete risk class, keep the rule set concise so the agent can hold it in context, and iterate from the issues your scanners and reviewers surface.
Specifications as scope boundaries [ND]
Control statement: Require a reviewed specification before code generation begins. Define what must change and what must not. Addresses R007.
Spec-driven workflows turn vague prompts into reviewable specifications before code is generated. This creates a human checkpoint at the design phase, where security decisions are made:
Requirements use testable notation that’s auditable before the agent writes a line of code. For example, the Easy Approach to Requirements Syntax (EARS): WHEN [condition] THE SYSTEM SHALL [behavior].
Tasks are ordered in implementation steps, each mapped back to a requirement.
For bug fixes, specifications add a critical element: unchanged behavior documentation. This is an explicit list of behaviors that must continue working, giving the agent a written boundary against scope creep.
In this model, the specification becomes the primary artifact, code is a derivative of it. Human review effort concentrates on whether the specification solves the right problem with the right constraints, not on reading implementation diffs line by line.
Controlled tool access using MCP [D + ND]
Control statement: Scope each MCP server to the minimum set of tools the agent needs, and give it a dedicated, scoped-down credential rather than the developer’s own. Maintain an allowlist of reviewed MCP servers. Addresses R005.
MCP servers act as controlled gateways between the agent, the external tools, and data:
Dependency management – An MCP server fronting your private package registry resolves dependencies against curated packages, not the public internet. This is a deterministic constraint on supply chain risk.
Infrastructure tooling – Visibility into current resource configurations prevents templates that conflict with existing infrastructure.
Scoped permissions – Each MCP server exposes a defined set of tools and resources. You choose exactly what the agent can access, supporting least-privilege at the integration layer. You supply that credential through the agent’s configuration (in Kiro, the env block of .kiro/settings/mcp.json). Avoid autoApprove: ["*"], which removes the human approval prompt on every tool call.
IDE code scanning [D]
Control statement: Run real-time static analysis in the IDE so security issues surface while the developer (and agent) still have full context. Addresses R002, R006.
Real-time diagnostics catch syntax errors, type mismatches, and configuration issues as the developer types. A malformed IAM policy is flagged before the agent builds further on it. Security-focused extensions (ESLint security plugins, Checkov, SAST) layer on top for immediate feedback while code is fresh in context.
Hooks: Automated guardrails at the point of action [D + ND]
Control statement: Attach deterministic checks to file-save events and non-deterministic verification to task-completion events. Addresses R002, R007.
Shell command hooks [D] – Triggered on file save, these run a linter, formatter, or security scanner and produce the same result every time. They enforce hard rules.
AI-powered hooks [ND] – Triggered on task completion. These prompt the agent to verify that the implementation matches the specification and check for any untested edge cases or files that were modified outside the task’s scope.
Pillar 2: Build-time controls (in the pipeline)
Build-time controls run in the pipeline after code is committed and before it reaches production. They verify and gate what the agent produced, catching what author-time controls did not. The following controls apply at this stage.
Layered security scanning [D]
Control statement: Run secrets detection, static analysis, dependency scanning, and infrastructure-as-code scanning in sequence. Fail the build on any critical finding. Addresses R002, R003, R004.
Secrets detection runs first because it’s cheapest and addresses a high-severity class of issue. It scans for hardcoded API keys, database connection strings, and credentials that AI agents might inadvertently include.
SAST scans source code for injection issues, insecure deserialization, and resource leaks. Custom rules can target AI-specific anti-patterns including overly broad exception handling, deprecated APIs, placeholder credentials, dynamic code execution through eval().
Software Composition Analysis (SCA) identifies known CVEs in dependencies. This is critical for AI-generated code, which might reference deprecated packages or hallucinate package names that open you to dependency confusion issues.
Infrastructure as code (IaC) scanning validates AWS CloudFormation, Terraform, and AWS Cloud Development Kit (AWS CDK) templates against security policies before deployment. Catches overly permissive IAM roles, unencrypted storage, and public-facing resources the agent created.
Each stage halts the pipeline on failure. Results export to a standard format (Static Analysis Results Interchange Format (SARIF)) for compliance auditing and flow downstream to human reviewers. The open source Automated Security Helper (ASH) bundles secrets, SAST, SCA, and IaC scanners behind one command that you can run locally and in AWS CodeBuild, emitting SARIF for the gates that follow.
Quality gates [D]
Control statement: Define pass/fail thresholds for each scan type. Block deployment on any critical or high-severity finding. Addresses R003.
Quality gates convert scan results into go/no-go decisions. Define thresholds for each severity: block on critical findings, require justification for highs, and track mediums. The gate is deterministic: if a threshold is breached, the pipeline stops. Exceptions require documented approval.
Differentiate blocking compared to advisory modes: hard failures on main, advisory on feature branches. Avoid gates becoming a friction that teams route around.
AI-assisted review [ND]
Control statement: Use an LLM reviewer to pre-screen every pull request for specification compliance, scope creep, and security anti-patterns before human review. Addresses R001, R006, R007.
Specification compliance – Does the implementation match the requirements document?
Scope verification – Were files modified outside the task’s stated scope?
Security pattern review – Are there logic errors, misused APIs, or insecure patterns that pass SAST but violate intent?
This pre-screening focuses human reviewer attention on genuine risks rather than formatting or obvious issues. On AWS, AWS Security Agent (code review in preview at publication) checks pull requests against AWS-managed and custom security requirements. The reviewer screens and surfaces findings; the merge decision stays with a human.
A critical principle: the agent that wrote the code should not be the agent that reviews it. A separate session helps avoid self-confirmation bias, but a separate session alone doesn’t always avoid the generator’s blind spots, because two sessions of the same model can share them. Where practical, use a different model for review so the reviewer is less likely to inherit the same systematic weaknesses.
Human-in-the-loop review [ND + H]
Control statement: Require human approval on most pull requests, especially those touching security-sensitive or high-blast-radius code. Lower-risk changes might be eligible for agent-assisted or fully automated approval as tooling matures. Provide reviewers with scan results, LLM pre-screening output, and specification context to enable fast, informed decisions. Addresses R003.
Scale review depth to the risk of the change. Low-risk or boilerplate changes can take a lighter-touch review, while security-sensitive or novel-logic changes warrant mandatory deep review and a second reviewer.
Scanners catch known patterns but can’t judge whether code implements the intended business logic. Human review also serves to calibrate trust: teams build intuition about where agents excel (boilerplate, test writing) and where they’ve tended to struggle (novel business logic, security-sensitive operations), recognizing that this frontier shifts as models improve.
Place two approval gates: after security scans (reviewer focuses on correctness and business logic, with scan results as context) and before production deployment (final sign-off after integration testing). Treat human review as a secondary control, not a guarantee: reviewers are themselves non-deterministic and can miss issues, so human review layers on top of the deterministic gates rather than replacing them.
Putting the framework into practice on AWS
The framework is tool-agnostic, but AWS gives you building blocks for each pillar. The following services map directly to the controls described previously: Kiro for author-time guardrails, and CodeBuild and CodePipeline for build-time gates.
Kiro: Structured AI development
Kiro maps to Pillar 1: It puts the author-time controls in the IDE, where the developer and agent still share full context. Each feature in the following list implements one of those controls, configured in-repo under .kiro/ so the guardrails are version-controlled and shared across the team rather than set per developer.
Steering documents – Markdown files in .kiro/steering/ load into the agent’s context at session start. Conditional inclusion using fileMatch (for example, ["**/*.tf"]) loads IaC-specific rules only when relevant.
Specification-driven workflows – Three-phase specifications (requirements in EARS, design, and tasks) with review checkpoints. Bug-fix specifications capture unchanged behavior explicitly.
Agent hooks – Triggered on file save, tool invocation, or task completion. Shell hooks run deterministic checks (linters, tests); Ask Kiro hooks run AI prompts for non-deterministic review. For example, a security pre-commit scanner hook can flag hardcoded credentials when the agent finishes a task.
Property-based testing – Guided by a specification or hook, Kiro can generate property-based tests (for example, using the hypothesis library) that exercise hundreds of randomized inputs, probing edge cases a hand-written test suite would miss.
MCP integrations – Connect Kiro to private package registries, internal docs, issue trackers, and infrastructure tooling, creating the controlled tool access pattern.
AWS CodeBuild and AWS CodePipeline: Pipeline controls
CodeBuild runs each scanning tool (checking for secrets, SAST, SCA, and IaC) as a build action. A non-zero exit code fails the action, and the stage halts or rolls back according to its OnFailure setting. Findings export as SARIF to Amazon S3 for compliance, and CodePipeline action variables pass results to downstream approval actions.
CodeBuild exit codes halt the pipeline on scan failures
AWS Lambda invoke actions evaluate scan results against configurable thresholds and return pass/fail decisions
Manual approval actions halt the pipeline, send Amazon Simple Notification Service (Amazon SNS) notifications, and link to review artifacts; decisions and reviewer identity are logged for audit
The following table consolidates the framework into a single view that includes each stage of the SDLC and the deterministic [D] and non-deterministic [ND] controls that apply there. Every stage carries both, a reminder that neither control type is sufficient on its own.
Full security scan suite, integration tests, and policy-as-code
AI-assisted review for human approvers
Post-deploy
Runtime monitoring and anomaly detection
AI-powered incident triage
Conclusion
This post laid out a framework for adopting AI coding agents at machine speed without letting unreviewed risk reach production. It layers guardrails at two points:
Author-time controls – Steering, specs, and scoped tools shape what the agent generates in the IDE.
Build-time controls – Scanning, quality gates, and layered review verify it before it reaches production.
No single layer is enough: deterministic gates enforce hard rules, non-deterministic review catches what they miss, and human judgment is reserved for the decisions that need it. Together, they let AppSec scale with agent-driven development.
Where to start this week:
Start with steering and specs – Encode security requirements as steering and use specifications for new features. Highest impact, lowest effort. For a ready-made starting set, the open source Project CodeGuard (a Coalition for Secure AI project under OASIS Open, of which Amazon is a contributing member) publishes reusable steering rules for common risk classes—hardcoded credentials, IaC misconfiguration, supply chain, and MCP security—that you can adapt to your AWS environment.
Add deterministic pipeline gates – Integrate SAST, SCA, and secrets detection. Table-stakes regardless of AI usage.
Calibrate and iterate – Review what controls catch, adjust steering for recurring issues, and expand agent autonomy as trust builds.
Accountability – Developers remain accountable for the security of what they ship. AI agents accelerate development; they don’t transfer ownership.
For years, the cybersecurity industry's understanding of software supply chain compromise has been anchored by a few watershed events, including Russian cyber espionage actor ICE RELIC’s (formerly known as APT29) 2020 compromise of SolarWinds and North Korean cyber espionage actor UNC4736's 2023 compromise of 3CX. However, Google Threat Intelligence Group (GTIG) has been tracking growth in threat activity targeting open source software repositories to conduct supply chain compromises over the past several years. A series of large scale open source software supply chain compromise campaigns in 2025 and the first half of 2026 underscore how important it is that organizations implement defensive strategies that directly address this threat vector.
In this blog post, GTIG and Mandiant discuss trends we have observed in threat actor use of software supply chain compromise, and provide mitigation and hardening recommendations that incorporate insights we have developed as a result of supporting customers through recent campaigns in which threat actors manipulated open source packages.
Open Source Supply Chain Compromise Grows in Volume and Impact in 2025 and Early 2026
The majority of the most impactful and far-reaching supply chain compromise incidents that GTIG tracked in 2025 and early 2026 involved the compromise of code repositories, software dependencies and developer tools (T1195.001). Open source supply chain compromises offer attackers the same efficiency, scale, and initial stealth as traditional supply chain compromises, but typically require significantly less planning and resources to execute. However, open source supply chain compromises are also noisy once enabled; malicious open source packages are often discovered and publicized much more quickly than traditional supply chain compromises.
GTIG assesses with high confidence that the growth in very large-scale, open-source supply chain compromise campaigns, including use of worms and iterative compromises in 2025 and early 2026, represent a significant expansion in use of this tactic compared to prior years. We anticipate that threat actors will emulate the tactics of these campaigns and contribute to growth in open-source supply chain compromise through the rest of 2026 and years to come. GTIG identified several notable supply chain compromises in 2025 and early 2026 that we believe exemplify this trend of exceptionally large campaigns, as measured by size and/or impact (Figure 1).
Figure 1: Notable open source supply chain compromises, 2025 - early 2026
For example from February to May 2026, UNC6780 (aka "TeamPCP") conducted extensive open source supply chain compromises targeting ecosystems like PyPI, npm, and Docker Hub. Initial infection vectors varied across incidents, and included abuse of the pull_request_target GitHub Actions trigger to obtain base repository secrets and write permissions. The threat actor typically used compromised packages to deploy credential stealers, including SANDCLOCK, to obtain high value secrets. In incident response engagements, we observed UNC6780 attempting to pivot from compromised artificial intelligence (AI) software to broader network environments. UNC6780 has monetized stolen credentials through either direct sale of the stolen data, or through partnerships with ransomware and data theft extortion groups.
In March 2026, GTIG observed the introduction of a malicious dependency in the legitimate axios package. GTIG analysis and the maintainer's post mortem indicate that the maintainer account was compromised via social engineering and used to publish the updated versions. We identified the malicious dependency as a dropper that deploys the WAVESHAPER.V2 backdoor, and attributes the activity to North Korean actor MIDNIGHT NEPTUNE (formerly known as UNC1069). While the malicious versions of axios were removed from the npm registry within three hours of their release, the scope of the compromise is estimated to be broad, as the package has over 100 million weekly downloads. GTIG supported customers in at least 15 industry verticals and 13 different countries affected by this incident. Further, axios is also a dependency for tens of thousands of other packages, and open sources reported that the malicious axios update had spread to several of these.
AI Likely to Accelerate Open Source Supply Chain Compromises
GTIG anticipates AI will accelerate the growth of open source software supply chain compromise. Integration of AI into open source software development practices, including "vibe coding," increases attacker opportunities both to manipulate AI functionalities and to take advantage of AI to speed and scale their own operational planning. Open sources have documented multipleinstances of threat actors planting malicious resources on open source AI communities and inserting malicious code into open source Model Context Protocol (MCP) packages. MCP is a standardized protocol for AI to interact with tools and data. Malicious packages have also tricked AI coding agents, which have unwittingly incorporated them into projects. North Korean threat actors reportedly uploaded malicious cryptocurrency-themed packages, and subsequently an AI coding agent co-authored a commit integrating one of the malicious packages as a dependency to a legitimate cryptocurrency trading project.
Thousands of Malicious Open Source Packages Detected
Corroborating GTIG's findings, statistics compiled by the Open Source Security Foundation (OpenSSF), a cross-industry, non-profit collaboration under the Linux Foundation, indicate that the number of malicious open source software packages identified increased exponentially, or 1,444% from 2024 to 2025 (Figure 2).
Figure 2: Count of malicious open source packages reported 2022–2025 (source: OpenSSF)
Traditional Supply Chain Compromise Remains Rare
In contrast to what we observed in the open source ecosystem, GTIG assesses with high confidence that traditional software supply chain compromise, the manipulation of source code or update/distribution mechanisms (T1195.002), remains rare. The handful of identified cases in 2025 and early 2026 were predominantly cyber espionage incidents with intentionally limited targeting scopes.
In the most significant case, North Korean threat actor UNC4899 reportedly used social engineering to compromise a developer's machine at a web3 organization. The threat actor used this access to inject malicious code into the frontend systems, specifically impacting smart contract functionality to alter transactions initiated by a third party organization that utilized the multi-signature wallet with the targeted organization. This compromise was tailored to a single victim, but did not directly touch the targeted organization's infrastructure. The compromise ultimately led to a cryptocurrency theft of assets with an estimated value of $1.4B USD.
Other examples include the compromise of hosting infrastructure serving updates of Notepad++ from June to December 2025, activity GTIG attributes to UNC6688. GTIG observed organizations in South Korea and France affected by this activity. GTIG also tracked the early 2026 compromise of DAEMON Tools installers. During this campaign, UNC6863 deployed SLICKDEMON to perform broad-spectrum reconnaissance and filter for targets of strategic interest. Following this profiling stage, the group selectively delivered the shellcoded loader BADFALL to facilitate hands-on-keyboard activity and bridge the deployment of the advanced QUIC RAT. The campaign targeted Russia, Brazil, and Turkey, with follow-on exploitation of government and scientific entities in Belarus and Thailand.
In addition to likely cyber espionage incidents, we observed suspected financially motivated compromises with broader distribution. In two separate incidents threat actors compromised underlying software used in consumer-facing websites: in one case, automotive dealership websites served ClickFix lures leading to the installation of SHADOWLADDER (aka SectopRAT), and in another, eCommerce websites were infected with web skimmers.
Mitigation Recommendations
To effectively mitigate and harden against software supply chain compromises, organizations should adopt a multi-tiered defensive strategy designed to minimize exposure and strengthen resilience against potential compromises.
Administrative Oversight and Risk Governance
Cataloging Assets and Dependencies: Maintain a tiered, continuous inventory of all applications, third-party vendors, and services based on operational importance to detect single points of failure and security risks.
Software Bill of Materials (SBOM): Implement an automated SBOM for all internal and third-party software packages, allowing security teams to continuously monitor and cross-reference active code inventories against newly disclosed vulnerabilities.
Action Bill of Materials (ABOM): Maintain a dedicated ABOM to inventory every third-party pipeline vendor and development utility in use, linking it to your container image inventory to track exactly which external actions are building your production images.
Software Development Lifecycle (SDLC) Threat Modeling and Attack Chain Mapping (Wiz SITF): Align your software supply chain risk management with capabilities such as the Wiz SDLC Infrastructure Threat Framework (SITF) to transition from treating security as a checklist of isolated controls to a holistic threat model. With this freely available framework, organizations can map recent incidents, threat actor campaigns, and red team exercises directly to Wiz SITF Reference IDs indexing each risk to its specific lifecycle stage: Version Control Systems (VCS), continuous integration and continuous delivery (CI/CD) pipelines, package registries, or production infrastructure. This methodology allows security teams to model complex "attack chains" where minor, isolated weaknesses (e.g., a lockfile bypass combined with an overprivileged pipeline token) are chained together by sophisticated threat actors to execute critical, high-impact breaches
Active Risk Monitoring: Maintain a dedicated supply chain risk register and a centralized remediation tracker to systematically group development lifecycle (SDLC) threats into clear operational domains: Governance, Identity, Pipeline Logic, and Supply Chain Hygiene. If using Wiz SITF, each vulnerability must be mapped to its exact pipeline stage with a unique Wiz SITF Reference ID. Instead of treating vulnerabilities as isolated bugs, prioritize the blocking of complex "attack chains" (such as a leaked token combined with missing branch protections and overprivileged OIDC trust) that pose the highest breach risk. Ensure each logged item has a designated owner, a targeted completion date, and clear tracking of technical dependencies.
Standardized Configuration & Change Control: Form a Change Advisory Board (CAB) to manage the rollout of all enterprise software and hardware. Ensure every modification includes a pre-deployment risk review, post-deployment monitoring, and a verified plan for recovery or backout.
Staff Security Education: Deploy ongoing training initiatives centered on supply chain hazards, social engineering techniques, and internal procedures for reporting incidents.
Node.js (npm/pnpm): Enforce cooldown controls by using the minimumReleaseAge configuration. Setting this value to at least 24 hours (1440 minutes) ensures that freshly published, potentially poisoned packages are quarantined until the broader security community has had time to identify and remove them. Ensure that older, unsupported package manager versions (such as legacy Yarn or pnpm versions) are modernized, as they will silently ignore these cooldown boundaries.
Python (pip): Ensure that Python project environments do not pull dependencies directly from the public PyPI registry, which bypasses internal release-age policies and gating controls. All configurations must specify a secure, vetted private --index-url in their configuration files to ensure consistent quarantine and vetting of upstream packages.
Vendor Lifecycle Management
Vendor Security Vetting: Conduct rigorous due diligence prior to procurement by assessing third-party security frameworks against industry standards such as ISO 27001 or SOC 2.
Cybersecurity Provisions in Contracts: Integrate specific security mandates into vendor agreements, including strict timelines for incident notification, persistent audit rights, and clear liability terms.
Hardware Provenance and Verification: Use supply chain tracing to confirm the integrity of components, establish methods for detecting counterfeit items, and secure the logistics of repairs and replacements.
Security Architecture and Engineering Controls
Identity and Access Management
Automated System and Workload Identities: Transition third-party integrations and build-system processes away from static, long-lived administrative Personal Access Tokens (PATs). Instead, mandate the use of dedicated GitHub Apps or short-lived system tokens via federated OpenID Connect (OIDC) for automated machine integrations. This ensures that credentials used by system-to-system workflows expire in a matter of minutes, neutralizing the risk of a persistent compromise if an automation pipeline is breached.
Developer and User Identity Controls (command-line interface (CLI) and Repository Access): Enforce strict access control boundaries for programmatic developer sessions. Because Okta-linked SAML SSO is only capable of verifying identity during the initial creation or authorization of personal tokens and keys, continuous session state cannot be challenged over programmatic CLI connections. Therefore, session security must be enforced through credential expiration and hardware-backed controls.
Enforce Strict Token Expiration: Strictly limit the allowable lifespan of all personal access tokens (PATs) and programmatic application programming interface (API) keys to a minimum threshold (e.g.a maximum 7-day limit). This guarantees that credentials expire regularly, forcing developers to re-authenticate through the primary SSO gateway.
Consider Restricting Personal Access Tokens to Neutralize Git-over-HTTPS & Mandate FIDO2 Secure Shell (SSH): To protect developer environments against credential theft, organizations should consider restricting Personal Access Tokens (PATs) globally across GitHub Enterprise Cloud. Because GHEC has no direct protocol-disable switch, administrators should consider disabling classic PATs and enforcing short token lifespans to effectively block unauthorized programmatic HTTPS connections. This protocol containment helps encourage developers to shift entirely to SSH authentication. To secure this transport layer, consider mandating the use of hardware-backed FIDO2 security keys to cryptographically verify physical token possession for all command-line repository actions.
Isolated CI/CD Execution: Utilize ephemeral runners for build pipelines that are purged immediately after completing a single task. This prevents malicious actors from maintaining a persistent presence between different build phases.
Workflow Trigger Governance (pull_request_target): Strictly limit and secure the use of highly privileged triggers such as pull_request_target in automated environments. Multiple prominent supply chain campaigns have actively exploited vulnerable workflows using this trigger as their initial entry vector.
Infrastructure Protection
Zero Trust and Least Privilege: Maintain rigorous control over managed service providers (MSPs) and third-party vendors by enforcing role-based access control (RBAC), multifactor authentication (MFA), and frequent audits of access rights.
Network Micro-Segmentation: Segregate vital hardware and software from the rest of the enterprise network. Use allow-list-only firewall rules to block unauthorized outbound traffic and disrupt command-and-control (C2) activities.
Secure Development Ecosystems
Pipeline and Sandbox Isolation: Ensure that testing environments, CI/CD pipelines, and informal scripting sandboxes are physically or logically isolated from production assets.
Artifact Management: To secure the supply chain, organizations can integrate Google's Assured Open Source Software into their internal workflows to defend against dependency confusion and malicious hijacking. This process provides "provenance" cryptographically signed evidence that the code has not been tampered with and originates from a verified source thereby establishing a higher level of trust for third-party dependencies.
Quarantine Gates: Require all binaries, packages, and container images to be hosted in monitored internal repositories. To defend against zero-day dependency hijackings, implement localized "quarantine gates" by enforcing cooling windows on newly published third-party assets.
Lifecycle Script Sandboxing (ignore-scripts): Mitigate the critical threat of arbitrary code execution by disabling the automatic running of package install scripts. Attackers commonly hijack dependencies and add malicious post-installation execution scripts to steal credentials from developer environments and runners during routine installs. Organizations should mandate ignore-scripts=true in their repository-level .npmrc files and configure native allowlists, such as pnpm's onlyBuiltDependencies, to restrict execution exclusively to verified, essential tools.
Software Composition Analysis (SCA) with Google OSV-Scanner: Integrate Google's open source OSV-Scanner tool into CI/CD build pipelines to continuously scan project dependencies for known security flaws. This tool provides an officially supported frontend to the OSV.dev database that maps a project's list of dependencies with the specific vulnerabilities affecting them.
High-Fidelity Vulnerability Detection: Unlike traditional scanners that rely on imprecise name matching, the OSV schema stores vulnerability data in a machine-readable format that maps unambiguously onto version ranges and commit hashes. This results in fewer false positives and produces highly actionable remediation notifications, significantly reducing development team triage overhead.
Authoritative & Collaborative Threat Intel: The underlying OSV.dev database aggregates high-quality threat intelligence from authoritative open sources, allowing the broader developer community to suggest continuous improvements. Utilizing OSV-Scanner helps developers identify impactful third-party open source vulnerabilities in their applications and focus remediation on genuine risks.
Hardware-Backed Key Protection: Secure code-signing certificates using Hardware Security Modules (HSMs) or vaulting solutions. Monitor public transparency ledgers and logs to detect any unauthorized certificate activity.
Hardened Distribution Points: Audit and lock down software delivery channels, such as Content Delivery Network (CDN) endpoints and FTP servers, to ensure legitimate binaries cannot be replaced by compromised payloads.
Audit NPM Package Maintainer Accounts for Stale or Expired Recovery Email Domains: Expired maintainer email domains are a critical risk because attackers can purchase them to intercept password reset emails, take over the package registry account, and publish malicious code to downstream users. To identify vulnerable packages, organizations can perform the following:
Deploy automated scanning tools to audit the entire dependency tree and verify the domain name system (DNS) resolution and registration status of all maintainer email domains.
For defense-in-depth, pipelines must disable package execution scripts and employ cold periods.
Use by default ephemeral, single-use runners to prevent compromised packages from accessing persistent build environments.
Isolate runners in a restricted network segment with strict egress filtering blocks any unauthorized connection to external domains even if an active exploit is triggered.
Integration with Native Ecosystem Guardrails
These organization-controlled quarantine policies must operate in conjunction with native platform-level security updates to achieve a Defense-in-Depth posture. Relying solely on client-side configurations or automated update tools in isolation creates single points of failure. The following native platform controls must be orchestrated alongside standard controls:
Dependabot Native Cooldowns (July 2026): Dependabot now enforces a default three-day cooldown on version updates to allow for the public discovery of upstream compromises (such as the historical chalk and debug hijackings) before automated Pull Requests are generated].
PyPI Server-Side Immutability (July 2026)]: PyPI now natively rejects new file uploads to any release older than 14 days. This prevents adversaries possessing compromised tokens from retroactively poisoning legacy, pinned dependencies (as observed in the LiteLLM and Telnyx compromises) .
npm v12 Install-Time Defaults (July 2026): npm v12 disables all lifecycle scripts by default (allowScripts: off) , replacing manual, workflow-level ignore flags with explicit, commit-verified package allow-lists
By explicitly aligning baseline configurations including .npmrc and pip.conf registry pinning, immutable installation protocols via npm ci, and runner isolation with these native platform-level guardrails, while committing to the continuous evaluation and adoption of new upstream security features as they are released, the organization establishes a resilient, multi-layered security boundary across the entire software supply chain
Continuous Verification, Monitoring, and Response
Automated Ingestion and Validation
Automate SBOM Management: Implement a Software Bill of Materials (SBOM) for all third-party and internal software. This enables continuous monitoring for emerging vulnerabilities like Log4j through automated cross-referencing. Automate and scale this process by feeding SBOMs into central vulnerability management platforms that continuously cross-reference deployed inventory against newly disclosed exploits.
Security Analysis Integration: Incorporate automated dynamic application security testing (DAST) and static application security testing (SAST) tools within development pipelines to identify and block compromised third-party code before it is compiled.
Verification of Cryptographic Integrity: Prior to installing updates, use automated systems to validate digital signatures and hashes against vendor-provided specifications.
Implement autonomous security verification: Organizations should look to integrate advanced security workflows directly into their CI/CD pipelines. These systems can behaviorally evaluate threats by executing simulations in isolated sandboxes, cross-reference those flags with cloud context to determine a flaw's actual reach, and automatically generate tested code patches to rapidly remediate verified risks at scale.
Proactive Threat Hunting and Monitoring
Egress and Proxy Analysis: Establish network traffic baselines to identify suspicious egress flows to external repositories or unrecognized Internet Protocol (IP) addresses.
Comprehensive Endpoint Security: Utilize endpoint detection and response (EDR) tools across infrastructure and developer workstations to detect post-execution malicious activities from supply chain compromises.
Log Aggregation and Alerting: Unified log management should alert on the following anomalies:
Development Systems: Watch for unauthorized code changes, build parameter adjustments, or irregular user activity.
CI/CD Integrity: Alert on unauthorized workflow modifications or anomalous triggers (e.g., repository_dispatch) that bypass standard code-review gates.
Injection Detection: Monitor logs for shell-escape characters or command-substitution patterns within untrusted input variables.
Credential Misuse: Track authentication hits on long-lived static keys from unrecognized IP addresses or regions.
Physical Assets: Record all firmware modifications, including installation status and source information.
Incident Response Strategies
Specific Supply Chain Playbooks: Perform tabletop exercises and document response plans for:
Upstream Package Takeover: Maintainer account takeover (ATO) on public registries leading to direct runtime application code manipulation
Dependency Confusion Exploits: Malicious registration of lapsed administrative recovery domains or unscoped internal namespaces on public registries to hijack local developer and build runner installations.
Automated Pipeline Harvesting: Pipeline poisoning of CI/CD environments via runner exploitation to harvest credentials and perform unauthorized package publication.
Developer Workstation & IDE Compromise: Targeted social engineering, malicious IDE extensions, or typosquatted local dependencies designed to exfiltrate private cryptographic keys, API tokens, and local session credentials.
Operational Re-evaluation: Create processes for immediate vendor re-mapping and security re-assessment during industry-wide security events.
Recommendations for mitigation strategies are also available publicly via:
Your phone rings, you pick up and say hello. On the other end: total silence. No one answers, and the call abruptly disconnects. If you don’t already use spam call blockers, you’ve almost certainly run into this situation before.
In most cases, these are scam calls. Today, we explain why these calls happen, what the callers want from you, and how to protect yourself. Most importantly, we’ll look at whether you even need to bother protecting yourself against them in the first place.
Who’s calling?
It’s not just scammers on the line — robots, legitimate call center operators, and ordinary folks make these calls too. Let’s break down each type of caller — ordered from best-case to worst-case scenario for your security.
Actual person
The most harmless scenario is that an actual person called you, but their microphone is acting up. Maybe they accidentally muted themselves with their ear, or their smartphone connected to a Bluetooth headset, speaker, or car system that isn’t capturing their voice. Carrier glitches can also mute one side of a call. The caller might have no idea there’s a problem — as far as they know, they are speaking, but no one can hear them. In cases like this, you usually recognize the incoming phone number.
If the call comes from an unknown number, there’s still no need to panic — though the list of those who might be calling gets much longer.
One legitimate possibility is a call center agent who simply didn’t pick up or connect their headset in time. Call center systems are designed to dial numbers faster than agents can wrap up their calls. The system tried to route the call to a human, but no reps were available. That’s why you sometimes have to wait a few seconds before hearing a single word, or why you might hear ringing tones as if you were the one making the call.
Robot or AI
Silence on the line is a common sign of robocalls. Robots test whether a phone number is active and, if it is, pass it along to a human — meaning a real sales rep (or scammer) will call you back in the next few days. It’s worth noting that scammers aren’t the only ones making these pinging calls. Legitimate call centers use the exact same tools to reduce the workload on their live agents.
An AI agent could also be behind the silent call. To the person answering, there’s no practical difference: the call looks identical to one made by a standard bot. However, AI can do more than just auto-dial numbers — it can analyze your response and use that data to decide whether your number is active and ready to be handed off to a live person for follow-up.
Unwanted caller
Now we get to the real threat. Perhaps one of the most dangerous and unpleasant sources of silent phone calls is a scammer. A quick, silent call like this can actually be the groundwork for a long, elaborate attack with cover stories about loans, government agencies, other fraudsters, even law enforcement.
Debt collectors might also be calling and staying quiet. Your number could end up on their radar if you, your family, or close contacts have outstanding debts. In these cases, a silent call is often used as a tactic for psychological pressure.
A similar technique is used in stalking. While silent calls cause no direct harm on their own, they can be leveraged to induce anxiety, create a feeling of being constantly watched, and cause ongoing emotional distress.
Why do they call and stay silent?
When you pick up, you likely respond out of habit with a quick “Hello?” or “Hi there.” That’s all it takes for the other party to gather a wealth of data. While this information used to be difficult to process, the rise of artificial intelligence has made the task significantly easier. Let’s look at what someone can learn about you from just one spoken word:
Region, accent, and location. Scammers are sophisticated and cunning. Their tactics are often tailored by region — targeting residents of specific countries or even regions within them. This is especially relevant in places like India or South Africa, which have 22 and 11 official languages, respectively.
Approximate age and gender. While a human listener might easily confuse a teenager’s voice with a young woman’s or misjudge someone’s age entirely, AI is far better at picking up on subtle vocal nuances. Knowing your age and gender helps scammers refine their playbook for future social engineering attacks.
Times you’re available. If you answer the phone in the morning, afternoon, or late at night, attackers can schedule their follow-up call during the exact time window when you’re most likely to pick up.
Likelihood of a successful attack. AI can automatically assess the potential value of a target. For instance, if someone answers quickly, speaks calmly, and doesn’t immediately hang up on unknown numbers, they’ll likely be assigned a higher priority for follow-up calls by live scam operators.
Back to the “why do they call and stay silent”, the main reason is to harvest biometric data. Just a few seconds of recorded audio can help cybercriminals create a voice deepfake. While one or two words might not yield a convincing clone on their own, attackers can stitch together recordings from multiple silent calls to build a believable replica.
This technology is already being used in real-world scams. Impersonating a relative, colleague, or boss, fraudsters can urgently ask you to send them money, to share a two-factor authentication code for government services, or to complete some other seemingly innocuous request. The more realistic the deepfake sounds, the harder it is to spot the scam — especially when backed by a convincing backstory.
What to do if you get a silent call?
If you answer a call, say a few words, and hang up, there’s no need to panic. However, that brief interaction can confirm to attackers that your number is active and that you’ll answer calls from unknown numbers. As a result, your phone number could end up on target lists for future spam or scam campaigns. That said, it’s important to remember that a single silent call poses no immediate security threat.
Here are a few tips to help you stay calm and avoid falling for scam tactics if those silent calls are becoming a problem:
Don’t answer calls from unknown or hidden numbers. Here’s a helpful tip: if someone genuinely needs to reach you, they’ll find another way to do so, or keep calling from the exact same number at various times. Scammers almost always dial from different numbers, while automated bots operate on a rigid schedule — like calling every day at precisely 8:05 AM.
Don’t rush to call back. Scammers often count on proactive victims who are curious enough to return calls from unfamiliar numbers. On top of that, calling back could end up costing you money if it’s a premium-rate number.
Don’t speak first. Wait for the caller to greet you before starting a conversation. If you hear muffled noise or complete silence on the line, hang up and save yourself the hassle — it’s likely a scam.
Block unknown numbers — even after the call. If you picked up and realized the call could be risky, it’s best to block the number right away. You can use the built-in features on most modern smartphones to do this.
Don’t share your number everywhere. Phishing sites, fly-by-night web pages, and sketchy giveaways often exist solely to collect your personal data. When filling out forms online, it doesn’t hurt to use a burner or secondary number.
Get a second phone number. Separate your daily life between two numbers. Use your main line strictly for family, friends, and work contacts, and reserve the secondary line for deliveries, online marketplaces, and general web sign-ups.
Amazon is sharing new findings about how a threat actor linked to the Democratic People’s Republic of Korea (DPRK) is targeting open source software libraries, the shared building blocks that companies around the world use to develop applications. Amazon Threat Intelligence has linked several recent compromises of popular Node Package Manager (NPM) libraries to the same DPRK-linked threat actor, a connection that hasn’t been publicly reported until now. The analysis also describes how generative AI is already changing what malicious software packages look like and how threat actors are beginning to probe AI-based code systems. We’re sharing this research to help the open source community and security teams better identify and address these types of events.
These developments come 2 years after the XZ Utils backdoor, which demonstrated how a patient attacker can compromise critical open source software by exploiting the trust and limited time of volunteer maintainers. Open source software underpins much of the internet’s infrastructure: operating systems, web servers, encryption libraries, and the application frameworks that businesses rely on daily. When an attacker compromises a widely used open source package, every organization that depends on that package is potentially affected. Since then, Amazon Threat Intelligence has observed the volume and sophistication of software supply chain attacks increase, driven in large part by DPRK‑linked threat actors and cybercriminal groups.
In this post, Amazon Threat Intelligence and the Amazon Inspector team share new details about recent campaigns against popular NPM packages, including evidence that the compromises of the axios, debug, chalk, and typo-crypto libraries were carried out by the same DPRK-linked threat actor tracked by the security community as SAPPHIRE SLEET, STARDUST CHOLLIMA, BlueNoroff, CageyChameleon, and Alluring Pisces. We also outline how the techniques used to compromise open source repositories are evolving, why these changes matter for organizations that depend on open source software, and what Amazon Web Services (AWS) is doing to help customers detect and respond to these threats.
One DPRK–linked group behind multiple NPM compromises
In March 2025, the DPRK-linked threat actor compromised the typo-crypto package. In September 2025, the same threat actor compromised the debug and chalk NPM packages. In March 2026, the same operational playbook appeared in a compromise of the axios package, one of the most widely used JavaScript libraries with more than 100 million weekly downloads. In each case with debug, chalk, and axios, the threat actor gained access by socially engineering a trusted maintainer of the package, then published a software update containing malicious code. Any organization that automatically pulled the latest version of these packages received the compromised update.
While the axios compromise has been publicly attributed to this DPRK-linked threat actor, the typo-crypto, debug, and chalk incidents haven’t previously been connected to it. Amazon Threat Intelligence identified shared tactics, techniques, and procedures (TTPs) across these supply-chain campaigns, including trojanized NPM packages, use of post-install hooks (scripts that run automatically when a package is installed), and code reuse. Based on analysis of command-and-control (C2) indicators and TTPs, Amazon Threat Intelligence assesses with medium confidence that these campaigns are attributable to the DPRK-linked threat actor tracked as SAPPHIRE SLEET, STARDUST CHOLLIMA, BlueNoroff, CageyChameleon, and Alluring Pisces. This is the first time these compromises have been publicly tied to this DPRK-linked threat actor.
Amazon Threat Intelligence assesses this as part of a financially motivated pattern: by compromising a small number of highly popular packages, the group gains potential access to thousands of downstream environments simultaneously. For a financially motivated threat actor, this approach is far more efficient than targeting organizations one at a time.
The aggregate impact of these incidents underscores the efficiency of targeting share dependencies. As reported by Wiz Research, roughly 1 in 10 cloud environments were affected by the debug and chalk supply chain event within a two‑hour window.
A smaller campaign that foreshadowed later activity
During routine analysis of indicators and TTPs related to the axios threat actor, Amazon Threat Intelligence identified a connection to a domain registered in 2025, prompting a full investigation into its historical activity. That investigation uncovered that the same DPRK-linked threat actor had committed a trojanized file to the typo-crypto NPM package in March 2025. The malicious file, core.js, masquerades as the legitimate core-js NPM package within the typo-crypto repository.
Based on the limited number of observed downloads, Amazon Threat Intelligence assesses that this campaign was small scale and likely served as a testing ground for the more visible supply chain operations that followed in late 2025 and 2026. The group appears to have been refining supply chain techniques more than a year before the larger campaigns that drew public attention. Amazon Inspector reported this malware to the Open Source Vulnerabilities (OSV) database, where it’s now tracked as MAL‑2026‑3400, so that the broader security community can benefit from these findings.
The trojanized file executes when it receives a hash input beginning with the value 0098273. When triggered, it downloads a second-stage payload from a hardcoded C2 server, then executes the payload based on the victim’s operating system, with behavior tailored for Windows, macOS, or Linux. The malware implements file-based persistence with payload rotation and uses multi-layer obfuscation, combining base64‑encoded text with an XOR cipher keyed to 01042025.
Amazon Threat Intelligence assesses that the group was experimenting with techniques that later appeared in the higher-impact campaigns against axios, debug, and chalk. Although the observed download volume was low, the tradecraft aligns with what we later observed in attacks on more popular packages.
How attacker tradecraft is shifting
Over the past year, Amazon Threat Intelligence and Amazon Inspector have observed threat actors changing the techniques they use to target open source libraries. These changes matter because open source packages remain attractive targets: they’re widely trusted, automatically updated in many environments, and maintained by communities that welcome new contributors. The following patterns describe how attackers are adapting their methods to evade modern defenses. Each is designed to exploit the gap between the moment a dependency is inspected and the moment it actually executes. A year ago, we looked for malicious packages. Today, we look for malicious behaviors split across packages that appear harmless on their own.
From package‑level attacks to fragment‑level attacks
Amazon Inspector has observed attackers increasingly splitting a single malicious workflow across several ordinary-looking packages. One package stores an encrypted blob disguised as configuration. A second ships the decryption logic. A third, often published later, fetches and executes the payload.
Viewed on its own, each package looks benign. There are no install hooks that stand out, no obvious evaluation of untrusted input, no network calls that look suspicious. The malicious behavior only appears when the components are used together in the intended sequence. This approach is designed to defeat scanners that evaluate packages one by one instead of reasoning about how they interact in a real dependency graph.
Long-horizon campaigns that invest in trust
We’re also observing threat actors taking a long view of trust accumulation. Instead of publishing obvious malware and waiting for downloads, they publish something genuinely useful and maintain it. They behave like real maintainers for weeks or months, shipping features, fixing bugs, and gaining dependents.
The same patience shows up on the human side. In some cases, the goal isn’t to launch a new package at all, but to become a contributor to an existing project. That’s the through line from XZ Utils backdoor to the debug, chalk, and axios maintainer compromises. In each case, the adversary treated legitimacy as an asset to be spent once, at the moment of maximum access.
Decoupling the package from its behavior
In many recent cases, a library is clean on the public registry yet still dangerous, because its real behavior depends on resources the attacker controls elsewhere. These can include guard or license scripts fetched from an external repository at runtime, configuration files that gate certain behaviors, or remote endpoints consulted at startup.
As long as those external resources remain benign, code reviews pass and automated scans return clean results. When an attacker flips the content or arms an endpoint that previously returned a placeholder, every installed copy can become malicious at once, without any new package release. A package that shows no malicious behavior today isn’t the same as a package that’s is safe by design.
From basic obfuscation to real cryptography
Where attackers used to rely on simple obfuscation such as minification or single-layer base64 encoding, we now observe multi-stage payloads that use stronger cryptographic techniques. Examples include AES‑GCM encrypted blobs gated by passphrases, RC4-style string arrays with per-call keys, layered XOR over base64, and native loaders that hold the next stage as an encrypted field decrypted only in memory.
The common design choice is that the decryption key is never stored in the package itself. It’s derived from runtime context, fetched from a server at execution time, or supplied as a license key. That means even an analyst with full source access can’t reliably decrypt the payload statically. Stage one looks like a simple decryptor; the malicious content remains ciphertext until it runs on a real target with the real key.
Payloads that avoid detonating in sandboxes
As defenders have scaled automated analysis in cloud sandboxes, attackers have made their code more environment aware. The payload decides whether it’s being analyzed before it acts. We see execution gated behind real package install lifecycles, single-use environment variables, and checks for signals of a genuine developer or build environment. These include interactive terminals, realistic usernames and hostnames, domain membership, plausible uptime, local file history, specific operating systems, and cloud metadata that helps distinguish analysis infrastructure from normal workloads.
Some delivery servers also tailor what they serve based on the client. A benign decoy goes to generic browser-like requests, while the live payload only appears for the exact user agent used by the malware. The result is that a clean verdict from a cloud sandbox often tells you more about how convincing your environment looks than how safe the package is.
How generative AI is reshaping both attacks and defenses
Generative AI is changing what attackers can produce and what defenders can rely on. Adversaries can generate novel code and content at scale. Historically, many malicious packages were caught because they looked wrong, with broken language, thin documentation, obvious copy-paste, or a telltale function reused across samples. Generative AI erases many of those signals.
Attackers can now produce thousands of lines of coherent, idiomatic, well-commented code, complete with convincing documentation, plausible commit histories, and synthetic maintainer identities, wrapped around a backdoor. Because each variant can be mutated, renamed, restructured, and re-encrypted, there is no single stable signature to match. Pattern-based detection loses ground against malware that looks one of a kind in every deployment.
AI is also creating new initial access vectors. One emerging technique is slopsquatting, where attackers register package names that exist only because an AI coding assistant hallucinated them. When a developer or an autonomous coding agent asks for help and the model confidently recommends a nonexistent package, an attacker can pre-register that name and wait. The next person who follows the recommendation might receive malware, despite not mistyping anything or visiting a malicious site, because the AI effectively delivered the bad dependency for them. As organizations move toward agents that install dependencies with limited human review, this path looks less like a curiosity and more like a scalable delivery channel.
Most significantly, AI changes the calculus for defensive automation. Attackers are no longer just writing malware for humans to miss. They’re writing malware for AI reviewers to approve. As organizations rely on AI systems to review code and triage packages, those AI systems themselves become part of the attack surface. We expect that indirect prompt injection, a technique where hidden instructions manipulate an AI system into taking unintended actions, will increasingly be embedded in malicious packages to fool AI-based code scanners. These instructions can be hidden in source comments, README files, docstrings, or test fixtures, and crafted to convince an automated system to mark malicious code as safe, skip a specific file, or perform an unintended action during analysis. The same content the malware needs to function can carry a second, separate message aimed at the machine that inspects it.
How AWS is responding
We’re investing across Amazon Threat Intelligence and Amazon Inspector to help customers adapt to this shifting landscape of software supply chain risk. Amazon remains committed to helping protect the security of our customers and the internet by actively hunting for and mitigating threats from sophisticated threat actors. We will continue working with Amazon teams, industry partners, and the security community to share intelligence and mitigate threats. Upon discovering this campaign, Amazon Threat Intelligence worked with Amazon Inspector so the malicious package was tracked, mitigated, and shared with the community through the OSV database. Additionally, the observed indicators were shared with Amazon GuardDuty to alert our customers of this activity.
Amazon Inspector uses these insights to refine our detection logic, broaden coverage across registries, and prioritize signals that reflect the tradecraft shifts described in this post, and is collaborating with industry partners such as package registries and Open Source Security Foundation (OpenSSF) to share findings.
We’re also investing in helping open source maintainers better secure their projects. In 2026, AWS joined the Linux Foundation and other industry leaders to launch Akrites, a collaborative initiative to defend critical open source software against AI-enabled cyber threats. AWS has also jointly invested $12.5 million alongside other organizations to defend the open source ecosystem from AI-driven attacks. These efforts reflect a broader commitment: the security of open source software is a shared responsibility, and defending it requires sustained investment from the organizations that depend on it.
Our goal is to help customers understand where their environments rely on open source components, identify suspicious behavior early, and respond quickly when the software supply chain is used as an entry point.
August 11, 20206: This post was updated to clarify that the social engineering of a trusted maintainer applied to the debug, chalk, and axios compromises specifically. The underlying attribution and findings remain unchanged.
Most threat intelligence frameworks were built around clear, recognizable motives—advanced persistent threats seeking intelligence, financially motivated ransomware syndicates, or ideological extremists pursuing political or religious goals. However, security practitioners and physical security teams are facing a vastly different and highly volatile new vector on the threat landscape: Nihilistic Violent Extremism (NVE).
Operating across surface web platforms, niche gaming servers, and encrypted messaging channels, NVE actors seamlessly blend traditional cybercrime, physical violence, real-world property destruction, and severe digital extortion.
In a recent Flashpoint webinar, our analysts took a deep dive into this complex digital threat, fully breaking down the inner mechanics of NVE, its warning indicators, and how cross-functional security teams can proactively monitor and mitigate these dangerous digital-to-physical threats.
Here are the core takeaways from our on-demand webinar that organizations need to understand.
What is Nihilistic Violent Extremism (NVE)?
Nihilistic Violent Extremism (NVE) defines criminal conduct driven by a deep misanthropy and a desire to trigger societal collapse through random acts of chaos, psychological cruelty, and violence. While casual observers might dismiss these activities as extreme “internet trolling” or adolescent angst, Flashpoint recognizes NVE as a digitized, accelerated evolution of long-standing extremist and occult philosophies.
NVE draws heavily from the Order of Nine Angles (O9A), a paramilitary philosophy originally established in the United Kingdom. Unlike traditional movements seeking political control, O9A advocates for the total destruction of modern civilization to force a return to social darwinism.
How NVE Transitioned from Ideological Literature to Gamified Online Terror
The transition of reclusive occult literature into digital networks followed a deliberate path of gamification. Threat actors stripped away the theological texts, replacing them with fast-paced, highly visual media designed to engage younger audiences on gaming platforms and encrypted messaging apps.
These repackaged materials were then adopted by the various groups within The Com, such as 764 and other scavenger cults. By wrapping graphic violence and extremist symbology in internet humor, these groups lower a recruit’s psychological defenses, accelerating their desensitization and drawing them rapidly into higher-harm activities.
Key Tactics, Techniques, and Procedures (TTPs) of NVE
NVE networks represent a primary example of digital-to-physical convergence, where virtual harassment directly manifests as physical security risks. For NVE actors, violence that remains private is considered wasted effort—because their focus is on generating public fear, breaking taboos, and winning peer status polls, publicity is an operational requirement.
Recorded acts of violence serve as the primary currency across all three pillars of “The Com”. To build status, gain access to private channels, or enforce extortion, threat actors rely on a distinct set of operational tactics to create a societal environment of fear and discord, elaborated on in our expert webinar.
The Demographic Realities and Accessibility of NVE Groups
A critical takeaway from the webinar was the demographic profile and accessibility of NVE networks, with participants—both perpetrators and victims—being overwhelmingly young, typically ranging from ages 11 to 22, with a high concentration of juveniles. Additionally, because extreme coercion and abuse are normalized in these spaces, victims are frequently pressured into becoming enforcers against others as a condition to cease their own victimization.
Because of this young demographic, most NVE actors do not rely solely on Tor hidden services. Instead, they recruit, coordinate, and broadcast activities across mainstream social media, open messaging apps, and popular online gaming platforms.
Protect Against NVE Risk Using Flashpoint
Tracking a highly decentralized threat ecosystem where groups form, rename, and dissolve within hours requires specialized, multi-disciplinary intelligence capabilities. Flashpoint provides enterprise security teams, physical safety leads, and CTI analysts with the visibility required to identify and mitigate NVE activity.
To explore the complete webinar discussion, which includes deeper analyst breakdowns of threat actor activity, behavioral indicators, and enterprise mitigation strategies, watch the on-demand recording today.
Update (July 30): A table listing the new names of select prominent threat actors was appended to this post.
Introduction
Today, Google Threat Intelligence Group (GTIG) will begin rolling out a unified naming schema for tracking threat actors. This new naming taxonomy represents an effort to standardize tracking across platforms and public reporting.
Why are we Adopting aDifferentNaming System?
Historically, Mandiant and Google’s Threat Analysis Group (TAG) maintained distinct tracking systems, relying on parallel naming schemas that grew independently over time. The creation of GTIG has necessitated a new, fused tracking system, and a new naming system. Thinking to the future, GTIG’s new system will rely on cryptonyms. Relying on sequential numbers or disparate identifiers (e.g. APT1) fails to provide defenders the critical context needed to operate quickly. Threat tracking shouldn’t be an exercise in memorization, but rather one of intuition. The new naming convention aligns with industry standard threat actor naming systems.
Our New Schema
Our new schema utilizes a cryptonym-based approach, employing memorable two-word combinations for each distinct threat actor:
The first word is a unique and memorable term chosen to represent the specific actor, particularly names that may have been used in prior public reporting. If no previously used term exists, this word is randomly generated to remove bias, then vetted by our analysts.
The second word categorizes threat clusters by motivation, attribution, or activity type based on which category we consider to be most important for defense and response strategies.
The table below provides a sample of how threat actor categories will map to the second word in each cryptonym:
Origin or Type
Group Name
People’s Republic of China
CASTLE
Iran
ION
North Korea
NEPTUNE
Russia
RELIC
Cybercriminal
COMET
Table 1: Examples of Google’s new threat actor naming system categories
We know there are many threat actor tracking schemas in the industry, so we are intentionally seeking to keep this system as simple as possible to streamline operations and facilitate mapping to other naming taxonomies. However, a significant caveat remains: because no two organizations have the exact same visibility into the threat landscape, direct, apples-to-apples comparisons between threat actors are rarely possible. Transitioning to a convention that is simpler to follow and remember is a practical step toward managing a highly intricate tracking problem.
A Work in Progress
We have initially prioritized renaming several dozen of the most active groups, and will continue this process on a rolling basis. Previous names will remain indexed and searchable in the Google Threat Intelligence (GTI) platform, with MITRE ATT&CK mappings and other vendor aliases preserved, see Figure 1.
Figure 1: Threat actor name appearance in GTI platform on initial rollout
We will continue to use UNC, or “uncategorized” designations for threat clusters that are still in the early stages of investigation, as described here.
The Flashpoint Method: Prioritizing Vulnerabilities in an Era of AI-Accelerated Discovery
We outline Flashpoint’s practical, repeatable framework for prioritizing vulnerabilities based on real-world risk, exploitability, and business impact.
Organizations are gaining new ways to identify vulnerabilities at scale, thanks to new generations of powerful AI models. However, security teams still face the same fundamental question: which vulnerabilities actually matter?
Vulnerability management teams have increasingly struggled to keep pace with growing disclosure volumes. From January 1, 2026 to June 30, 2026, Flashpoint tracked 21,667 vulnerabilities, an 8% period-over-period increase, with one-in-five containing publicly available exploit code at time of disclosure. At the same time, the gap between disclosure and exploitation continues to shrink, with some vulnerabilities weaponized in as little as 24 hours.
Flashpoint’s Method for Threat-Informed Vulnerability Prioritization
Recent developments such as Anthropic’s Mythos model have highlighted the growing potential for AI-assisted vulnerability discovery. As advances in code analysis enable researchers and organizations to identify software flaws at unprecedented speed and scale, the volume of discovered vulnerabilities is set to potentially increase significantly across software ecosystems.
That’s why we created this guide, The Flashpoint Method for Threat-Informed Vulnerability Prioritization, a practical, intelligence-driven framework designed to help vulnerability and exposure management teams cut through the AI-driven noise and focus on the vulnerabilities that matter most. By incorporating real-world exploitation activity, threat actor behavior, asset exposure, business context, and remediation considerations, organizations can make faster, more informed decisions and reduce risk more effectively.
Download to gain:
A clear, threat-informed prioritization framework: How to assess which vulnerabilities demand immediate attention, and why — moving beyond static severity scores alone.
Core and expanded prioritization checklists: Criteria spanning asset criticality, active exploitation, CVSS severity and ransomware risk, social risk and community chatter, business context, compensating controls, zero-day status, KEV inclusion, EPSS scoring, ease of remediation, and vulnerability age.
How to operationalize prioritization at AI scale: Insight into how Flashpoint’s vulnerability intelligence platform and analyst expertise help teams keep pace as AI-assisted discovery accelerates disclosure volume.
Prioritize Vulnerabilities More Effectively and Faster Using Flashpoint
While increased visibility into vulnerabilities is ultimately a positive for defenders, it amplifies a challenge security teams already face—separating which vulnerabilities represent meaningful risk to your environment and require immediate action.
What is threat-informed vulnerability prioritization?
Threat-informed vulnerability prioritization is the process of evaluating vulnerabilities based on real-world risk rather than severity scores alone. It incorporates factors such as active exploitation, exploit availability, threat actor activity, asset exposure, business context, and remediation considerations to determine which vulnerabilities require immediate attention.
Why is vulnerability prioritization important?
Organizations face thousands of newly disclosed vulnerabilities each year, while security teams have limited time and resources to remediate them. Effective vulnerability prioritization helps organizations focus on the vulnerabilities most likely to be exploited and most likely to impact their environment.
How is AI changing vulnerability management?
AI-assisted code analysis is enabling researchers and organizations to identify software flaws faster and at greater scale. While increased visibility into vulnerabilities benefits defenders, it also increases the volume of vulnerabilities that security teams must evaluate, making effective prioritization even more important.
Why isn’t CVSS enough for vulnerability prioritization?
CVSS provides a standardized measure of technical severity, but it does not account for whether a vulnerability is actively being exploited, relevant to your environment, or likely to impact your business. Effective prioritization combines severity with threat intelligence and organizational context to assess real-world risk.
How does Flashpoint help organizations prioritize vulnerabilities?
Flashpoint combines analyst-driven vulnerability intelligence with real-world exploitation data, threat actor insights, asset exposure, and business context to help organizations identify the vulnerabilities that pose the greatest operational risk. This intelligence supports faster, more informed remediation decisions and operationalizes threat-informed vulnerability management at AI scale.
Understanding Illicit Ecosystems: Inside Rehub’s Rise as a Primary Ransomware Marketplace
As part of our ongoing series, Flashpoint intelligence tracks Rehub, breaking down its migration, infrastructure, and the various RaaS groups sponsoring and partnering with it.
Rehub, also known as ReHub or RehubCom, is a Russian-language cybercrime forum founded in August 2025 by a former XSS moderator following its shutdown in the summer of 2025. Rehub dedicates itself to the commercial and marketplace use of ransomware, while its counterpart, DamageLib, serves as a knowledge base archive and exchange.
2025
July 23: XSS is taken down by law enforcement
August 1: XSS moderators launch DamageLib, which completely abandons illicit commerce.
August 10, 2025: Rehub forum is launched by a former XSS moderator, fully embracing illicit commerce.
January 28, 2026: RAMP is seized by law enforcement, with its users migrating to Rehub.
Operating both on Clear Web domains and an onion domain, the forum positions itself as free from state and law enforcement interference, framing existing XSS iterations as compromised. After law enforcement seized the RAMP (RAMP4U) forum in January 2026, Rehub absorbed a significant portion of the displaced cybercriminal community and became one of the primary destinations for ransomware operators.
The Rehub login page in August 2025, early stage of the forum. (Source: Rehub)
Who Are Known Members of Rehub?
There are many notable threat actors among Rehub moderators and users, including ransomware operators, vendors, and other prominent threat actors active across several illicit communities. Several current or ex-Rehub moderators were also maintainers of other illicit forums such as XSS, DamageLib, and RAMP.
Notably, Ransomware-as-a-Service (RaaS) groups such as DragonForce have maintained an active presence on the platform to market their affiliate programs. Flashpoint assesses that DragonForce is likely the forum’s primary sponsor or partner, as their banner is permanently displayed on the forum’s home page, with both logos merged—similar to its previous placement on RAMP.
The Rehub home page with the DragonForce logo. (Source: Rehub)
As of July 2026, Flashpoint intelligence observes over 8,300 active users, 15,000 posts, and nearly 3,000 threads. Despite being free to join, Rehub practices a zero trust policy, which was established in mid-April 2026. Under this system, the forum restricts newly registered users from accessing any section other than its Sandbox. Users can also purchase paid upgrades:
Premium status (gold rank): Costing US $100 per year, this rank grants distinctive color, custom title, nickname changes, unlimited post editing/deletion, extended signature, unlocks all hidden text regardless of post count, likes, join date, ability to bump commercial threads, and inherits all lower-tier perks.
Patron status(pink/magenta rank): Costing US $5,000 per year, this rank grants custom title editing, a personal profile link, custom styling for posts, profile, and postbit, and inherits all “Premium” perks.
The only section available to newly registered users on Rehub forum. (Source: Rehub)
What are the Various Rehub Forum Sections?
Rehub sections, similar to other forums, are grouped by major activities, separating the knowledge base from commerce and from general discussions.
The list of Rehub forum sections. (Source: Rehub)
Sandbox
Serves as an entry-level general discussion area and a place for community questions. Main activity consists of queries about operational security, introductory networking, and entry-level fraud or malware logistics.
Technical
Covers threads ranging from traditional network infrastructure vulnerabilities to emerging technologies such as AI jailbreaking and deepfake social engineering. Highly active, most communications focus on network vulnerabilities and carding.
Programming (Development)
This is a dedicated space for discussions on software engineering, system administration, and web optimization within the forum. Primary activities include sharing programming language tutorials, comparing backend technologies, and developing specialized automation tools.
Library
Serves as a repository of resources for the forum, hosting the most threads and community engagement. Users share operational materials, leaked databases, and utility software. Additionally, this section aggregates cybersecurity and tech industry news and articles.
Supermarket
This is a commercial section featuring ransomware affiliate programs, compromised network access, malware tools, stolen financial data, bulk spam infrastructure, forged documents, anonymous hosting, and crypto laundering services.
Arbitration
Serves as the forum’s internal justice system, where members resolve financial disputes and flag scammers. The “Black List” subsection functions as a public record of bad actors and scam sites.
Administration
This is where forum staff post announcements, policy updates, and operational notices, including rules, official domains, forum news, moderator applications, and 2FA requirements. Members use it to ask questions, request escrow services, propose features, and raise concerns about the forum’s public image.
Monitor Illicit Marketplaces Using Flashpoint
Flashpoint will continue to monitor Rehub’s marketplace activity and infrastructure updates. Rehub’s rapid evolution from a post-XSS refuge to a heavily sponsored ransomware marketplaces demonstrates the resilience of the cybercrime ecosystem.
Positioning itself as the primary ransomware marketplace, Rehub has built a high-barrier, high-reward environment for sophisticated threat actors. Request a demo to learn how Flashpoint delivers visibility into illicit communities—empowering security teams to track threat actors, identify exposed assets, and mitigate ransomware risks.
There’s a new boogeyman in the battles over AI: so-called “stealth crawlers.” We’ll admit it—the term “stealth crawlers” sounds quite nefarious. In reality, they’re anything but.
“Stealth crawlers” are simply automated tools to access and collect public web data—without disclosing the user’s identity. Private crawlers like these facilitate all kinds of important work that benefits the public, including investigative reporting, academic research, cybersecurity protection, and more.
Anonymous crawling enables some of the most publicly beneficial uses of the open web.
Many publishers want to unmask crawlers anyways—and are pushing for new legislation that would give them new powers to do so. These legislative proposals threaten the open web, user privacy, and valuable research without directly addressing the problems they’re supposedly intending to solve.
Alarmingly, these harmful proposals are gaining traction. The New York state legislature has already passed such a bill, the NY Stealth Crawler Protection Act, which is now on Governor Hochul’s desk. We expect to see similar bills introduced in other states, and potentially in Congress. That’s a big problem for the open web—and the many benefits it provides.
Anonymous crawling is worth protecting
Anonymous crawling enables some of the most publicly beneficial uses of the open web. Researchers, journalists, and other watchdog groups use unidentified automated tools to gather the information necessary to hold powerful institutions accountable and protect the public.
Anonymous crawling fuels important investigative journalism. For example, The Markup, a non-profit news site, used anonymous crawlers to investigate potentially anti-competitive practices by tech companies, such as Amazon’s tendency to prioritize Amazon brands and Amazon-exclusive products over competitors with higher ratings. The crawlers identified themselves as ordinary Firefox browsers to web servers, which allowed The Markup to understand how Amazon search results pages would appear to ordinary users. Similarly, ProPublica used an automated tool designed to simulate an ordinary Amazon customer to reveal that the site steered shoppers to more expensive products over cheaper alternatives.
Anonymous web scraping is also crucial for cybersecurity professionals, who use automated tools to monitor the web for information that helps them protect against malicious attackers. Privacy tools, including EFF’s own Privacy Badger, also crawl sites anonymously to identify trackers without compromising user privacy.
However, without the ability to scrape anonymously, these tools would likely be blocked. Sites can—and do—block crawlers operated by researchers, journalists, and activists who criticize them. For example, Facebook shut down accounts belonging to researchers who used automated tools to study misinformation on the platform and demanded that they take down published research. Many sites block automated access by anyone who hasn’t paid to crawl public webpages.
Unmasking crawlers threatens the open web
News publishers—and their allies in government—say that unmasking crawlers is necessary to protect news organizations from technological strain caused by AI-related crawling, and fears that AI could reduce news sites’ traffic and ad revenue. These are legitimate concerns.
But enacting broad, reactionary restrictions on automated access is not the answer. Legislation targeting anonymous crawling threatens the open web, user privacy, and valuable research without actually addressing these technological and potential economic harms of scraping.
The New York state legislature recently passed the NY Stealth Crawler Protection Act, a law that would make it illegal to crawl news websites without revealing who is operating the crawler and all possible future uses of the data collected by the crawler. The law would give websites the power to obtain court orders that unmask anyone using an unidentified crawler—without any evidence that they broke the law.
Laws like the New York bill sweep far beyond AI, and do not meaningfully address the technological or potential harms of AI-related web scraping. These policies would chill beneficial crawling by allowing publishers to veto lawful public access, giving them the power to block not just bad actors, but also security professionals, researchers, dissidents, or anyone who has not paid for a license to view public text. This needlessly undermines the free and open internet.
Digital news publishers—like most websites—face real technological challenges in the AI era. While web crawling has been around for decades, with the proliferation of AI, crawlers now collect far more public web data than they used to. This pushes servers closer to their maximum capacity, and if some bots collect information too aggressively, they may strain web servers to the point that it degrades site performance. The problem is not anonymity—so unmasking crawlers won’t solve it. The real problem is overaggressive crawling, which can be effectively addressed with technical measures that target harmful conduct without impeding anonymous access to information.
A better path forward
There are other, far less harmful ways to protect publishers from the harms these “stealth crawler” laws claim to target. Addressing the harms of AI-related crawling requires policies that narrowly target the causes of these issues–without undermining free expression and the open web. Policies that target crawlers and scrapers are anything but.
Login
Table Of Contents
