Introduction

On one hand, artificial intelligence accelerates product development. This is the focus of the report “2026 State of Product Security for the AI Era”, which analyzes how Product Security and AppSec are dealing with the massive influx of AI into the development cycle.

On the other hand, the report “State of AI in Security Operations 2025” observes the impact of this same movement within SOCs and SecOps and DevSecOps teams, where the increased attack surface translates into more signals, more decisions, and more operational pressure.

This article stems from this contrast between software development (product) and operations (security) to discuss how to bridge these two worlds and why the Zero-CVE strategy emerges as a consistent path to align speed, standards, and security in the use of AI.

1. AI in software development: greater speed, less visibility

In the slice of software development, the study shows that AI is already widely present in the code and the workflow of teams.

The most sensitive data is not about adoption, but about risk and governance:

• Only 19% of organizations say they have complete visibility of where AI is used in the development cycle;

• 65% report that security risk has increased since the adoption of AI in development;

• More than 50% still do not have a centralized AI governance, making decisions distributed among teams.

What this means in practice

→ Code gets to production faster, but it is not always clear where, how, and to what extent AI participated in the construction of this code.

→ It becomes difficult to identify which parts of the product carry more risk and which security decisions depend directly on AI-generated or assisted components.

Where is the critical point

Without a centralized governance, each team creates its own rules for AI use, with different levels of care and criteria.

The result is a mismatch: the speed and volume of code grow faster than the capacity to understand where AI operates and what risks it adds to the product.

2. AI in SecOps: high volume, difficult choices

On the side of security operations, the data shows the daily pressure on SOC teams:

• Large companies deal with about 3,000 security alerts per day;

• On average, 40% of alerts do not get investigated;

• 57% of organizations suppress detection rules to cope with volume, reducing the number of signals entering the SOC funnel.

What this means in practice

→ SOC can't look at everything; part of the risk is consciously accepted, simply because there is not enough human capacity to investigate all events.

→ Suppressing rules works as a “survival filter”: the team reduces noise, but also gives up visibility precisely in critical surfaces, like cloud and identity.

Where is the critical point

This dynamic forces the SOC to operate in reactive mode, choosing what will (and what will not) be seen, while the environment keeps accumulating events at an ever-increasing pace.

AI begins to enter here as a relief force, helping in triage and prioritization, but without a connected vision with development and product, it addresses the symptom of volume without necessarily tackling the source of risk.

Read more: Software chain glossary (Kubernetes, containers, SBOM, CVEs): Quor Edition

3. A strategic path: connect the origin and effect of the risk

Both studies point to the same roadblock: too much noise, little context.

In development, there is a lack of clarity about how, where, and under what criteria AI enters the software development cycle and what risk comes along. In SOC, there is a lack of context to decide what really matters among thousands of daily alerts.

A strategic path is to change the question. Instead of only asking “how many vulnerabilities do we have” or “how many alerts do we receive”, the question becomes: what criteria define what can be promoted to production?

This requires linking the origin and effect of the risk: from the code, dependencies, and the software supply chain to alerts, incidents, and attempts to exploit.

The goal is clear: reduce the chance that known vulnerabilities are introduced or advance in the pipeline to deployment, using detection as a safety net, not as the first line of defense.

Read more: Do you know what a CVE is? And what it can do to your product strategy?

What this changes for the teams

For development and Product Security teams, this starts with a mindset shift: no component touching critical infrastructure should reach production without clear traceability. It is necessary to know the origin, the function, and what technical criteria support the decision to put it into operation. This applies to container images, central services, sensitive integrations, AI-supported components, and elements of the software supply chain. In other words, opaque technical decisions become unacceptable.

For SecOps, SOC and DevSecOps, the role evolves from reactive to a more integrated model amid the sprawl of tools. The priority becomes connecting alerts and events to their origin and impact context: where it came from (code, dependencies, pipeline, software supply chain), what component or asset it is on, and what the potential path to production is. This way, the operation is no longer guided by volume and becomes guided by risk, continuously reducing the chance that known vulnerabilities remain in critical components in production.

For the organization as a whole, the point is to align language and criteria and avoid each area operating in isolation, without the context of the whole. Engineering, security, DevSecOps, and product need to answer the same questions: what do we accept in production, in what type of component, and with what remediation timeline. Instead of treating regulations, security by design and software supply chain security as separate demands, all of this becomes part of the same decision-making framework and guides trade-offs of speed, risk, and prioritization consistently.

Read more: Not All Heritage Is Good: The Risk of Container Images

Conclusion

Both studies point to the same misalignment: the speed of development has increased, but visibility, context, and criteria have not kept pace. In SOC, this appears as volume and difficult choices; in development, as inconsistent traceability and opaque technical decisions.

A Zero-CVE-oriented approach, understood here as a goal and operating philosophy, enters as a convergence point between these worlds. It means establishing clear and shared criteria among development, Product Security, SecOps, and operations regarding which known vulnerabilities, insecure configurations, and risk signals are blockers before promoting software components and artifacts to production.

With this, alerts and incidents cease to be the first line of defense and start operating as a safety net. The result is a more consistent model for controlling risk and exposure, without relying solely on reaction and without sacrificing speed.

References:

• Cycode. 2026 State of Product Security for the AI Era. Available at: cycode.com/state-of-product-security-ai-era-2026/

• Prophet Security. State of AI in Security Operations 2025. Available at: resources.prophetsecurity.ai/state-of-ai-in-security-operations