devopsy.kinsta.cloud

Category: Continuous Delivery

Continuous delivery is a software engineering discipline that allows organizations to consistently develop and release quality software at a rapid pace. It is achieved by automating the software development lifecycle, enabling tasks such as development, testing and release to occur concurrently and continuously.

The DevOps Standard Gives Teams a Shared Model for Software Delivery
A release can pass every pipeline check and still leave an organization uncertain about whether to proceed. Security evidence may exist in another system, the recovery plan may be incomplete, and nobody may own the final decision. The difficulty lies in how the delivery system connects its capabilities and responsibilities.

The new DEVOPS INSTITUTE Official Book: The DevOps Standard, published by PeopleCert on October 1, 2026, addresses that problem with a vendor-neutral definition and operating model. It gives practitioners a shared reference for examining delivery across organizational boundaries, including AI-assisted work. It helps teams identify which capability needs attention and what evidence would demonstrate improvement.

I served as the book’s lead contributor. PeopleCert and many professionals who reviewed the material helped shape a reference intended for use across different organizations and technology environments. The question is how that reference changes everyday decisions.

The book defines DevOps as:

“A socio-technical system that integrates people, process, and technology practices to support the efficient, safe, and reliable delivery of software-enabled products and services.”

That definition gives teams a concrete starting point. DevOps includes the working relationships, practices, and technical capabilities through which an organization changes and operates its products and services. It therefore reaches into design, leadership, security, release decisions, and production learning. A central automation team can contribute important capabilities while responsibility for delivery remains organization-wide.

Consider an illustrative change to an online retailer’s inventory availability service. AI helps an engineer implement a revised allocation rule, and automated checks pass. The organization still needs evidence that concurrent orders will behave correctly, that inventory data remains protected, and that operators can detect and contain incorrect availability information. Product ownership must establish whether it reduces overselling without rejecting valid orders.

Two Views of the Same Delivery System

The DEVOPS INSTITUTE Operating Model connects the DevOps Nine Pillars of Practices with a four-layer DevOps Architecture Blueprint. Continuous governance and feedback connect the work to delivered value, governed delivery, and organizational learning. The Pillars provide a practice view, while the Blueprint provides a delivery architecture view. Their relationship helps teams connect a capability problem to the places where it affects work.

The Nine Pillars are Leadership, Collaborative Culture, Design for DevOps, Continuous Integration, Continuous Testing, Elastic Infrastructure, Continuous Security, Continuous Delivery and Deployment, and Continuous Monitoring and Observability. Each includes people, process, and technology. They are interdependent, and the book does not prescribe implementing them in a fixed sequence.

For the inventory change, a testing weakness could originate in insufficient concurrency scenarios, unreliable environments, or unclear ownership of acceptance criteria. Buying another test tool would address only some possible causes. Looking across the relevant Pillars helps the team investigate the actual constraint before choosing an improvement.

The Blueprint’s four layers make the operating implications clearer:
- Elastic Infrastructure supplies consistent, scalable, secure, and recoverable environments.
- The CI/CD Pipeline integrates and validates changes while producing readiness evidence.
- Application Release Orchestration coordinates dependencies, risk decisions, exposure, and recovery.
- Value Stream Management connects work and investment to operational results and business outcomes.
A Pillar can contribute to several layers. Continuous Security, for example, influences environment configuration, pipeline validation, release decisions, and operational response. Teams should use the Blueprint to locate those contributions rather than assigning each practice to one isolated tool or department.

Applying the Model to a Release Decision

Follow the inventory change through these layers. The infrastructure must provide realistic validation conditions and controlled access to data. The pipeline should test the allocation behavior, preserve information about the change’s origin, and make its results available for review. Release orchestration should establish exposure limits, dependency readiness, and the response if the allocation rule behaves incorrectly.

Value Stream Management completes the view by examining the intended result. Did overselling decrease? Did rejected valid orders increase? What did support teams and production telemetry reveal? Those findings should influence the next engineering and product decisions.

Governance becomes more useful when teams design it into this flow. Define the evidence needed, who can accept residual risk, and which exceptions require escalation. Automate routine controls where appropriate, while preserving meaningful authority over consequential decisions. If approval still requires reconstructing evidence from scattered systems, improving that connection may matter more than accelerating compilation.

AI Increases the Importance of Explicit Evidence

The Standard places AI-assisted artifacts and decisions within the same delivery operating model as other work. AI involvement requires appropriate traceability, validation, security, and accountability. Teams should establish what an assistant or agent may do and what conditions require human review.

In the inventory example, AI-generated code still needs validation against the service’s expected behavior. An AI summary of release evidence also needs an identifiable basis and appropriate review before it supports a consequential decision. The organization should deliberately govern both artifact creation and decision support.

Begin With a Constraint You Can Demonstrate

A useful first step is to select one recent change and examine where work waited, evidence became unclear, or operational knowledge arrived too late. Map that constraint across the Pillars and Blueprint. Name an improvement owner, define the expected outcome, and measure whether the intervention helped. The book’s assessment guidance supports this conversation with evidence rather than relying on confidence or tool inventories.

For the retailer, the next improvement might be realistic concurrency testing or a dependable way to stop exposing the new rule. Success would mean a better-supported release decision and fewer harmful allocation outcomes. That is the practical purpose of a shared DevOps standard: helping people improve the delivery system through decisions they can explain and results they can demonstrate.

A free digital copy of The DevOps Standard is available at The DevOps Standard.
October 2, 2026
Talentica Software Unfurls Managed AI Service to Optimize Software Delivery

Talentica Software this week launched a managed software delivery service that leverages artificial intelligence (AI) to enable DevOps teams to deploy applications developed using AI coding tools at scale.

Company CTO Manjusha Madabushi said the DevX AI Pods service makes use of a set of AI agents that Talentica has trained to provide the context needed to successfully build and deploy applications using AI tools. Those agents analyze existing artifacts such as product requirement documents (PRDs), the codebase, test cases, and the underlying software architecture to ensure that the application developed using AI tools can actually run in a production environment, she added.

Specifically, AI agents leverage a Correctness, Consistency, Completeness and Relevance (CCCR) framework that Talentica developed to evaluate the code being created. That output is then validated by a team of more than 600 Talentica software engineers to ensure it meets the original criteria specified.

That approach enables AI agents to more holistically reason about the changes rather than implementing each one independently, said Madabushi. AI agents, for example, can map dependencies, reuse existing functionality, and perform root-cause analysis on failures.

The overall goal should not be to simply generate code quicker but rather to enable DevOps teams to reliably deploy higher-quality applications at a much faster rate, noted Madabushi. The issue that far too many DevOps teams are encountering is that while AI coding tools make it possible to generate more code than ever, they are not actually increasing the rate at which applications are deployed, she added. Additionally, AI tools tend to create a lot of duplicate code that eventually creates a level of bloat that impacts application performance, noted Madabushi. In effect, AI coding tools are actually increasing the amount of technical debt that DevOps teams need to eventually retire, she noted.

It’s not clear at what rate the rise of AI has actually resulted in more applications being deployed faster but there is clearly now no shortage of code. A recent Futurum Group survey found more than half (54%) now work for organizations that use AI across more than half of their software development lifecycle (SDLC), with 40% reporting AI already generates the majority of production code merged in the last 90 days. Within the next three years, a total of 58% expect AI to build 80% or more of their software. However, three-quarters of survey respondents (75%) have encountered a production issue that they have confirmed is attributable to AI, with 42% experiencing multiple incidents.

The challenge, of course, is that it’s difficult to determine how much of that code is making it into production environments and, potentially more troubling, was it validated before being incorporated into a software build. Each DevOps team will, of course, need to decide how best to manage the volume of code now being generated in the AI era. There is, at this point, little doubt that achieving that goal will require more reliance on AI to resolve all the coding issues now being created by AI.

September 24, 2026
New npm Threat Bypasses Install Script Protections

A malicious npm package that has been downloaded millions of times comes with a new way of spreading the malware that makes it easier to bypass security protections, say researchers with security vendor Checkmarx.

Rather than using more common preinstall or postinstall scripts, the bad actors instead created a malicious package – indexed-btree – that mimics the legitimate sorted-btree package and hides the malware in the package’s runtime code, according to Checkmarx security researcher Bruno Dias.

Indexed-btree “runs entirely from application code at runtime,” Dias wrote in a report. “Additionally, this package achieved almost 2 million weekly downloads, which shows not much has changed in the npm ecosystem despite the limitations put on lifecycle scripts.”

The latest malware targeting npm packages hides inside the Btree.prototype.set, the standard method in JavaScript B-Tree data structures. Because there’s no install hook inside the package.json file, installing the package does not launch any malicious activity. However, using the package can trigger the JavaScript code that includes the malware’s first stage.

The malicious package includes a heavily obfuscated file that includes a range of tasks, including fingerprinting and exfiltrating such host information as the operating system architecture, hostname, the CPU, and memory, which are then sent to a hardcoded Slack channel and Telegram chat.

It also uses an Ethereum smart contract on Sepolia testnet – a proof-of-stake (PoS) testnet that developers use to deploy and test smart contracts – as its command-and-control (C2) channel. The testnet “exposes getter and setter functions that the malware polls instead of requesting a plain domain,” Dias wrote, adding that the technique “is more resilient to domain [or] IP takedown than traditional C2 approaches, since it uses the smart contract as a pointer to a new address whenever the old one gets taken down.”

The malicious code includes the ability to delete its malware files and remove the trigger code to erase its traces.

Attacker Creates a GitHub Repository

Along with the decision to hide the malicious code by mimicking a legitimate package, the attacker also includes a seemingly legitimate GitHub repository that comes with realistic commits and an account. As of late last week, the repository was still up and the attack was ongoing, according to Checkmarx.

“A GitHub repository is something that attackers don’t usually bother creating,” Dias wrote. “This one is clever enough to not include the malicious code. Additionally, the presence of many commits can aid in making it look like a legit repository.”

In addition, while there is not much in the account in terms of activity or an in-depth bio, it does include an AI-generated photo, which is another way of giving the repository an air of legitimacy.

Checkmarx estimates that the bad actor was able to collect 109 ETH, or about $264,963.

Adapting to Defenses

“What makes this campaign particularly important is that it shows attackers adapting almost immediately to stronger software supply chain defenses,” SOCRadar CISO Ensar Seker said. “npm has improved install time security by restricting dependency lifecycle scripts, but this campaign demonstrates that attackers can simply move malicious execution into legitimate looking runtime functionality instead.”

A clean installation no longer leads to a clean dependency, Seker said, adding that software supply chain security now needs to extend beyond the reputation of a package and installation-time scanning. Defenders need to look at such areas as dependency provenance, unexpected code changes, runtime behavior, and outbound network connections.

“The broader lesson is that security controls change attacker behavior rather than eliminate the underlying threat,” he said.

September 22, 2026
Why Your CI/CD Pipeline Is Your Most Unprotected Attack Surface

Your team probably spends considerable effort securing your application. WAFs, rate limiting, input validation, penetration testing. Then code passes through a CI/CD pipeline that runs with privileged credentials, executes arbitrary code from third-party actions, has broad network access to internal systems, and logs secrets in plain text if someone makes one configuration mistake.

The pipeline that builds and deploys your secure application is itself the least secure system in your infrastructure.

Think about what a CI/CD pipeline actually is from an attacker’s perspective. It is a system that automatically executes code, often with administrative access to your cloud accounts, container registries, databases, and production environments. It pulls dependencies from the public internet. It runs plugins and actions written by strangers. It often has access to every secret needed to deploy to every environment. If you designed a system specifically to be an attractive target for supply chain attacks, you would design a CI/CD pipeline.

The XZ Utils backdoor was a masterclass in exploiting this exact attack surface. A patient attacker spent years building trust in an open-source project, then introduced a backdoor that would have propagated through build systems worldwide. That attack was caught by accident. The next one might not be. And your pipeline is running builds right now that pull in hundreds of dependencies, each of which is a potential vector.

Here is what a hardened pipeline actually looks like. First, pipeline credentials should be scoped to the minimum required for each stage, not a single service account that can do everything. Second, third-party actions and plugins should be pinned to specific commit SHAs, not tags that can be silently updated. Third, pipeline execution environments should be ephemeral and isolated, with no network access beyond what is explicitly required for that build step. Fourth, every pipeline run should produce a signed provenance attestation that can be verified independently.

Most organizations are nowhere near this. They are running Jenkins instances that have not been patched in months, GitHub Actions workflows that use community actions pinned to “latest,” and build agents with permanent credentials stored in environment variables. The gap between how seriously we take application security and how casually we treat pipeline security is the biggest unaddressed risk in modern DevOps. And it will take one high-profile breach through a CI/CD vector to make everyone suddenly care.

September 18, 2026
How I Consolidated Duplicate Delivery Pipelines With Parameters and Build Tags
Two modules in a repository had near-identical Azure DevOps build and release definitions. A third would have required another pair.

The delivery chain used five definitions: one change decider, two builds, and two releases. I consolidated it into one decider, one generic build, and one release with a deployment stage for each onboarded module. The count excludes package and pull request validation.

Figure 1. The consolidation removed one duplicated build and one duplicated release.

The Decider Passes the Module as a Run Parameter

The old builds repeated the same image and chart tasks with different module values. The releases repeated the same deployment tasks with different variable groups. A shared build change required matching edits in both build definitions, and a shared deployment change required matching edits in both release definitions. Adding another module would have required another build and release pair.

I named the shared definitions by product, service, scope, and kind:
```
<Product>.<Service>.<Scope>.<Kind>
```
The decider holds the only continuous integration trigger. It checks changed paths, then queues the generic build with the module and service as parameters. It also fans out shared build-input changes to every registered pair. An optional module value limits manual diagnostic runs.

The decider pins each child to the branch and commit it inspected. A later push cannot change what that child builds. It compares the current commit with its first parent because the protected branch receives changes through merges. Repositories that accept multi-commit direct pushes need to compare the before and after commit IDs from the build event.

The Azure DevOps Build REST API expects parameters as a JSON-encoded string. This reduced example shows the two routing fields and the escaping that preserves their inner quotes:
```
BODY="{\"definition\":{\"id\":$BUILD_ID},\
\"sourceBranch\":\"$(Build.SourceBranch)\",\
\"sourceVersion\":\"$(Build.SourceVersion)\",\
\"parameters\":\"{\\\"service\\\":\\\"$SERVICE\\\",\\\"module\\\":\\\"$MODULE\\\"}\"}"
```
The variables that receive those queue-time values must also retain Azure DevOps’s Settable at queue time option, stored as allowOverride: true. A cloned definition can lose that flag. The decider may identify the correct change, then fail when it hands the values to the child build.

Both registered modules resolve to the same generic build.

The Generic Build Adds the Routing Tag

The generic build has no continuous integration trigger. It receives the service and module, derives the image and chart names, publishes the artifact, and tags the run with a value such as module-b.

I first tried module:module-b, but Azure DevOps rejected the colon in the request path. The hyphenated form worked.

I kept the decider separate from the build because a combined design had triggered releases from dispatcher runs that contained no artifact. After the split, every successful generic build produced an artifact for the release.

Stage Conditions Select the Module After Release Creation

Azure DevOps supports tag filters on both the continuous deployment trigger and individual release stages. Each filter controls a different decision.

The definition trigger decides whether Azure DevOps creates a release. A module-a filter there prevents a module-b build from creating any release. The build stays green and the chain stops without a release record.

The stage artifact condition decides which deployment stage runs after Azure DevOps creates the release:
```
Release trigger
    tag filter: none

Module A stage
    artifact condition: module-a

Module B stage
    artifact condition: module-b
```
Every qualifying completion of the generic build on the configured branch creates one release. The tag selects the matching module stage. For the nonmatching stage, Artifact conditions not met is an expected skip rather than a deployment failure.

The same status can also describe a malformed condition, so the run summary alone cannot prove correct routing. The branch half adds another ambiguity: the interface displays a short branch name, while the stored condition uses a full refs/heads/... value. I checked the stored condition directly.

Figure 2. The parameter selects what the build produces. The tag selects which stage deploys it.

I Used the Other Workload as a Control

I tested the consolidated chain with a change for Module B in a nonproduction environment. The decider queued the generic build with Module B, the build added module-b, and Azure DevOps created one release.

The Module B stage completed successfully. The Module A stage reported Artifact conditions not met. I then checked Module A in AKS and confirmed that it still used its previous container image.

Renames Preserved Execution and Left Stale Labels

I renamed the definitions using the service naming scheme. Azure DevOps kept their IDs, so execution references remained valid. Seven build validation policies still displayed the old pipeline name, and I updated those labels separately.

A snapshot of the release definition taken one week later still held the former build name in its artifact metadata. The release continued to bind by ID, but its interface displayed stale text.

The duplicate definitions also carried deployment history. Azure DevOps returned HTTP 409 when I tried to delete a build because a release still retained runs from it. I disabled its trigger, removed the remaining references, and archived it.

Another Module Adds Three Configuration Items

Another module now needs one decider map entry, one variable group, and one release stage. The generic build derives its tag from the queue parameter, so the team adds no module-specific build or release definition.

The application and environment still require their own preparation, including code and Dockerfile support, a database, a broker vhost, variable values, and Kubernetes namespace resources.

Figure 3. A new module extends the chain without adding a build or release definition.

This pattern fits modules that share a repository, artifact type, build process, and deployment mechanics. A different artifact or approval process may need its own chain. Here, parameters carried the module values, and build tags selected the correct deployment stage.

References
September 16, 2026
Cloudsmith Extends Policies and Controls to Secure Application Binaries

Cloudsmith this week revealed it has expanded the policy management and continuous risk detection capabilities it makes available within its software artifact management platform to now include policy templates, cooldown policies, and expanded evaluation triggers.

Alison Sickelka, vice president of product for Cloudsmith, said these additions to the platform will make it simpler to prevent malicious packages from inadvertently being incorporated into the binaries that DevOps teams deploy in production environments.

For example, policy templates written in the Rego programming language can now be used to provide a set of baseline controls that are consistently implemented across a DevOps workflow.

Additionally, DevOps teams can now implement a set of cooldown policies that prevent any recently made available software package from being indexed. That capability ensures that only versions of a validated package are exposed to application developers, noted Sickelka. That’s crucial because many of those packages have been created by maintainers of open source software projects that are targeted by adversaries that have no shortage of time, patience and financial resources.

Finally, the expanded evaluation triggers now consider when a policy was created or updated as part of the metrics used alongside threat intelligence feeds to generate an alert. That capability helps ensure that policies are updated as the application development environment continues to evolve, said Sickelka.

Rather than trying to secure software supply chains by focusing mainly on the source code used to create binaries, Cloudsmith is making a case for applying policies to the binaries that cybercriminals are actually targeting. That approach ensures that application developers are not incorporating malicious packages spread, for example, through a compromised instance of the Axios Node Package Manager that resulted in malicious code being added to an application after it had been deployed, noted Sickelka.

In general, the way software supply chains are secured now clearly needs to evolve, added Sickelka. The days when DevSecOps teams could prioritize their efforts based on the severity ranking of a vulnerability are over. As business and IT leaders in the artificial intelligence (AI) era become more aware of threats to software supply chains, there is a lot more focus on preventing security incidents from occurring in the first place by ensuring malicious packages and other known vulnerabilities that can now be easily exploited don’t find their way into production environments, said Sickelka.

In fact, in many cases CISOs are now willing to fund the acquisition of the tools and platforms needed to secure software supply chains in the hopes of reducing the number of downstream incidents they might later need to respond to in the event of a cyberattack, she added.

Hopefully, the increased focus on software supply chains will result in more secure applications being deployed. In the short term, however, it’s probable there will be a significant amount of turmoil as cybercriminals leverage AI to exploit increasingly well-known weaknesses in software supply chains. The challenge and the opportunity now is to reduce as many of those potential incidents as possible by applying more rigorous policies and controls that, if properly implemented, should not slow down the pace at which modern software can be securely built and deployed.

August 18, 2026
Fast-Moving Shai-Hulud Attack Infects npm Packages with 2 Billion Monthly Downloads

Researchers at Aikido Security and Endor Labs are tracking a fast-spreading supply-chain attack that is compromising a wide range of npm software packages that combined have more than 2 billion installs a month and is stealing a wide range of secrets and other information.

According to Ilyas Makari, malware researcher with Aikido, the bad actor on the morning of August 4, compromised the GitHub account of jaredwray, the maintainer behind keyv, a key-value storage library with about 127 million weekly npm downloads, and then used that access to spread information-stealing malware across the entire package family.

“The compromise was carried out by pushing malicious files directly to the main branch and then immediately cutting a new release, meaning the poisoned versions were published to npm with valid provenance signed by GitHub Actions,” Makari wrote in a report.

Kiran Raj, security researcher and engineer with Endor Labs, wrote that “the pattern is consistent across them: an npm publishing token was stolen and used to push malicious versions, in most cases a CI or service-account token likely harvested from a build runner that had itself installed a poisoned dependency.”

It appears to be an attack linked to Shai-Hulud, the notorious worm that rose to prominence late last year and has continued to haunt developers and the open source software packages they use. After stealing a range of credentials and other information from victims’ systems, the data is exfiltrated to a public GitHub repository whose description says “Shai-Hulud: Here We Go Again.”

In his last update, Makari wrote that 868 packages across 1381 versions had been compromised by the malware. The packages combined account for more than 2 billion monthly installs.

Since Makari’s update, the worm has spread significantly. According to Charlie Eriksen, security researcher at Aikido, researchers are seeing 50 to 100 new packages infected every few minutes, reaching more than 1,280 packages.

A Fast-Spreading Infection

The massive attack is spreading so quickly that Aikido researchers couldn’t keep pace in their blog.

At one point, Eriksen posted to X that it had been about 25 minutes since the latest infected package appeared, though he predicted that “wave 2 of the attack will hit any minute now.” An hour earlier, he wrote that the attackers were “still trying to debug their attack” and were “deleting all issues posted about it in the repos.”

The threat actors were able to quickly scale their attack. The maintainer behind keyv also controls eight other packages, including caching utilities like flat-cache, with 565 million downloads a month, file-entry-cache (557 million a month), cacheable/utils (34 million), cacheable (29 million), cacheable/memory (28 million), and cache-manager (16 million).

Company Packages Infected

It’s also spreading to other maintainers and packages, including those of organizations such as online food and grocery delivery company Deliveroo, AI orchestration and automation platform vendor OneReach, and ServiceTitan, which makes cloud-based field service management software.

Also seeing their npm packages infected are Picsart, which offers an AI-powered photo and video editing platform, and Qlik, whose platform offers business intelligence, data integration, and other capabilities.

A Payload of Info-Stealers

According to Makari, every infected package received two files – setup.mjs and Math_Symbol.js, and a preinstall entry.

“Anyone who ran npm install against an affected version would have had setup.mjs execute automatically before their install completed,” he wrote. “setup.mjs is a heavily obfuscated dropper. Its only job is to silently download the Bun JavaScript runtime from github[.]com/oven-sh/bun/releases/download/bun-v1.3.13/ and use it to execute the real payload, Math_Symbol.js.”

Math_Symbol.js a 728 KB JavaScript file that is highly obfuscated and delivers credential stealers that grab secrets from victims’ systems, encrypts what it finds, and then exfiltrates it to the Shai-Hulud-flavored GitHub repository. Through the payload, the malware can move worm-like to infect packages of other maintainers who have installed one of the compromised packages.

Tokens, Secrets are Stolen

The payload also includes a number of credential extractors that each target a different secret store in a victim’s system. The stolen information includes npm and GitHub tokens, Amazon Web Services (AWS) credentials, Kubernetes secrets, HashiCorp Vault tokens, and Stripe and Slack tokens.

A scanner that can run on macOS and Linux systems runs about 200 glob patterns across a computer’s filesystem, looking for such information as private keys, SSH keys and configuration data, Terraform state files, Docker registry credentials, KeePass databases, and VPN and IDE configurations.

The malware skips over files that are greater than 5 MB and uses up to 64 concurrent reads.

“A generic regex engine is also applied across all scanned files, flagging PEM private keys, SSH public keys, Azure storage keys, database connection strings with embedded credentials, and generic key=value patterns matching common secret field names,” Makari wrote.

What To Do

Endor Lab’s Raj wrote that organizations need to pin or roll back infected packages to before they were compromised, use npm, yarn and pnpm overrides for keyv, flat-cache, and file-entry-cache – “they are usually transitive,” he wrote – and rotate credentials on any machine or runner that ran npm install after 09:30 UTC. That includes npm tokens, GitHub PATs, cloud keys, CI secrets, and Vault tokens.

They should also search lockfiles and CI logs for malicious versions, including devDependencies, and prefer –ignore-scripts in CI.

“It blocks this class of install-hook malware,” he said.

August 4, 2026
Building SOC 2 Compliant CI/CD Pipelines on AWS with GitHub Actions

CI/CD pipelines make developers’ lives easier and let them ship changes to end users faster. However, they are also part of compliance frameworks such as SOC 2, which require careful design to satisfy specific controls.

AWS Account Architecture

You don’t want to host all your environments, such as staging and prod, in the same AWS account but rather use a multi-account AWS architecture.

Each of your environments — dev, staging, UAT, prod — should live in its own separate AWS account, rather than having all of them share a single account. This way, you can have clean logical access controls (CC6.1).

Once each environment has its own account, a natural question follows: Where should your ECR repository live? Should you host one in each environment account or centralize it in a single account that all environments pull images from?

ECR Repository Architecture

You could host your ECR repository in the prod environment account, but ideally, you should create a separate AWS account for shared tooling and host your ECR repository there. Your pipeline should only have push access to that repository, scoped to the common account.

Each environment account (dev, staging and prod) then needs cross-account permissions to pull (not push) images from that shared repository. In the common account, create an IAM role that authenticates via OIDC and can push to the relevant ECR repositories. This role doesn’t need pull access.

An example permissions policy for that role is as follows:

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowECRAuth", "Effect": "Allow", "Action": "ecr:GetAuthorizationToken", "Resource": "*" }, { "Sid": "AllowPushToScopedRepos", "Effect": "Allow", "Action": [ "ecr:BatchCheckLayerAvailability", "ecr:PutImage", "ecr:InitiateLayerUpload", "ecr:UploadLayerPart", "ecr:CompleteLayerUpload" ], "Resource": [ "arn:aws:ecr:<REGION>:<COMMON_ACCOUNT_ID>:repository/myapp-*" ] } ]}

ecr:GetAuthorizationToken has to stay scoped to all resources since AWS doesn’t support restricting that specific action to a repository ARN. It’s how the ECR login token is issued. Everything else is locked to the specific repository naming pattern, not a bare wildcard.

The trust policy below is what actually enforces who can assume this role. It defines exactly which GitHub repository and branch is permitted to authenticate via OIDC. Without this scoping, any workflow in your GitHub organization could potentially assume the role.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::<COMMON_ACCOUNT_ID>:oidc-provider/token.actions.githubusercontent.com" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "token.actions.githubusercontent.com:aud": "sts.amazonaws.com" }, "StringLike": { "token.actions.githubusercontent.com:sub": "repo:<GITHUB_ORG>/<GITHUB_REPO>:ref:refs/heads/main" } } } ]}

The sub condition is what actually locks this down. It ensures that only workflows running against the main branch of this specific repository can assume the role. You can modify this role later or create new ones as you add more GitHub repositories and their corresponding ECR repositories.

Last, make sure ‘scan on push’ is enabled on your ECR repository. This ensures that every image is automatically scanned for known vulnerabilities the moment it’s pushed, rather than on a periodic schedule. It’s a direct piece of evidence for CC7.1 (vulnerability management).

ECR Life Cycle Policies

Set up life cycle policies so your ECR repository doesn’t grow indefinitely and rack up storage costs. Don’t use one blanket rule though, since untagged images, dev builds and promoted releases have different retention needs.

Expire untagged images within a few days; they have no ongoing value. For dev-tagged images, size the retention count to your actual dev cycle rather than guessing a fixed time window. If your team iterates through many builds before settling on one to promote, keep a larger count (500–1,000); if your dev cycles are short, a smaller count (100–200) is fine. For staging- and prod-tagged images, keep the last 100–200 releases regardless of age, since these serve as your audit trail.

{ "rules": [ { "rulePriority": 1, "selection": { "tagStatus": "untagged", "countType": "sinceImagePushed", "countUnit": "days", "countNumber": 3 }, "action": { "type": "expire" } }, { "rulePriority": 2, "selection": { "tagStatus": "tagged", "tagPrefixList": ["dev-"], "countType": "imageCountMoreThan", "countNumber": 200 }, "action": { "type": "expire" } }, { "rulePriority": 3, "selection": { "tagStatus": "tagged", "tagPatternList": ["*.*.*"], "countType": "imageCountMoreThan", "countNumber": 200 }, "action": { "type": "expire" } } ]}

ECR evaluates rules in priority order, and each image is expired by the first rule that matches it, so the order and tag prefixes matter. Adjust the dev- prefix and the numbers to match your own tagging convention and release cadence.

Now you can design your pipeline based on how your team works. Here’s one example, assuming you have dev, staging and prod environments.

CI/CD Pipeline Architecture Example

When a pull request merges into main, the pipeline deploys to dev. Use image tagging, for example semver, so each dev build gets a dev- prefix, a patch version and the last seven characters of the commit SHA. Dev image tags in ECR would look like this:

dev-0.2.1-a3f9c2edev-0.2.2-8d4b17f

Each of these tags should also be tagged in GitHub so you can show an auditor exactly which commit was running in a given environment at a given time.

Once you’re happy with a dev version and want to promote it to staging, use a manual workflow trigger that retags that specific dev image, passing the target minor version as a parameter (no commit SHA needed). For example, dev-0.2.2-8d4b17f gets a second tag, 0.3.0. This is the same image with two tags, not a new build, which is the point: You’re promoting the exact artifact that was tested in dev, not rebuilding it.

If you find that dev, staging and prod need genuinely different images, that’s usually a sign of a design problem elsewhere in the pipeline. The better fix is to parameterize whatever differs between environments (config, environment variables or feature flags) rather than building separate images per environment.

Say staging runs integration tests, load tests and whatever else is part of your pipeline, and you’re ready to promote to prod. Use another manual workflow trigger, ideally with a required approval step that retags the same image with a version bump. For example, 0.3.0 gets a third tag, 1.0.0. At this point, the same image carries three tags: dev-0.2.2-8d4b17f, 0.3.0 and 1.0.0.

Now you’re running the same artifact in prod that was tested in dev and staging. It’s also traceable back to the exact code version running on GitHub, satisfying CC8.1 (change management).

Conclusion

This covers a common CI/CD pattern, not a one-size-fits-all blueprint. Your account structure, tagging scheme and life cycle rules should reflect how your team actually works. Review this against your own SOC 2 scope and controls and adjust it where your workflow genuinely differs.

Keep in mind that this is only the CI/CD part of SOC 2 on AWS. Achieving complete SOC 2 compliance on AWS requires considering more details such as GuardDuty, Security hub and more tools.

July 24, 2026
FakeGit Targets AI Coding Agents with Malicious GitHub Repos

Threat actors continue to find new ways to incorporate AI into schemes aimed at luring developers into downloading malware from fake repositories.

The latest example involves almost 7,600 malicious GitHub repositories that are being used to distribute a loader and an information-stealer. The FakeGit campaign is nothing new, with Oleg Zaytsev, lead security researcher with Island, noting that it and SmartLoader have been haunting developers for years with false GitHub repositories that deliver the malware.

What’s new is that the bad actors behind FakeGit have added AI into the mix, with many of the repositories presenting as AI skills or Model Context Protocol (MCP) servers and driving exposure via AI registries. They’re part of a technique Island calls “AgentBaiting,” which happens when a developer sends out an AI agent to autonomously find something they can use within GitHub repositories.

“This brought an established malware operation into the workflows people and agents use to discover and install new AI capabilities,” Zaytsev wrote in a report. “An AI agent searching for a new capability such as a Skill or an MCP server can discover a campaign repository on its own, treat the attacker’s README as legitimate documentation, and hand the installation instructions to the user.”

Surfacing Malicious Repositories

Island researchers in tests found that Anthropic’s Claude Code, Google’s Gemini, and OpenAI’s ChatGPT all pitched malicious campaign repositories to developers without being shown a link, he wrote, adding that “a playbook built to deceive people now deceives the agents acting on their behalf.”

The 7,600 or so malicious GitHub repositories confirmed by Island were created by about 6,600 profiles, with some 1,400 of those tied to AI tools, agents, or workflows, and more than 800 posing as Skills or MCP servers that reach from tools in such environments as Gmail, WhatsApp integrations, Databricks, Jenkins, and Docker, according to Zaytsev.

As of this month, there have been more than 14 million downloads from about 200 of the campaign’s repositories. Tied to the campaign were thousands of other repositories that embedded malicious ZIP files directly in the project, where downloads aren’t publicly counted.

Fast-Scaling Campaign

That said, the AI-focused part of the campaign ramped up quickly, he wrote. According to GitHub creation dates, that started to build in March and peaked in April, when almost 300 such AI-related repositories were created.

“The repositories were designed to meet demand already forming around AI capabilities, borrowing the names and workflows of familiar consumer and enterprise tools,” he wrote. “That familiarity gave the malicious ZIP files a credible reason to be downloaded, while the README guided users or agents from what appeared to be routine setup into the SmartLoader attack chain.”

According to Island, the fraudulent repositories are made to resemble real projects, and at times are simply copies of them.

If a fake repository is chosen, the “Download Latest Release” button sends the developer to a malicious ZIP archive inside, which includes instructions for downloading, extracting, and running the application. This kicks off the attack chain, starting with a heavily obfuscated 300 KB Lua payload that is disguised as a text, icon, license, or data file.

Next Comes SmartLoader, StealC

From there, SmartLoader is dropped, which then deploys StealC, which can steal a range of information, including browser passwords and extension data, cookies, active sessions, screenshots, host information, and email and remote-access credentials.

“The malware chain itself is familiar,” Zaytsev wrote. “What changes is the route that leads to execution.”

That route is exploiting the autonomous capabilities of AI agents. The agent doesn’t need to be given a malicious link. Instead, it can discover a FakeGit repository itself, treat the README file as legitimate, and then send the bad actor’s instructions to the user. This is AgentBaiting, and the FakeGit operators built the AI-based lures around it.

Top Coding Agents Fall for It

The Island researchers tested it using Anthropic’s Claude Code developer assistant, watching the model search the web, follow results through an MCP marketplace and GitHub, and open two repositories. One was benign, the other a FakeGit repository in the malicious skills category. Claude Code recommended the benign repository, but saw the malicious one as a legitimate alternative.

In other tries, the AI model detected the malicious content in the fraudulent repository and didn’t recommend it.

“That variability is the point: it independently discovered a campaign repository and, in one run, turned its attacker-written README into actionable installation guidance,” he wrote. “At the scale of this campaign, even an occasional miss creates a path to malware execution.”

Tests on both Gemini and ChatGPT showed similar results.

No Breach Needed

Zaytsev stressed that the FakeGit operators didn’t have to breach anything in the campaign.

They “published convincing repositories, borrowed real developers’ identities, spread its listings across public registries, and let discovery do the rest,” he wrote. “With AgentBaiting, that discovery no longer requires a person at all: an agent searching for a Skill or MCP server can find the lure, read the attacker’s README, and carry its instructions forward.”

Organizations need defenses to interrupt the chain before it executes. That includes evaluating each new capability in an isolated environment first, verifying the publisher and the project, and keeping an eye on the paths AI agents go down.

Island researchers aren’t the only ones to detect such activity. Straiker AI in February reported a campaign using fake GitHub accounts to exploit the MCP ecosystem and a cloned Oura Ring server to sneak into developer environments with info-stealing malware. A month later, Derp.ca wrote about FakeGit distributing Lua-based malware through GitHub.

July 23, 2026
GitHub API Abuse, ‘Ghost’ Accounts Part of Malicious Efforts to Map Organizations

A cluster of coordinated and overlapping campaigns that have been running for several months is abusing GitHub’s API and leveraging dozens of “ghost” accounts that have been dormant for years to map organizations and their developers.

Many of the operations are using the API to scrape public information; some have gone further, including cloning private repositories, compromising users’ tokens, and, in one case, exfiltrating data from a private repository, according to researchers with Datadog.

The campaigns are not the result of a single bad actor, but what Julie Agnes Sparks, senior security engineer with Datadog, described as a “blend of custom automated scanner tools, opportunistic abuse of leaked credentials, and coordinated networks of burner (ghost) accounts.”

“Individually, most of these requests are unremarkable,” Sparks wrote. “They hit public endpoints, authenticate cleanly or not at all, and return successful responses. The concern lies in the aggregate: a group of accounts moving in sync across companies’ GitHub organizations with versioned custom tooling iterating over weeks, and in the worst case, actors that stopped enumerating and started cloning.”

Threat to Public Repositories

In the larger context, the coordinated campaigns are another example of how threat groups are increasingly targeting developer environments by compromising the code repositories – like GitHub, npm, and the Python Package Index (PyPI) – they rely on. Fortran noted that GitHub has become the “standard for version control and collaborative software development,” given that it hosts more than 420 million repositories and serves more than 150 million developers around the globe.

The threat is only growing. According to Jacob Malimban, cyber analyst with Cofense, the number of malicious campaigns against Git repositories has grown every year since 2021 – with almost 50% of the abuse during that time period happening in 2025 – primarily for credential phishing or to deliver malware.

Cofense found that 95% of the campaigns targeted GitHub, with 5% abusing GitLab. In addition, 58% delivered credential phishing, with the other 42% bringing malware.

No Authentication Needed

According to Datadog’s Sparks, much of what’s available through GitHub’s API can be reached without authentication. That includes an organization’s public repositories, its users’ followers and following lists, starred repositories, and organizational memberships. Likewise, running GraphQL queries against public objects can also bring in data. Given that all of these pathways are public, there’s no alert regarding authentication.

“An operator can build a detailed map of an organization, such as its public repositories, its members, who those members follow, and which projects they touch, entirely from public data,” she wrote. “This traffic blends into normal API usage.”

Another challenge is that with external resources, GitHub doesn’t collect geolocation data for events, which limits attribution based on where the signal is coming from and the VPN or proxy used. That said, the logs do record the GitHub actor that makes the request and the kind of access tokens they use.

The Use of Ghost Accounts

Another way the campaigns are keeping under the radar is through the use of ghost accounts. Datadog found more than 50 such accounts being used by the bad actors that have been left dormant for anywhere from two to five years before being activated to send API traffic to multiple organizations. Sparks noted that an account that’s existed for multiple years often is considered more legitimate than one registered the same week it begins scraping data.

The threat actors tend to use the ghost accounts for one to three weeks before their use ends. While in use, the accounts are given a mixture of names, from GitHub-Company-Scraper and GitHub-Scraper-Tool/1.0 to more benign-sounding names such as GitHubAnalytics/1.5.

Most of them target GraphQL, an open-source query language for APIs, while others look to REST, which Sparks said is what’s expected when talking about mapping organizations. It won’t give abusers access, but it will allow for reconnaissance.

Exposed Personal Tokens

Some campaigns used personal account tokens (PATs) exposed by users who posted them accidentally or had their systems compromised. One campaign between December and January used three stolen tokens from a progression of the same user agents and ran its infrastructure on a hosting provider, 3xK Tech, which has been the subject of several abuse reports.

“Dozens of distinct legitimate GitHub user accounts made API requests to a single organization within a window of only a few minutes,” Sparks wrote. “Their requests targeted private repository commit paths, and in this campaign, the attempts failed. The functional focus of this campaign was narrow and consistent: listing organization repositories, fetching commits, and probing private repository paths.”

There were a handful of cases in which campaigns were able to access data. In one, a user agent with the handle “repo-dumper” exfiltrated data from a private repository using a mix of Git cloning and API requests.

Keep an Eye on Indicators

Sparks wrote that among the indications of unauthorized activity in an organization’s environment are user agents, event activity, and actor names. Datadog researchers are detecting a rise in legitimate vibe-coded or custom tools that have names similar to user agents they’ve identified.

“It’s important to know what normal looks like in your environment,” Sparks wrote. “We suggest enabling GitHub audit log streaming, baselining your user agents, proactively threat hunting, and developing detections unique to your GitHub organization.”

July 14, 2026