A Cybersecurity and Infrastructure Security Agency program that provides tools and capabilities to other agencies has to get speedier so it can push them toward being able to move more quickly themselves, an agency official said Tuesday.

“We have to get faster,” said Richard Grabowski, acting branch chief of service delivery and deputy program manager for the Continuous Diagnostics and Mitigation program at CISA. “The way that we collaborated today wasn’t fast enough for the threats of yesterday, and they certainly aren’t going to be fast enough for the threats of tomorrow.”

That means pushing responsible automation of tasks that also can do so at scale, he said, so that experts “can focus more [on] dealing with the novel threats and adoption and tuning of advanced technology, and not hitting alerts every other day.”

Velocity is one of the three core goals for the CDM program, along with unification and data-driven risk management, Grabowski said at the Elastic Federal Cyber Defense Breakfast, produced by FedScoop.

Unification means keeping data out of silos so “we are connecting those deployments in a meaningful way to really stimulate reusable, actionable lessons learned,” Grabowski said. And data-driven risk management means that in the event of a crisis-level event, agencies are able to “see what is happening with timely, accurate, and trustworthy data, so that we are the tool of first response when the things hit the fan.”

One of CDM’s offerings is Security Information and Event Management (SIEM) as a Service, a cloud-based platform for threat analytics, incident response and more. Grabowski said there’s a three-year roadmap for expanding and enhancing it, including by ramping up staff and conducting training.

Mike Duffy, the acting federal chief information security officer, said at the same event that three principles should guide what comes next for CDM. One is aggregating demand across agencies that share common problems: “When agencies need the same capabilities, we should use federal scale to improve security, interoperability and value.”

Second, he said, “is buying outcomes, not product” by making it clear what outcomes the federal government is seeking and then allowing commercial markets room to innovate. 

Duffy said the third was to “design acquisition for continuous improvement,” meaning making sure that acquisition models promote competition and opportunities for new capabilities to enter.

“Now is not the time to set capabilities and move on for the next 10 years,” he said. “Mow that agile mindset of how we can continue to deliver and deploy capabilities based on the threats we’re seeing to reduce risk at scale across the federal government — that is absolutely key.”

CDM has been evolving since the SolarWinds breach that compromised at least nine federal agencies, said Matt House, CISA’s acting associate director and program manager for CDM.

“Post-SolarWinds, one of the things that that the government took away was, we lack what I would say is a common operating picture with respect to the operational visibility we need to be able to assess and coordinate response government wide,” House said at the event.

The post What’s next for CISA’s CDM program that gives cybersecurity tools to federal agencies appeared first on CyberScoop.

AI is getting better at much of what security teams have long spent time on: analyzing information, identifying patterns, and providing technically sound recommendations quickly. As those capabilities become more routine, they are changing what security practitioners spend their time on.

Reaching a technically sound recommendation is also getting easier, which puts more weight on the judgment about what to do with it. A recommendation can make complete sense from a security perspective and still carry consequences for the systems, people and business around it that change what the right decision is.

Experienced practitioners bring context an AI system usually lacks: how systems are actually used, which parts of the business depend on them, what happened during previous incidents, and what an action is likely to set off. That context often changes what a team decides to do next.

This matters for security leaders as they hand AI a larger role in operations. They are the ones deciding where it can act with more freedom and where human judgment stays in the loop. Some of the hardest calls start with analysis that is technically sound, because the information available to the AI may not include enough context about that particular environment.

Security teams face this daily. For example, a critical vulnerability with a public exploit may need to be patched immediately. But if it affects a line controller or a medical device running under vendor certification, an unscheduled reboot could stop production or create a regulatory issue. The environment determines how and when the team should respond.

The same applies to suspicious infrastructure. An IP address tied to malicious activity may also belong to shared cloud infrastructure or a content delivery network that business services depend on, and blocking it would take those services down with it.

Context changes the decision

Experienced practitioners know things about their environments that never made it into an asset inventory, a runbook, or any dataset AI can reach. They know the unimportant server still supports a critical business process. They remember that isolating one network segment during a previous incident took down another service. They can also tell that activity which looks hostile is really an authorized red team, a security test, or scheduled vendor work.

In one case, for instance, a service account showed authentication activity far above its baseline, baseline was connecting from an unfamiliar host at 3 a.m. The recommendation was to disable it pending investigation. An experienced analyst checked the account’s activity and noticed the same spike, host and timing four times a year, during the quarterly close. The activity was statistically unusual and completely normal for that particular business process. Disabling the account would have stopped financial settlement mid-run and cost the team days of manual reconciliation.

This is one of the decisions CISOs now face as they expand AI’s role. How much autonomy to grant a system should not rest mainly on model confidence or threat severity, since neither tells you what happens once the recommended action is taken. Reversibility and blast radius are the better test, and they need to be assessed separately. Isolating a domain controller is reversible by reconnecting it and doing it at the wrong moment can cause an organization-wide outage.

Low-impact, reversible actions are better candidates for greater autonomy, with safeguards in place. More scrutiny makes sense when actions are difficult to reverse. They have a broad potential impact, cross legal or trust boundaries, affect systems beyond the evidence available, or reduce the organization’s ability to investigate what happened.

AI models and their capabilities will keep changing. Security leaders still need to understand the potential impact of the actions they allow them to take.

Look at what people actually do

AI can leave an analyst with dozens of recommendations to review in the time they once spent investigating a handful of cases. Each analyst now has more decisions to make. Organizations need to measure what happens to those decisions.

The KPI you choose determines the behavior you get. Make automation rate the focus, people have an incentive to approve more. Make mean time to resolution the focus and people close cases faster. Neither measures whether the decisions improved. A 90 percent automation rate tells a CISO very little on its own. What matters is what happened in the 10 percent of cases where someone stepped in.

Leaders should look at what happens when a recommendation reaches a person. Whether the analyst approves, edits, or rejects it can tell you more than the automation rate alone. The time spent on the review matters too, along with whether the analyst’s intervention changed the outcome.

AI recommendations can be harder to review because they may arrive already looking well supported. The explanation is fluent, uses the right terminology, and points to evidence that looks credible, even when it does not fully support the conclusion. The signals experienced practitioners relied on to spot weak analysis can become much harder to see.

Under-reliance deserves attention, too. An analyst who second-guesses correct recommendations without adding anything reduces the efficiency AI was meant to provide. Approval latency is a useful signal here. A long queue of recommendations approved almost instantly, especially when people are under pressure, should prompt leaders to check how much review is actually happening.

AI recommendations can be harder to review because they can look convincing. They may use the right language and point to real evidence. The reviewer still needs to check whether the evidence actually supports the recommendation.

For CISOs expanding AI in security operations, a human approval step in front of every automated action is not enough. Leaders need to know what happened during the review, not just that someone approved the recommendation.

Build autonomy policies around reversibility and blast radius. Track what people actually do with AI recommendations, and test whether oversight works by deliberately introducing known-wrong recommendations into controlled workflows.

False negatives need particular attention. A false positive generates something the team can investigate. A confident false negative generates nothing, and the absence of a finding can feel reassuring. An AI-generated all-clear should be treated as a claim requiring evidence, particularly when the consequences of missing something are significant.

As AI takes on more of the initial analysis, practitioners will face more decisions that require context and experience. Security leaders need to make sure that judgment remains part of how their teams work. Getting to a technically sound recommendation faster only helps if the action that follows makes sense for the environment.

The post Why judgment is emerging as cybersecurity’s defining skill appeared first on CyberScoop.

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.