Vercel announced this week that teams on its free Hobby plan will now have older, unprotected deployments deleted immediately if they exceed the 10GB Deployment Storage limit. 

When asked why Vercel decided to change its retention rules, Jas Garcha, head of pricing at Vercel, tells The New Stack the update is a move to keep the free tier viable amid rapidly growing deployment volumes: 

“This change allows us to continue supporting a Hobby community that’s deploying at a much higher rate than it was a year ago.”

Old deployments now deleted immediately

Before, users in the free tier could count on eligible deployments to stick around for up to 30 days. But that window is gone for teams over the limit, and the protections that used to spare older deployments have narrowed for every Hobby project.

Now, if users exceed the standard 10GB of Deployment Storage included on the free tier, old deployments not covered by Vercel’s retention-policy exceptions will be deleted immediately, per Vercel’s updated Deployment Retention Policy. 

“This change allows us to continue supporting a Hobby community that’s deploying at a much higher rate than it was a year ago.”

What gets to stay? 

Vercel says each Hobby project will keep the three most recent production deployments, along with its three most recent deployments of any type, regardless of age. That’s a cut from the previous Hobby exception, which preserved the 10 most recent production deployments, and it applies to every Hobby project — not only teams over the 10GB limit.

Plus, preview deployments lose a separate protection

In addition to cutting the 30-day holding period for over-limit teams, Vercel’s policy update also removes a separate retention exception for preview deployments. 

Preview deployments have not vanished from Vercel’s exception list entirely — the latest preview deployment on an active Git branch is still protected on every plan. What Hobby lost is the count-based exception: Pro and Enterprise teams keep their last 20 non-production deployments in a Ready state, and that protection no longer applies to Hobby.

Per Garcha, “Your current production deployment is never deleted, and aliased and active-branch deployments remain protected, along with each project’s most recent deployments.” 

Why the change?

Garcha tells The New Stack that Vercel’s latest policy update is needed to keep the Hobby tier sustainable as deployment volumes dramatically rise:  

“Our former retention defaults were designed for teams that ship constantly and need deep rollback history. They made less sense for Hobby projects, where dormant deployments were quietly consuming storage that active projects need.” 

“Your current production deployment is never deleted, and aliased and active-branch deployments remain protected, along with each project’s most recent deployments.” 

And activity is much higher, even compared to a year ago. According to Garcha, Vercel now handles more than 10 million deployments every day— more than a 6x increase YoY. Immediately deleting older, unprotected deployments, Garcha says, is one way to free up storage for active projects as Vercel handles much higher deployment rates.

In other words, Vercel is moving out some of the old to make room for the new. It describes how the storage limit works in its post:

“Every deployment you keep uses some of it [Deployment Storage], and going over the limit can block you from deploying until you free some up.” 

What Hobby users should do

It’s important to note that deletion isn’t immediately permanent. Vercel gives successfully built deployments a 30-day recovery period, and users can restore them from a project’s Settings, under Security → Recently Deleted. Hobby users who want to stop old, unprotected deployments from being deleted in the first place can move off the free tier and onto the Pro plan. In the Pro tier, storage beyond the plan’s included allowance is billed at $0.10 per GB-month, and the retention exceptions stay far more generous: the last 10 deployments created in a project, the last 20 production deployments in a Ready state, and the last 20 non-production ones.

For users who can’t or don’t want to upgrade to Pro, Vercel offers guidance for optimizing Deployment Storage usage to help users stay under the free 10GB storage limit, like reducing unnecessary deployment output.

Still, Garcha says few Hobby users will feel the effects enough to warrant making a change. Pointing to Vercel’s list of exceptions that still protect certain deployments, he tells The New Stack, “The vast majority of Hobby users won’t notice the change.” 

Garcha also says Vercel’s stricter retention policy helps the company keep offering Hobby as a permanent free plan.

“We’re one of the few platforms where the free tier isn’t a trial or a credit that expires. It’s a permanent plan, and we’ve kept expanding it,” he says. “By ensuring its resources go to people actively building, we’re able to continue offering it.”

The post “Dormant deployments were quietly consuming storage”: Why Vercel tightened its free-tier rules appeared first on The New Stack.

While AI code generators help teams ship faster than ever, that speed brings a hidden killer: Comprehension Debt. As soon as an AI produces functionally correct code that violates your domain boundaries, the team loses its mental model of the system. Here, I’ll show how to switch from passive documentation to Executable Architecture using Python-based testing tools like pytest-archon and CI/CD pipelines.

The most dangerous thing an AI coding agent can do is generate code that works.

If a junior developer writes poor code, it breaks the build or staging environment. The team catches it, reverts it, and discusses it. But if an AI coding agent produces 500 lines of functionally correct and bug-free code that subtly violates your system’s boundaries, it merges without issues.

“The most dangerous thing an AI coding agent can do is generate code that works.”

Gradually, the AI connects your billing service to the user authentication component. It gives your presentation layer database access. It wires dependencies in a way that works but violates the design assumptions of human developers who maintain the system. 

Technical debt has given way to something far more pressing — Comprehension Debt: the growing gap between how fast code gets written and how well the human team understands its architecture. The problem isn’t messy logic; it’s a lost mental model. That happens when the team no longer knows why the codebase exists.

If you view AI as a mere machine for faster typing, the architecture has started to degrade. To endure in the era of AI-driven coding, architecture enforcement must shift — from documentation to Executable Architecture.

The illusion of documentation

The accepted guidance for AI-assisted development is: “Make better documentation so the AI understands the rules.”

This is a fallacy. Documentation will become obsolete. If your AI agent finds an easier way to reach its objectives by skipping a service layer, it will take it. And since human reviewers increasingly struggle to review thousands of AI-generated pull requests, these detours slip through code review undetected.

“You cannot depend on human beings to detect architectural drift. You have to trust the CI/CD pipeline.”

You cannot depend on human beings to detect architectural drift. You have to trust the CI/CD pipeline. 

If your architectural boundaries matter, check them the same way you’d check any business requirement. We need fitness functions that fail the build when an AI agent violates a boundary condition.

Introducing executable architecture in Python 

In the Java ecosystem, tools such as ArchUnit have traditionally enforced architectural boundaries. In Python, tools like pytest-archon do the same job.

Consider a concrete example. You’ve built a modular monolith for an e-commerce application and established strict boundaries:

• The Billing domain should never import from the Shipping domain.
• Domain model code should not import from infrastructure (AWS SDK, SQLAlchemy, etc.).

You task the AI agent with adding shipping cost calculations based on the user’s billing tier. Without thinking about the architecture, the AI imports the Shipping Calculator directly into the billing service. Test passes. The application works. But the architecture fails.

Here’s how pytest-archon prevents the agent from doing that.

Step 1: Install the dependency

First, install the architectural testing dependency.

Python
pip install pytest-archon

Step 2: Define the architectural rules as tests

Instead of finding the rules on the Wiki page, we define them as pytest features. We create a test_architecture.py file in the test folder.

Python
from pytest_archon import archrule

def test_billing_is_isolated_from_shipping():
    """
    Ensure the billing module never imports shipping logic.
    This prevents the AI from creating tight coupling between distinct domains.
    """
    (
        archrule("billing_isolation", comment="Billing must not know about shipping")
        .match("ecommerce.billing*")
        .should_not_import("ecommerce.shipping*")
        .check("ecommerce")
    )

def test_domain_models_are_pure():
    """
    Ensure domain models only depend on standard libraries or pydantic.
    Prevents the AI from leaking infrastructure (DBs, APIs) into the core logic.
    """
    (
        archrule("pure_domain", comment="Domain models must not import infrastructure")
        .match("ecommerce.*.models")
        .should_not_import("sqlalchemy*")
        .should_not_import("boto3*")
        .check("ecommerce")
    )

Step 3: Close the agent feedback loop

Then, once the AI agent pushes its pull request, pytest runs automatically as part of the CI workflow. Regardless of how well the AI agent generates code that calculates the Shipping fee, the build will immediately fail with something similar to this:

text
FAILED tests/test_architecture.py::test_billing_is_isolated_from_shipping -
AssertionError: Rule 'billing_isolation' violated:
ecommerce.billing.invoice imports ecommerce.shipping.calculator

A human reviewer doesn’t have to track down the entire import tree manually. Most importantly, the best engineering teams never rely on humans for this.

Once again, we feed the output of these failing pytest tests directly back into the AI agent’s context window using Aider or custom CI/CD scripts, and the AI can fix architectural problems without human help.

Strategies for avoiding Comprehension Debt

Running architectural tests alone is not enough. Here’s how to shield your team from Comprehension Debt:

1. Hard boundaries vs. soft conventions

AI agent obeys hard constraints but not soft suggestions. Get rid of sloppy folder-based architecture and establish clear module boundaries instead. Use tools like import-linter or pytest-archon to block forbidden imports with physical barriers. The path of least resistance must be the most architecturally sound.

2. Limit automated complexity

Well-defined APIs and boundaries are good, but not enough to let you off the hook for messy, complex implementation. If AI creates spaghetti code in your billing module, causing downtime from race conditions at 3 AM, a human engineer will still need to maintain and understand that codebase.

For this purpose, run architectural tests alongside cyclomatic complexity gatekeepers such as Ruff, Radon, or SonarQube as part of your CI pipeline. Set hard limits on complexity to force AI to decompose huge functions into smaller ones.

3. Examine the interfaces, not just the implementation

In code reviews of AI-generated PRs, the developer’s mind is a precious resource. Stop looking at each line, trying to decipher loops and variable assignments. Look at what changes the system from the outside. Instead, are there new dependencies? Did the PR expose new API endpoints? Did it change the data schema? If not, your mental model remains intact.

Conclusion

AI coders are very strong, but they have one big flaw — they are very pragmatic. The maintainability of your code doesn’t interest them — they care only about completing the task you assign them.

“AI coders are very strong, but they have one big flaw. They care only about completing the task you assign them.”

If you try to control your system design by relying on the human factor only, you will drown in Comprehension Debt sooner or later. It’s not a question of slowing down your AI implementation process— it’s a question of making your environment more resistant.

You don’t need to study every line of AI-generated code. You just need to create a cage for this AI.

The post Stop AI code sprawl before it destroys your software design appeared first on The New Stack.

Ask two experienced engineers about how to handle the flood of AI-generated code in their review queues, and you’ll get two different answers.

The debate remains very much unsettled. And on Tuesday, September 29, two industry leaders will join a live event to hash out what to do.

John Bristowe, Principal Developer Advocate at Octopus Deploy, will join Viktor Farcic, the platform engineering voice behind DevOps Toolkit, for the live conversation we’re calling “Human Review vs. Verified Pipelines: What Catches Bugs in the Age of AI Code.”

Here are the facts: Developers have adopted AI en masse. According to the 2026 DORA report, 90% of developers now use AI at work. The result? Developers are merging 98% more pull requests than they managed in the pre-AI era. 

But all that AI-generated code is leaving a mess. Bugs per developer are up 54%, and one analysis of 10,000 developers found that incidents per pull request have climbed a staggering 243%. Octopus Deploy’s own AI Pulse report found that while AI usage enables faster code creation, it can “degrade overall performance” because coding agents write large code updates that humans struggle to fully understand.

Part of the problem is that developers have adopted automated code generation faster than they have adopted automated code review, effectively moving the human bottleneck further down the software creation chain without removing it entirely. And AI code review may have the same shortcomings as the coding agents.

Bristowe argues that code review has quietly become little more than theater. No human reviewer can quickly audit a 40,000-line, agent-created pull request, since they were not part of the reasoning that produced it and cannot realistically understand everything it may change. 

What does Bristowe recommend? Moving the quality gate off the humans’ desks and into the delivery pipeline itself. Does that mean more AI? Not necessarily, with the developer advocate arguing that building robust “policy-as-code” rules into deployment standards can flag only what goes against those policies. Humans can handle those exceptions, without pretending they are “reviewing” the entire package.

Expect Farcic to press Bristowe on how well a policy-as-code setup can truly absorb judgment, and whether we’re simply creating another accountability sink in software development. The conversation will also explore the plight of the junior engineer, who can no longer expect to join a team of humans writing code that other humans review and discuss.

The debate kicks off at 2:30 p.m. Eastern/11:30 a.m. Pacific on Tuesday, September 29. It’s free to attend, and attendees will receive a companion resource built from Octopus Deploy’s AI Pulse data, available immediately for participants who show up live. Register today.

What you’ll take away:

• Why AI-generated code broke the assumptions code review was built on, and why more review isn’t the fix
• Why using AI to review AI’s own code doesn’t close the gap (same training data, same blind spots)
• How to build a pipeline that verifies every deployment against a defined set of rules, no matter who or what wrote the code
• Where code review still earns its keep, and where it needs to step aside for the pipeline

The post AI broke code review. Two experts disagree on what replaces it. appeared first on The New Stack.

On September 15, 2025, npm’s registry did something unprecedented: Packages began updating themselves. 

No maintainer ran npm publish. No pull request got merged. New versions just materialized, each carrying a hidden passenger that would go on to publish even more versions of more packages, on more machines, with no human involvement whatsoever. Between September 14th and 18th, more than 500 package versions were altered. The worm’s authors had their creation leave a calling card with an intriguing literary sobriquet: every stolen credential was uploaded to a new public GitHub repo named Shai-Hulud, after the untamable apex keystone species of Frank Herbert’s Dune book series.

“What should we learn about trusting infrastructure from a worm that writes and republishes its own malware?”

That wasn’t the end of the story. Two months later, on November 24, a larger variant christened Shai-Hulud 2.0 was able to backdoor 796 packages, move its execution earlier in the install process to render developer triggers irrelevant, and salt the wound on its way out by deleting the user’s home directory if it couldn’t find credentials to steal or a way to spread. By spring of 2026, its offspring, Mini Shai-Hulud, had evolved from hunting generic developer secrets to specifically targeting credentials belonging to Claude, Codex, Cursor, and Gemini, and had come to the logical conclusion that AI coding tools are involved in all the most interesting projects, making them a ripe hunting ground. 

The latest variant, named ChainDrop, appeared a few weeks ago, on August 4, 2026. In less than four hours, it compromised more than 400 packages by riding a legitimate, cryptographically signed release pipeline, which granted each poisoned version a valid SLSA provenance attestation. This allowed them to circumvent the very mechanism built to verify that a package hadn’t been tampered with. Even its command infrastructure was parked inside an Ethereum smart contract, rendering any domain blocklists moot.

Who can you trust?

Every package manager and infrastructure registry runs on the same precarious assumption: installing something means running whatever’s in the package, sight unseen, with whatever permissions the install process has. When publishing required a person to sit down and do it, that assumption was safe enough.

“If publishing can now be automated by non-human agents already in the environment, it is no longer safe at all.”

If publishing can now be automated by non-human agents already in the environment, it is no longer safe at all. In such an environment, the worm doesn’t need to convince anyone of anything. It simply needs one compromised credential and an install script. After that, the registry confers trust and credibility, and every subsequent dependency reinforces it.

What happened

The strategy is brutally simple. A compromised npm package runs a postinstall script (in Shai-Hulud’s case, a single file called bundle.js) that searches the infected machine for anything resembling credentials, including npm and GitHub personal access tokens, AWS or GCP secrets, and whatever it can extract from a cloud instance’s metadata service. It downloads Trufflehog, a legitimate open-source secret-scanning tool, and uses it to confirm the validity of any credentials it finds. So, the silver lining is that you at least get a free security audit (of sorts) out of the infection.

Upon locating a GitHub token, it exfiltrates everything to a new public repo and, for extra credit, makes any private repos it can reach public as well, republished under the original name with a “-migration” suffix appended, perhaps to make it appear as if the victim had requested the move themselves. If it finds an npm token, it calls the registry’s API to list every package the compromised developer maintains, downloads them, injects itself into the postinstall step, bumps the version number, and republishes them. That’s it. No further input required. Palo Alto Networks’ Unit 42 is moderately confident that the malicious script was partly written by an LLM, based on stylistic tells such as code comments and emoji embedded in the payload.

We must not fear. Fear is the mind-killer.

This vulnerability isn’t specific to npm. Trade npm publish for terraform apply, and the mechanics hardly change. A Terraform provider pulled from a public registry, like an npm package pulled from its registry, is code that a publisher’s account was trusted to ship, running with whatever access the machine that requested it holds. 

A CI runner with a standing cloud credential and an open path to the internet is the same target as a maintainer’s laptop with a valid npm token: one a worm can compromise once and then use to spread itself to everything downstream of it, at whatever speed automation allows.

“Attestation tells us where a package came from; it doesn’t say anything about whether the commit should exist at all.”

Up until now, the industry’s answer to this problem was provenance: sign the package, attest to the build, and prove cryptographically that what shipped and what’s reviewed match. ChainDrop is the answer to that answer. It didn’t forge a signature. It compromised a maintainer account with legitimate write access and let that account’s legitimate, signed pipeline build and publish the malware on its behalf. Attestation tells us where a package came from; it doesn’t say anything about whether the commit should exist at all.

The fix

Every dependency should be pinned to an immutable reference. Terraform’s dependency lock file, .terraform.lock.hcl, has a recorded cryptographic checksum for every provider version since Terraform 0.14, operating on a trust-on-first-use model. Once a checksum is recorded, any future terraform init that doesn’t match it fails rather than accepting a swapped-out binary. Modules deserve the same discipline. Pin a module’s source to a full commit SHA, not a branch or even a tag, since tags can be moved or deleted at the origin in a way a commit hash cannot. Checkov’s CKV_TF_1 rule and TFLint’s module-pinned-source check both exist because reviewers keep forgetting this.

Source providers and modules through a registry your organization curates. The public Terraform registry, like the public npm registry, will resolve whatever its maintainers choose to publish. If a maintainer account is compromised, everyone downstream inherits the problem on their next init. Routing provider and module resolution through a private, versioned, allow-listed registry means the potential sources a deployment can pull from are controlled by somebody on your team, not the entire public internet’s worth of Terraform code.

Credentials should be scoped to the deployment, not the developer or runner. Every stage of Shai-Hulud’s lineage depends on a long-lived secret that sits still, whether a token in a .npmrc file or a key in a CI environment variable. Short-lived, per-deployment credentials issued through OIDC, an identity token traded for temporary cloud access at the moment a deployment runs and discarded the moment it finishes, mean there’s no standing secret for a Trufflehog pass to find. A worm can still steal a credential that lives in memory for the ninety seconds an apply takes, but it can’t steal one that was never written down in the first place.

Control what a runner is allowed to talk to on its way out. Every generation of this worm relied on an open outbound path: a webhook endpoint for exfiltration, the GitHub API for persistence, npm’s own registry API for propagation, and, in ChainDrop’s case, an Ethereum RPC endpoint chosen specifically because no domain blocklist could touch it. Restricting a runner’s egress to the handful of domains a deployment actually needs (the registry, the state backend, the cloud API), and nothing else, means any attempt the worm makes to phone home runs straight into a firewall before it ever leaves the building.

Those that can destroy a thing, they control it

A build pipeline isn’t a convenience layer sitting tasteful and demure outside your security boundary. It’s production infrastructure, running unattended, typically wielding more standing privileges than the systems it deploys.

“A build pipeline isn’t a convenience layer sitting tasteful and demure outside your security boundary. It’s production infrastructure.”

Pipelines weren’t built this way intentionally. They ended up like this because until these vulnerabilities were exposed, everyone treated them like plumbing, as if history weren’t replete with examples of plumbing used to evade defenses. Turns out, it’s also a perfect avenue for worms to get to the keys that protect your secrets.

Shai-Hulud figured this out within its first 24 hours. The industry is scrambling to catch up, in progressively more painful installments, paid every couple of months. 

Software supply chains used to get compromised. Now, they get infected; and infections don’t wait; they spread. The humble worm that started as a credential thief has now learned to forge the very cryptographic proof meant to catch it. Its latest prey is the AI tooling teams use to speed up production. An unpinned reference and open registry pull are all it would take for this to spread to Terraform providers and modules. The only remedies are: pin what can be pinned; allow-list what can’t; scope credentials for what’s left. Close all paths out. 

Otherwise, by the time you notice the next worm, it’ll have already spread to everything downstream of the one reference you forgot to pin.

The post Shai-Hulud: Whoever controls your package registry controls your pipeline appeared first on The New Stack.

JetBrains is urging users of its Cadence cloud development service to rotate credentials and treat previous executions and their outputs as untrusted after attackers exploited a critical TeamCity vulnerability on a server the company failed to patch.

The irony is hard to miss. JetBrains disclosed CVE-2026-63077, a critical vulnerability in TeamCity On-Premises, on July 27. The flaw allows an unauthenticated attacker with HTTP or HTTPS access to a vulnerable TeamCity server to execute arbitrary operating system commands with the privileges of the TeamCity server process. 

By August 7, the company announced that attackers were already exploiting unpatched TeamCity servers.

But one vulnerable server was still exposed: JetBrains’ own.

“The server should have been patched as part of our response to the vulnerability, but it was not,” JetBrains acknowledged in its disclosure of the Cadence incident.

“The server should have been patched as part of our response to the vulnerability, but it was not,”

Cadence’s unpatched TeamCity server

Attackers targeted api.cadence.jetbrains.com, which is the server behind Cadence, JetBrains’ cloud compute service for PyCharm. JetBrains found out about the attack on August 23 and took the server offline the next day. Their investigation shows that malicious activity started on August 8, so the affected period is from August 8 to August 24.

Cadence integrates with PyCharm via an optional plugin, giving developers the ability to run projects on cloud compute resources. TeamCity sat behind the service, orchestrating those workloads.

That put the compromised server in a particularly sensitive part of the development environment.

Exposed credentials and source code

JetBrains says the attackers got hold of a complete Cadence server backup from 2024, potentially exposing everything stored in it, including credentials, configuration files, artifacts, and logs. 

The company also confirmed that multiple AWS IAM users and their associated credentials were compromised, including IAM users belonging to JetBrains employees who had used Cadence.

Attackers accessed files in S3 buckets within JetBrains AWS accounts used by the service. JetBrains is still determining the full scope and says it does not yet know whether customers’ storage buckets were accessed.

Developers using the PyCharm plugin could sync project files to Cadence before running them, so source code and any credentials or configuration files included with those projects may also have been exposed.

The breach also exposed usernames, real names, email addresses, last-login timestamps, and last-accessed IP addresses. Credentials used during Cadence executions may have provided access to other connected services as well.

Supply chain risk compounds quickly

JetBrains says users should consider any credentials or secrets stored in Cadence, included in the compromised backup or used during an execution to be compromised. 

That could mean rotating AWS, Azure, and Google Cloud credentials, as well as tokens for GitHub, GitLab, and Bitbucket. JetBrains also warns about credentials for npm, Maven, NuGet, PyPI and container registries such as Docker Hub, ECR, GCR, and ACR.

Access to those registries creates another problem. An attacker with publishing credentials could push a malicious package that gets pulled into other projects, similar to a recent npm attack that used provenance attestations to spread through the software supply chain.

The warning also covers Slack tokens, webhooks, API tokens, SSH and deployment keys, service account credentials and signing keys or certificates.

Anything run through Cadence during the affected period, including the resulting output, should also be treated as untrusted, according to JetBrains. The concern isn’t limited to exposed data and credentials; anything Cadence ran during that time could potentially have been altered.

CI/CD and remote execution systems often have access to private repositories, dependencies, cloud storage, package registries and deployment systems. Their central role in software delivery is part of what has made CI/CD infrastructure an acquisition target and also gives attackers more places to go after gaining access. Once the environment itself has been compromised, developers can’t assume the credentials that passed through it or the artifacts it produced are safe. 

Once the environment itself has been compromised, developers can’t assume the credentials that passed through it or the artifacts it produced are safe. 

Audit logs reveal lateral movement

Changing potentially exposed credentials is only part of JetBrains’ advice. Users also need to check if those credentials were used elsewhere and if anything changed in systems connected to Cadence.

JetBrains recommends checking source control audit logs for unexpected repository clones or downloads, unauthorized commits, and changes to repository secrets or webhooks. Users should also look for new or changed personal access tokens, API tokens, and SSH keys.

JetBrains recommends checking source control audit logs for unexpected repository clones or downloads, unauthorized commits, and changes to repository secrets or webhooks.

Cloud environments need the same careful review. JetBrains says users should look for unexpected IAM changes, new users or service accounts, and unusual access to storage like S3 buckets. Authentication logs can also show if credentials used in Cadence were later used from unknown places.

Package repositories and release histories should be checked for unexpected publications or changes, especially where Cadence had credentials that could publish packages or artifacts.

Since JetBrains treats previous Cadence executions and their outputs as untrusted, the investigation goes beyond just checking account logs alone. Developers may also need to review artifacts made through the service during the affected period and make sure they match trusted source code and expected build results.

The company published six IP addresses associated with detected exploitation: 150.109.230.104, 43.153.227.206, 62.210.127.48, 210.247.242.190, 15.235.225.205 and 152.233.30.18 with a warning that these indicators are not complete, so not seeing them does not mean an account or system was not compromised.

The post JetBrains told everyone to patch. It didn’t patch itself. appeared first on The New Stack.