Vulnerability | Breaking Cybersecurity News | The Hacker News

AI coding agents are already inside engineering organizations. The problem security teams need to solve is not only that AI-generated code might be vulnerable. You already have ways to catch that: code review, CI, SAST, dependency scanning, and production monitoring. The real problem is that tools such as Claude Code, OpenAI Codex, Claude Cowork, and GitHub Copilot are becoming extensible agent runtimes. Skills, plugins, hooks, repository instructions, and MCP servers can influence what the agent reads, which tools it selects, what commands it runs, and where enterprise data is sent. Most AI governance programs stop at approving the application. Very few can tell you everything that has been installed inside it. That is the supply-chain gap. What changed: Third-party components are no longer participating only at build or deploy. They are participating in the agent's decision loop. From coding assistant to agent runtime The first generation of coding assistants mainly...

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 ...

Cybersecurity teams have no shortage of threat data: New vulnerabilities are disclosed, malware is discovered, attack campaigns are analyzed, and manufacturers, CERTs, and security agencies continuously publish indicators of compromise (IoCs), security advisories, and other technical information. For operators of critical infrastructure, however, collecting this information is not even the most challenging part. Security teams still need to determine whether a threat is relevant to their environment, which assets may be affected, and what the observed activity actually means in the context of an operational network. In the energy sector, that requires knowledge extending beyond enterprise security and into the protocols, equipment, and processes that keep power systems operating. A suspicious packet in an office network is one thing. Understanding whether communication between an engineering workstation and a protection device using IEC 61850 represents expected maintenance activi...

For nearly two decades, offensive security has centered around the same basic ritual: schedule an annual or quarterly penetration test, brace for the findings, remediate what you can, and then repeat the next cycle next year. It's familiar, predictable, and built into every compliance framework. It's also fundamentally mismatched to the way modern infrastructure works and the way attackers operate.  Today's environments change too quickly for point-in-time testing to provide real assurance. Cloud deployments shift daily; CI/CD pipelines push new code constantly, and new assets appear abruptly. A penetration test conducted in November tells you almost nothing about your exposure in January.  This is where Continuous Penetration Testing (CPT) comes in. CPT doesn't just improve offensive security outcomes but reshapes the equation entirely. When organizations adopt continuous validation, they gain clearer visibility, shorter remediation cycles, and tangible, measurable ROI. ...

Security teams today live in two different realities. On one side, platforms like ServiceNow create order: every vulnerability has a ticket, every incident has a workflow, and everything ties back to the CMDB. On the other side, attackers create chaos. They don't follow workflows. They look for the easiest way in, chaining together whatever exposures they can find until they reach something valuable. A vulnerability marked as "medium" in a ticketing system can still be the critical link in an attack path that leads straight to a company's crown jewels. In the ticketing system, the issue appears in isolation, yet attackers see how it connects to everything else. Without visibility into how exposures link together, teams risk wasting effort while the actual attack paths stay open. This is where ServiceNow's integration with XM Cyber comes in. By layering attack graph analysis onto VR and SIR , the platform lets teams see each issue through an attacker's eyes. Tickets and incidents ar...

Device and software vulnerabilities pose an increasing risk to modern security. However, patch management is an infamously difficult (and downright Sisyphean) task for IT and security teams, who are faced with an ever-growing list of CVEs to remediate. This task was difficult enough in the days of on-premise environments, but a modern distributed workforce has to contend with all the users, devices, and applications that may exist outside the purview of traditional security solutions, like MDM. Overall, with the ever-growing number of CVEs and the ever-growing sprawl of shadow IT, patch management has become both more urgent and more daunting than ever. IT and security teams need to adopt zero trust methods to ensure that only healthy and patched devices are able to access their critical systems. With the help of SaaS management and employee-remediation tactics, teams can do even more to improve efficacy and support for their company-wide patch management programs.  French philo...

Automated tools give you visibility. Adversarial testing gives you clarity. In Salesforce environments, you need both. The Problem with Checkbox Security in a Platform-Centric World Salesforce has become more than just a CRM—it's the backbone of how many organizations operate. It holds customer data, governs workflows, drives revenue, and connects to dozens of internal and third-party systems. But that complexity is exactly what makes it hard to secure. And too often, security teams rely solely on generic scans or scheduled audits that were never designed to handle the nuance of Salesforce's layered permissions, custom logic, and evolving integrations. The result? A lot of surface-level findings—and a lot of assumptions about what those findings actually mean. Automation Is Essential—But It's Only One Layer There's no question that modern scanning tools play a vital role in Salesforce security. The right platforms can surface deeply nested permissions, cross-object access paths,...

Reachability has quickly become one of the latest buzzwords in cybersecurity, but every vendor means something slightly different by the term. In part one of this series, I argued that reachability is really about only showing exploitable vulnerabilities. In part two , I compared runtime and static reachability to determine that if the goal of reachability analysis is to only fix exploitable vulnerabilities, only runtime reachability will get us there. The final question to address is, "Which type of runtime reachability is the right kind?" In 2025, almost every vendor uses the term reachability, alongside a nifty funnel showing your vulnerability count going down, but vendors almost always mean different things by the term. In this article, we'll explore the complexity of reachability types, and how while there's no silver bullet, function level reachability for vulnerabilities is the best overall answer to the problem. Flavors of Runtime Reachability All excalidraws are availab...