Audit Linux privileges now to limit compromise, escalation, and system-wide damage. Review Linux Privileges×
Stay Ahead With Linux Security Features
security advisory vulnerability For decades, Linux defenders relied on a comfortable assumption: a public security patch did not imply an imminent vulnerability. While open-source openness made vulnerability fixes public to everyone on kernel.org or the Linux Kernel Mailing List (LKML), converting a raw commit into a weaponized exploit took a significant amount of manual effort. This delay, estimated in weeks or months, gave businesses enough time to assess exposure, organize testing windows, and push changes across...
Jul 27, 2026
security advisory path traversal Two newly fixed storage bugs in Kubernetes showed more than just a problem with path traversal. They found a common security flaw in the cloud: powerful parts often think that requests accepted by a higher system are safe to run. This is a simple lesson for the platform and security teams: RBAC can accept a request without showing that its parameters will stay within a certain filesystem boundary. This is clear from a new study from SentinelLabs into flaws in the Kubernetes CSI drivers for NFS...
Jul 24, 2026
security advisory update A large volume of Linux security updates and advisories this week across major distributions once again, but it wasn't just the volume that was the story. Where maintainers and security teams focused their attention was evident in the concentration of fixes targeting Linux kernel updates, identity services, DNS infrastructure, and internet-facing software. . Instead of looking at each advisory in isolation, administrators gain more value from the general trends they reveal about Linux security...
Jul 23, 2026
identity management security tactics For years, we secured our Linux infrastructure by building walls: VPCs, security groups, and hardened SSH configurations. We treated the cloud like a virtual data center, assuming that if we kept the "bad guys" out of the network, our workloads were safe. . That model is no longer sufficient. Today, one of the most common paths from an initial compromise to a major cloud breach is the identity assigned to your Linux workload. When an attacker gains code execution on a Linux instance—through a...
Jul 17, 2026
security practices patch management Most of us don't hear about a kernel vulnerability until a CVE lands in our inbox or the vulnerability scanner starts complaining. By then, the patch isn't new anymore. Kernel developers may have been passing it around for review, arguing over the implementation, or revising it for days before anyone outside that community noticed it. None of those discussions are secret. They're sitting in mailing list archives, Git commits, and patch reviews where they've been the whole time. The strange...
Jul 14, 2026
Refine features
X Clear Filters
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
Are host-based firewalls still worth using?
Loading...
Explore Latest Linux Security features
We found -3 articles for you...
102
software transparencyattack patternssupply chain riskWhy Linux Supply Chain Attacks Are Becoming a Nightmare for DevOps Teams
Linux has long carried a reputation for resilience, bolstered by open-source reviews, hardened kernels, and transparent development pipelines. While that trust is well-founded, attackers have shifted their focus to a more vulnerable target: the surrounding software supply chain. . Instead of breaking Linux directly, malicious actors are poisoning the delivery pipeline. The shift is obvious when you look at the last few years of incidents. Compromised maintainers, malicious packages, dependency confusion, and poisoned updates frequently land on systems long before defenders realize the code has changed. While security teams are busy patching traditional vulnerabilities, attackers are quietly slipping through package managers and CI/CD workflows we assumed were trustworthy. The XZ Utils backdoor fundamentally changed the tone of this conversation. The XZ Backdoor: The Scenario Everyone Feared In early 2024, attackers inserted a backdoor into XZ Utils , a compression library embedded across Linux distributions and SSH-related workflows. The malicious code targeted liblzma (a data compression library) and created a path to intercept SSH authentication under specific conditions. It was subtle, heavily obfuscated, and positioned deep enough in the stack that most environments would never notice it during routine reviews. But the most dangerous part wasn’t the payload itself—it was how access was gained. A contributor operating under the alias "Jia Tan" slowly built trust inside the project over months. The pattern started with normal, helpful commits, routine maintenance, and participation, before the poisoned update eventually landed. This long-game approach mirrors what’s happening across open-source ecosystems today: attackers are playing the long game rather than relying on smash-and-grab compromises. The backdoor was ultimately caught by Microsoft engineer Andres Freund after he noticed strange CPU behavior in Debian test environments. If that anomaly had gone unnoticed for a fewmore release cycles, the blast radius would have been catastrophic. The Pattern Didn't Stop with XZ In March 2026, a supply chain attack hit Axios , one of the most widely used HTTP client libraries in the JavaScript ecosystem. Attackers got access to a maintainer’s npm account and quietly published two compromised versions, 1.14.1 and 0.30.4, before anyone caught it. The Axios source code itself wasn’t altered. That part mattered. Instead, the attackers slipped a malicious dependency called plain-crypto-js into the release chain, which is a much easier place to hide when everyone’s focused on the main project diff and not the packages underneath it. Once installed, npm automatically ran post-install scripts tied to the dependency. The code was heavily obfuscated and built to stay unnoticed long enough to deploy a remote access trojan across Linux, macOS, and Windows systems. Researchers later connected the infrastructure and forensic overlap to North Korean operators. What unsettled a lot of security teams wasn’t the sophistication. It was the timing. The poisoned packages were live for only a few hours, but Axios pushes tens of millions of downloads every week, so developer workstations, CI runners, and production pipelines started pulling the update almost immediately without anyone stopping to inspect a routine dependency refresh. That’s the part that supply chain attacks keep exposing now. Attackers do not always need to compromise the primary codebase anymore. A transitive dependency buried deep enough in the update path can move through trusted channels quietly, especially in environments where automated installs happen faster than meaningful review ever does. Takeaway : Open-source trust models are incredibly vulnerable to patient attackers. To learn more about how organizations are improving software transparency, you can review the CISA Software Bill of Materials Guidance Linux Repositories as Active Attack Surfaces The problem extends far beyond Linuxdistributions themselves. Language ecosystems are hit constantly because developers install dependencies—third-party code modules used to speed up development—at scale with almost zero scrutiny. Go Modules: In 2025, researchers uncovered malicious Go modules (such as prototransform, go-mcp, and tlsproxy) that deployed destructive shell scripts to wipe Linux disks through /dev/sda. The payload didn't even attempt to extort the user via ransomware; it destroyed the systems outright. PyPI Packages: Packages frequently serve as delivery mechanisms for credential theft and remote access tooling. Some have abused Gmail SMTP infrastructure and WebSockets to blend exfiltration traffic into normal outbound communications, easily bypassing monitoring in smaller environments. Node.js Ecosystem: The event-stream compromise remains one of the clearest examples of this evolution. A maintainer handed project ownership to a new contributor who gradually introduced malicious code through a nested dependency targeting cryptocurrency wallets. npm audit failed to flag it because it wasn't tied to a known vulnerability at the time. You can read the original breakdown of the event-stream GitHub discussion to understand how social trust becomes an attack vector. Why Traditional Dependency Scanning Falls Short Many organizations treat tools like npm audit, Dependabot, or standard vulnerability scanners as a complete supply chain defense. They aren't. These tools are great for identifying known vulnerable versions tied to published advisories and helping with patch management. However, they fail to reliably catch: Compromised maintainer accounts Typosquatted or malicious packages Obfuscated payloads Malicious post-install scripts Dependency confusion attacks Insider sabotage Runtime exfiltration behavior The ua-parser-js compromise demonstrated this gap. Attackers hijacked the maintainer’s account and pushed malicious package versions that deployed cryptominers andcredential-stealing malware. The window lasted only a few hours, but thousands of developer systems and CI pipelines pulled the update automatically before any advisory was published. Ecosystems are trying to improve trust validation, and you can see how in the npm Registry Signatures and Provenance documentation . The Trap of Trust at Scale Modern applications routinely pull hundreds or thousands of dependencies through transitive package chains (where one dependency relies on another). Most teams cannot realistically audit all of them manually, leading to the dangerous assumption that "popular" equals "safe." Attackers know developers trust download counts, GitHub stars, and familiar names: Typosquatting: Campaigns exploit simple human errors. Packages like crossenv successfully harvested environment variables simply because someone missed a hyphen while trying to install cross-env. Dependency Confusion: In research by Alex Birsan, public packages using internal company names tricked package managers into pulling malicious versions from public registries rather than private ones. Giants like Apple, Microsoft, PayPal, and Tesla were impacted during testing. This attack chain works because the package resolution behavior itself is exploited. You can review the original Dependency Confusion Research to see how this vulnerability operates. How to Reduce Supply Chain Risk There is no single silver bullet. Because attackers target multiple parts of the pipeline simultaneously, teams need layered verification: Lockfiles and Integrity Validation Lockfiles (like package-lock.json or yarn.lock) pin exact dependency versions and verify integrity hashes. In production pipelines, use npm ci instead of npm install to enforce deterministic installs rather than recalculating dependency trees dynamically. It's a small change with a big security difference. SBOMs and Dependency Visibility Software Bills of Materials (SBOMs) provide much-needed visibility into what is running insideapplications. Tools like CycloneDX and Syft generate SBOMs for Linux systems and container images, helping teams quickly check whether suspicious components exist in their environments. To learn more about reproducible builds and software integrity frameworks, check out the SLSA Framework . Provenance and Signed Builds Projects like Sigstore modernize software provenance verification using cryptographic signing tied to CI/CD workflows, rather than relying on developer machines. This ensures we know where a package was built, which pipeline produced it, and if it was altered afterward. You can read the Sigstore project overview to learn more. Restrict Install-Time Execution Many attacks abuse post-install scripts that inherit broad execution privileges. Using flags like npm install --ignore-scripts stops an entire category of malicious behavior. High-trust production pipelines should strictly limit unnecessary execution paths and isolate build runners to prevent lateral movement. 5 Things Linux Teams Should Do This Week Require MFA for package maintainers Pin dependency versions in production Disable unnecessary install scripts Generate SBOMs during builds Monitor dependency changes in CI pipelines Open Source Security Relies on Human Processes Some of the hardest problems in supply chain security aren't technical: maintainer burnout, poor account security, weak review pipelines, and underfunded projects maintaining critical infrastructure. The colors.js and faker.js sabotage incident showed what happens when maintainers themselves become unpredictable risk factors. This wasn't an external intrusion; the maintainer intentionally broke downstream systems. The industry is slowly responding by requiring MFA, improving provenance tooling, and adopting reproducible builds. But adoption is uneven outside of large enterprises, and that gap is where attackers continue to operate. Treat Supply Chain Monitoring Like Endpoint Security The old assumption thatLinux repositories are inherently trustworthy no longer holds up under modern attack patterns. Defenders need visibility into dependency changes, unusual network behavior, build pipeline anomalies, and maintainer activity—not just CVEs. Because most supply chain compromises don’t arrive as traditional exploits. They arrive as routine updates: quietly, usually signed, and almost always trusted. If you’re tracking issues like this, Linux security newsletters are a great way to keep them on your radar. . Malicious actors target Linux supply chains, compromising maintainers and code to exploit systems undetected.. Supply Chain Attacks, Software Transparency, Dependency Management, Threat Monitoring, Linux Security Best Practices. . MaK Ulac
May 06, 2026
•
102
open sourcedata encryptionsoftware transparencyBiden'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
•
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
Are host-based firewalls still worth using?
Search Topics
Powered By
Linux Security - Your source for Top Linux News, Advisories, HOWTOs and Feature Releases
QUICK LINKS
subscribe to newsletters!
Like staying secure? So do we.
Sign up for updates, tips, and alerts!