Features Category

Security Depends On More Than Just The Operating System Hero Esm H240

security advisoryrisk managementpatch management

Does Linux Give Users a False Sense of Security? What This Year's Biggest Linux Security Incidents Actually Reveal

If more than 12 million enterprise systems can be exposed by flaws in a security control designed to harden Linux, it's probably worth asking whether Linux gives people a false sense of security. That's a question that has come up repeatedly throughout 2026. . This year alone, researchers have disclosed privilege-escalation vulnerabilities, root-level kernel flaws, and multiple supply-chain compromises affecting Linux environments. That doesn't mean Linux suddenly became insecure. It means that vulnerabilities still exist, trusted software can still be compromised, and security depends on much more than the operating system itself. Linux earned its reputation for security, but that reputation can sometimes lead people to assume they're safer than they actually are. Why Linux Earned Its Reputation It did not get that reputation by accident. The controls are real. They change how a system behaves after something goes wrong. They limit what a normal user can touch, what a compromised process can modify, and how much software is exposed in the first place. Permission separation: Keeps normal users and compromised processes away from root-level access. Open-source code: Can be inspected by researchers, maintainers, and security teams. Package managers: Centralized repositories make updates easier to distribute and discourage downloading random executables. Security frameworks: Tools like SELinux and AppArmor restrict what processes can do after they are already running. These aren't cosmetic advantages. They reduce exposure and slow down privilege abuse. The mistake is treating these controls as the end of the security conversation. When Advantage Becomes Misconception The misconception starts when those advantages get turned into assumptions. Fewer visible attacks get read as no attacks. Open source gets treated as if someone has definitely reviewed the code. Security features get mistaken for secure outcomes. The operating system gets all the attentionwhile identities, packages, and build systems sit in the background. That matters now more than ever: Trusted workflows: A malicious package doesn't need to defeat the Linux permission model if a developer installs it inside a trusted CI/CD pipeline. Credential exposure: An exposed credential does not care which distribution is running underneath it. Operational reality: A weak build system can leak secrets while the host OS behaves exactly as configured. The systems that stayed protected in 2026 were not protected because they ran Linux. They were protected because vulnerabilities were patched, dependencies were managed, and security controls were maintained. The Problem With Assuming Security by Default: Copy Fail The Copy Fail ( CVE-2026-31431 ) kernel flaw was a reminder that even core components are not exempt. It was a local privilege escalation, meaning an attacker with low-privileged access could move to root. What stood out wasn't the bug—privilege escalation happens in every major OS—but where it lived. Administrators weren't dealing with a neglected third-party package; they were patching a core component. The systems that stayed vulnerable didn't fail because Linux was insecure. The lesson wasn't about kernel design. It was about patch management. A vulnerability with a fix is no longer a software problem; it's an operational one. Mature Code and the Myth of Review: Dirty Frag Dirty Frag ( CVE-2026-43284 and CVE-2026-43500 ) affected mature networking components like IPsec ESP and RxRPC. These aren't experimental features. They are established parts of the networking stack. The assumption is usually: The component has been around forever. Large organizations use it. If something serious existed, somebody would have found it by now. Dirty Frag showed that complex networking code accumulates edge cases over time. Stability and security are related, but they are not the same thing. Public code can be examined by anyone, but that does not meaneveryone is looking at it. Old code earns trust; it does not earn immunity. Complexity as an Implementation Problem Sometimes a vulnerability is the result of architectural complexity. Sometimes it’s a single character. A 2026 kernel flaw came down to a small implementation mistake that created a privilege escalation path for containers. These bugs are frustrating not because they are common, but because they are ordinary. There was no failed security model. The problem was that inside a massive codebase, one small mistake survived long enough to become a vulnerability. The kernel contains millions of lines of code; complexity creates opportunities for mistakes, regardless of the review process. The Attack Surface Shifted The compromises involving Nx Console and the Mini Shai-Hulud campaign were notable because Linux often wasn't the target. The target was trust. Compromised packages: Can expose secrets within a build. Stolen credentials: Provide access to cloud infrastructure and Kubernetes environments. The human element: The XZ backdoor attempt showed that maintainer relationships and social engineering are as important as the code. Visibility helped uncover these problems, but visibility alone did not prevent them. That is why initiatives like SBOMs and software provenance are gaining attention. The goal is to make trust easier to verify. In several recent supply-chain incidents, organizations weren't breached through a kernel exploit at all. They were breached because trusted software, build pipelines, or credentials became part of the attack path. What Actually Protects Linux Systems The incidents of 2026 happened because vulnerabilities existed, software became complex, and trust relationships were abused. The OS matters, but what surrounds it matters just as much. For desktop users: Apply updates, enable MFA, and treat browsers as a primary attack surface. For self-hosters: Harden SSH, maintain a regular patching schedule, andreview which services are exposed to the internet. For developers: Audit dependencies, secure CI/CD pipelines, and scan containers before deployment. For enterprise admins: Prioritize identity protection, monitor endpoint visibility, and review supply chain controls. Notice how few of these depend on Linux specifically. That’s the point. Linux remains one of the strongest security platforms available. But the real danger is not choosing Linux. The real danger is assuming Linux removes the need for patching, monitoring, governance, and operational discipline. 2026 has already provided several reminders why. Want more Linux security news, vulnerability analysis, and software supply chain updates? Subscribe to the LinuxSecurity Newsletter and get the latest threats, advisories, and expert insights delivered directly to your inbox. Related Reading Linux Security Uncovered: Open Source, User Privilege, and Defense Tactics Why Linux Supply Chain Attacks Are Becoming a Nightmare for DevOps Teams Nx Console Supply Chain Breach Shows How Trust Becomes the Attack Surface . In 2026, Linux systems faced multiple security incidents highlighting the importance of patching and operational discipline.. Linux Security, Vulnerability Management, Incident Response, Cybersecurity Best Practices. . MaK Ulac

Jun 15, 2026 •

MaK Ulac

Supply Chain Risk Starts At The Workstation Hero Esm H240

security advisoryimportantsupply chain

Compromised VS Code Extension Puts Linux Development Pipelines at Risk

The compromise of Nx Console shows how much infrastructure now sits behind a single developer account. GitHub repositories, CI/CD pipelines, container build systems, Terraform projects, Kubernetes deployments. None of those systems was the initial target. The workstation was. . Attackers did not need a Linux privilege escalation bug or a remote code execution chain. They needed developers to trust a tool they were already using. For many organizations, that was enough. What Happened? Federal authorities confirmed the compromise in a public alert covering Nx Console and associated GitHub repositories. According to the CISA advisory, the incident was tracked under CVE-2026-48027 and involved supply-chain activity affecting development environments. The compromise centered on Nx Console, a popular extension used by developers working with Nx-managed projects. Rather than targeting production infrastructure directly, attackers inserted themselves into a trusted part of the software development workflow. That matters because extensions already operate with broad visibility into projects, repositories, and developer activity. Nx maintainers later published an incident timeline in their security update , including affected versions, discovery details, and remediation guidance. Users running impacted releases were instructed to remove affected versions and update immediately. At a high level, the attack followed a pattern security teams have been seeing more often over the last several years. Compromise a trusted component. Collect credentials. Use existing trust relationships to move deeper into the environment. No exploit chain required. Incident Overview Item Details Incident Type Supply-chain compromise Affected Component Nx Console CVE CVE-2026-48027 Primary Target Developer credentials Secondary Risk Repository and CI/CD compromise Potential Impact Source code, secrets, infrastructure access How the Attack Worked Modern development extensions have a surprising amount of visibility. They can read project files, interact with repositories, inspect build processes, and in some cases, access authentication material already present on the system. That trust model exists for convenience. Attackers understand that. Research discussing the broader attack methodology, including credential theft and GitHub-focused abuse techniques, was later examined by Microsoft Threat Intelligence in its security research. The mechanics vary between incidents, but the objective rarely changes. Collect credentials that provide access to systems developers already use every day. GitHub tokens are particularly valuable because they collapse multiple attack stages into one. Instead of breaking into a repository, an attacker authenticates. Instead of probing infrastructure, they inspect deployment workflows and secrets already stored inside the environment. The token becomes the foothold. From there an attacker may be able to: Clone private repositories Review deployment workflows Access package registries Harvest CI/CD secrets Modify build pipelines Publish malicious code updates Establish persistence through automation None of those actions require root access on a Linux workstation. Sometimes they do not require touching the workstation again. Why GitHub Tokens Matter GitHub stopped being just a source code platform years ago. For many organizations, it functions as the operational center of the environment. Infrastructure definitions live there. Deployment workflows live there. Kubernetes manifests, Helm charts, Terraform projects, Ansible playbooks, cloud automation scripts. Same place. The value of a stolen token depends on permissions. The problem is that developers often need extensive permissions to do their jobs. A single account may have access to: Private Repositories: Source code theft GitHub Actions: Pipeline manipulation Package Registries: Malicious Releases Organization Secrets: Credential Exposure Infrastructure Repositories: Cloud and platform visibility Deployment Automation: Unauthorized changes That is why developer accounts keep showing up in modern attack chains. They sit between development and production. Attackers know it. The Linux Security Impact This is not really a VS Code story. It is a Linux infrastructure story that happens to begin inside a development tool. Many affected users run Linux workstations because they manage Linux environments. Ubuntu systems administering Kubernetes clusters. Fedora laptops maintain cloud infrastructure. Debian workstations managing CI/CD pipelines. Different distributions. Similar trust relationships. The workstation becomes the first hop. A compromised developer machine may expose: GitHub tokens SSH keys Cloud credentials Kubernetes configuration files Internal repositories Build automation scripts Not every stolen credential leads directly to production. Enough of them do. Teams often focus heavily on server hardening while developer systems quietly accumulate administrative access across multiple environments. An attacker does not necessarily need local privilege escalation when repository permissions already open the next door. CI/CD Pipelines Build systems represent one of the highest-value targets in a software environment. Once repository access is established, workflow definitions become attractive targets. A modified pipeline can collect secrets, alter builds, inject code into releases, or create long-term persistence that survives workstation cleanup. Those investigations get expensive fast. Containers and Kubernetes Container environments depend heavily on automation. Repositories define what gets built, where it gets pushed, and how it gets deployed. Attackers increasingly target the pipelinerather than the cluster itself. Modifying trusted deployment paths is often easier than breaking through cluster defenses. Infrastructure-as-Code Repositories Terraform and Ansible repositories frequently contain the blueprint for an entire environment. Even when secrets are managed correctly, those repositories reveal architecture, permissions, cloud services, deployment patterns, network layouts, and operational processes. An attacker can learn a great deal before ever launching a second-stage attack. The initial compromise happens on a workstation. The visibility gained afterward can extend across an entire organization. What Linux Developers Should Do Now The immediate priority is determining whether affected extension versions were installed and whether repository credentials may have been exposed. Organizations should review guidance published by Nx, GitHub, and CISA while treating exposed credentials as compromised until proven otherwise. Extension Review Remove affected extension versions Update to verified releases Review installed development extensions Check for unexpected modifications Credential Response Rotate GitHub personal access tokens Revoke unused credentials Review OAuth integrations Replace exposed secrets Repository Audit Review commit activity Inspect branch protections Check workflow modifications Examine the package publication history Investigate unusual logins CI/CD Review Rotate pipeline secrets Audit service accounts Validate deployment workflows Review recent build activity Lessons for Open Source Security Supply-chain attacks keep succeeding because they exploit trust that already exists. Developers trust extensions. Pipelines trust repositories. Production systems trust deployment workflows. Attackers do not need to build those relationships. They inherit them. That shift changes how Linux defenders need to think about risk. The boundary is no longer theserver. It is the entire path that leads to the server. Extension ecosystems, package registries, source repositories, CI/CD platforms, and developer workstations all sit inside the same attack surface now. Treating them as separate problems creates blind spots that attackers are increasingly willing to exploit. Conclusion The most important detail in this incident is what was not exploited. There was no Linux kernel vulnerability. No container escape. No exposed daemon is listening on the internet. The attacker gained leverage through a trusted development tool and moved through existing trust relationships from there. As more infrastructure becomes defined through GitHub repositories, containers, Kubernetes deployments, and infrastructure-as-code projects, developer workstations continue to increase in value. They hold credentials. They control pipelines. They connect directly to the systems organizations depend on every day. That makes them a target. Related Reading GitHub Actions Compromise CI/CD Supply Chain Risks Explored Why CI/CD Pipelines Are Targets in Software Supply Chain Attacks Risks of GitHub Repo Breach on Linux Supply Chain Security Why Linux Supply Chain Attacks Are Becoming a Nightmare for DevOps Teams GitHub Actions Linux Self-Hosted Runners Security Risks Open-Source Supply Chain Attacks Threaten Linux Production Systems . Attackers did not need a Linux privilege escalation bug or a remote code execution chain. They neede. compromise, console, shows, infrastructure, behind, single, developer, accoun. . MaK Ulac

Jun 03, 2026 •

MaK Ulac

security advisoryRed Hatimportant

Red Hat npm Package Compromise Highlights a Growing Supply Chain Problem

Researchers investigating a campaign now tracked as Miasma found that more than 30 packages in Red Hat's @redhat-cloud-services npm namespace had been altered to deliver credential-stealing malware. . The packages weren't being used to deploy ransomware or sabotage systems. From what has been reported so far, the objective appears to have been much simpler: collect credentials from developer environments and use that access elsewhere. GitHub tokens, cloud credentials, SSH keys, and other secrets were reportedly among the targets. That's not particularly surprising. Development environments tend to end up with access to far more systems than anyone originally planned for, especially once build automation, cloud services, and deployment tooling start getting layered on top of each other. The question usually isn't whether useful credentials exist. It's how many are sitting there and what they can reach. By the time someone starts inventorying what a CI runner can reach, the answer is often more than expected. Red Hat says it has not identified customer or partner impact, and the investigation is still underway. The compromise is notable less because of the malware itself and more because of where it showed up. A package repository sits in a place most organizations have already decided to trust. Once that trust relationship gets involved, the discussion usually shifts away from malware and toward access, validation, and how much confidence teams should place in automated software distribution. A Trusted Namespace Becomes an Attack Vector According to researchers, the compromised packages were distributed through Red Hat's @redhat-cloud-services namespace on npm. That detail matters because software teams often make decisions about risk based on reputation. Packages maintained by a well-known vendor naturally receive more trust than those published by an unknown developer. Compromising a trusted namespace gives malicious code a much better chance of reaching developer workstations, buildservers, and automated deployment environments without raising immediate suspicion. The goal is not necessarily widespread infection. Access to a handful of well-positioned systems can be enough. Investigators believe the campaign affected dozens of package versions across multiple projects. Those packages were primarily frontend libraries rather than customer-facing Red Hat products, but frontend dependencies are routinely pulled into enterprise development workflows. Once a malicious package enters a build process, the attack surface expands quickly. How Miasma Targets Linux-Based Environments Unlike traditional malware campaigns that focus on persistence or disruption, Miasma appears to have been built around credential collection. The malware searched infected Linux systems for the files and environment variables that DevOps teams rely on daily: SSH keys: Stored in ~/.ssh. Registry credentials: Found in files like ~/.npmrc and ~/.docker/config.json. Cloud credentials: Stored locally or exposed through metadata services. Kubernetes configuration files , such as ~/.kube/config. CI/CD secrets: Injected directly into runners through environment variables. For an attacker, these files represent immediate opportunities for lateral movement. A GitHub token may provide access to private repositories. A Kubernetes credential can expose cluster resources. Cloud access keys may unlock storage buckets, deployment pipelines, or administrative functions. Each credential becomes another step deeper into an environment that already trusts the user or service associated with it. That strategy also generates less noise than many conventional attacks. Security teams often have detections for privilege escalation attempts, malware execution, and suspicious binaries. Legitimate credentials present a different challenge. Activity performed with valid authentication frequently blends into normal operations, especially inside busy development environments where automation is alreadyperforming thousands of actions every day. CI/CD Pipelines: The Prime Target for Linux Operators One of the most concerning aspects of this incident involves how the packages were published. Researchers believe the attackers abused GitHub Actions trusted publishing workflows using OIDC rather than stealing a traditional npm authentication token. This highlights a shift in supply chain risk. Security controls designed to eliminate long-lived credentials are becoming the new target. An attacker who gains access to a publishing workflow effectively inherits the permissions of that workflow. Since those workflows are already authorized to push updates to official namespaces, the attacker doesn't need to break into the publishing process. The publishing process becomes the attack path. Trusted publishing has become increasingly popular because it removes long-lived credentials from deployment workflows. Instead of storing permanent tokens, systems establish trust relationships between source repositories, build pipelines, and package registries. The benefit: The model is generally more secure. The risk: Those trust relationships become valuable targets. An attacker who gains access to a publishing workflow may not need the credentials at all; the workflow already possesses the permissions required to publish software. In effect, the trust relationship becomes the credential. Why Linux Teams Should Care Modern software development doesn't just run on Linux. Most of the infrastructure responsible for building, packaging, signing, and deploying software relies on Linux systems. DevOps teams Build runners serve as the bridge between source code and production. If those runners operate with excessive permissions, a single dependency update can expose an entire CI/CD pipeline. Linux administrators The servers responsible for compiling, packaging, and deploying software often contain some of the most valuable credentials in the environment. They deserve the sameattention as production systems. Kubernetes operators Compromised build pipelines can provide a path into clusters through service account tokens or deployment automation. An attacker doesn't need direct access to the cluster if the pipeline already has it. Security teams Traditional perimeter defenses provide little protection when trusted systems begin performing malicious actions using valid credentials. What Linux Organizations Should Review Now Rather than waiting for the next supply chain notification, organizations should use incidents like Miasma as an opportunity to examine their own Linux-based development infrastructure: Audit build runner permissions: Use a least-privilege lens to review what your runners can access (cloud accounts, SSH keys, registries). Focus on runner isolation: Use container isolation, workload separation, and credential scoping to limit how far an attacker can move after gaining a foothold. Apply Linux-native security controls: Use SELinux or AppArmor to restrict process access, seccomp filtering to reduce dangerous system calls, and read-only filesystem configurations to impede unauthorized modifications. Monitor package changes: Many supply chain attacks begin long before code reaches production; dependency monitoring should be as critical as production workload monitoring. Reconsider trust: Trust remains necessary, but it should never replace verification. The Real Lesson The Red Hat compromise wasn't significant because attackers found a new way to steal credentials. Those techniques have existed for years. What makes this incident noteworthy is that the attack leveraged systems and workflows organizations already trusted. Package repositories, CI/CD pipelines, publishing workflows, and automated deployment systems have become attractive targets because compromising them allows attackers to inherit existing trust relationships rather than create new ones. The Linux supply chain is deeper and moreinterconnected than many organizations realize. Protecting it requires acknowledging that the most dangerous threats may not arrive through an exposed service or an unpatched vulnerability. They may arrive through the same trusted mechanisms used to deliver software every day. Related Reading GitHub Actions Compromise CI/CD Supply Chain Risks Explored Why CI/CD Pipelines Are Targets in Software Supply Chain Attacks Linux Supply Chain Attacks Threaten DevOps Teams and Security GitHub Actions Linux Self-Hosted Runners Security Risks . The packages weren't being used to deploy ransomware or sabotage systems. From what has been reporte. researchers, investigating, campaign, tracked, miasma, found, packages. . MaK Ulac

Jun 02, 2026 •

MaK Ulac

GitHub Actions Runners In Linux Hero Esm H240

security advisorylinuxsupply chain

GitHub Actions Compromise CI/CD Supply Chain Risks Explored

For years, most software supply chain attacks focused on malicious dependencies and vulnerable open-source packages. Recent GitHub Actions compromises exposed a different problem entirely. Attackers increasingly target the automation systems responsible for building, testing, and deploying software because those systems often hold broader operational access than the applications themselves. . Several recent attacks demonstrated how compromised workflows, poisoned GitHub Actions, and malicious CI/CD automation can expose deployment secrets, cloud credentials, and package publishing systems without triggering obvious operational failures. Instead of targeting production systems directly, attackers increasingly focus on the workflows already trusted to access them. That shift turned GitHub Actions into a growing attack surface across Linux-based CI/CD environments, especially in organizations where runners already sit close to Kubernetes clusters, cloud infrastructure, and production deployment pipelines. The broader strategic shift is significant: while earlier attacks sought to poison software code, modern CI/CD attacks focus on the automation systems distributing and deploying that software. Compromising the pipeline provides direct access to infrastructure and release systems simultaneously. Why GitHub Actions Became an Attractive Target GitHub Actions became widely adopted because it simplified modern software delivery. Developers could automate testing, vulnerability scanning, container builds, release management, infrastructure deployment, and package publishing using reusable workflows assembled quickly from public repositories. For Linux-heavy development environments running cloud-native infrastructure, the flexibility made adoption almost inevitable. As workflows expanded, they gradually accumulated access to: cloud deployment credentials, Kubernetes environments, internal repositories, package publishing systems, infrastructure automation tooling, containerregistries, and production release pipelines. A typical Linux-based CI/CD environment may contain AWS credentials, GitHub Personal Access Tokens, DockerHub authentication keys, PyPI or npm publishing secrets, Terraform state files, and SSH deployment keys stored inside encrypted workflow variables so automation can authenticate automatically during runtime. That large concentration of privileged credentials and infrastructure access changed the value of CI/CD systems entirely. Compromising the pipeline often provides broader infrastructure reach than compromising a single production server directly, particularly in environments where workflows already manage deployments and infrastructure changes across multiple systems. The problem becomes larger when organizations rely on reusable third-party GitHub Actions, inheriting trust relationships automatically without reviewing how those dependencies change over time. The GitHub Actions Compromises That Changed the Conversation One of the clearest examples arrived during the compromise of the widely used GitHub Action tj-actions/changed-files . The action performed a relatively simple task—identifying file changes—but it was deeply embedded inside thousands of production deployment pipelines. Attackers did not target those repositories individually. Instead, they compromised the shared dependency already trusted across them. Once the malicious changes propagated downstream, affected workflows continued running normally. Most organizations saw no obvious deployment failures or disruptions because the workflows still completed successfully in the background. The malicious activity focused on exposing secrets already available inside the CI/CD environment through workflow logs and runner execution. Depending on the environment, compromised GitHub Actions tokens may provide access to: cloud infrastructure administration, deployment automation, Kubernetes clusters, package publishing systems, internal repositories, orproduction release tooling. Investigators later connected the incident to a broader chain of compromises involving additional GitHub Actions dependencies, including reviewdog/action-setup . This demonstrated how quickly one compromised automation component can spread through thousands of environments before defenders fully understand where the original trust relationship failed. Why GitHub Actions Abuse Is Difficult to Detect One of the reasons GitHub Actions abuse became such a serious supply chain problem is that the activity rarely resembles traditional intrusion behavior. The workflows continue operating normally, builds still succeed, and deployments still complete successfully. Because the malicious code executes inside trusted automation, defenders often see: legitimate GitHub Actions runners, approved repositories, valid deployment credentials, and expected CI/CD activity patterns. That operational normalcy makes malicious workflow behavior difficult to separate from ordinary automation tasks. Why Traditional Security Monitoring Often Misses CI/CD Abuse Many traditional security controls focus heavily on: endpoint compromise, malware execution, privilege escalation, or suspicious interactive logins. CI/CD abuse frequently bypasses those assumptions entirely because attackers operate through already trusted automation systems using legitimate credentials that the workflow already possesses. In practice, defenders may only discover the compromise after: unauthorized package publishing, suspicious outbound requests, unexpected cloud API activity, or downstream software tampering. By that point, the malicious workflow may have already exposed secrets or modified deployment artifacts across multiple environments. How a Compromised Workflow Escalates To see the operational impact, consider a typical Kubernetes deployment pipeline. A single compromised GitHub Action can allow an attacker to simultaneously expose cloudIAM credentials, kubeconfig files, and container registry tokens. That combination allows attackers to: replace trusted container images during deployment, modify deployment artifacts before release, access internal repositories, or publish poisoned software packages downstream. In many environments, the CI/CD runner already has enough trusted access to perform these actions without triggering traditional intrusion alerts. Because these workflows resemble ordinary automation updates, many repositories initially show few obvious signs of compromise. How Mutable Tags Became a Major Security Problem Many recent GitHub Actions attacks relied on a surprisingly simple workflow weakness: mutable version tags. Large numbers of repositories still reference reusable GitHub Actions using tags such as: uses: tj-actions/changed-files@v35> At first glance, that configuration appears stable. The problem is that version tags can later be modified if attackers gain access to the repository, maintaining the Action. A typical compromise chain may look like this: Attackers compromise the Action maintainer account. A trusted version tag is redirected toward malicious code. Thousands of downstream workflows automatically consume the update. CI/CD secrets become exposed during workflow execution. Attackers pivot into cloud infrastructure or package publishing systems. That trust propagation is what makes CI/CD compromise scale so quickly across the software supply chain. This distinction became extremely important during several recent compromises because many organizations focused heavily on reviewing commits inside their own repositories while paying far less attention to external automation dependencies. A hardened configuration pins directly to an immutable commit hash instead: uses: tj-actions/changed-files@24d32ffd492484c1d75e0c0b894501ddb9d30d62> Once pinned to a commit hash, attackers cannot silently redirect the workflow toward newer maliciouscode unless maintainers explicitly update the reference themselves. Why Linux Runners Became High-Value Targets Most modern CI/CD infrastructure runs heavily on Linux-based environments. Linux runners now handle container builds, Kubernetes deployments, and cloud provisioning across many enterprise pipelines. This operational role makes Linux runners—especially self-hosted runners—high-value targets. Some attacks specifically targeted self-hosted runners because persistent environments often retain: cached credentials, deployment keys, temporary artifacts, shell histories, and environment variables between jobs. Unlike ephemeral cloud runners that disappear after execution, persistent systems may continue exposing sensitive data long after the original compromise finishes. Furthermore, some organizations allow self-hosted runners to share network access with internal infrastructure or Kubernetes control planes. Once attackers compromise the workflow environment, the runner may become a pivot point for deeper lateral movement inside the organization. What Security Teams Should Change Immediately The recent GitHub Actions compromises reinforced the need to treat CI/CD workflows like privileged infrastructure. Security teams should prioritize the following hardening steps: 1. Identify Mutable Tags Review whether your environment still uses version tags rather than commit hashes: grep -R "uses: .*@v" .github/workflows/ 2. Enforce Least Privilege. Many GitHub Actions environments still run with broader repository access than they require. Avoid permissions: write-all and move to a safer baseline: permissions: {} Then explicitly grant only the permissions required, such as: permissions: contents: read 3. Implement Workflow Reviews: Require mandatory code review approval for any changes to workflow files. Modifications to .github/workflows/ should be treated with the same scrutiny as production infrastructure changes. 4. Additional HardeningMeasures Prefer short-lived OIDC authentication over long-lived cloud credentials. Isolate self-hosted runners from sensitive internal networks. Restrict pull_request_target usage to prevent secret exfiltration. Regularly audit third-party Actions for unexpected ownership changes. GitHub Actions Abuse Is Still Expanding GitHub Actions workflows now sit directly inside the software supply chain. They build applications, publish packages, and deploy infrastructure across production systems every day. That operational position makes them extremely attractive targets. The recent compromises were not isolated incidents. They exposed a broader issue where trusted automation inherits far more infrastructure access than defenders realize. For Linux-heavy infrastructure running cloud-native workloads, the risk is significant because the same runners handling workflows sit close to production systems already. In many modern environments, compromising the pipeline now provides faster access to production than compromising production directly. . GitHub Actions compromises expose critical security risks in CI/CD pipelines, highlighting supply chain vulnerabilities.. GitHub Actions, CI/CD Security, Automation Vulnerabilities, Supply Chain Risks. . Dave Wreski

May 26, 2026 •

Dave Wreski

When The Pipeline Becomes The Target Hero Esm H240

infrastructure securitycredential theftsupply chain

Why CI/CD Pipelines Became Targets in Software Supply Chain Attacks

For years, software security discussions centered on vulnerable code. A bug inside an application could expose a workstation, production server, or cloud workload, so most supply chain conversations focused on malicious packages, outdated dependencies, and exploitable libraries buried somewhere inside the stack. That is no longer the main problem. . A single compromised GitHub Action can quietly hand attackers the same infrastructure access senior administrators use to deploy production systems, publish software updates, manage cloud workloads, and rotate secrets. In many environments, the pipeline now holds broader operational access than the engineers maintaining it. Attackers realized they often do not need to exploit software directly when they can steal the credentials used to build, deploy, and publish it instead. As CI/CD pipelines became the backbone of modern development, they also became one of the most attractive targets in the software supply chain. The shift changed the nature of software supply chain attacks. Instead of poisoning code alone, attackers increasingly target the automation infrastructure responsible for building and delivering trusted software in the first place. CI/CD security is no longer a DevOps problem sitting quietly in the background. It is now core infrastructure security. Pipe-Psiphon and the Shift Toward Credential Theft In early 2026, a campaign known as Pipe-Psiphon showed how effective that transition had become. A widely used developer scanning tool was modified with malicious code that blended directly into normal CI/CD workflows. Nothing crashed. Most organizations saw no obvious alerts, failed deployments, or unusual system behavior during the initial compromise window. The tool simply operated inside runner environments and waited. Each pipeline execution gave it another opportunity to scrape secrets directly from memory, including GitHub tokens, AWS credentials, npm authentication keys, SSH material, and deployment secrets. The collecteddata was then transmitted to the attacker-controlled infrastructure while workflows continued running normally in the background. What made the campaign dangerous was not the malware sophistication alone. The compromised tool inherited the same trust relationships already granted to the pipeline itself, including deployment access, cloud permissions, package publishing authority, and repository automation privileges. By that point, the code being scanned mattered less than the infrastructure performing the scan. The trust sitting behind the pipeline had become the real target. The Assembly Line Behind Modern Software Understanding why these attacks work starts with understanding what CI/CD actually does. CI/CD, short for Continuous Integration and Continuous Delivery, functions as the automated assembly line behind modern software development. Developers push code into GitHub, GitLab, or internal repositories, then automated workflows begin testing applications, scanning dependencies, building containers, publishing packages, and deploying updates into production infrastructure. Most organizations rely on this automation heavily because it removes manual deployment work. Developers no longer need to log into servers directly every time software changes. Pipelines handle most of the operational work automatically. Convenient, but dangerous. The pipeline itself needs privileged access to function, which means CI/CD environments gradually accumulate credentials tied to cloud infrastructure, repositories, package registries, Kubernetes clusters, deployment tooling, and production systems. A typical environment may contain: AWS credentials for deployments DockerHub authentication tokens SSH keys for infrastructure access GitHub Personal Access Tokens npm publishing credentials Kubernetes configurations and Terraform state files Most of those secrets live inside environment variables or encrypted secret stores so workflows can authenticate automatically atruntime. Teams add more access over time because deployments fail without it, and eventually the pipeline ends up holding broader operational reach than many individual administrators. Attackers noticed that years ago. GitHub Actions Wake-Up Call One of the clearest previews arrived in March 2025 during the compromise of the widely used GitHub Action tj-actions/changed-files . The tool itself handled a relatively simple task. It identified which files changed during workflows so automation logic could react accordingly. More than 23,000 repositories depended on it, many of them deeply embedded inside deployment pipelines. Attackers did not target those repositories one by one. They compromised the shared dependency already trusted across thousands of environments, then modified the action so it quietly exposed secrets available during workflow execution. Some credentials leaked directly into public workflow logs. Other attacks relied on memory scraping techniques against active CI/CD runners, pulling secrets from live environments while jobs continued executing normally. The credential exposure mattered less than the access attached to those credentials. Investigators later connected the incident to a broader campaign affecting at least 218 repositories, including systems associated with Coinbase. Researchers also identified compromises tied to another dependency, reviewdog/action-setup , which widened the supply chain impact even further. Supply chain attacks scale differently from ordinary intrusions. One compromised automation component can spread through thousands of downstream environments before defenders fully understand where the trust boundary actually failed. Why Credentials Became the Real Target Older cyberattacks often focused on disrupting systems or exploiting software vulnerabilities directly. Modern supply chain operations increasingly revolve around stealing trusted access instead. A compromised personal password may expose a single account. A compromisedCI/CD credential can expose the infrastructure responsible for building and distributing software across an entire organization. That access may include: Cloud infrastructure administration Deployment pipeline control Software publishing permissions Kubernetes cluster access Package signing capabilities Administrative access across repositories and workloads For attackers, that level of access is usually far more valuable than compromising one server through a traditional exploit. Later CI/CD compromises involving Aqua Security's Trivy GitHub Actions infrastructure reportedly exposed GitHub tokens, Kubernetes configurations, Terraform state files, SSH keys, shell histories, VPN configurations, and even cryptocurrency wallets pulled directly from active runner environments. At that point, the pipeline was no longer supporting the attack surface. It had become the attack surface. The problem gets worse because malicious activity originating from CI/CD infrastructure frequently appears legitimate. Updates deployed through trusted automation systems often bypass traditional monitoring entirely since the activity comes from approved workflows using valid credentials. Attackers are not just targeting software anymore. They are targeting the factory responsible for producing and delivering it. The Convenience Problem Inside GitHub Actions GitHub Actions became widely adopted largely because developers can automate almost anything with minimal friction. Testing, vulnerability scanning, deployments, and release pipelines. Most of it can be assembled quickly using reusable public actions. That convenience also created a predictable attack path. Many repositories still reference third-party GitHub Actions using floating version tags such as: uses: tj-actions/changed-files@v35> At first glance, that looks reasonably safe, but it is not. Version tags are mutable. If attackers gain access to the repository maintaining the action, tags like @v35 can be silentlyredirected toward malicious commits without downstream users realizing anything changed. Existing trust relationships do the rest. Pipelines continue executing the compromised code automatically because the dependency was already approved months earlier. In practice, many organizations are running third-party automation pulled from public repositories with direct access into production environments, package registries, cloud infrastructure, and deployment tooling. Some teams barely review the dependencies beyond confirming the workflow still succeeds. Attackers understand these environments extremely well by now. Recent supply chain operations have repeatedly targeted: Mutable GitHub Action tags Overprivileged automation accounts Exposed Personal Access Tokens Insecure pull_request_target workflows Workflow logs containing secrets Long-lived credentials stored inside repositories The attack paths are often surprisingly simple. Compromise one trusted automation component, wait for downstream pipelines to execute it automatically, then collect the credentials already available inside the environment. No exploit chain required. How One GitHub Action Exposed Thousands of Repositories The tj-actions/changed-files compromise became a wake-up call because downstream repositories often had no indication that anything was wrong. Attackers modified a trusted GitHub Action already embedded across thousands of CI/CD workflows. Once the pipelines executed the malicious update, secrets stored inside the runner environments became exposed through logs, memory scraping activity, and inherited workflow permissions. Most affected organizations never intentionally approved malicious code. They approved a floating tag months earlier and trusted the dependency relationship to remain stable afterward. That distinction matters. A typical vulnerable workflow looked like this: uses: tj-actions/changed-files@v35> A hardened version pins directly to an immutablecommit hash: uses: tj-actions/changed-files@24d32ffd492484c1d75e0c0b894501ddb9d30d62> Once pinned, attackers cannot silently redirect the workflow toward newer malicious commits without maintainers explicitly updating the reference themselves. The operational problem is that most teams still treat CI/CD dependencies like convenience tooling rather than privileged infrastructure. Pipelines inherit secrets, deployment access, repository permissions, cloud credentials, and package publishing authority almost automatically. One compromised action can inherit all of it. How to Audit Your CI/CD Environment Organizations trying to improve pipeline security should start by reviewing existing workflows before adding new tooling. Most exposure comes from accumulated convenience decisions made over time rather than one catastrophic configuration mistake. A useful first step is identifying workflows using floating tags instead of immutable commit hashes: grep -R "uses: .*@v" .github/workflows/ That will usually surface reusable actions still pinned to mutable version labels. Next, review workflow permissions. Many GitHub Actions environments run with broader access than they actually need. Overly permissive example: permissions: write-all Safer baseline: permissions: {} Then explicitly grant only what the workflow requires: permissions: contents: read The same review process should apply to secrets management. Teams should identify: Long-lived Personal Access Tokens Secrets shared across multiple repositories Unused deployment credentials Exposed environment variables inside logs pull_request_target workflows executing untrusted code Self-hosted runners exposed to public repositories Secret sprawl becomes difficult to track once pipelines scale across multiple repositories and cloud environments. By then, most organizations have credentials sitting in workflows nobody has reviewed in months. Several tools help automateparts of the audit process: Gitleaks for secret discovery inside repositories Trivy for container and workflow scanning OpenSSF Scorecards for supply chain risk analysis GitHub Secret Scanning for exposed credential detection OPA/Conftest for enforcing workflow security policies Even basic scans usually uncover old Personal Access Tokens, overprivileged automation accounts, or deployment secrets that should have been rotated years earlier. Hardening the Software Supply Chain Improving CI/CD security does not require rebuilding the entire development process, but it does require treating automation infrastructure as critical infrastructure rather than background tooling. One of the most effective GitHub Actions hardening steps is pinning reusable actions to immutable commit hashes instead of floating tags. Unlike labels such as @v35 , commit hashes cannot be redirected silently after approval. Another major improvement involves reducing default workflow permissions. Many pipelines still run with unnecessary repository write access because GitHub Actions historically granted broad defaults. Restricting permissions aggressively reduces the blast radius if a workflow or third-party dependency becomes compromised. Example hardened workflow configuration: permissions: contents: read pull-requests: read OIDC authentication also helps reduce long-lived credential exposure. Instead of storing static cloud secrets inside repositories, pipelines request temporary credentials dynamically during runtime. Example AWS OIDC trust relationship: { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "token.actions.githubusercontent.com:aud": "sts.amazonaws.com" } } } That approach limits the value of stolen credentials because the authentication tokens expire automatically after short periods rather than remaining valid indefinitely. Short-lived authentication is becoming more important as well. Many organizations are moving toward OpenID Connect (OIDC) models where pipelines request temporary credentials that expire automatically instead of relying on long-lived secrets that remain valid for months or years. Other hardening measures include: Reducing unnecessary repository permissions Rotating exposed tokens regularly Removing unused secrets from workflows Enforcing MFA for maintainers Reviewing workflow logs for leaked credentials Restricting self-hosted runner access Auditing third-party GitHub Actions before deployment The objective is no longer limited to protecting source code. Organizations now need to protect the trust relationships responsible for delivering software across their environments. Why CI/CD Security Became Core Security Modern software development depends heavily on automation. CI/CD systems build applications, publish packages, deploy infrastructure, scan dependencies, and distribute updates across production environments every day, usually with minimal human interaction once the workflows are in place. In many organizations, the pipeline now holds more operational access than the developers using it. That reality changed the economics of software supply chain attacks. The danger no longer sits exclusively inside malicious downloads or vulnerable open-source libraries hidden somewhere in the dependency tree. Increasingly, attackers focus on the automated infrastructure trusted to build and distribute software in the first place because compromising that layer scales far better than targeting individual systems. The GitHub Actions compromises and the Pipe-Siphon campaign made that painfully clear. One exposed credential inside a CI/CD environment is no longer just a configuration mistake sittingquietly in a workflow file. It can become the entry point into the entire software supply chain. Stay Ahead of Linux Security & Infrastructure Trends Interested in more in-depth coverage of Linux security, CI/CD security, software supply chain defense, DevSecOps , and enterprise hardening strategies? Subscribe t o the LinuxSecurity newsletter for weekly threat analysis, infrastructure security insights, and practical guidance covering the Linux and open-source ecosystem. Related Reading Linux Supply Chain Attacks Threaten DevOps Teams and Security CI/CD Pipelines Vulnerabilities in Trusted Execution Paths The Next Wave of Supply Chain Attacks: NPM, PyPI, and Docker Hub Incidents Set the Stage for 2026 Securing the Software Supply Chain with In-Toto Open-Source Supply Chain Attacks Threaten Linux Production Systems . A single compromised GitHub Action can quietly hand attackers the same infrastructure access senior . years, software, security, discussions, centered, vulnerable, inside, application. . MaK Ulac

May 14, 2026 •

MaK Ulac

security advisorydebianintegrity

Debian 14 Makes Reproducible Builds Mandatory for Linux Packages

Debian 14 “Forky” will begin blocking packages that fail reproducibility checks, marking a major shift in how Linux distributions verify software integrity. . After the XZ backdoor scare, one thing got painfully clear across Linux. Most people installing packages still cannot verify whether the binary on their system actually matches the source code that the source code maintainers published. The project will begin blocking packages that fail reproducibility checks, turning reproducible builds from a recommended practice into something closer to policy. Debian’s release team confirmed that the migration infrastructure will reject both newly submitted packages and existing ones that regress into non-reproducible states. Debian Is Changing Linux Supply Chain Security At first glance, this sounds like internal packaging cleanup. It is bigger than that. Debian sits underneath a massive chunk of the Linux ecosystem, directly and through downstream distributions. Once Debian starts enforcing reproducibility at the migration level, maintainers and vendors across that chain will feel pressure to clean up build environments, remove inconsistencies, and make binaries independently verifiable. The timing is not accidental either. XZ exposed how much of the open-source supply chain still relies on assumptions rather than validation. Maintainers trust upstream code, users trust package repositories, distributions trust automated build systems, and almost nobody checks whether the shipped binary truly matches the reviewed source code after everything moves through CI pipelines and mirrors. Reproducible builds do not stop supply chain attacks on their own. They do make silent tampering harder to hide. If the same source code consistently produces identical binaries across separate systems, defenders and researchers get a practical way to detect when something in the build chain changes unexpectedly. What Is a Reproducible Build? A reproducible build generates identical binariesevery time the same source code is compiled under the same conditions. Not “similar.” Not functionally equivalent. Bit-for-bit identical. That means anyone, including independent rebuilders, researchers, distributors, or enterprise security teams, can rebuild a package themselves and verify that the resulting binary matches the one Debian distributes publicly. Without reproducibility, users effectively trust: the build server, the CI/CD pipeline, package maintainers, signing infrastructure, and every dependency involved in producing the final binary. With reproducibility, that trust becomes independently testable. Why the XZ Backdoor Changed Everything The XZ Utils compromise fundamentally changed how many Linux developers and security teams think about package integrity. The attack wasn’t hidden inside obvious source code changes. Instead, malicious code was introduced into release artifacts that diverged from the reviewed source repository. That exposed a dangerous blind spot in modern software distribution. Even if the source code appears legitimate, users still need a reliable way to verify that the binaries they install were actually built from that source and not modified somewhere in the release pipeline. Reproducible builds help close that gap. If independent rebuilders compile the same source and produce different hashes than the distributed binaries, something is wrong: The build environment may have been compromised, Artifacts may have been altered, Or the package contains hidden non-deterministic behavior. That verification capability has become increasingly important as supply chain attacks continue targeting: Package repositories, CI/CD systems, Developer tooling, Container pipelines, and open-source infrastructure. Why Linux Builds Become Non-Reproducible One reason reproducible builds took years to mature is that modern software pipelines contain countless tiny sources of non-determinism. Some are surprisingly mundane. A package built at 10:01 AM and rebuilt again one minute later may produce different hashes simply because archive metadata contains different timestamps. Compiling the same project inside /home/alice/project versus /build/project can leak different filesystem paths into debugging metadata, changing the final binary output. Even file ordering can break reproducibility. If a linker processes object files in a slightly different order due to filesystem behavior or parallel builds, the resulting binary hash may change despite identical source code. Other common causes include: locale settings, embedded build dates, randomized compression behavior, environment variables, CPU architecture differences and non-deterministic compiler output. Over time, Debian’s Reproducible Builds initiative developed tooling specifically designed to eliminate or diagnose these issues. Tools Behind Debian’s Reproducibility Push Several tools now form the backbone of Debian’s reproducibility ecosystem: SOURCE_DATE_EPOCH Standardizes timestamps during builds so packages stop embedding unpredictable build times. diffoscope Compares binaries, archives, packages, container images, ELF files, and other artifacts to pinpoint exactly why two builds differ. reprotest Builds packages multiple times under varying conditions to identify reproducibility failures. .buildinfo Files Record build dependencies, architecture details, and checksums so independent rebuilders can recreate the same environment. Independent Rebuilders External systems continuously rebuild packages and compare hashes against official Debian binaries to detect inconsistencies. Together, these tools move Linux package verification away from institutional trust and toward independently verifiable software delivery. How This Impacts Everyday Linux Users For developers and distro maintainers, reproducibility is a technical challenge. For regular Linuxusers, it’s fundamentally about trust. Reproducible builds increase confidence that downloaded packages were not silently altered somewhere between source code review and installation. In practical terms, that means researchers and rebuilders can independently verify whether Debian packages actually match their published source code. That matters during: supply chain attacks, compromised build infrastructure incidents, suspicious package updates, mirror tampering concerns, or large-scale CI/CD compromises. Most users will never manually rebuild packages themselves. But the existence of a verification ecosystem makes hidden tampering significantly harder to conceal. What Maintainers Will Need To Change Debian’s new enforcement policy introduces real operational pressure for maintainers. Packages that once built “well enough” may now fail migration if they cannot reproduce consistently. Maintainers will increasingly need to: remove embedded timestamps, normalize archive ordering, eliminate environment-specific metadata, stabilize compiler behavior, strip absolute filesystem paths, and audit build scripts for non-deterministic behavior. Common fixes often involve: using SOURCE_DATE_EPOCH, sorting linker inputs deterministically, applying -ffile-prefix-map or -trimpath, using deterministic compression flags, and testing packages repeatedly with reprotest. That work can be tedious, especially across thousands of packages and multiple architectures, but Debian has already made substantial progress. According to the broader reproducible builds project, Debian now reproducibly builds the overwhelming majority of packages in testing. The Impact Goes Beyond Debian Debian’s decision will likely influence far more than Debian itself. Many Linux distributions and infrastructure projects already participate in reproducibility efforts to varying degrees, including: Arch Linux, Alpine, Tails, Yocto, Guix, NixOS, and portions of the Fedora and Red Hat ecosystems. The broader cloud-native ecosystem is also paying attention. Reproducibility is becoming increasingly important for: container images, Kubernetes deployments, cloud CI/CD systems, signed build provenance, SBOM validation, and software supply chain frameworks like SLSA. Container infrastructure especially benefits from deterministic builds because distributed systems continuously rebuild and redeploy software across multiple environments. Inconsistent artifacts make auditing significantly harder. Reproducibility helps reduce that ambiguity. Reproducibility Is Not a Silver Bullet Reproducible builds do not automatically make software secure. A package can still be reproducible while containing malicious code if the source itself is compromised. What reproducibility provides is assurance that: Distributed binaries match audited source code, The release infrastructure did not silently alter artifacts, Independent parties can verify software integrity themselves. That distinction matters. For years, software distribution largely operated on institutional trust. Debian’s reproducibility push reflects a broader shift away from “trust the pipeline” and toward independently verifiable software delivery. In an era of increasingly sophisticated supply chain attacks, that may eventually become as fundamental to Linux security as package signing itself. Stay Ahead of Linux Security & Infrastructure Trends Interested in more in-depth coverage of Linux security, supply chain defense, open-source infrastructure, and enterprise hardening strategies? Subscribe to the LinuxSecurity newsletter for weekly analysis, threat updates, and technical insights from across the Linux ecosystem. Related Reading How the XZ Utils Backdoor Shook the Linux Ecosystem Why Software Supply Chain Attacks Are Becoming Harder To Detect Securing CI/CD Pipelines Against ModernOpen-Source Threats Ubuntu Dirty Frag Important Local Privilege Escalation Exploit Linux Could Soon Disable Vulnerabilities Without a Reboot: Kernel Killswitch . Debian 14 mandates reproducible builds to enhance software integrity, affecting Linux package verification.. Debian Security, Package Integrity, Reproducible Builds, Supply Chain Trust. . MaK Ulac

May 12, 2026 •

MaK Ulac

security advisorycode executionimportant

CI/CD Pipelines Vulnerabilities in Trusted Execution Paths March 2026

Time and time again, Linux systems execute attacker-controlled code during normal operation, and nothing in the system reports it as a failure. Security models still lean on the idea that something has to break first. An exploit fires, a misconfiguration opens a path, a control fails. But in these cases, there is no breakpoint to trace back to, because the commands being used are valid, expected, and fully trusted by the system. The pattern becomes easier to see in automated environments and is a defining trait of modern software supply chain attacks. CI/CD pipelines run these workflows constantly. They assume the inputs they receive are safe by default, which makes them a clear example of how trusted execution paths turn into execution paths for attacker-controlled code. . CI/CD Pipelines Execute Attacker-Controlled Code Through Rewritten Git Tags In March 2026, a widely used security tool called Trivy was compromised during a routine CI/CD workflow . Nothing was exploited or misconfigured; the system ran exactly as designed, yet still executed malicious code. Pipelines automate tasks like pulling code based on version tags (e.g., v0.69.4). These tags are treated as stable references that should always resolve to the same content. How Git Tags Become Mutable Execution References That trust breaks at the reference level. In the Trivy case, attackers reassigned 76 out of 77 tag pointers to malicious commits. Because Git allows tags to be moved, the system accepted this as a valid state. The pipeline resolved the tag at runtime and executed whatever code it pointed to without verifying if the reference had changed. This is the core issue. The execution path is authorized, so whatever flows through it is trusted by default, even when silently altered. Why Trusted Execution Paths Fail to Verify Content What’s missing here isn’t a failed control. It’s how trust is defined in the first place. Most systems validate access, not whether what they execute is still the samething. If a workflow is allowed to run and the command is valid, the result is treated as trusted by default. That assumption only holds if the thing being executed stays the same. In these environments, it doesn’t. A tag can move, a maintainer can change, or a commit can be rewritten, while the execution path remains untouched. The system validates the path, not the content flowing through it, so nothing fails because nothing appears out of place. The result followed naturally. During execution, the pipeline exposed credentials from environment variables like GitHub tokens and AWS keys, because the process still had full access, and no part of the system recognized that the code being executed was no longer what was originally intended. The Fix: Stop trusting tags. Pin to the exact content using a full commit SHA. Because a SHA is tied to the code itself, the reference cannot be silently reassigned. For external binaries, always validate a checksum before execution. npm install Executes Attacker-Controlled Code During Package Installation While the Trivy case involved manipulated references, the npm ecosystem often suffers from identity failures. Here, the reference remains the same, but the identity behind the code is compromised. This has happened repeatedly. In multiple incidents, such as the phishing compromise of a prolific maintainer , attackers hijacked accounts to publish malicious updates. Because these updates come from the expected publisher, they are installed automatically. This is a fundamental trust gap: the system validates the publisher, not the content. On Linux, this leads to immediate execution. npm install does more than pull files; it automatically runs lifecycle scripts as the current user. This allows attacker-controlled code to execute before the application even starts, granting it access to your files, network, and environment variables—all within a "trusted" workflow. The system doesn’t fail; it simply trusts the wrong thing. The Fix: Breakthe link between retrieval and execution by disabling lifecycle scripts during installation: npm config set ignore-scripts true npm install --ignore-scripts This keeps the package on disk without running its code, so execution does not happen until the code is actually reviewed or invoked. git pull Executes Attacker-Controlled Code From Manipulated Repository History In the Trivy case, the system trusted a reference. In the npm case, it trusted a hijacked identity. With Git, the trust failure shifts to the repository history itself. When you run git pull, you likely check git log to see who made changes. What you see looks like a reliable timeline of names and dates. However, a Git commit is simply a stored object containing unverified fields for author name, email, and timestamp. This is not a hack; it is a core feature. Anyone can use the git commit --author command to set any identity they choose. Because Git does not verify these fields by default, an attacker can rewrite history to include malicious code that appears to be authored by a trusted contributor years ago. When this rewritten history is pushed, and you git pull, your system accepts it as valid input. You aren't just trusting the code; you are trusting unverified metadata. The result is consistent: malicious code is merged because it looks like it belongs. The system didn't fail—it trusted a history that was never authenticated. The Fix: Verify the commit, don't just read it. Enable commit signature visibility to shift trust from easily faked names to cryptographic signatures: Bash git config --global log.showSignature true This ensures the author’s identity and the commit’s integrity are cryptographically proven before you merge. Linux Must Enforce Execution Boundaries When Trusted Workflows Execute Untrusted Code By the time the code reaches your system, the critical decisions have often already been made. A reference was resolved, a package was installed, or a repository was pulled—allthrough trusted workflows that failed to verify the content. This leaves only one place where control still exists: the moment of execution. Linux Executes Untrusted Code With Full Permissions By default, Linux tools run with the same permissions as the user who launched them. Attacker-controlled code inherits your access to files, networks, and environment variables without needing to bypass a single security control. To limit this, isolate execution. Use Podman to run tools inside containers with restricted access, ensuring that even if code runs, it cannot exfiltrate data or modify your host: Bash podman run --rm --network=none -v $(pwd):/apps:ro Processes Automatically Expose Credentials Linux processes inherit environment variables from the parent shell. Tokens, API keys, and cloud credentials exported earlier are passed automatically to new processes. Attackers don't need to "find" your secrets; they are handed to them at startup. Reduce this exposure by using scoped execution via systemd-run or temporary subshells, and avoid exporting sensitive variables globally in files like .bashrc. The Point of Execution is the Point of Truth Whether it's a "latest" tag or an unverified binary, the pattern is consistent: the system isn't being bypassed; it is executing exactly what it was given. To address this, verify the code before it touches your CPU. Use sha256sum to confirm a binary matches its expected value and review commit history for inconsistencies. If the origin of code cannot be cryptographically proven, it must be treated as untrusted. When verification fails at the workflow level, the only remaining safety net is the execution boundary you build within the OS. Execution Without Trust Across all three cases, nothing was exploited, and nothing was misconfigured. The system had access, the workflows were valid, and the commands executed exactly as expected, which is why this keeps happening. The risk is not unauthorized access. It is authorizedexecution from unverified sources, where a tag moves, a maintainer changes, or a commit lies, and the system accepts all of it because it trusts what it sees. Stop trusting what can change: Names and labels Tags Authorship Start verifying what cannot: Commit hashes Signatures Checksums Doing this manually does not scale. That is why teams use tools to track and update pinned versions, so the workflow stays usable while the references stay fixed. If the origin of the code cannot be proven, treat it as untrusted before execution. Because at that point, the system will execute it anyway. . CI/CD tools face major risks as trusted code execution paths allow for attacker-controlled code to execute within workflows.. secure coding practices, CI/CD security, software supply chain, code execution integrity, code review processes. . MaK Ulac

Mar 31, 2026 •

MaK Ulac

open sourcedata encryptionsoftware transparency

Biden's Cybersecurity Order Requires Federal Software Compliance Standards

On Wednesday, May 12th, in the wake of the recent Colonial Pipeline ransomware attack that shut down one of the largest US pipelines for nearly a week, President Biden signed an executive order placing strict new standards on the cybersecurity of all software sold to the federal government. This order is part of a broad, multi-layered initiative to improve national security by incentivizing private companies to practice better cybersecurity or risk being locked out of federal contracts. . For the first time, the United States will require all software purchased by the federal government to meet, within six months, a series of new cybersecurity standards. Although the companies would have to “self-certify,” violators would be removed from federal procurement lists, which could kill their chances of selling their products on the commercial market. The new order also requires all federal agencies to encrypt data, whether it is in storage or while it is being transmitted. This order addresses a disconcerting trend: cyberattacks - the vast majority of which are email-borne - are rapidly evolving to become more sophisticated, prevalent and far-reaching than ever before. Many of these attacks target critical infrastructure - a point most recently highlighted by the Colonial Pipeline ransomware outbreak. Over the past year, approximately 2,400 ransomware attacks have hit corporate, local and federal offices. Biden’s new executive cybersecurity order recognizes the critical importance of Open Source in securing the software supply chain, stating that the government must ensure "to the extent practicable, to the integrity and provenance of open-source software used within any portion of a product." It is not surprising that the report specifically addresses open-source security. After all, according to open-source company Tidelift, 92% of applications contain open-source components. Luckily, the open-source community itself is already combating this issue with the Software Package DataExchange (SPDX), which aims to enable software transparency through a Software Bill of Materials (SBOM) - a formal record containing the details and supply chain relationships of various components used in building software - that already meets the executive order's requirements. In addition, The Linux Foundation’s Open Source Security Foundation (OpenSSF) has also been working to secure open-source software and its components through its mission of “collaboration to secure the open-source ecosystem”. Also, the Linux Foundation recently announced a new open-source software signing service: the sigstore project , which seeks to improve software supply chain security by enabling the easy adoption of cryptographic software signing backed by transparency log technologies. Besides sigstore, the Linux Foundation oversees multiple projects designed to maintain trusted source code supply chains including in-toto , The Update Framework (TUF) and OpenChain (ISO 5230). The open-source community is also addressing the order’s call for the encryption of data at rest and in transit with the renowned open-source project Let's Encrypt , the world's largest certificate authority for TLS certificates. The bottom line is that Open Source shows significant promise in meeting today and tomorrow’s most significant cybersecurity challenges. It has become clearly apparent that cybersecurity needs to be a top priority - not just for the federal government, but for everyone. David A. Wheeler, the Linux Foundation's Director of Open Source Supply Chain Security, emphasizes the importance of community involvement in securing the open-source supply chain, "We couldn't do this without the many contributions of time, money, and other resources from numerous companies and individuals; we gratefully thank them all. We are always delighted to work with anyone to improve the development and deployment of open-source software." I’m pleased to see this type of legislation put into place. Cybersecurity and data privacy areserious, universal concerns that must be addressed individually by businesses, as well as at the national level. This order offers vendors a great enough incentive that it is hard to imagine they would choose not to comply. While there is no silver bullet, it is encouraging to see that the open-source community is well on its way to meeting this order’s critical demands. . The federal government imposes updated cybersecurity regulations for software acquired by its agencies, bolstering defenses across the board.. Enhanced Cybersecurity Standards, Open Source Initiatives, Software Supply Chain Compliance. . Brittany Day

May 24, 2021 •

Brittany Day

Community Poll

More Polls

Should Linux servers automatically install security updates?

Yes — critical security patches should install automatically.
No — every update should be tested before deployment.
Only critical vulnerabilities should auto-install.
I patch when Reddit starts panicking.

Stay Ahead With Linux Security Features

Refine features

Get the latest News and Insights

Community Poll

Should Linux servers automatically install security updates?

Trending Features

Cron Job Abuse For Linux Persistence Mechanisms Detection

Essential Cybersecurity Practices for Businesses to Protect Data

HTTP/2 Bomb: Why Linux Infrastructure is Vulnerable to a New Low-Bandwidth DoS Attack

Red Hat npm Package Compromise Highlights a Growing Supply Chain Problem

Explore Latest Linux Security features

Does Linux Give Users a False Sense of Security? What This Year's Biggest Linux Security Incidents Actually Reveal

Compromised VS Code Extension Puts Linux Development Pipelines at Risk

Red Hat npm Package Compromise Highlights a Growing Supply Chain Problem

GitHub Actions Compromise CI/CD Supply Chain Risks Explored

Why CI/CD Pipelines Became Targets in Software Supply Chain Attacks

Debian 14 Makes Reproducible Builds Mandatory for Linux Packages

CI/CD Pipelines Vulnerabilities in Trusted Execution Paths March 2026

Biden's Cybersecurity Order Requires Federal Software Compliance Standards

Get the latest News and Insights

Community Poll

Should Linux servers automatically install security updates?

Trending Features

Cron Job Abuse For Linux Persistence Mechanisms Detection

Essential Cybersecurity Practices for Businesses to Protect Data

HTTP/2 Bomb: Why Linux Infrastructure is Vulnerable to a New Low-Bandwidth DoS Attack

Red Hat npm Package Compromise Highlights a Growing Supply Chain Problem

Powered By

Linux Security - Your source for Top Linux News, Advisories, HOWTOs and Feature Releases

QUICK LINKS

subscribe to newsletters!

Stay Ahead With Linux Security Features

Refine features

Topics

Authors

Published Date

Get the latest News and Insights

Community Poll

Should Linux servers automatically install security updates?

Trending Features

Explore Latest Linux Security features

Get the latest News and Insights

Community Poll

Should Linux servers automatically install security updates?

Trending Features

Search Topics

Powered By

Linux Security - Your source for Top Linux News, Advisories, HOWTOs and Feature Releases

QUICK LINKS

subscribe to newsletters!