Secure by Design, Secure by Default

Secure by Design is simply good engineering. Engineers need clear requirements, dependable components and tests that show whether their work meets those requirements. Security belongs in each of those decisions from the beginning. Product Security helps engineers define what must be protected and provides practical ways to build the protections. Secure by Default makes those protections the starting configuration. Together, these practices reduce guesswork and rework while helping the business deliver safer software.

Consider Boerum Hill Spice Company, the fictional business introduced in Part 1. It sells primarily online through Shopify, operates stores in New York and Paris and fulfills orders from Brooklyn. Its remote developers connect the commerce platform to warehouse software, an ERP and internal applications. Suppose the support team wants a new application that brings order details and shipment status together and allows employees to issue refunds. The business wants faster customer service. Engineering needs to know exactly what the application should allow.

Make the Security Requirements Explicit

"Only authorized employees can issue refunds" leaves important decisions unresolved. Which employees, against which orders and up to what amount? Who approves a larger refund? Can the same person request and approve it? Can two simultaneous requests refund the same purchase twice? These are business questions with engineering consequences.

Support and Finance should define the refund policy. Product should incorporate it into the requirements. Engineering and Product Security should translate those requirements into security invariants: conditions the system must always enforce. A refund must have an authorized actor. Its amount must remain within the permitted limit. A repeated request must not move money twice. Any approved exception must follow a defined authorization path.

Those conditions belong in the service that authorizes and executes the transaction. Hiding the refund button from an employee is insufficient if that employee can send the same request directly to the service. The support interface, an integration and an AI agent must all be subject to the applicable authorization rules. Engineers should receive those requirements before implementation, along with examples of permitted and prohibited behavior.

That division of work makes security actionable. Product Security contributes abuse cases, standards and review expertise. Engineers turn the requirements into working software. Business owners decide the legitimate policy. CISA's Secure by Design guidance reinforces the leadership responsibility behind this work: own customer security outcomes, be transparent about weaknesses and lead from the top.

Make Secure Implementation Easier

Engineers should have a supported way to implement common protections. A maintained authorization component can check permissions consistently. An approved integration pattern can provide scoped credentials and safe handling of sensitive data. A standard audit mechanism can record consequential actions. Clear examples and tests show teams how to use each one.

For the refund application, this means developers can use an established permission check and transaction-recording mechanism instead of designing both from scratch. They still need to supply the business rules: who can refund, how much and under what approval conditions. The shared components reduce repeated implementation while leaving those business decisions explicit.

Netflix described this approach in its 2019 account of scaling application security. Its Security Paved Road supplied shared solutions for authentication, authorization, secrets and certificates. The useful lesson is to invest in an engineering environment where common protections are readily available. A small spice company can apply the same principle with a few well-maintained libraries and patterns.

These capabilities need owners and engineering time. Someone must maintain the components, explain their limits and help teams adopt them. In return, developers face fewer unresolved security decisions and fewer late requests to redesign finished work. When a defect reveals a weakness in a shared pattern, correcting that pattern can improve multiple applications. NIST's Secure Software Development Framework includes addressing root causes to prevent recurring vulnerabilities.

Use Secure Settings From the Start

Secure by Default means a newly created account, application or integration starts with appropriate protections already enabled. A support account could begin with limited order-lookup access. Refund authority would require a separate grant. A shipping integration would receive only the data and permissions needed for fulfillment. Diagnostic logging would exclude credentials and unnecessary customer information.

This reduces the work required to operate safely. Administrators should not have to discover and remove excessive permissions every time they add an account. Developers should not have to remember a separate hardening checklist for every new integration. The initial configuration should reflect the intended use, with broader access requiring a deliberate decision. OWASP's authorization guidance supports least privilege, denial by default and permission checks on every request.

Legitimate exceptions need an approved path. If a refund exceeds an employee's limit, the application can route it to an authorized approver and record the decision. The security requirement still holds because the larger refund receives the required approval. If ordinary work repeatedly needs exceptions, revisit the requirements and workflow.

Verify the Requirements Still Hold

A requirement becomes useful evidence when it can be tested. For the refund application, Engineering and Product Security should agree on checks such as these:

Requirement:

Refund authority. Test that an employee without refund permission cannot execute one, including by calling the service directly.

Duplicate requests. Test that retries and simultaneous requests cannot produce refunds above the permitted total.

Authorization failures. Test that the application declines the refund when it cannot verify authority and provides a clear recovery path.

Investigation records. Verify that records identify the actor, order, approval and outcome without exposing secrets.

The third check makes failure behavior explicit. If the permission service is unavailable, the application should decline the refund and tell the employee how to retry or escalate. An unavailable security check must not become permission to move money. The business should agree on that behavior before an outage forces someone to improvise.

These requirements must continue to hold when the application changes. A new refund endpoint needs the same authorization rules. An upgrade must preserve them. Tests that run with consequential changes help engineers catch regressions before release. Change management should make the affected requirements and verification visible, with a defined decision process for unresolved exposure.

Improve What Already Exists

Existing applications may have broad credentials, inconsistent checks or missing records. Begin with a consequential workflow and identify where the protections fall short. Give each material gap an owner and a correction plan. If the support application uses an administrative credential for every operation, Engineering may need to change its integration design before narrower permissions are practical. Interim restrictions and monitoring can reduce exposure while that work proceeds, with a clear end condition.

AI-generated software needs the same discipline. A coding assistant can build the refund interface quickly, but it still needs explicit rules for authority, limits and duplicate requests. Give it the approved components and acceptance criteria, then verify the implementation against those criteria. An explanation generated alongside the code does not establish that the checks work. Clear requirements and repeatable verification help engineers use the speed without surrendering judgment.

Secure by Design makes security part of ordinary engineering work through explicit requirements, supported implementation patterns and verification. Secure by Default makes the resulting protections available from the start. At Boerum Hill Spice Company, that means engineers can build a faster support workflow with clear refund rules and reliable ways to enforce them. The business gets safer software, and engineers spend less time guessing, rebuilding and negotiating security after the work is done.

Continue the Series

The next article applies Zero Trust to product architecture, using protect surfaces, transaction flows and Zero Trust Chains to examine the decisions across a business workflow.

Part 1: Building Your Business Secure by Design in the AI Age

My companion toolkit repo on GitHub includes a Secure by Design Assessment Skill, Security Requirements Register and Design Evidence Checklist, with worked examples for Boerum Hill Spice Company. Use them to define requirements for your own application, identify missing evidence and plan the engineering work.

Sources and Further Reading

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

Contents