Skip to main content

Removing 50 Objects from Orbit Would Cut Danger From Space Junk in Half

3 weeks 2 days ago
If we could remove the 50 most concerning pieces of space debris in low-Earth orbit, there'd be a 50% reduction in the overall debris-generating potential, reports Ars Technica. That's according to Darren McKnight, lead author of a paper presented Friday at the International Astronautical Congress in Sydney, which calculated the objects most likely to collide with other fragments and create more debris. (Russia and the Soviet Union lead with 34 objects, followed by China with 10, the U.S. with three, Europe with two, and Japan with one.) Even just the top 10 were removed, the debris-generating potential drops by 30%. "The things left before 2000 are still the majority of the problem," he points out, and "76% of the objects in the top 50 were deposited last century." 88% of the objects are post-mission rocket bodies left behind to hurtle through space. "The bad news is, since January 1, 2024, we've had 26 rocket bodies abandoned in low-Earth orbit that will stay in orbit for more than 25 years," McKnight told Ars... China launched 21 of the 26 hazardous new rocket bodies over the last 21 months, each averaging more than 4 metric tons (8,800 pounds). Two more came from US launchers, one from Russia, one from India, and one from Iran. This trend is likely to continue as China steps up deployment of two megaconstellations — Guowang and Thousand Sails — with thousands of communications satellites in low-Earth orbit. Launches of these constellations began last year. The Guowang and Thousand Sails satellites are relatively small and likely capable of maneuvering out of the way of space debris, although China has not disclosed their exact capabilities. However, most of the rockets used for Guowang and Thousand Sails launches have left their upper stages in orbit. McKnight said nine upper stages China has abandoned after launching Guowang and Thousand Sails satellites will stay in orbit for more than 25 years, violating the international guidelines. It will take hundreds of rockets to fully populate China's two major megaconstellations. The prospect of so much new space debris is worrisome, McKnight said. "In the next few years, if they continue the same trend, they're going to leave well over 100 rocket bodies over the 25-year rule if they continue to deploy these constellations," he said. "So, the trend is not good...." Since 2000, China has accumulated more dead rocket mass in long-lived orbits than the rest of the world combined, according to McKnight. "But now we're at a point where it's actually kind of accelerating in the last two years as these constellations are getting deployed." A deputy head of China's national space agency recently said China is "currently researching" how to remove space debris from orbit, according to the article. ("One of the missions China claims is testing space debris mitigation techniques has docked with multiple spacecraft in orbit, but U.S. officials see it as a military threat. The same basic technologies needed for space debris cleanup — rendezvous and docking systems, robotic arms, and onboard automation — could be used to latch on to an adversary's satellite.")

Read more of this story at Slashdot.

EditorDavid

Are Software Registries Inherently Insecure?

3 weeks 2 days ago
"Recent attacks show that hackers keep using the same tricks to sneak bad code into popular software registries," writes long-time Slashdot reader selinux geek, suggesting that "the real problem is how these registries are built, making these attacks likely to keep happening." After all, npm wasn't the only software library hit by a supply chain attack, argues the Linux Security blog. "PyPI and Docker Hub both faced their own compromises in 2025, and the overlaps are impossible to ignore." Phishing has always been the low-hanging fruit. In 2025, it wasn't just effective once — it was the entry point for multiple registry breaches, all occurring close together in different ecosystems... The real problem isn't that phishing happened. It's that there weren't enough safeguards to blunt the impact. One stolen password shouldn't be all it takes to poison an entire ecosystem. Yet in 2025, that's exactly how it played out... Even if every maintainer spotted every lure, registries left gaps that attackers could walk through without much effort. The problem wasn't social engineering this time. It was how little verification stood between an attacker and the "publish" button. Weak authentication and missing provenance were the quiet enablers in 2025... Sometimes the registry itself offers the path in. When the failure is at the registry level, admins don't get an alert, a log entry, or any hint that something went wrong. That's what makes it so dangerous. The compromise appears to be a normal update until it reaches the downstream system... It shifts the risk from human error to systemic design. And once that weakly authenticated code gets in, it doesn't always go away quickly, which leads straight into the persistence problem... Once an artifact is published, it spreads into mirrors, caches, and derivative builds. Removing the original upload doesn't erase all the copies... From our perspective at LinuxSecurity, this isn't about slow cleanup; it's about architecture. Registries have no universally reliable kill switch once trust is broken. Even after removal, poisoned base images replicate across mirrors, caches, and derivative builds, meaning developers may keep pulling them in long after the registry itself is "clean." The article condlues that "To us at LinuxSecurity, the real vulnerability isn't phishing emails or stolen tokens — it's the way registries are built. They distribute code without embedding security guarantees. That design ensures supply chain attacks won't be rare anomalies, but recurring events."BR> So in a world where "the only safe assumption is that the code you consume may already be compromised," they argue, developers should look to controls they can enforce themselves: Verify artifacts with signatures or provenance tools. Pin dependencies to specific, trusted versions. Generate and track SBOMs so you know exactly what's in your stack. Scan continuously, not just at the point of install.

Read more of this story at Slashdot.

EditorDavid