AI, SecOps, and Product Security: connecting the origin and effect of risk with a Zero-CVE approach

Introduction

On one side, 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 entry of AI into the development lifecycle.

On the other side, 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 starts from this contrast between software development (product) and operations (security) to discuss how to bring these two worlds closer 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: higher speed, lower visibility

In the software development segment, the study shows that AI is already widely present in the code and 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 into where AI is used in the development cycle;

• 65% report that security risk has increased since adopting AI in development;

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

What this means, in practice

→ Code reaches production faster, but it is not always clear where, how, and at what depth AI participated in the construction of that code.

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

Where the critical point lies

Without centralized governance, each team creates their own rules for using AI, with different levels of care and criteria.

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

2. AI in SecOps: high volume, difficult choices

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

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

• On average, 40% of alerts end up not being investigated;

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

What this means, in practice

→ The SOC cannot look at everything; part of the risk is consciously accepted, simply because there is no human capacity to investigate all events.

→ Rule suppression acts as a "survival filter": the team relieves the noise, but also gives up visibility precisely on critical surfaces, such as cloud and identity.

Where the critical point lies

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

AI is beginning to enter here as a relief force, helping with triage and prioritization, but without a connected view with development and product, it solves the volume symptom without necessarily attacking the source of the risk.

Read more: Glossary of the software chain (Kubernetes, containers, SBOM, CVEs): Quor Edition

3. A strategic path: connecting the source and effect of risk

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

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

A strategic approach is to change the question. Instead of looking only at "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 source and effect of the risk: from code, dependencies, and the software supply chain to alerts, incidents, and exploitation attempts.

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

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

What this changes for teams

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

For SecOps, SOC, and DevSecOps, the role evolves from reactive to a more integrated model amidst the tools sprawl. The priority becomes connecting alerts and events to their source and impact context: where it came from (code, dependencies, pipeline, software supply chain), in what component or asset it resides, and what the potential path to production is. Consequently, operation stops being volume-driven and becomes risk-driven, continuously reducing the chance of known vulnerabilities remaining in critical components in production.

For the organization as a whole, the point is to align language and criteria and prevent each area from 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 SLA. Instead of treating regulations, security by design, and software supply chain security as separate demands, all of this becomes part of the same decision framework and guides trade-offs of speed, risk, and prioritization consistently.

Read more: Not All Inheritances Are Good: The Risk of Container Images

Conclusion

Both studies point to the same misalignment: development speed has increased, but visibility, context, and criteria haven't caught up yet. In the SOC, this shows up 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 philosophy of operation, serves as a point of convergence 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 stop being the first line of defense and start operating as a safety net. The result is a more consistent model to control 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