Building Your Business Secure by Design in the AI Age

Product security protects the software-dependent capabilities that make a business valuable. Its purpose begins with what the company sells, how it serves customers and what could prevent it from keeping its promises. Those questions establish what needs protection and where failure would hurt. They also determine which engineering decisions deserve the most attention. A useful product security program makes those decisions explicit, gives people the means to implement them and produces evidence that the resulting protections work.

Consider a fictional mail-order spice company. Its headquarters are in Manhattan's Flatiron District, its stores are in New York and Paris, and most of its sales are online. The packaging is beautiful, the sourcing is meticulous and the Brooklyn warehouse crew has strong opinions about coffee. The company is growing quickly. Its developers work remotely.

Customers buy through Shopify. An ERP manages purchasing and financial records. Warehouse software directs picking and shipping, while a co-packer blends spices and packages finished goods. Custom applications and integrations keep orders, inventory and shipment information moving between them. The company sells spices. Delivering them depends on software behaving correctly across several organizations.

Follow the Customer Order

An order from your customer provides the best starting point for security design. A customer submits a delivery address and pays for a purchase. An integration passes the order into fulfillment. Warehouse staff pick the products, a carrier receives shipment information and the customer receives a tracking message. A support employee may later change an address or issue a refund. Each step grants someone or something permission to act on valuable information.

The relevant failures are concrete. An integration credential could expose customer addresses. A support application could allow unauthorized refunds. A compromised deployment account could introduce malicious storefront code. Altered inventory or lot records could undermine fulfillment or the company's ability to trace affected products. The consequences reach revenue, customer privacy, operating continuity and trust.

These dependencies establish priorities. An application that can issue refunds deserves different scrutiny from a tool that suggests descriptions for cinnamon. An integration that only needs shipment status should have permissions limited to that purpose. Security becomes easier to explain when its requirements follow the work and the consequences of getting it wrong.

Define the Responsibility

For this series, product security means the responsibility for protecting a digital product throughout its lifecycle, including the architecture, software, dependencies, configuration and services on which its security relies. Application security, usually shortened to AppSec, is a central discipline within that responsibility. It includes security requirements, threat modeling, design review, secure development, testing and remediation. The organizational boundaries vary. GitLab, for example, places application security within its broader product security organization.

At the spice company, this responsibility centers on the storefront, customer-facing services and custom integrations. Internal applications also need AppSec practices, with ownership shared among their business owners, IT and Engineering. Product Security contributes specialist expertise and consistent requirements across those boundaries. Someone still has to own each system, its access decisions and its maintenance.

Buying a platform changes the work. The provider operates important parts of the system, while the merchant makes decisions about staff access, installed applications, integrations and its own code. Those responsibilities need to be understood and assigned. A capable supplier cannot compensate for every permission the customer grants or every unsafe integration the customer builds.

The first deliverable is therefore a clear account of the business: its critical workflows, valuable information, system owners and dependencies. From that account, the organization can establish scope and priorities. Buying a scanner before doing this work risks producing a detailed answer to an unimportant question.

Build the Conditions for Secure Software

Secure by Design puts security requirements into product and engineering decisions from the beginning. Secure by Default concerns the protection users receive without having to discover and enable it themselves. CISA and its international partners place customer security outcomes, transparency and executive leadership at the center of their guidance for software manufacturers. Those principles also offer a useful test for companies building digital services around purchased platforms: which risks can the company remove through its own design decisions?

Suppose support staff need to issue refunds. Product management defines the legitimate workflow and approval requirements. Engineering enforces permissions in the service that performs the refund. Security helps examine abuse cases and tests the boundary. The application records the action so it can be investigated. The design should make the permitted action straightforward and the unauthorized action difficult, regardless of what the interface happens to display.

This requires people, process and technology, in that order. Engineers need usable requirements and access to security expertise. Teams need a dependable way to review consequential changes, release software and correct defects. Reusable components and automated checks then make good decisions easier to repeat. NIST's Secure Software Development Framework supports this lifecycle approach, including reducing vulnerabilities and addressing their root causes.

Zero Trust supplies a complementary architectural discipline. Following the approach developed by John Kindervag and explained in George Finney's terrific book, Project Zero Trust, we begin with what requires protection, map its transaction flows and design the controls around those flows. In my own Zero Trust Chains approach, each consequential decision must stand on its own: no decision inherits trust. A valid customer login does not authorize access to every order. A support tool's permission to retrieve a record does not automatically justify exporting it or issuing a refund.

Separation of Duty

Many, if not most, organization place product security inside the tech org. My recommended model places Product Security within the CISO organization and outside of Engineering. This model gives product security an independent voice while embedding with the engineering teams keeps a close working relationship with Product and Engineering. The CISO establishes security direction, requirements and escalation. Engineering owns secure implementation, remediation and the software it operates. Product incorporates security requirements into planning. Business leaders provide resources and accept residual risk within defined authority.

That division needs practical decision rights. Teams should know which requirements govern release, who can approve an exception and when a disagreement must be escalated. If a serious defect threatens an important launch, the decision should identify the exposure, compensating measures, accountable executive and deadline for correction. Commercial urgency is real. Recording the decision makes its costs visible.

For a startup, these are responsibilities to assign before they become departments to staff. A small function can establish requirements, advise engineers and coordinate specialist assessments. Its effectiveness depends on whether the organization acts on the work. A queue of unresolved findings says something about engineering capacity and leadership priorities as well as security performance.

Test, Learn and Continuously Secure

Testing supplies evidence about whether the protections work. Code analysis, dependency checks, application tests, penetration testing and external research each examine different parts of the problem. Findings should lead to an owner, a verified correction and, where possible, a change that prevents recurrence. A penetration test is particularly useful when it demonstrates how a weakness can become a business consequence. Its value depends on what happens next.

AI makes this operating model more consequential. At our fast scaling spice company, a support manager might vibe code a useful internal application with an AI coding assistant and then request access to live customer orders. The company needs an accessible path from that experiment to supported operation, with ownership, constrained access, testing and maintenance. Security requirements should follow the application's capabilities and exposure. The author's job title provides little evidence about either.

My later articles in this comprehensive series will follow that prototype into production, examining the ownership, access controls and engineering practices it needs along the way.

Leaders should judge the program by the exposure it reduces and the engineering habits it improves. Can a compromised integration be contained? Are critical access paths tested? Do consequential defects get corrected promptly? Are the same mistakes recurring? Those questions provide more useful direction than the number of scans completed or findings entered into a dashboard.

Product security serves the business by making its dependence on software safer to sustain and easier to change. At the spice company, that means protecting the path from a customer's order to the right package arriving at the right address. Clear ownership, secure design, explicit trust decisions and verified improvements support that outcome together. The program succeeds when those practices become ordinary parts of how the company delivers on its promises.

Apply this to your business: The companion GitHub toolkit includes a Business-Context Discovery Skill, Product Profile Template and Product Security Charter to help you establish your own program's scope, ownership and priorities.

Sources

The concept of the "Zero Trust Chain" was developed by James Kittle and is part of his ongoing work on Zero Trust systems.

Contents