Audit Linux privileges now to limit compromise, escalation, and system-wide damage. Review Linux Privileges×
Security Vulnerabilities 
cisa kev vulnerability prioritization
cisa kev vulnerability prioritization Organizations should combine the NVD and CISA KEV catalog to prioritize vulnerabilities effectively, focusing on managing real risks rather than being overwhelmed by theoretical scores and alert fatigue.. To solve this, organizations typically lean on the National Vulnerability Database (NVD) and CISA’s Known Exploited Vulnerabilities Catalog. But these aren’t competing lists. They answer two entirely different questions. While the NVD provides baseline technical metrics aligned with the...
Jul 22, 2026
Desktop Securitysecurity advisory vulnerability
security advisory vulnerability GNOME is officially shortening its standard vulnerability disclosure window from 90 days to 30 days, a change that impacts upstream maintainers, downstream Linux distributions, and system administrators in how they handle software vulnerabilities. The policy shift, announced by long-time security coordinator Michael Catanzaro , addresses modern software patching realities and a growing influx of automated submissions. . Because GNOME is the default desktop environment on several major Linux...
Jul 21, 2026
Security Vulnerabilities security advisory moderate
security advisory moderate For organizations that run a self-hosted Git platform, it’s no longer just about hosting static code repositories. Today, Git servers are responsible for deployment pipelines, API tokens, SSH keys, package repositories, and the automation scripts that push code directly. Confirm that the upgrade addresses known vulnerabilities but also provides production environments. . That makes them trusted systems within the development environment and attractive targets for attackers looking to move...
Jul 20, 2026
Server Securitydata privacy automation
data privacy automation Every system admin has lived through the same Monday morning ritual. A queue of forty tickets, half of them password resets, permission errors, or disk space warnings that any experienced technician could resolve in under two minutes. The other half require actual judgment. For years, automation promised that software would eventually sort the two apart on its own. That promise is now being tested in production Linux environments. . Early results are reshaping how IT teams think about tier-1...
Jul 17, 2026
Privacydata collection automation
data collection automation You're running a web scraping project to collect pricing data from e-commerce sites. You set up a pool of datacenter proxies, launch your scripts, and within minutes — banned . CAPTCHAs everywhere. Your data pipeline stops before it really begins. . It's a frustrating scenario that plays out daily in ad verification, market research, and multi-account management. The website doesn't know you're doing legitimate research or monitoring. It just sees traffic coming from IP ranges it recognizes as...
Jul 17, 2026
Refine news
X Clear Filters
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
Should Linux servers automatically install security updates?
Trending News
Loading...
Explore Latest Linux Security news
We found 4 articles for you...
82
European Commissionpublic sectorsoftware maintenanceEurope’s Open Source Strategy Takes Aim at Software Security’s Maintenance Problem
Some of the software the world depends on most is maintained by people most users will never know by name. The project might be sitting inside Linux distributions, enterprise software, cloud platforms, and government systems without most users ever realizing it is there. . The problem is not difficult to find. Critical software components can end up supporting thousands of products and services while being maintained by small teams with limited resources. By the time a vulnerability, governance failure, or supply chain incident becomes visible, the software is often already embedded across environments that depend on it. The European Commission's new Open-Source Strategy is an attempt to address that problem. The strategy focuses on long-term maintenance, critical dependency mapping, open standards, procurement, governance, and public-sector adoption. More importantly, it recognizes that open-source security often depends on project health long before a CVE appears. What Europe’s Open Source Strategy Actually Proposes The European Commission published the strategy in June 2026. It sits inside Europe’s wider push for technological sovereignty, where open source is being tied to cloud, AI, public-sector systems, and long-term control over software infrastructure. The focus is practical: Adoption Governance Maintenance Skills Public-sector use The strategy is not only looking at new software. It is looking at projects that are already inside systems, already pulled into packages, already supporting workloads that governments may not fully understand until a patch fails or a dependency shows up in an incident. The main pieces are the Open Source Maintenance Instrument, critical dependency mapping, stronger Open Source Program Offices, open standards, interoperability, and procurement reform. Those are maintenance controls as much as policy ideas. They decide who can find the dependency, who owns support, who understands the upstream project, and whetherpublic-sector buyers keep treating open source as free code with no operational tail. That is the useful part of the strategy. It treats open source like something that keeps running after deployment. Code needs maintainers. Dependencies need visibility. Public systems need support paths before a vulnerability, abandoned package, or broken update turns into the reason everyone finally starts looking. Why Maintenance Has Become a Security Problem Open-source security problems do not always begin with vulnerable code. Sometimes the warning signs appear much earlier. A maintainer steps away. Reviews become less frequent. Issues sit unanswered. Releases slow down. The project is still being used, but fewer people are actively keeping it moving. That can become a problem surprisingly quickly. Critical software is not always maintained by large teams with dedicated funding and formal processes. A package may end up inside Linux distributions, enterprise products, cloud platforms, and government systems, while a small group of maintainers handles most of the work. As adoption grows, the dependency footprint expands. The maintainer team often does not. Consider these high-profile examples: Heartbleed : Exposed the risk inside a cryptographic library that much of the Internet already trusted. Log4Shell showed how a single open-source component could be embedded across thousands of environments, leaving organizations scrambling to find where it was running. The xz Backdoor : Shifted attention from the malicious code itself to maintainer trust, project stewardship, and how influence had been established inside a widely used project. These incidents looked different, but they shared a common thread. The security issue became visible at the end of the story. The maintenance, governance, and dependency problems were already there. Why Europe Is Linking Open Source to Digital Sovereignty The strategy is also tied to Europe's broader push for digital sovereignty. That term can soundpolitical, but much of the discussion comes down to technology dependencies. Governments, public institutions, and critical services increasingly rely on software, cloud platforms, and AI technologies that are controlled by a relatively small number of providers. For more context on these objectives, refer to the EU Open Source Strategy Fact Page . Open source fits into that conversation because it changes some of those dependencies. Code can be inspected. Systems can be maintained without relying on a single vendor. Software can be replaced, modified, or supported by another provider if requirements change. None of those guarantees better security on their own, but they can give organizations more visibility and more control over the systems they depend on. Open standards and interoperability appear throughout the strategy for similar reasons. Public-sector systems often remain in service for years. Sometimes decades. The ability to move data, replace components, or change providers becomes much more difficult when systems are tied to proprietary formats or vendor-specific technologies. The security relevance is not really about politics. It is about understanding what is running, reducing unnecessary dependencies, and avoiding situations where critical systems become difficult to maintain because too much control sits outside the organization responsible for operating them. If the strategy leads to better-supported open-source projects and healthier software dependencies, the security benefits are fairly easy to see. Critical Dependency Mapping Could Be the Most Important Security Piece Organizations cannot protect dependencies they cannot identify. That sounds basic until a vulnerable package shows up three layers down in an application stack, and nobody knows which system pulled it in. Linux systems are built from thousands of libraries, packages, tools, and upstream projects. Some are obvious. Others sit quietly under installers, containers, appliances, build systems, and managedservices. They only become visible when a patch is needed or an advisory forces teams to trace the dependency path. That is why critical dependency mapping matters. It gives governments and public institutions a way to see: Which projects are actually supporting their systems. Which ones need review. Which ones may need funding or maintenance support before they become the next emergency. This also connects directly to SBOMs, vulnerability management, and software supply chain visibility. Inventory is no longer just asset management. It is part of knowing where exposure begins. Can Procurement Fix What Volunteer Labor Cannot? SUSE’s argument is that Europe does not have a supply problem. Open-source software already exists. The harder problem is demand that is scattered across agencies, vendors, contracts, and procurement rules that do not always reward maintenance or support. Public-sector buying can change that. If governments require open standards, support pathways, and maintain open-source solutions, money starts moving toward the organizations and projects keeping the software alive. That creates pressure in the right place. But procurement does not fix everything: A contract can support a vendor and still miss the upstream maintainer doing the real work. A public-sector requirement can increase adoption without improving review, governance, or release discipline. Buying open-source software is not the same as sustaining it. The bet is that coordinated demand can make maintenance less accidental. That only works if the money reaches the projects and support structures that actually carry the load. Further economic context can be found in the European Commission 2021 Economic Impact Stud y and the research provided by Frank Nagle at Harvard Business School . The Risks: Strategy Does Not Secure Code by Itself Mapping dependencies is easier than maintaining them. A list can show where a project is used, but it does not review patches, handlereleases, resolve maintainer burnout, or fix governance problems. Funding has the same issue. It has to reach the projects that need it, not just the institutions best positioned to apply for it. Public-sector procurement is slow. Member states may adopt different standards, different timelines, and different definitions of what “critical” means. There is also a simpler failure mode. Governments adopt more open source without building the maintenance path around it. The software footprint grows, but the support model does not. Risk moves around instead of going away. The strategy has value only if it turns into operational support. Funding. Review. Governance. Maintainer help. Procurement rules that reward long-term support instead of treating open source as a cheaper line item. As the Open-Source Initiative (OSI) notes , the implementation details matter as much as the intent. What Linux Users and Open Source Teams Should Watch The first thing to watch is whether the Open Source Maintenance Instrument becomes real support or just another framework. The difference will show up in whether maintainers see funding, review help, staffing, infrastructure, or reduced workload. The definition of “critical” also matters. If ENISA or other EU bodies define it too narrowly, important packages will be missed. If the definition is too broad, the process becomes paperwork, and nobody knows where to focus. Procurement is another signal. Public-sector contracts may start requiring open standards, support paths, SBOMs, or clearer maintenance responsibilities. That would affect vendors, integrators, and Linux teams supporting government environments. OSPOs are worth watching too. A program office without authority becomes documentation. A program office with budget, policy control, and technical staff can change how an institution selects software, tracks dependencies, and handles upstream relationships. The useful question is simple. Do maintainers, vendors, and public-sector users getpractical help from this, or do they get more forms to fill out? Conclusion Europe’s Open Source Strategy matters because it recognizes a hard truth. Software security is not only about finding vulnerabilities after they appear. It is also about keeping the projects underneath critical systems healthy enough that failure is less likely in the first place. That means people. Funding. Governance. Dependency visibility. Review. Support paths that exist before a CVE, broken package, or supply chain incident forces everyone to care. If Europe turns the strategy into real maintenance support, it could strengthen the open-source foundations Linux users already rely on. If not, it becomes another document that correctly identifies the problem without changing what happens when the next critical project starts to crack. . Europe's Open Source Strategy addresses software security maintenance, focusing on dependencies and governance for better safety.. Open Source, Software Maintenance, Security Governance, Dependency Mapping, Digital Sovereignty. . MaK Ulac
Jun 19, 2026
•
Government
79
security advisorysecurity enhancementssystem riskLinux 6.11 EOL: Upgrade to 6.12 for Enhanced Security and Stability
The Linux kernel community recently issued an EOL announcement regarding the 6.11 kernel series, urging sysadmins to upgrade quickly to 6.12 . This announcement has significant ramifications for secure Linux system administration, as operating outdated kernels can expose systems to unpatched security flaws and associated risks. . The 6.12.y branch offers continuous maintenance and security updates to ensure critical safeguards are in place. Enhancements included improved hardware support, performance optimizations, and bug fixes, which streamline system operations to provide greater reliability and efficiency for system operations. Major distributions like Ubuntu and Fedora have already started adopting the Linux 6.12 kernel upgrade. This announcement is an urgent call to action for admins: Upgrade to Linux kernel 6.12 as soon as possible! Why does upgrading matter, and what can we expect from the 6.12.y branch? Let's dive deeper into the aspects of this transition to understand its impact on the security and administration of your Linux systems. The End-of-Life Status of Linux 6.11: A Risk You Can't Ignore The end-of-life status of Linux 6.11 marks an essential point in its lifecycle. It signals to users that the community will no longer provide security patches, bug fixes, and updates to this kernel series. Utilizing an EOL kernel is like leaving your doors unlocked in an unsafe neighborhood. Without active support for its updates and patches, any newly discovered vulnerabilities leave admins at risk of attacks compromising system integrity, confidentiality, and compliance. As infosec professionals know, modern security threats move quickly, with attackers seeking vulnerable systems they can exploit. By continuing with Linux 6.11, you risk potential breaches that could compromise your systems and critical data. Availability of the 6.12.y Branch: What's New and Why You Should Care With the 6.12.y branch now available, upgrading from an outdated 6.11 kernel series should benearly effortless. Not just another version, 6.12.y represents another step in Linux kernel evolution, with regular maintenance updates and security patches safeguarding systems against vulnerabilities. Upgrading to Linux 6.12 assures continuing support, meaning any security vulnerabilities discovered will be quickly addressed with timely patches . This is essential for anyone managing Linux servers since being up-to-date on security patches is integral to maintaining a safe and resilient environment. Furthermore, performance optimizations and bug fixes keep this series stable and efficient. Examining Notable Changes in Linux 6.12: A Roadmap for Transition The transition from Linux 6.11 to 6.12 brings exciting changes, new features, and enhancements, including: Improved Hardware Support: The 6.12 kernel features improved support for new and emerging hardware technologies, providing administrators with essential compatibility and optimal performance when using more modern equipment. Intel and AMD processor support has also been greatly expanded, enabling better resource utilization efficiency and management. Security Enhancements: Linux 6.12 stands out for its commitment to security, with features such as KFENCE (Kernel Electric-Fence) , an error detection and mitigation system designed to identify memory corruption bugs before they can be exploited by other means. Filesystem Improvements: Filesystem reliability and performance have significantly improved over the years. In particular, Btrfs and EXT4 filesystems have received updates that will enhance reliability and performance to better suit demanding workloads. Network Enhancements: The 6.12 kernel features enhanced networking features, such as improved handling of high-throughput data transfers and lower latency networking operations, which are essential in server environments. Performance Optimizations: Regular performance tuning and optimization ensure Linux 6.12 can manage more workloads efficiently by improvingCPU scheduling, memory administration, and overall system responsiveness. Bug Fixes and Stability Improvements: As with every kernel release, 6.12 contains numerous bug fixes to address issues discovered during previous releases and to further increase system stability and reliability by decreasing crashes or downtime. Adoption by Major Linux Distributions Adopting new kernel releases by major Linux distributions is often seen as a reliable barometer of their stability and suitability for production environments. Many prominent distros have begun adopting Linux 6.12 into their systems already, signifying its robustness as well as the trust that members of the community have placed in this release. Such distros include: Ubuntu: Widely known for its reliability in server environments, Ubuntu now incorporates the Linux 6.12 kernel in its latest releases to provide users access to its performance and security enhancements. Fedora: Fedora continues its tradition of adopting cutting-edge technologies early. It took an innovative stance with its Linux 6.12 integration, giving users access to its improvements and features before other distributions do so. Fedora often sets an example that other distributions follow closely behind. Arch Linux: Recognizing that its users require cutting-edge software, Arch Linux quickly added the 6.12 kernel to provide its users with the most up-to-date features and innovations. These early adopters attest to the reliability and suitability of Linux 6.12 for production use, assuring administrators contemplating an upgrade. Our Final Thoughts on Embracing the Future of the Linux Kernel As Linux 6.11 nears end-of-life status, system administrators and infosec professionals must update to a more modern kernel. Updating to the 6.12.y branch offers continued security support and improvements that enhance compatibility, system performance, and protection. The risks of using outdated software have become too great in today's security landscape,where vulnerabilities are constantly discovered and exploited. Continuing support through version 6.12.y mitigates these risks and provides enhancements that improve compatibility, system performance, security features, and overall protection features. The Linux 6.12 kernel represents its constant evolution and improvement, offering administrators the means to ensure their systems remain secure, efficient, and capable of taking advantage of new hardware and technological advancements. Have you updated to Linux 6.12? Reach out to us @lnxsec and let us know! . Transition to Linux 6.12 for enhanced security patches and improved performance capabilities, leaving behind the obsolete 6.11 kernel.. Linux 6.12, EOL kernel, system upgrades, kernel security, software maintenance. . Brittany Day
Dec 06, 2024
•
Security Projects
79
security advisorysystem updateLinux kernelLinux Kernel 4.9 End Of Life: Urgent Upgrade Needed For Security
After being supported for a little more than six years, the Linux 4.9 kernel series has finally reached end of life with the 4.9.337 update released earlier this morning. The kernel is now marked appropriately as EOL on the kernel.org website, which means that it will no longer receive maintenance and security updates. . Linux kernel 4.9 was released on December 11th, 2016, and it brought support for shared extents and copy-on-write support on the XFS file system, a hardware latency tracer to detect firmware-induced latencies, support for the Greybus bus from Project Ara, a more efficient BPF profiler, a new optional BBR TCP congestion control algorithm, virtually mapped kernel stacks, and more. Due to its long-term support (LTS) status, Linux kernel 4.9 was most probably used on mass-production devices by big companies that produce hardware powered by a Linux-based operating system. But, the time has come to move on to newer kernels that include all the features of Linux kernel 4.9 and more. Renowned kernel developer Greg Kroah-Hartman announced earlier today that Linux kernel 4.9 will no longer be supported from here on, urging users to upgrade to a newer LTS (Long Term Support) series, such as Linux kernel 4.14, which will be supported for another year until January 2024, or the latest and greatest Linux kernel 6.1 , which should receive support for at least a couple of years. The link for this article located at 9 to 5 Linux is no longer available. . Following more than six years in service, Linux kernel 4.9 has officially reached its end of life, encouraging users to transition to more recent long-term support releases.. Linux Kernel, Long Term Support, System Upgrade, Security Updates, End of Life. . LinuxSecurity.com Team
Jan 09, 2023
•
Security Projects
209
open sourcesecurity challengesoftware maintenanceOpen Source Challenges: Security Risks And Software Maintenance
Open source may be the most viable option for most companies today but it comes with its own set of problems too. . Many people support the use of open source software (OSS). After all, why would we keep trying to build code that addresses issues that have already been resolved by others? Why not share the information and progressively and iteratively enhance the current open source solutions? These egalitarian values, however perhaps fundamental to civilization in general, not to mention software, nonetheless include conflicts that have been a problem for millennia. The problem with open source software security is that just because anyone can view the source code doesn’t imply they will. There are extensively used open-source projects that are only being maintained by a limited number of engineers. These engineers are unable to provide their time and effort completely voluntarily since they also need to pay their bills. . Explore the landscape of open-source vulnerabilities and the potential threats that modern organizations encounter when safeguarding essential software applications.. Open Source Software, Security Challenges, Software Maintenance. . Brittany Day
Oct 09, 2022
•
Security Trends
79
security issuescybersecurity initiativesoftware maintenanceGoogle's Open Source Crew Supports Critical Projects and Security
The Google Open Source Maintenance Crew will support under-resourced critical open-source products to fix security issues. . Google has created a new "Open Source Maintenance Crew" who will help upstream maintainers of critical open-source projects to handle bugs and patching processes. The new team is part of Google's contribution to the White House's push to improve cybersecurity in open source and protect software supply chains following the White House's January summit with major tech vendors , including Microsoft, Google, IBM and Amazon Web Services. . Google's Open Source Development Team seeks to improve assistance for vital projects while strengthening cybersecurity protocols.. Open Source Maintenance, Google Initiative, Cybersecurity Support, Critical Security Issues, Software Supply Chain. . LinuxSecurity.com Team
May 26, 2022
•
Security Projects
209
open sourcesoftware maintenancesecurity investmentInvesting in Open-Source Security and Developer Support
Devs and maintainers are getting paid ... though not to concentrate on security. . Open-source software has always been more secure than proprietary software, but that doesn't mean it's "secure." To lock it down, we need to invest serious cash in developers and maintainers. You may have noticed that a lot of people are getting seriously cranky about open-source software security lately. They have a reason. Our screw-ups have been making the news a lot lately. . To guarantee strong safeguards, open-source software necessitates considerable dedication of resources towards its developers and maintainers.. Open Source Security, Development Cost, Software Maintenance, Code Security. . Brittany Day
Feb 15, 2022
•
Security Trends
79
application securityrisk mitigationsoftware maintenanceEnhancing Application Security By Managing Open Source Risks
Since Apache Maven, the brainchild of Sonatype founder Jason van Zyl, emerged as a top-level Apache Software Foundation project in 2003, the Central Repository has become a primary source of open source components. Jackson says the Central Repository receives four billion requests per year for its 300,000 components. . But after crunching the data on how the Central Repository's components are used--with the help of application security specialist Aspect Security--Jackson says he believes organizations need to be much more diligent in their practices around open source components because many are exposing themselves to risk by deploying older, vulnerable versions of components. The link for this article located at Network World is no longer available. . Firms need to bolster their efforts in overseeing open source elements to reduce hazards associated with obsolete iterations.. Open Source Components, Application Security, Component Risk. . LinuxSecurity.com Team
Apr 03, 2012
•
Security Projects
79
security measurespatch managementopen sourceEssential Security Updates for Linux Distros And Patch Management
If you. Today we The link for this article located at ITS Tatictical is no longer available. . Enhance your Linux security with effective patch management and timely software updates. Discover essential strategies to strengthen system resilience against threats. Linux Patch Management, System Update Practices, Open Source Security Protocols. . LinuxSecurity.com Team
Dec 19, 2011
•
Security Projects
Get the latest News and Insights
Get the latest Linux and open source security news straight to your inbox.
Community Poll
Should Linux servers automatically install security updates?
Trending News
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!