The National Institute for Standards and Technology is looking for input on how to overhaul its vulnerability reporting process to better meet the challenges of an “evolving cybersecurity landscape increasingly shaped by artificial intelligence and machine-consumable security data.”

In a request for information set to publish Wednesday in the Federal Register, NIST said its National Vulnerability Database, one of the primary ways the federal government coordinates with security researchers to identify and fix software vulnerabilities, must be updated for the AI age.

NIST is concerned that as large language models become more capable of finding and exploiting vulnerabilities at scale, the NVD’s process must be updated.

“The inadequacies of traditional vulnerability management approaches, which center on periodic scanning, static prioritization, and manual remediation, are increasingly apparent,” the RFI states.

NIST believes AI hacking tools are contributing to recent trends in vulnerability reporting. The NVD has seen increased volume and complexity of disclosed vulnerabilities, inconsistent data quality, increased reliance on automation and machine-readable security data, and “demand for near real-time vulnerability enrichment” from defenders facing faster threats.But NIST believes these challenges also present an “opportunity to transform the vulnerability management ecosystem” through proactive reforms and NVD innovation.

That’s where the public comes in. NIST is posing a series of questions that must be answered before a larger strategy can be developed. Many of their questions focus on better integrating automation – AI or otherwise – into the process.

The agency asked for insight on how defenders could better leverage automation in the vulnerability reporting process; which capabilities, products and processes would help more quickly disseminate information to stakeholders, how to build transparency and auditability into AI-driven decisionmaking, and what role AI should play in automated vulnerability remediation.

“NIST intends to support a future-ready vulnerability management ecosystem that is continuous, contextual, and automated, while enabling cybersecurity practices to respond appropriately to real-world threats and business priorities,” the RFI states.

The NIST effort to revamp its vulnerability database comes a month after the Trump administration rolled out a new federal clearinghouse, overseen by the Department of Treasury, for sharing AI threat information between government and the private sector called “Gold Eagle.”

It’s not clear how Treasury’s process will interact with NIST’s database. The White House also partnered with Carnegie Mellon’s Software Engineering Institute to create the Vulnerability Information and Coordination Environment, (VINCE) which will collect and distribute reports on AI-discovered vulnerabilities.

The post NIST wants to overhaul its vulnerability database for the AI age appeared first on CyberScoop.

A new scan of internet-connected industrial equipment found over 4,000 Rockwell Automation and Allen-Bradley controllers exposed online, including 22 in cities impacted by cyberattacks on U.S. water systems.

The findings, published Wednesday by Forescout’s Vedere Labs, show that direct internet access to equipment used in water and wastewater operations remains common despite years of warnings from manufacturers and federal agencies.

The exposed devices use EtherNet/IP, an industrial protocol that allows for communication between control equipment, engineering workstations and other systems. When the port is open to the public internet, outside users may be able to identify devices and, depending on their setup, change settings or write new configurations.

The scan, run through the Shodan search engine Monday, found that 2,844 of the exposed controllers (65%) were in the United States.

The FBI and Environmental Protection Agency issued a joint advisory last week confirming attacks at water and wastewater utilities in at least 12 states since July 27. Officials have since named Michigan, South Dakota and Georgia among the affected states. Nine systems were hit in Michigan, and one wastewater lift station was hit in South Dakota.

Several reports have linked the attacks to Iranian actors, but Sai Molige, senior manager of threat hunting at Forescout, says the company has not attributed this activity to any actor or group.  

“The evidence supports opportunistic, at-scale exploitation of a known class of vulnerabilities affecting internet-exposed devices,” Molige told CyberScoop. “The scale and speed of the activity are more consistent with mass scanning and enumeration than with zero-day exploitation, a months-long intrusion campaign, or custom malware.”

The advisory said attackers targeted programmable logic controllers (PLCs) made by Rockwell Automation under its Allen-Bradley brand, specifically the MicroLogix 1100 and 1400 models. In at least one case, attackers reached controllers remotely and changed their IP addresses and passwords, cutting off the utility’s own view and control of the equipment. The advisory said the attacks caused pressure loss and flooding.

Forescout’s research states that the most common exposed device family was the MicroLogix 1400, which made up half of the devices found. Other versions, such as AllenBradley’s CompactLogix 1769 controllers, made up 22%. MicroLogix 1100 and ControlLogix 5590 devices each accounted for about 8%.

Forescout cross-referenced those machines against the recently targeted cities and municipalities and found 22 devices still exposed to the internet. However, the company did not say those systems had been attacked or that they belonged to the affected utilities.

The research also found that 19 of the 22 hosts in affected cities appeared, based on firmware versions, to be open to CVE-2017-16740, a remote code execution flaw disclosed in 2017 that impacts MicroLogix 1400 devices. An attacker would need Modbus TCP enabled to use that flaw, and the researchers could not confirm whether the affected systems had it enabled.

Rockwell Automation and other industrial equipment makers have warned customers not to place controllers directly on the public internet as far back as 2018.

Beyond the controllers, the researchers also looked at the digital records tied to these utilities. They found expired certificates, remote-access web addresses left unrenewed for months or years, and servers that appear abandoned — in one case, a server that has shown nothing but a default Microsoft webpage since April 2019. 

“These stale services can increase the attack surface; however, we have not yet confirmed how the observed attacks occurred,” Molige told CyberScoop.

The post Despite federal warnings, thousands of U.S. industrial controllers used in water systems remain exposed online appeared first on CyberScoop.

An updated advisory from federal agencies provides information on the techniques used to hack programmable logic controllers.

The post US Warns of Iranian Hackers Targeting Siemens, Schneider, and Rockwell ICS Devices appeared first on SecurityWeek.

AI-generated code is part of everyday software development. Developers use it to prototype, refactor, troubleshoot, and move from idea to implementation with less friction than ever before. The productivity gains are undeniable, which means that security leaders now face a hard question: whether their organizations can govern the risk that AI creates at that same speed.

That challenge is rooted in scale. AI changes how quickly software can be created, while many application security programs still depend on controls designed for a slower development model. When code generation accelerates beyond the capacity to review, test, and remediate issues, security debt accumulates faster.

That is the hidden cost of AI-assisted development. Risk now enters the enterprise at machine speed, while many organizations still manage it with human-scale processes. CISOs should govern AI-generated code as a high-risk input: tested automatically, checked for unsafe dependencies, remediated quickly, and blocked from production if it fails policy.

The metric that matters is risk velocity

Application security has long been measured through discovery. Teams count vulnerabilities, categorize severity, report trends, and show whether the numbers are improving. Those questions still matter, but AI adds a more urgent metric: risk velocity. Security leaders need to know how quickly the organization creates new software risks and how quickly it can reduce or eliminate them.

AI changes the economics of security debt. A development team that produces significantly more code without a matching increase in security capacity will create more issues than it can reasonably review or fix. Even when AI-generated code is comparable to human-written code on a per-line basis, the total risk can rise because the volume of change is higher. The backlog grows, vulnerabilities persist, and security debt eventually constrains the business.

AI expands familiar failure modes

The failure modes are familiar. AI coding tools can reproduce insecure patterns found in training data, including weak input validation, unsafe authentication flows, insecure direct object references, hard-coded secrets, and vulnerable dependency choices. They can also miss the context that determines whether code is secure in a specific environment: authorization models, tenant boundaries, data sensitivity, production configurations, and how services interact in a real application.

There is also a human factor. Under the pressure of deadlines, developers may accept code that works without fully understanding how it does so. The result is misplaced confidence. Code compiles, tests pass, features ship, and hidden risk enters the system. Over time, the organization may lose sight of the security concerns that naturally arose during manual development.

The supply-chain risk is bigger than the code itself

The software supply chain adds another layer of risk. Modern applications are assembled from open-source components, frameworks, plugins, containers, APIs, and cloud services. AI coding tools can recommend outdated packages, vulnerable libraries, or nonexistent dependencies. Veracode’s 2025 GenAI Code Security report found that AI coding tools produce insecure code nearly half (45%) of the time. It may sound like an amusing hallucination until attackers register malicious packages with similar names and wait for developers or automated tools to pull them in. At that point, a coding shortcut becomes a supply chain exposure.

AI is already part of the development lifecycle, and its use will continue to expand. Security teams need a control model built for that reality.

“Shift Left” needs an enforcement layer

The industry has spent more than a decade moving security earlier in the development lifecycle, improving visibility and helping teams catch issues sooner. Many organizations, however, moved findings closer to developers without also moving enough ownership, automation, and remediation capacity with them. Developers received more alerts, while security teams gained more visibility into risks they still struggled to reduce.

AI makes that operating gap more urgent. As software output increases, security cannot remain a checkpoint near the end of the process. It must become a continuous control system built into the way software is created, tested, approved, and deployed.

Secure-by-design has to become infrastructure

Secure-by-design in the AI era requires an engineering environment where unsafe choices are harder to make and easier to catch. Approved frameworks, secure defaults, reference architectures, dependency controls, automated testing, and policy enforcement should be embedded directly into developer workflows and CI/CD pipelines.

Remediation also must move closer to the point of creation. When a coding assistant introduces a vulnerable pattern, the ideal response is an inline fix that is proposed, validated, and governed as part of the normal development process. AI can help defenders here when it is connected to reliable security signals, policy context, and evidence from real testing. Counterintuitively, developers using AI to write code often don’t trust AI to automatically remediate code without human review. This takes one of the best ways to keep up with machine-speed created vulnerabilities and slows it down to human speed. An acceptable balance between risk and speed must be found.

Approval is not governance

CISOs should focus on governance, not just approving AI coding tools. Governance means tracking where AI-generated code enters your environment, documenting the policies and tests applied, recording what issues were found and fixed, and keeping proof of these decisions. This documentation becomes critical as AI-assisted development becomes standard. If vulnerable code reaches production, you’ll need to show that adequate controls were in place and risks were managed according to policy.

What leaders should do now

CISOs and engineering leaders should treat AI-generated code as untrusted until proven otherwise. They must require automated testing before release, enforce dependency controls, prioritize remediation based on exploitability and business impact, and measure success by the rate at which critical risk is reduced.

Additionally, boards and organizational policymakers should ask whether organizations can demonstrate that AI-assisted software is governed before it is deployed. The key evidence should include the policies applied, the tests performed, the vulnerabilities remediated, the risks accepted, and the approvals recorded. Today, many organizations can confidently track what their AI tools produce, but they cannot demonstrate how that output was secured, reviewed, and governed before reaching production. The industry is still working to close this gap.

AI is changing how quickly software risk moves through the enterprise. The organizations that succeed will make security move just as quickly by embedding governance, remediation, and proof directly into the software delivery pipeline.

The post AI-generated code has made security debt a governance problem appeared first on CyberScoop.

ISSUE 23.27.1 • 2026-07-09 By Susan Bradley As a result of researchers’ using AI to do more in-depth code reviews of operating systems and applications, expect to see more security updates and more vulnerability counts. As Apple indicated to Reuters, the recent release of Apple security updates was done in an accelerated fashion because “… […]

Post-quantum cryptography didn’t sneak up on the industry. 

For years, security teams, standards bodies, hyperscalers, and governments have been pointing at the same horizon: a cryptographically relevant quantum computer will, eventually, dismantle the public-key algorithms underpinning today’s enterprise security. The latest executive order doesn’t introduce a new threat. It codifies what the field has long understood, and attaches deadlines to it.

For CISOs, the framing shift matters. PQC is fundamentally a readiness problem, not a cryptography problem. Watching Google accelerate its quantum roadmap, or seeing federal agencies restructure their security architecture around PQC, makes the stakes impossible to ignore.” Boards are already asking: “How are we thinking about post-quantum transition today?” For most organizations, the gap between that question and a credible answer is wider than it should be.

The EO is unambiguous on scope. PQC has moved from a research effort to real policy, with deadlines, accountability structures, and direct consequences for federal agencies, contractors, critical infrastructure operators, and the broader private sector that supports them.

Federal high-value systems must transition key establishment to PQC by Dec. 31, 2030. Digital signatures will follow by Dec. 31, 2031.

Those dates may appear distant, but for anyone who has navigated an enterprise-scale security transformation, with the procurement cycles, architecture reviews, and organizational change management that entails, 2030 sits squarely inside current planning horizons. The window for orderly execution is already narrowing.

What makes that window even tighter is that the most immediate risk has nothing to do with deadlines. “Harvest Now, Decrypt Later” attacks are already operational. Nation-state adversaries are collecting encrypted data today and storing it until quantum capabilities are sufficient to decrypt it: intellectual property, health records, financial transactions, source code, government communications, and more. The encryption protecting that data right now is, functionally, a time-delayed vulnerability. Long-lived sensitive data may already be compromised in ways that won’t become visible for years.

The first step for CISOs is shifting from awareness to ownership.

PQC readiness cannot be delegated to individual application teams or treated as a future compliance checkbox. That approach will not survive given the EO’s accountability requirements. Every organization needs a point person: a program lead, a cross-functional steering committee, or a dedicated cryptographic risk office. Whatever the structure, it needs authority and a seat at the leadership table.

That ownership must span security, IT, infrastructure, engineering, product, legal, compliance, procurement, and business stakeholders. Cryptography is embedded across the entire enterprise: certificates, keys, protocols, APIs, hardware, cloud services, code-signing systems, identity infrastructure, third-party platforms. No single team has the bandwidth to address this alone. A cross-functional working group or Center of Excellence should be an organizational prerequisite as we move into the future.

Visibility is going to be critical, and this is where most organizations will find the largest gaps.

CISOs need a clear picture of where cryptography exists across their environment: which algorithms are in use, which systems depend on vulnerable cryptography, what data requires long-term confidentiality, and which business processes would be disrupted by migration. Without that inventory, risk assessment is guesswork, remediation is impossible, and demonstrating progress to regulators or boards becomes an exercise in speculation.

The principle is straightforward: you cannot protect what you cannot see.

Furthermore, a cryptographic inventory cannot be a static spreadsheet updated annually and then filed away. It needs to function as a living view of the organization’s trust infrastructure, covering certificates, keys, algorithms, libraries, protocols, signing systems, certificate authorities, HSMs, workloads, devices, and third-party dependencies. 

Once that visibility exists, prioritization follows from business impact. Systems protecting long-lived sensitive data, critical infrastructure, customer trust, software integrity, and regulated environments move first, with everything else sequenced accordingly.

Beyond visibility, CISOs need a roadmap aligned to the order’s milestones rather than aspirational planning documents that never translate into funded programs.

The 2030 key establishment deadline requires understanding every point where encryption and key exchange mechanisms operate across critical systems. The 2031 digital signatures deadline extends that challenge to software integrity, code signing, document signing, authentication, identity infrastructure, and long-term verification. This is a multi-year transformation program, and it warrants the same organizational rigor as any other enterprise-wide initiative of comparable scope.

That means three categories of dedicated resources. First, funding: PQC readiness cannot be absorbed into existing security budgets without displacing other priorities. It requires multi-year investment in discovery tooling, testing, migration execution, automation, and governance. Second, talent: organizations need cryptography expertise, enterprise architecture capability, PKI experience, risk management, compliance support, and program leadership, a combination already in short supply across the industry. Third, technology: discovery tools, certificate and key lifecycle automation, policy enforcement, reporting infrastructure, and the architectural capability for crypto-agility.

Crypto-agility is the long-term objective that makes this transition worth doing properly.

Organizations that treat PQC as a one-time algorithm swap will find themselves back in the same position when standards shift again. The quantum transition is occurring in parallel with the rise of AI, machine identities, autonomous systems, and increasingly complex digital ecosystems, all of which depend on cryptographic trust. Organizations that do not actively govern that trust infrastructure will struggle with AI security, software supply chain integrity, identity governance, and the compliance mandates that follow.

The order functions as a forcing mechanism, converting PQC from a future technical concern into a present-day leadership accountability. Three questions now define where an organization stands:

• Do we have a clear picture of where our cryptographic risk lives?
• Do we have a funded, sequenced migration plan that meets the order’s deadlines?
• Can we demonstrate that our trust infrastructure is agile enough to adapt as standards and threats continue to evolve?

The debate over precisely when quantum computing will be a reality is a distraction. Building the visibility, governance, funding, and automation required to move with confidence is where we need to be spending our collective time and effort.

CISOs have moved past the question of whether to act. The operative question is how far behind the organization already is, and how quickly it can transform cryptography from an invisible dependency into a managed, measurable, and adaptive system of trust. The organizations that begin that work now will be the ones with options when the deadlines arrive.

The post What the post-quantum executive order really demands of CISOs appeared first on CyberScoop.

Deceptive-Auditing is a tool that deploys Active Directory honeypots and automatically enables auditing for those honeypots.

The post Deceptive-Auditing: An Active Directory Honeypots Tool appeared first on Black Hills Information Security, Inc..

This webcast was originally published on November 8, 2024. In this video, Hayden Covington discusses the detection engineering process and how to apply the scientific method to improve the quality […]

The post The Detection Engineering Process appeared first on Black Hills Information Security, Inc..

Hannah Cartier // Social engineering, especially phishing, is becoming increasingly prevalent in red team engagements as well as real-world attacks. As security awareness improves and systems become more locked down, […]

The post Phishing Made Easy(ish) appeared first on Black Hills Information Security, Inc..

Kent Ickler // A robot wearing boots… with straps…. Have you been tasked with automation in the Command and Control (C2) world? If so your goal is to shorten the […]

The post Empire Bootstrapping v2 – How to Pre-Automate All the Things! appeared first on Black Hills Information Security, Inc..