Software Security | Breaking Cybersecurity News | The Hacker News

In eleven days, on September 11, manufacturers of products with digital elements sold into the European Union have to tell a regulator within 24 hours of learning that a vulnerability in one of their products is being actively exploited, with a fuller account due at 72 hours. I have a decent idea what the next eleven days look like inside most of those companies, having spent close to thirty years watching software organizations get ready for a date on a calendar. There will be a spreadsheet of products and owners that somebody builds over a weekend, a notification template that goes to legal for review, probably a consultant on a two-week engagement. It will mostly work. By September 10, the majority of them will be able to file inside 24 hours, and they will be right to feel relieved about it, because filing on time is exactly what the regulation asks, and it is not a trivial thing to arrange. What I would gently point out is that almost none of them will come out of the exercise ...

AI-driven vulnerability discovery is no longer a research project. Claude Mythos proved that. In a single sweep, it uncovered thousands of vulnerabilities in software we use every day, generated working exploits, and exposed bugs that had survived decades of human review. Other AI models are rapidly catching up, and we've entered into an entirely new operating environment for cybersecurity. The industry is treating this as a turning point, and it is. But not for the reason most people might think. The Real Problem Was Never Finding Vulnerabilities Most of the conversation around AI security focuses on discovery: AI can now identify vulnerabilities faster than human teams ever could. That is certainly true, but it also misses the larger operational reality organizations have been struggling with for years. Security teams were already overwhelmed long before AI entered the picture. Vulnerability scanners, fuzzers, and static analysis tools have consistently generated more...

When Shai-Hulud 2.0 hit in late 2025, it was a brutal, expensive wake-up call for DevSecOps teams. It showed that the industry's direction of shifting left, where teams pass security onto developers, wasn't the silver bullet everyone hoped for. Pushing that responsibility was fine in theory, but it crumbled quickly because the foundation it was built on was inherently flimsy. As we move further into 2026, we need a more definitive fix to the structural weakness in the pipelines in light of a potential Shai-Hulud 3.0. A major lesson from 2.0 was that internal CI/CD runners were easily hijacked and turned into attack botnets. Teams need to take that finding and come back with a truly proactive defense. A curated catalog is a way for security teams to control exactly what code and components enter their environment, while still giving engineering teams a fast, secure way to build - it is the key to creating a sustainable solution. More on a curated catalog later. The Anatomy o...

Open-source libraries allow developers to move faster, leveraging existing building blocks instead of diverting resources to building in-house. By leaning on existing open-source packages, engineers can focus on complex or bespoke elements of their products, using package managers and open-source maintainers to make it easy to pull everything together.  However, you can't deny that building software using open source makes your applications more vulnerable to security risks. In an open-source library, attackers have direct access to code, and can search for current and historical vulnerabilities, as well as any issues and tickets managed on websites such as GitHub or GitLab. This helps threat actors to quickly find packages that are vulnerable and launch an attack.  This is where Software Composition Analysis (SCA) comes in, with the purpose of scanning packages and uncovering vulnerabilities. SCA compiles and manages a catalog of software packages, alongside details such ...