DEV Community: Ranjan Kumar Singh

NPM 12 Will Change Script Execution Behavior to Prevent Attacks

Ranjan Kumar Singh — Sun, 21 Jun 2026 07:20:38 +0000

NPM 12 is changing the rules, and AI coding agents are the reason it can't come soon enough

For nineteen years, npm install has quietly done something most developers never think about: it executes code. Not just downloads it runs them automatically via preinstall, install, and postinstall lifecycle hooks before a human ever reviews a single line.

That implicit trust model is finally ending. Starting with npm 12 (expected in July 2026), GitHub is flipping the default from opt-out to opt-in. As a cloud and security architect who has spent the last several years building landing zones and policy-as-code guardrails, I think this is one of the most consequential supply chain changes in npm's history and it's arriving at exactly the moment a new class of attacker has learned to target it.``

What's actually changing in npm 12

preinstall, install, and postinstall scripts from dependencies will no longer run automatically they require explicit approval via npm approve-scripts.
Native module builds via node-gyp (commonly triggered through a binding.gyp file) are blocked by default unless explicitly allowed.
Git dependencies and remote URL/HTTPS tarball dependencies will no longer resolve automatically you need --allow-git or --allow-remote.
A new min-release-age setting lets teams block freshly published package versions until they've existed for a configurable window, closing the door on attacks that rely on rapid adoption before detection.

Teams on npm 11.16.0+ can run npm approve-scripts --allow-scripts-pending today to see exactly which dependencies in their tree currently run scripts, approve the ones they trust, and commit that allowlist to package.json before the breaking change lands.

This directly targets a pattern that has repeated for years event stream, ua-parser-js, and colors but recently escalated sharply. A backdoored version of Axios (400 million monthly downloads) shipped a cross-platform RAT that executed roughly one second into installation, before dependency resolution even finished. The malicious version sat live for just over three hours before removal, plenty of time for mass compromise.

Why this matters more in an agentic world

Here's the part that should concern every security architect right now: the threat model just changed shape. It's no longer only humans running npm install.

AI coding agents Claude Code, Cursor, Cline, and similar tools now run package installs autonomously, around the clock, without a human watching the terminal. When a postinstall hook drops a remote access trojan, a human developer might notice something feels off. An agent reports "dependencies installed" and moves on to the next task because nothing in its interface signals that a detached background process just started beaconing to a command-and-control server.

Attackers have noticed. A few patterns worth knowing:

Config-file prompt injection:- Campaigns have planted hidden instructions including zero-width Unicode text inside .cursorrules and CLAUDE.md files. When a developer opens the project, the assistant reads these as legitimate project instructions and runs a "security scan" that quietly exfiltrates local secrets.
Documentation written for agents, not humans:- Researchers have found malicious packages with unusually persuasive READMEs written, it turns out, less to convince a human and more to read as an attractive match to an LLM evaluating which package satisfies a function it needs.
Compromising the agent's own automation:- In one disclosed case, a prompt-injection chain against an AI coding assistant's own GitHub issue-triage bot was used to steal the npm publishing credentials for that same tool, which were then used to push a malicious release to its own user base.
Evasion of script-based scanners:- Some campaigns have shifted the trigger mechanism away from the lifecycle hooks most tools watch (preinstall/postinstall) and into binding.gyp-driven native builds which is precisely one of the gaps npm 12 closes.

What this means for your architecture, not just your CI config

If you're designing platform guardrails, npm 12 gives you a real lever, but only if you build a process around it:

Run the readiness check now:- npm approve-scripts --allow-scripts-pending against your dependency tree today, before the breaking change lands in July, so you're not debugging broken builds under deadline pressure.
Don't let agent autonomy bypass review gates:- If AI agents in your environment can run npm install or --dangerously-skip-permissions, or similarly permissive flags, treat that as a privileged action requiring the same approval workflow as a human-initiated install not an exception to it.
Treat min-release-age as a CSPM control, not a developer inconvenience:- A short publish-to-install delay window is one of the few mitigations that works against worm-style campaigns that rely on rapid, automated adoption before detection.
Extend lifecycle-script awareness to CI/CD runners and AI agent sandboxes equally:- Several recent campaigns specifically targeted the credentials available inside build environments SSH keys, cloud tokens, and deployment secrets precisely because that's where blast radius is highest.
Audit what your agents are allowed to trust as "instructions":-If your coding assistant reads repo-level config files (.cursorrules, CLAUDE.md, equivalents) as authoritative, that's now an attack surface requiring the same scrutiny as any other trust boundary in your architecture.

The bigger shift

NPM 12 is a narrow technical fix to a specific execution path. But the underlying lesson generalizes well beyond JavaScript tooling, every automation layer you add CI/CD, IaC pipelines, AI agents inherits the trust assumptions of the layer beneath it, often invisibly. Zero Trust principles that we've applied for years to human identity and network access now need to extend to non-human actors, making installation and execution decisions on our behalf.

The npm ecosystem just decided implicit trust isn't good enough anymore. Worth asking the same question about every other automated decision-maker in your stack.

JFrog Pipelines

Ranjan Kumar Singh — Mon, 06 Apr 2020 07:11:54 +0000

What is JFrog Pipelines?

JFrog Pipelines is one of the most advanced DevOps automation solutions in Today's world to perform end-to-end automation tasks of building, testing, and deploying software as part of a system of (CI/CD).

Some Important concept of JFrog Pipelines

Steps

Steps are executable units that perform a specific task, such as building an application, pushing to an artifactory, Docker, AWS, GoogleCloud, etc. provisioning the machine on ubuntu_16.04, ubuntu_18.04, CentOS_7 and windowServer_2019, etc.

Resource

Resource typically contains information needed for a step in a pipeline to execute and can also be used to store information produced by a step. For example source code control system (Git Repository ), Image, FileSpec, HelmChart etc.
The available resource for Jfrog Pipelines are:
Aql, BuildInfo, DistributionRule, FileSpec, GitRepo, Image , ReleaseBundle, RemoteFile, VmCluster and Webhook.

Integrations

Integrations are used to connect your Pipelines workflows to third party platforms or services and manage secrets like tokens, passwords, configuration detail that are needed for Steps in a Pipeline to interact with the source.
All credential information is encrypted and maintained separately from the pipeline definition, and held in a secure storage.

The available integration types for Jfrog Pipelines are:
Airbrake, Artifactory, AWS Keys, Azure Keys, Bitbucket, Digital Ocean, Distribution, Docker Registry, External Webhook, File Server, Generic, Github Enterprise, Github, Gitlab, Google Cloud, Internal Webhook, Jira, Kubernetes, Newrelic, PEM Key, Slack, SMTP Credentials and SSH Key.

Pipelines

Pipelines is a collection of interconnected series and parallel steps to achieve an outcome.

Run

Run is an instance of Pipelines execution. The Pipeline Run Logs view of Pipelines provides the facilities to view the log of execution, test results, and other information for steps in the pipeline.

Unified Dashboard view of JFrog Pipelines

You can see each pipe and what is the status of its runs:

And for each task:

And even you can see the yml file that is used in each step:

Some of the important functionality of Steps

Generic Steps

A generic step is for general-purpose execution. The Bash and PowerShell steps, which execute any series of shell commands you specify, are the single generic steps for Linux and Windows runtimes, respectively.

Native Steps

Pipelines native steps, you only have to tell your automation server what to do, not how to do it. As part of the JFrog Platform, Pipelines natively knows the best way to publish your builds to Artifactory, as well as build and deliver release packages through Distribution. Native steps provide you quick building blocks to perform the everyday tasks that fill your Artifactory repositories.

Start your free trial on JFrog Platform

Hope this helps! :)

DevOps? In Today World!

Ranjan Kumar Singh — Sun, 26 Jan 2020 13:36:01 +0000

We have noticed that the word DevOps sparks confusion, especially for non-technical and many technical people. Sure, the word itself is a combination of two-word development and operations, but what is DevOps?

What is DevOps?

The word DevOps is a combination of two words development and operations. “Dev” refers to software application development, and “Ops” refers to IT operations. DevOps is a culture that improves collaboration between Software Development and IT Operations Team to deploy code to production faster in an automated & repeatable way.

DevOps process involves a lot of development, testing and deployment technologies for developing automated CI/ CD pipelines. Following are some of the famous DevOps tools:

GitHub, GitLab & Bitbucket – Source code management
Jfrog pipelines, Jenkins & TeamCity – Automation server, with plugins built for developing CI/ CD pipelines
Robotium & Selenium – Automation testing
Docker – Software Containerization Platform
Kubernetes – Container Orchestration tool
Chef, Ansible & Puppet – Configuration Management and Deployment
Lansweeper & Nagios – Continuous Monitoring

DevOps has four fundamental core values:- Culture, Automation, Measurement, and Sharing.
DevOps practice has five levels:- values, principles, methods, practices, and tools.

In any company developers, the team writes code for new products, features and bug fixes. In a traditional software development life-cycle process, it takes weeks for the Dev team’s work to be placed into production.

When the Development team code is finally deployed into the Production Environment, Some time unexpected errors or problems occur. This mostly happens because the Development team is focused on writing code for its Development Environment.

The Operations team is responsible for maintaining the uptime of the Production Environment. The tools that the Operation team uses to manage or administer servers might not be effective or efficient when the number of servers increases largely within the company.

This challenge affects how new code is deployed in the Production Environment which is why the Operations team usually requires code deployments to be scheduled and are allowed only once a month in most cases. Once the code is deployed into the Production Environment, the Operations team is responsible for error diagnoses or problems caused by the changes.

Adopt DevOps require a new mindset, tools, and skills. DevOps integrates developers and operations teams in order to improve collaboration and productivity by automating infrastructure, workflow, and continuously measuring application performance.

DevOps is The Secret to Doing More, Faster and Better.

DevOps can be implemented in

Automated Testing
Continuous Integration
Continuous Delivery

Automated Testing

Automated testing is a method in software testing that makes use of special software tools to control the execution of tests and then compares actual test results with predicted or expected results.

The process of using special automation tools to control the execution of software tests to compare the outcome with the expected results is called Automation Testing. It is used to reduce the testing time of complex activities like regression testing and other laborious or extensive testing processes in the software development cycle.

Continuous Integration

Continuous integration -> CI ->set of processes ->Build pipeline/CI Pipeline

Continuous integration is a DevOps software development practice where developers regularly merge their code changes into a central repository, after which automated builds and tests are run

Important benefits continuous Integration

Minimizes the human error
Faster Mean Time To Resolution
Smaller Backlog
Increase Team Transparency and Accountability
Reduce Costs
Easy Maintenance and Updates

Continuous Delivery

Continuous delivery is the important process of delivering the Updates/software to production in smaller increments, ensuring that the software can be released at any time. The main focus and objective of continuous delivery is to build, test and release to the customer bit faster and more frequently.

Important benefits continuous Delivery:-

Lower costs
Increases the number of deliveries.
Low-risk releases.
Minimize the risk of failure in production.
Reduces manual work.
Increases confidence in the team.
Higher quality
It enables the team to automate everything.
Better products.
Enables faster feedback.

Continuous Deployment

When software is deployed quickly into production since team members make sure the application goes through complete Automation or manual testing.

DevOps Team:-

Developer (Dev)
Quality Assurance (QA)
Operations (System Admin, Production support)

Benefits of DevOps:-

Shorter Development Time, Faster Innovation
Reduced Deployment Failures, Rollbacks, and Time to Recover.
Better Communication and Cooperation
Reduce Costs and IT Staff
Lower cost
Reduction of Bugs
Increase the rate of software delivery and faster time to market.
Good processes across IT and teams, including automation.
Cross-skilling and self-improvement.

Thanks!!