Product security: risks, focus areas, and how AI can help

What is product security?

Product security is the practice of protecting a product’s hardware, software, and systems across its entire lifecycle from design to end-of-life. It protects everything that ships to customers, including first-party application code, open-source dependencies, build artifacts, and the cloud infrastructure and runtime environments where the product operates.

Effective product security combines secure development practices, vulnerability detection, software supply chain security, runtime analysis, and cloud security context. The goal is not to find as many vulnerabilities as possible, but to work out which weaknesses are exploitable in the delivered product and fix them without slowing development more than necessary.

What does product security cover? Key focus areas:

• First-party application code: Identifies weaknesses in internally developed software through secure coding, code review, threat modeling, and security testing.
• Open-source and third-party dependencies: Tracks components, detects known vulnerabilities, and assesses whether vulnerable functionality is reachable.
• Software builds and artifacts: Validates shipped components and protects build pipelines, signing credentials, and artifact integrity.
• Cloud infrastructure and runtime environments: Addresses insecure cloud configurations, excessive permissions, exposed services, and runtime risks.
• Container images: Scans image layers, removes unnecessary packages and credentials, and promotes trusted base images and minimal privileges.
• APIs and application interfaces: Protects exposed functionality through authentication, authorization, input validation, rate limiting, and endpoint inventories.
• Product configuration and deployment: Establishes secure defaults, validates deployment settings, and detects configuration drift.

This is part of a series of articles about application security.

Why is product security important?

Product security helps organizations protect customer-facing products by managing risks across application code, third-party components, APIs, cloud services, and infrastructure. It enables teams to prioritize actionable vulnerabilities, reduce exposure to attacks, and safeguard customer data without unnecessarily slowing development.

• Reduce security risk in customer-facing products: Connect findings across source code, build artifacts, and deployed workloads to identify vulnerable dependencies, exposed interfaces, excessive permissions, and insecure configurations.
• Address exploitable vulnerabilities before production: Use reachability analysis and environment-specific context to identify actionable issues early, helping developers fix meaningful risks without delaying releases over irrelevant findings.
• Protect customer data and business-critical systems: Assess how vulnerabilities could affect sensitive information, user accounts, and connected systems. Prioritize remediation to support customer trust, service availability, and compliance.

Product security vs. application security

Application security (AppSec) focuses on identifying and preventing security weaknesses in software applications. It includes secure coding, code review, static and dynamic analysis, dependency scanning, penetration testing, and other practices designed to protect application functionality and data.

Product security has a broader scope that covers the complete product delivered to customers, including the application, its dependencies, build artifacts, deployment infrastructure, cloud services, configurations, and runtime environment. It also examines how security risks change as the product moves from development into production.

Aspect	Application security	Product security
Primary focus	Securing software applications	Securing the complete delivered product
Scope	Application code, APIs, dependencies, and application behavior	Code, dependencies, builds, artifacts, infrastructure, and runtime environments
Security analysis	Identifying vulnerabilities in applications and their components	Connecting security findings with how the product is built, deployed, and operated
Typical activities	SAST, DAST, code review, dependency scanning, and penetration testing	AppSec activities plus build security, deployment analysis, cloud configuration assessment, and runtime risk evaluation
Risk assessment	Application vulnerabilities and potential exploitation	Exploitability in the deployed environment and potential product or business impact

The two disciplines overlap significantly, and modern AppSec programs may also incorporate infrastructure and runtime context. The main distinction is that product security explicitly takes an end-to-end view of the delivered product rather than evaluating application vulnerabilities in isolation.

Common product security risks

Product security risks arise across application code, dependencies, infrastructure, and software delivery processes. Addressing them requires identifying weaknesses, validating exploitability, and prioritizing remediation based on application context and potential impact.

• Vulnerabilities in first-party code: Internally developed code may contain injection flaws, insecure deserialization, path traversal, memory safety errors, or broken access controls. Secure coding, code review, and security testing help detect and prevent these weaknesses.
• Vulnerabilities in AI-generated code: AI coding assistants can reproduce insecure patterns or overlook application-specific security requirements. Context-aware security analysis and developer review help identify weaknesses before generated code is merged or deployed.
• Vulnerable open-source dependencies: Direct and transitive dependencies may contain known vulnerabilities, including packages suggested by AI assistants. Software composition analysis identifies affected components, and reachability and exploitability analysis help establish their actual risk.
• Business logic vulnerabilities: Applications may allow technically valid actions that violate business rules, such as bypassing payments or repeatedly applying discounts. Threat modeling, abuse-case testing, and context-aware analysis help uncover these application-specific flaws.
• Container and base image vulnerabilities: Container images can include outdated operating system packages, runtimes, and libraries. Image scanning, timely rebuilds, and minimal, trusted base images help reduce exposure.
• Misconfigured cloud resources: Public storage, overly permissive identities, and unrestricted network access can expose products and data. Infrastructure-as-code scanning, configuration monitoring, and least-privilege controls help prevent and detect these errors.
• Exposed services and attack paths: Unnecessary public endpoints and forgotten environments expand the attack surface. Exploitability analysis assesses whether weaknesses can be exploited, while attack path analysis evaluates accessibility, lateral movement, and potential consequences.
• Software supply chain attacks: Attackers may compromise repositories, developer accounts, dependencies, or build and release systems. Strong access controls, protected pipelines, dependency verification, artifact signing, and provenance records help safeguard software delivery.

What does product security cover?

First-party application code

First-party code is software written and maintained by the organization developing the product. Security issues can include injection flaws, broken authentication, insecure authorization, unsafe input handling, exposed secrets, and business logic errors.

Product security applies secure coding standards, code review, static analysis, dynamic testing, and penetration testing to identify these weaknesses. Threat modeling can also identify risky design decisions before developers implement them.

Open-source and third-party dependencies

Modern products depend heavily on open-source libraries, frameworks, software development kits, and commercial components. Vulnerabilities in these dependencies can affect a product even when its own code is secure.

Product security teams track dependencies and their versions, scan them for known vulnerabilities, and assess whether vulnerable functionality is actually reachable. Software bills of materials (SBOMs) can improve visibility into components and help teams respond quickly when new vulnerabilities are disclosed.

Software builds and artifacts

The software stored in a source repository is not necessarily identical to what reaches production. During the build process, dependencies may be excluded, replaced, updated, or bundled differently. As a result, a vulnerable package identified in source code may not appear in the final artifact, while build-time dependencies or generated components may introduce additional risks.

Product security examines the actual packages, binaries, and other artifacts produced by the build process. Comparing repository dependencies with built components helps teams validate whether reported vulnerabilities are present in the software that ships, reducing false positives and improving remediation accuracy.

Build security also includes protecting CI/CD pipelines, managing access to build systems, securing signing credentials, and verifying artifact integrity and provenance. These controls help prevent attackers from inserting malicious components or modifying software during the build and release process.

Cloud infrastructure and runtime environments

A secure application can still be exposed by insecure cloud infrastructure. Common risks include public storage, excessive identity permissions, exposed management interfaces, weak network controls, and insecure infrastructure-as-code templates.

Product security covers the environment where the product runs as well as the software itself. This can include cloud configuration scanning, identity and access management, network segmentation, secrets management, runtime monitoring, and controls that restrict workloads to the permissions they actually need.

Related content: Read our article about cloud application security

Container images

Container images package application code together with operating system packages, libraries, and runtime dependencies. Vulnerabilities can exist in any of these layers, including components that developers did not directly add.

Product security includes scanning images for known vulnerabilities, removing unnecessary packages, avoiding embedded credentials, and using trusted base images. Images should also run with minimal privileges and be rebuilt regularly so security updates are included.

APIs and application interfaces

APIs expose product functionality and data to browsers, mobile applications, integrations, and other services. Weak authentication, missing authorization checks, excessive data exposure, and insufficient input validation can allow attackers to misuse these interfaces.

Product security addresses these risks through strong authentication, object- and function-level authorization, schema and input validation, rate limiting, and secure error handling. Teams should also maintain an inventory of active API endpoints so obsolete or undocumented interfaces do not remain exposed.

Product configuration and deployment

Security depends partly on how a product is configured and deployed. Unsafe defaults, enabled debugging features, overly broad permissions, exposed administrative functions, or incorrect environment settings can introduce vulnerabilities even when the underlying code is secure.

Product security establishes secure defaults and validates configurations before and after deployment. Automated policy checks can detect configuration drift, while hardened deployment templates help teams apply consistent controls across development, staging, and production environments.

How AI is transforming product security

Earlier generations of security tools made it practical to scan every code change and dependency for known vulnerability patterns, and that coverage is still the foundation of most product security programs.

AI is changing product security by enabling analysis that goes beyond those known patterns. Instead of treating scanner results as isolated findings, AI-powered security tools can examine application behavior, investigate exploitation prerequisites, and connect vulnerabilities with the environments in which software operates.

• From rule-based scanning to AI-powered code understanding: Traditional security scanners detect known vulnerability patterns using predefined rules and signatures, but can miss business logic flaws, complex data flows, and authorization weaknesses. AI-native tools analyze relationships between functions, trace data flows, and reason about intended application behavior to identify vulnerabilities beyond predefined patterns. This approach also helps detect weaknesses in AI-generated code and reduces the effort required to support additional programming languages.
• From reachability analysis to environment-specific exploitability validation: Traditional tools use call graphs to determine whether vulnerable code can be reached and prioritize findings using severity, exposure, and threat intelligence. AI-native tools go further by tracing attack paths and evaluating exploitation prerequisites, including runtime configurations, permissions, attacker-controlled inputs, and security controls. This helps distinguish vulnerabilities that are merely reachable from those that can actually be exploited in a specific environment.
• From isolated code findings to unified code-to-cloud security context: Traditional security tools analyze source code, dependencies, containers, and cloud infrastructure separately, making it difficult to assess the full impact of vulnerabilities. AI-powered tools correlate findings across these layers, connecting vulnerable code to deployed workloads, runtime configurations, internet exposure, and accessible cloud resources. This provides the context needed to assess exploitation risks and potential consequences across the complete product.
• From manual vulnerability triage to AI-assisted investigation and remediation: Traditional vulnerability management requires security engineers to investigate findings by hand, assess exploitability, identify code owners, and recommend fixes, and much of that time goes to scanner false positives. AI-assisted tools automate parts of this process by gathering evidence, validating findings, evaluating exploitability, and generating remediation guidance. They can route actionable findings to responsible developers with relevant code locations and recommended fixes, reducing manual effort and helping security teams prioritize high-impact risks.

The role of context in product security

Understand where vulnerable code is deployed

A vulnerability has different implications depending on whether the affected code exists only in a development repository, is included in a production artifact, or runs in an externally accessible service. A vulnerability identified in source code may not even be present in the software that ultimately reaches customers.

Security teams need to trace vulnerable components from repositories through build artifacts and container images into deployed workloads. This helps identify which products and environments contain the affected code, whether customers are exposed, and which systems require further investigation.

Deployment information provides essential context, but it does not independently establish exploitability. Even a vulnerability running in production may be impossible to exploit under the current configuration.

Determine whether a vulnerability is reachable

Reachability analysis determines whether an execution path exists to vulnerable code. For example, an application may include a library with a known vulnerability but never import, invoke, or otherwise execute the affected functionality. In that situation, the vulnerability may be present in the dependency without being reachable through the application’s analyzed execution paths.

Analyzing function calls, data flows, and component relationships helps security teams identify whether vulnerable functionality can be reached. This provides more useful information than dependency presence alone and can eliminate findings involving code that is not used.

However, reachability is not the same as exploitability. A vulnerable function may be reachable but impossible to exploit because the required input, configuration, privileges, or other prerequisites are absent. Reachability analysis is one part of checking exploitability, so it narrows the investigation rather than providing a definitive risk assessment.

Determine whether a vulnerability is actually exploitable

Exploitability describes whether a vulnerability can actually be exploited under the conditions of a particular environment. A vulnerability may be reachable through an application’s execution path but still not be exploitable because a necessary prerequisite is missing. Exploitation may depend on attacker-controlled inputs, specific permissions, configuration settings, runtime behavior, or the absence of effective security controls.

For example, an application may call a vulnerable library function, making the affected code reachable. However, if the vulnerability requires a particular configuration option that is disabled in production, the weakness may not be exploitable under that deployment’s current conditions.

Environment-specific exploitability analysis combines code behavior with dependency, build, runtime, and cloud context to assess whether the required conditions are satisfied. This helps security teams distinguish vulnerabilities that can realistically be exploited from findings that are reachable but not exploitable in the assessed environment. Where evidence is insufficient, findings should remain under investigation rather than being classified as safe.

Understand exploitability vs. exploit availability and known exploitation

Exploitability, exploit availability, and known exploitation describe different aspects of vulnerability risk. A vulnerability can be exploitable in a particular environment without a publicly available exploit, while a published exploit may not work against an organization’s deployed configuration.

These distinctions are important when using vulnerability intelligence sources:

• Environment-specific exploitability: Whether the vulnerability can be successfully exploited in the organization’s application or infrastructure under the relevant conditions.
• Exploit availability: Whether exploit code or a proof of concept exists, particularly if it is publicly accessible. Availability does not guarantee that the exploit works against every affected environment.
• Exploit Prediction Scoring System (EPSS): Estimates the probability that a published CVE will be exploited in the wild over the next 30 days. It does not directly assess whether exploitation is possible in a specific organization’s environment.
• CISA Known Exploited Vulnerabilities (KEV): Identifies vulnerabilities with evidence of exploitation in the wild. Inclusion is an important threat signal, but does not independently establish that a particular deployed instance is exploitable.

Security teams should use these signals together rather than interchangeably. EPSS and KEV can help identify relevant threat activity and inform urgency, while environment-specific analysis helps establish whether the organization’s systems are affected and exploitable. Known active exploitation should also prompt timely investigation and remediation in accordance with applicable requirements.

Correlate code, dependency, runtime, and cloud context

Security tools often examine source code, dependencies, containers, cloud infrastructure, and runtime activity independently. This can produce disconnected findings without revealing how a vulnerability relates to a deployed product or whether the conditions required for exploitation exist.

Consider a vulnerable open-source library identified in a repository. On its own, the finding provides limited information about risk. The library may be excluded during the build or included in a component that is never executed. If the same library is present in a production container behind a public-facing load balancer, the deployment and exposure context make the finding more relevant for investigation.

Even in the second scenario, internet exposure does not automatically establish exploitability. Teams must still determine whether the vulnerable functionality is reachable and whether the necessary exploitation prerequisites exist. Correlating code, dependency, build, runtime, and cloud information helps establish these conditions and evaluate the potential consequences of a successful attack.

Product security best practices

The practices below help teams catch weaknesses early, focus remediation on vulnerabilities that are exploitable in their environment, and get fixes to the right developers without slowing delivery.

Build security into the development lifecycle

Product security should begin during design rather than after software reaches production. Threat modeling, secure design reviews, coding standards, dependency controls, and automated security tests can identify weaknesses while developers are still working on the affected components. Addressing problems at this stage is usually simpler than redesigning or patching deployed systems.

Security checks should also be integrated into existing development workflows and CI/CD pipelines. Static analysis, software composition analysis, secrets scanning, and infrastructure-as-code scanning can run automatically when code changes. Teams can define policies that block releases for high-risk issues while allowing lower-risk findings to enter normal remediation workflows.

Security requirements should continue through testing, deployment, and maintenance. Changes to architecture, dependencies, APIs, or infrastructure can introduce risks even when the original design was secure. Repeating relevant security checks throughout the lifecycle helps prevent these changes from creating unnoticed weaknesses.

Prioritize exploitable vulnerabilities over scanner severity alone

Traditional vulnerability prioritization often relies heavily on CVSS scores and external exposure. For example, a team might automatically classify any internet-facing vulnerability with a CVSS score above 8 as urgent. However, CVSS describes standardized vulnerability severity, not whether the flaw is exploitable in a particular environment. An externally accessible service may contain vulnerable code that cannot be exploited under its current configuration.

A more effective approach evaluates whether a vulnerability is exploitable in the actual deployment before assessing how likely it is to be exploited and its potential business impact. This requires understanding the vulnerable code, its execution path, runtime conditions, configuration, permissions, and relevant security controls.

Teams should prioritize findings according to three main considerations:

• Environment-specific exploitability: Determine whether the necessary conditions exist to exploit the vulnerability in the deployed product.
• Likelihood of exploitation: Assess how likely an attacker is to actually exploit the vulnerability, including how exposed it is, whether it’s being exploited in the wild, and the access, privileges, and other prerequisites an attack would need.
• Potential business impact: Evaluate what an attacker could accomplish, including data exposure, privilege escalation, service disruption, or access to sensitive systems.

Combining these factors helps security teams direct remediation toward vulnerabilities that create meaningful business risk. CVSS, EPSS, KEV, and external exposure remain useful supplementary signals, particularly when exploitability cannot yet be established, but they should not replace analysis of the actual environment.

Reduce scanner false positives and security noise before sending findings to developers

Traditional security scanners often produce false positives because they rely on predefined rules, signatures, or incomplete information about application behavior. A scanner may flag code that resembles a vulnerable pattern even when the surrounding logic prevents exploitation. Similarly, dependency scanners may report vulnerabilities in packages that are excluded from the final build or whose vulnerable functions are never executed.

Sending these findings directly to developers creates unnecessary investigation work and reduces trust in security tools. Developers may spend time reproducing vulnerabilities that do not exist, researching unused dependencies, or determining whether a flagged issue can be exploited. Over time, repeated false positives can make teams less responsive to legitimate security findings.

AI-powered security analysis can reduce this noise by examining code behavior, data flows, and application context rather than relying exclusively on static patterns. Combined with build and environment-specific exploitability analysis, these capabilities can improve detection accuracy and filter out findings that do not represent actionable vulnerabilities. The best tools also show the evidence behind each conclusion, so teams can check the reasoning before a finding is closed or a change is made automatically.

Route fixes to the right developer

Security findings should reach the developer responsible for the affected code or component rather than being assigned to a general security queue. Organizations can establish ownership relationships using repository metadata, CODEOWNERS files, service catalogs, and development workflows. This helps direct vulnerabilities to the people best positioned to understand and resolve them.

Each finding should include the information required to take action, rather than forcing the developer to repeat the security team’s investigation. A well-prepared ticket or pull request should identify the affected code, explain why the vulnerability is exploitable, provide relevant evidence, and recommend a specific fix. Where possible, AI-assisted remediation can also suggest code changes that address the underlying weakness.

Connecting validated findings directly to the responsible developer reduces unnecessary handoffs and shortens remediation time. It also helps engineering teams focus on implementing fixes rather than interpreting scanner output or researching vulnerabilities that have already been investigated.

Continuously reassess risk as the environment changes

Product security risk changes over time, even when application code remains unchanged. For example, a product may include an open-source dependency that had no publicly known vulnerabilities when it was deployed. Months later, a new CVE may be disclosed against the same dependency, creating a security issue in software that has not been modified since its original release.

Runtime and infrastructure changes can also affect exploitability. A previously isolated service may become internet-facing, a workload may receive additional cloud permissions, or a configuration change may enable functionality required to exploit an existing vulnerability. Conversely, updated security controls or changes to deployed components may reduce risk.

Teams should continuously reassess findings using current vulnerability intelligence, dependency information, deployed artifacts, and runtime and cloud context. This enables them to identify newly exploitable vulnerabilities, update remediation priorities, and avoid maintaining backlogs based on outdated assumptions about the product’s security posture.

Related content: Read our article about application security best practices

Securing products from code to cloud with Maze

Every practice in this guide depends on context, from where the vulnerable code runs to whether an attacker could actually exploit it there, and gathering that context for every finding takes more security engineering time than most teams have. Maze’s founders kept running into this while working with security teams, whose tools could list thousands of vulnerabilities but couldn’t say which ones mattered in their environment. They built Maze so that every vulnerability gets the investigation those teams never had time to run.

Maze uses AI to find, investigate, and fix vulnerabilities across the code your team writes (AI-SAST), your third-party dependencies (AI-SCA), and the containers and VMs running in your cloud, all on one platform. It was built from the ground up so its AI can gather the context it needs from your code, build, runtime, and cloud, and reason through each vulnerability the way your best security engineer would. On average, Maze finds that over 70% of vulnerabilities are not exploitable, and those are closed with the full reasoning behind the decision.

Key capabilities of Maze:

• Every vulnerability investigated: Maze looks at every vulnerability in your backlog, not only the critical ones, and shares the context it gathers across every investigation, so code and cloud findings are assessed together instead of in isolation.
• Exploitability, not just reachability: Maze uses AI to trace the path from an entry point to the vulnerable code, then checks whether an attacker can control what reaches it and whether a setting or control blocks it, so you see what can be exploited in your environment rather than what is simply reachable.
• AI-SAST for the code your team writes: Maze uses AI to understand what your code does, which is how it finds business-logic flaws and novel vulnerabilities that pattern-matching tools miss. AI-SAST runs on every pull request and across your entire codebase.
• AI-SCA for your dependencies: Maze finds vulnerable direct and transitive dependencies, then investigates each one with context from your code and cloud to decide which create real risk. If you already run something like Dependabot, Maze investigates and deduplicates those findings too.
• Cloud vulnerability investigation: Maze Cloud investigates the vulnerabilities your existing scanners find in the workloads running in your cloud, so a vulnerable library in a production container behind a public-facing load balancer is assessed as the distinct risk it is, with one ticket per issue instead of several.
• Zero-day sweeps: When a new vulnerability is disclosed, Maze picks it up in near real time and investigates it against what you’ve already shipped, so you know whether it affects you without waiting for the next scan.
• Fixes where your developers work: Maze traces each vulnerability to its root cause, writes a fix that matches your code, and routes it to the developer who owns it as a pull request or to the coding agent your team already uses, such as Claude Code or Cursor. Because a single fix can close many vulnerabilities at once, Maze shows which changes cut the most risk, and when no patch exists it recommends a mitigation instead.
• Transparent, evidence-based verdicts: Every conclusion is grounded in evidence from your code, cloud, and business context, and you can open any verdict to see exactly why Maze reached it.

Learn more about how Maze secures your code and cloud