Latest Linux Security News & Information

security advisoryvulnerability managementopen source initiative

Linux Foundation Launches Akrites to Strengthen Software Supply Chain Security

The Linux Foundation has officially launched Akrites , a coordinated industry initiative designed to improve how critical open source vulnerabilities are validated, coordinated, and disclosed before patches reach downstream users. Backed by a diverse coalition—including AWS, Google, Microsoft/GitHub, Red Hat, NVIDIA, and OpenAI—Akrites establishes a shared Security Incident Response Team (SIRT) to streamline the validation, remediation, and disclosure of vulnerabilities in the foundational code that underpins the modern digital economy. . AI Is Changing Software Supply Chain Security One detail in the Linux Foundation announcement stands out more than the launch itself. The organization isn't suggesting that open source projects suddenly need more vulnerability reports. They already receive plenty. The problem is volume. AI-assisted analysis has made it possible to review large codebases much faster than before. Researchers can identify suspicious patterns, compare projects, and generate vulnerability reports in a fraction of the time that manual analysis once required. That is good news for open-source security, but it has also exposed a weakness in the current response model. Every report still has to be reviewed by a person. Someone has to reproduce the issue, determine whether it affects supported releases, understand its severity, decide whether a CVE is appropriate, develop a patch, and move that fix through coordinated vulnerability disclosure before technical details become public. None of those tasks has become significantly easier simply because AI can produce findings more quickly. According to Endor Labs, one of Akrites' founding members, fewer than 5% of recently validated open source vulnerabilities have been patched . Whether that percentage changes over time, it illustrates the same trend. Discovery is accelerating faster than remediation. Why Existing Open Source Security Processes Are Under Pressure The reality for many maintainers looks verydifferent from how people imagine open-source security working. A widely used library isn't necessarily maintained by a large engineering team. In many cases, it's a handful of contributors or even a single developer balancing maintenance with a full-time job. Now imagine that the project suddenly receives dozens of reports describing the same underlying issue. One submission comes from a commercial scanner. Another is generated by an AI coding assistant. A third arrives through a bug bounty program. None are identical, but all require investigation. The difficult part isn't opening the email. It's figuring out whether the report is accurate, whether the vulnerability can actually be reproduced, whether downstream users are affected, and how the issue should move through vulnerability disclosure without exposing organizations before a fix is available. Akrites is intended to reduce that burden by acting as a shared Security Incident Response Team. Instead of every organization independently contacting maintainers, the initiative provides a coordinated process for validating reports, removing duplicates, and helping projects prepare fixes before disclosure begins. Recent Incidents Showed Why Coordination Matters Recent security incidents have demonstrated that identifying a vulnerability is often only the beginning. Log4Shell became a global response effort almost overnight. The challenge wasn't limited to understanding the vulnerability itself. Linux distributions, software vendors, cloud providers, security teams, and enterprise administrators all had to coordinate patches, advisories, testing, and deployment under intense time pressure. The XZ Utils backdoor exposed a different weakness. It showed how much critical infrastructure still depends on software maintained by very small teams. When one upstream project experiences a security problem, the consequences spread through Linux distributions, enterprise products, containers, cloud platforms, and countless applications built ontop of that code. Akrites would not have prevented either incident. The Linux Foundation isn't making that claim. Instead, the initiative attempts to strengthen the coordination that happens after a vulnerability is discovered and before it reaches the wider ecosystem. What Akrites Means for Open-Source Security Akrites represents a clear realization: open source security can no longer rely solely on the efforts of individual maintainers. Every critical project eventually hits the same wall: the software becomes indispensable long before the maintenance team has the resources to manage it. One interesting aspect of this initiative isn't just the technology—it's the list of founding members. Organizations like Citi, JPMorgan Chase, Ericsson, and Cisco rarely launch joint initiatives unless they share a massive, systemic problem. In this case, they do. Modern infrastructure shares an enormous amount of upstream code, which means one overwhelmed maintainer is now a systemic risk for banks, power grids, and cloud providers alike. What This Means for Linux Administrators Linux administrators rarely work directly with upstream maintainers, yet they depend on them every day. Enterprise distributions such as Red Hat Enterprise Linux, Ubuntu, Debian, SUSE, AlmaLinux, and Rocky Linux package software only after upstream projects have investigated reports, developed patches, and coordinated disclosure. Improvements at the upstream level can ripple through the entire software supply chain, ultimately affecting how quickly organizations receive trusted updates. : Faster upstream patch coordination: Verified fixes land in your distribution’s repositories sooner because the "middle work" of validation and deduplication is handled upstream. More consistent security advisories: Standardized reports make it easier to track and prioritize updates across your fleet. Better support for widely used components: Akrites says it can serve as a "maintainer of last resort" for certain criticalprojects by helping coordinate remediation when active maintenance is no longer sufficient. How Akrites Coordinates Vulnerability Response The initiative formalizes the vulnerability disclosure lifecycle to ensure confidentiality and speed. Instead of maintainers fielding reports from hundreds of sources, they have one predictable partner. Discovery: A researcher or AI surfaces a potential flaw. Confidential Submission: The report is sent to the Akrites SIRT, not a public bug tracker. Validation & Deduplication: The SIRT verifies the issue and removes duplicates. Remediation: Maintainers and industry engineers collaborate on a fix in a secure environment. Upstream Merge: The fix is merged into the original project's repository. Synchronized Disclosure: A coordinated CVE is published to alert the ecosystem. Akrites Won't Replace Vulnerability Management It is vital to note that Akrites is an upstream coordination body, not an enterprise security product. Organizations still need robust internal programs, including vulnerability management processes, asset inventories, and monitoring tools to detect threats within their specific environments. Akrites improves the upstream coordination of security, but the responsibility for securing the downstream enterprise environment remains with the organization. Akrites complements existing vulnerability management programs rather than replacing them. Organizations will still need scanners, patch management workflows, asset inventories, and software bills of materials (SBOMs) to identify affected systems and deploy updates. Akrites focuses on the upstream coordination that happens before those updates reach enterprise environments. Conclusion For years, the industry invested heavily in tools designed to identify software vulnerabilities faster. Akrites reflects a strategic recognition that discovery is no longer the limiting factor. As AI continues to accelerate vulnerability research, the challenge hasbecome how quickly maintainers can validate reports, coordinate fixes, and deliver patches before attackers exploit them. Whether Akrites succeeds will ultimately be measured not by the number of vulnerabilities it processes, but by whether it successfully shortens the time between discovery and remediation across the open source ecosystem. By professionalizing the "messy middle" of the response process, Akrites is attempting to build the operational infrastructure needed to keep our most critical software secure in an age of AI-accelerated threats. Want more Linux security news, open source security analysis, and software supply chain insights? Subscribe to the LinuxSecurity Newsletter for the latest vulnerability disclosures, security advisories, threat analysis, and expert coverage of the technologies shaping the Linux ecosystem. Related Reading Why Linux Supply Chain Attacks Are Becoming a Nightmare for DevOps Teams Targeted Attacks on Open Source Maintainers Highlight Security Risks . The Linux Foundation's Akrites aims to improve the response and management of open source vulnerabilities through collaborative efforts.. Linux Foundation, Akrites, Open Source Security, Vulnerability Coordination, Software Supply Chain. . MaK Ulac

Jun 29, 2026 •

MaK Ulac Security Projects

risk assessmentsecurity frameworkOpenSSF

Integrating GUAC: Enhancing Software Supply Chain Security Framework

Integrating the Graph for Understanding Artifact Composition (GUAC) in the open-source security framework has tremendous potential to improve software supply chain security . GUAC is an initiative introduced by Google, Kusari, Purdue University, and Citi that aggregates software security metadata into a high-fidelity graph database. . By joining the Open Source Security Foundation (OpenSSF) as an incubating project, GUAC aims to enhance existing tools for software security. It helps organizations understand their software supply chain by recognizing connections and enabling threat detection and response. What Is the Significance of GUAC in the Realm of Software Supply Chain Security? GUAC is experiencing growing adoption and maturity and is compatible with existing OpenSSF technologies. GUAC can consume SPDX SBOMs (Software Package Data Exchange), SLSA (Supply Chain Levels for Software Artifacts) attestation, and scorecard information about project dependencies. It enables organizations to analyze their dependencies easily, leading to more secure software. The implications of integrating GUAC into the software supply chain landscape are noteworthy. While SBOM capabilities have improved security, GUAC goes beyond generating SBOMs. It leverages metadata and documents across projects to provide insights and answer critical questions about the software supply chain. This approach allows for a better understanding of risks and highlights fleet-wide vulnerabilities. One intriguing aspect is GUAC's ability to perform graph analysis. GUAC provides a comprehensive view of the software supply chain by extracting additional insights from various datasets. This has long-term consequences, enabling security practitioners to focus their investments on improving application and dependency security. GUAC can ingest multiple types of security-related documents, such as VEX (Vulnerability Exploitability eXchange) statements and OSV vulnerability data, to better understand the connections between dataand assess risks efficiently. GUAC is currently in beta release. The project aims to reach its 1.0 release and create built-in dashboards with prioritized actionable items. This would facilitate organizations' understanding of their security posture and efficiently utilize the software supply chain knowledge graph. However, it is crucial to consider GUAC's evolution and how it adapts to emerging threats and technologies. From the perspective of Linux administrators, infosec professionals, internet security enthusiasts, and sysadmins, GUAC presents a valuable addition to its security toolkit. It brings together various sources of software security metadata, empowering practitioners to identify gaps in software supply chain data. This strengthens security practices and enables effective threat detection and response. Our Final Thoughts on the Implications of GUAC Integrating GUAC into the open-source security framework signifies a significant step in enhancing software supply chain security. It provides a valuable tool for security practitioners to understand their software dependencies better, analyze risks, and focus on improving application security. As GUAC continues to evolve, its potential to unlock a range of use cases and facilitate integration with other components will contribute to organizations' long-term security posture. . GUARD incorporates encryption details into software distribution scrutiny for improved safeguard and threat evaluation.. GUAC, Software Supply Chain, Security Framework, Risk Assessment. . Dave Wreski

Mar 08, 2024 •

Dave Wreski Security Projects

security advisorymalwareopen source

PyPI Security Alert: Malicious Packages Target Developers' Accounts

The recent uncovering of malicious Python projects being distributed through the Python Package Index (PyPI) is an urgent reminder of the need for enhanced vigilance and security around the Python open-source ecosystem. Threat actors have been able to compromise developer accounts and push out trojanized versions of legitimate Python libraries, enabling them to harvest credentials, execute arbitrary commands, and more. . While concerning, this attack vector also provides an opportunity to reinforce best practices around vetting and reviewing dependencies in Python and other languages. The key is applying lessons learned to mitigate risk without losing the incredible value of open source. Details of Malicious Packages Security researchers discovered three malicious Python packages that were uploaded to PyPI, the official third-party software repository for the Python programming language. The malicious packages were: python3-dateutil - This package contained a reverse shell module that allowed remote command execution. Once installed, it could enable attackers to gain full control over the victim's system. jeIlyfish - This misspelled package masqueraded as a legitimate jellyfish library. It exported a leet function that could execute system commands. pillow-simd - This package spoofed the real pillow-simd image library. It exported a primals module that enabled remote code execution. If installed, all three packages leveraged Python's extensive capabilities and third-party ecosystem to carry out malicious actions. They posed a serious threat to Python developers and systems running Python applications. Infection Vector The infection began by compromising PyPI accounts belonging to legitimate developers. The threat actors uploaded malicious versions of legitimate packages, often using confusingly similar package names. For example, one malicious package was called "qrcode" compared to the legitimate "qrcode[all]" package. The extra"[all]" was left off to appear as the original. Once published on PyPI, the malicious packages spread quickly. Developers frequently use pip or poetry for dependency management in Python projects. When dependencies are installed, pip pulls packages from PyPI automatically. So any project that listed the compromised packages as dependencies resulted in the malware being installed. This allowed the malicious code to propagate rapidly to end-users via PyPI before being detected. The supply-chain style attack through a trusted platform like PyPI demonstrates how dangerous typosquatting and social engineering can be in open source. It also served as a wake-up call to vet dependencies and practice defense in depth. Developer Accounts Compromised The report details how the threat actors could compromise legitimate developer accounts on PyPI to distribute their malicious packages. Once the developer accounts were compromised, the attackers could publish malicious versions of legitimate packages and distribute malware to unsuspecting users. Some of the common techniques used to compromise developer accounts included phishing, password spraying, and exploiting previously disclosed vulnerabilities. The report found that compromised credentials were likely obtained through various data breaches over the years and then leveraged in credential-stuffing attacks. This highlights the importance of using strong, unique passwords across all accounts and enabling two-factor authentication wherever possible. Developers must also protect their accounts and respond quickly to suspicious activity. The report is an important reminder that the open-source software supply chain faces risks. Malicious actors actively seek ways to distribute malware by compromising infrastructure and developer accounts. The infosec community needs to continue working on improving the open-source ecosystem's security. What Are the Implications for Open Source? The compromised Python packages on PyPI underscore serious concernsabout the open-source software supply chain. Millions of developers rely upon open-source repositories like PyPI and npm daily. The ability of threat actors to insert malicious code into critical open-source libraries creates massive risks. Once tainted code enters an open-source repo, it can spread exponentially fast. Downstream dependencies and products inheriting the bad code can infect countless applications and systems. Compromised developer accounts further amplify the attack surface and blast radius. This enables threat actors to target various industries and organizations under the radar. The incident reveals glaring vulnerabilities in the open-source ecosystem, especially regarding identity assurance. Without sufficient safeguards, attackers can easily impersonate and commandeer legitimate developer accounts. More rigorous identity proofing and verification controls are needed to secure software repositories. Open source maintainers must also improve proactive security to detect anomalous and suspicious check-ins. Repositories should leverage threat intelligence, behavioral analysis, sandbox environments, and automated code scanning. While open source delivers immense value, we must reinforce its security foundations. Detection and Protection Detecting and protecting against malicious Python packages requires vigilance on multiple fronts. At the developer level, use multi-factor authentication for PyPI and GitHub accounts to prevent account takeovers. Monitor account activity closely through notifications and audit logging to identify any unusual or unauthorized actions. Secure software development practices like code reviews and static analysis are established for organizations to catch malicious code before deployment. Perform malware scans on dependencies before use in production applications. Limit what base images and packages can be used to only trusted sources. System administrators should employ endpoint detection solutions that watch for suspicious Python processbehavior like network calls, filesystem changes, and execution of OS commands. Monitor systems for unexpected or unnecessary Python packages being installed. Network security teams can analyze traffic to and from PyPI for command and control or data exfiltration patterns. Detect outbound encrypted connections from Python processes to unknown destinations. Security operations centers should create threat intel feeds of malicious packages, accounts, and infrastructure to block. Have incident response plans ready for supply chain attacks through Python dependencies. For all Python users, only install packages from reliable sources and developers. Check user reviews and the maturity of packages before using. Run updates frequently and monitor Python-related security announcements. Practice defense in depth to limit damage from any single compromise. Multiple layers of protection at the development, organizational, network, and endpoint levels can significantly reduce the threat from malicious Python packages. However, continued vigilance and collaboration across the open-source community are key to identifying and responding to new supply chain attacks. Lessons Learned The recent discovery of malicious Python packages being distributed through PyPI is an important reminder of the need for diligence when consuming and publishing open-source software. There are several key takeaways from this incident that both developers and users of open source should keep in mind going forward: Trust but verify. While the open-source community prides itself on transparency and trust, incidents like this demonstrate that attackers are finding ways to exploit that trust. Consumers of open-source packages should use tools to scan for vulnerabilities or malware before deploying and be cautious about immediately updating to the latest version without fully verifying the changes. Developer credentials matter. The compromised developer accounts used in this attack had existed for years and builtup a reputation of trustworthiness. Developers should be extremely protective of their credentials for publishing open-source packages and enable multifactor authentication wherever possible. Monitor dependencies. The malicious packages in this incident were dependencies used by other legitimate projects. Keeping track of all dependencies used in a project and watching for vulnerabilities or suspicious changes helps mitigate risk. Defense in depth. No single solution will fully protect against threats like compromised packages. Combining scanning tools, dependency monitoring, credential protection, and code audits makes open-source use more secure and resilient. This incident is a reminder to remain vigilant about security, even when using reputable open-source libraries. However, staying informed and combining proactive measures can help defend open-source projects and users against emerging threats. Prevention Strategies The open-source community must come together to implement better security practices in order to prevent similar supply chain attacks targeting PyPI and other package repositories in the future. First, two-factor authentication should be required for all developer accounts that can publish packages. This would prevent malicious actors from easily hijacking legitimate accounts. In addition, package repositories need to implement code scanning to detect malware or suspicious activity. Machine learning could be leveraged to automatically flag anomalous publishing patterns or new packages from dormant accounts. Developers should also leverage tools like virtualenv and containerization to isolate their Python environments. This would limit the blast radius if a compromised package is installed. Finally, end users should only install packages from trusted sources and avoid pip installing directly from PyPI in production environments. Organizations should have a vetting process for evaluating open-source software dependencies. With increasedvigilance and proactive security measures, the open-source community can reduce the risk of supply chain attacks that could undermine the integrity of critical software ecosystems. However, it requires a coordinated effort among all stakeholders. Final Thoughts on Python Security This report highlights the growing threat of malware being distributed through open-source repositories like PyPI. Although concerning, this type of attack is not entirely surprising given the popularity and ubiquity of Python packages and open source in general. As more developers rely on downloading and integrating third-party code, there is increased vulnerability if proper security practices are not followed. For organizations, some key takeaways include being vigilant about vetting and scanning any Python packages before use in production systems. Monitoring account activity is also critical to detect any potential compromises early on. Multi-factor authentication should be required for all accounts that allow uploading to repositories. For individual developers, enabling 2FA, using unique passwords, and being cautious about third-party contributions can help reduce risk. It's also important to be selective about sharing account credentials across projects and teams. Overall, Open Source allows developers to build faster by standing on the shoulders of others. But inherent in this free exchange of code is the risk of introducing vulnerabilities, whether intentionally through malware or unintentionally. As the adoption of platforms like PyPI continues to grow, all stakeholders must remain proactive about security to minimize attacks. With greater awareness and collective responsibility, the benefits of open source can continue to outweigh the risks. . Developers must enhance security vigilance against malicious Python packages from PyPI, prioritizing proactive vetting practices.. Python Package Security, Dependency Review, Supply Chain Threat. . LinuxSecurity.com Team

Jan 01, 2024 •

LinuxSecurity.com Team Hacks/Cracks

risk managementcontainer securitysoftware supply chain

Docker Scout and Sysdig Partner to Boost Container Risk Management

Today at DockerCon, Docker has announced the General Availability of Docker Scout. With the integration of Sysdig Runtime Insights, Docker Scout helps developers prioritize risk. This will significantly improve software supply chain security. Let's find out why. . A top priority in the attempt to harden the supply chain is to focus on the containers' security. We've recently examined Wolfi the Linux Unidistro which works by releasing container images already provided with signing and sensible defaults. Docker has taken an alternative approach by introducing Docker Scout as the replacement of the legacy 'docker scan'. With 'docker scan' you would manually vet your image for vulnerabilities; Docker Scout however has ditched the old-fashioned manual and scheduled scans behind and instead it embraces a modern event-driven model. That is, if a new vulnerability affecting your images is announced, Scout shows the updated risk within seconds. Its always alert, updating vulnerability info from 17+ sources in real time and this data is compared with your Software Bill of Materials for up-to-the-minute accuracy. . Docker Guard enhances the safety of the software development pipeline by collaborating with Sysdig to provide instant vulnerability oversight.. Docker Security, Container Management, Sysdig Insights. . Brittany Day

Oct 05, 2023 •

Brittany Day Organizations/Events

secure accesspasswordless authenticationsoftware supply chain

OpenPubkey Enhances Docker Signing With Zero-Trust Authentication

The newest open-source project hosted by the Linux Foundation is OpenPubkey, which is a collaboration with Docker and BastionZero and will be available for Docker container signing with zero-trust passwordless authentication. . OpenPubkey is born out of BastionZero's secure infrastructure access product and comes down to being a protocol to securely and accurately bind cryptographic keys to users and workloads by creating a CA out of an OpenID Connect Identity Provider. The hope is OpenPubkey can help secure the software supply chain for Docker and other software projects. The link for this article located at Phoronix is no longer available. . SecureSign enhances Kubernetes pod verification with seamless authentication and strives to bolster the application delivery pipeline.. OpenPubkey Project, Docker Signing, Zero-Trust Authentication, Software Supply Chain, BastionZero Collaboration. . LinuxSecurity.com Team

Oct 04, 2023 •

LinuxSecurity.com Team Security Projects

security strategyDevSecOpssoftware supply chain

Managing Your Software Supply Chain Security With Backstage

An internal developer portal can help you consolidate and evolve your security strategy. . Software nowadays is rarely written from scratch. According to Forrester , the average software is composed of at least 75% open source code. Additionally, teams rely heavily on third-party code. Thus, the code you put into production comes from different sources and goes through various networks and actors to get there. This is known as the software supply chain. Software supply chains have gained significant attention after severe attacks over the past few years. In the United States, the federal government has even issued software supply chain guidelines for state contractors. As the Cloud Native Computing Foundation (CNCF) Security working group states, “Supply chains require more than one linked process, and supply chain security relies on the validation and verification of each process.” Therefore, to adopt security practices in each step of the development life cycle, companies usually adopt a DevSecOps approach. . Software systems encounter vulnerabilities caused by dependency on external sources. Discover strategies to enhance protection using Backstage.. Software Supply Chain, Security Strategy, Internal Developer Portal, Third-Party Code, DevSecOps. . LinuxSecurity.com Team

Aug 08, 2023 •

LinuxSecurity.com Team Security Projects

security threatsmalicious codeopen source risk

Risk of AI Hallucinations in Open Source Security Threatens Enterprises

Researchers at an Israeli security firm on Tuesday revealed how hackers could turn a generative AI’s “hallucinations” into a nightmare for an organization’s software supply chain. . In a blog post on the Vulcan Cyber website, researchers Bar Lanyado, Ortel Keizman, and Yair Divinsky illustrated how one could exploit false information generated by ChatGPT about open-source software packages to deliver malicious code into a development environment. They explained that they’ve seen ChatGPT generate URLs, references, and even code libraries and functions that do not actually exist. If ChatGPT is fabricating code libraries or packages, attackers could use these hallucinations to spread malicious packages without using suspicious and already detectable techniques like typosquatting or masquerading, they noted. . Analysts revealed the potential for AI-generated delusions to take advantage of vulnerabilities in public software and threaten corporate safety.. Enterprise Security, AI Exploitation, Software Supply Chain, Malicious Code, Open Source Risks. . Brittany Day

Jun 13, 2023 •

Brittany Day Security Trends

27.Tablet Connections Blocks Lock Esm H240

cybersecuritydependency managementsecurity challenges

Understanding Dependency Security Risks in Open-Source Projects

Open-source software and hardware projects are becoming increasingly popular, but their complexity and large supply chains bring new challenges for engineers in terms of cybersecurity. With the growing threat of cyber attacks, it's important to understand the security issues posed by dependencies and how the future of open-source projects can mitigate these risks. . PyTorch, a popular open-source platform for Python, is just one example of the potential benefits and drawbacks of open-source projects at scale. Open-source projects have the potential to provide innovative solutions but also come with risks that must be carefully considered. As technology continues to progress, open-source solutions are becoming increasingly dominant. Agricultural industries that have historically been tied to manufacture-specific solutions that lock out individual developers are being challenged, software companies are shifting their focus to open-source solutions in an attempt to demonstrate security and privacy, and even large businesses (such as IBM) who have garnered success on closed-source solutions are now even joining in the open-source movement. But why exactly has the open-source movement proven to be a modest success? Many would be quick to suggest that the free nature of open-source hardware makes it popular with those looking to save money, and there is undoubtedly some truth in this. However, considering that the vast majority of people continue to use paid solutions (such as MS Office over LibreOffice) provides counter-evidence to this motive. . Engineers must understand the significance of supply chain vulnerabilities in open-source software and take measures to enhance security.. Open-Source Projects, Security Risks, Dependency Management. . Brittany Day

Feb 22, 2023 •

Brittany Day Security Trends

Community Poll

More Polls

Stay Ahead With Linux Security News

Refine news

Get the latest News and Insights

Community Poll

Is continuous patching actually viable?

Trending News

Misuse of Cron Jobs for Long-Term Access in Linux Environments

Risks of GitHub Repo Breach on Linux Supply Chain Security

After Years of Supply Chain Attacks, npm Is Finally Closing the Door on Auto-Scripts

FFmpeg PixelSmash Vulnerability Exposes Linux Media Servers to Remote Code Execution Risk

Explore Latest Linux Security news

Linux Foundation Launches Akrites to Strengthen Software Supply Chain Security

Integrating GUAC: Enhancing Software Supply Chain Security Framework

PyPI Security Alert: Malicious Packages Target Developers' Accounts

Docker Scout and Sysdig Partner to Boost Container Risk Management

OpenPubkey Enhances Docker Signing With Zero-Trust Authentication

Managing Your Software Supply Chain Security With Backstage

Risk of AI Hallucinations in Open Source Security Threatens Enterprises

Understanding Dependency Security Risks in Open-Source Projects

Get the latest News and Insights

Community Poll

Is continuous patching actually viable?

Trending News

Misuse of Cron Jobs for Long-Term Access in Linux Environments

Risks of GitHub Repo Breach on Linux Supply Chain Security

After Years of Supply Chain Attacks, npm Is Finally Closing the Door on Auto-Scripts

FFmpeg PixelSmash Vulnerability Exposes Linux Media Servers to Remote Code Execution Risk

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 News

Refine news

Topics

Category

Authors

Published Date

Get the latest News and Insights

Community Poll

Is continuous patching actually viable?

Trending News

Explore Latest Linux Security news

Get the latest News and Insights

Community Poll

Is continuous patching actually viable?

Trending News

Search Topics

Powered By

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

QUICK LINKS

subscribe to newsletters!