# Secure by design

> Secure by design is the practice of building security and supply-chain integrity into software from the start — bounded defaults, reviewed and tested generated code, and verifiable provenance for every artifact — rather than adding it afterward.

Category: AI governance
Also searched as: secure software development, supply-chain security, SSDF, SLSA
Source: Mediator Solutions — https://mediatorsolutions.io/learn/#secure-by-design
License: free to read, learn, cite, and apply, with attribution to Mediator Solutions.

## What it is

Security added at the end is security that can be bypassed. Secure by design puts fail-closed defaults, least privilege, and artifact provenance into the construction itself. Generated code is not trusted because it was generated; it is reviewed, tested, scanned, and bound to a provenance record before it ships.

## Why it matters

Security added at the end is security that can be bypassed, because the paths that matter were decided before anyone thought about them. Building it in means the restrictive default is the starting point and access is opened deliberately, not the reverse. The specific discipline for an age of generated code is that provenance travels with the artifact: generated code is not trusted because it was generated, it is reviewed, tested, scanned and bound to a record of exactly what was built — so what runs is provably what was reviewed, not something that drifted in between.

## When to use it

- Starting any new system, feature, or integration where access and data paths are being decided.
- Reviewing generated code before it is trusted to run.
- A security control is being added late, after the architecture is set.

## Principles

- Fail-closed defaults and least privilege are design decisions, not later patches.
- Generated code is followed by review, test, scan, and provenance before it is trusted.
- Every artifact has verifiable provenance, so what runs is what was built.
- Supply-chain integrity is checked, not assumed.

## Practice

1. Start from the most restrictive defaults and open only what is needed.
2. Gate generated code behind review, test, and security scan.
3. Bind each build artifact to a provenance record and verify it before release.
4. Treat an unverifiable dependency as a risk to resolve, not a convenience to accept.

## Where it fails

- **Bolt-on security** — Protection added at the end leaves the paths that matter already decided, so the control can be bypassed by design.
- **Generated-means-trusted** — Code is trusted because a model produced it, so an unreviewed artifact reaches production carrying unknown behavior.
- **Permissive default** — Access starts open and is closed case by case, so the gap no one closed becomes the way in.

## In practice

A team adds an AI feature that calls internal tools. Bolted on, auth is checked at the UI and the tool calls run with broad credentials — one injection and the blast radius is the whole toolset. Secure by design starts restrictive: each tool has the narrowest scope that works, generated code is reviewed, tested, scanned, and bound to a build record, and provenance travels with the artifact so what runs is provably what was reviewed. Opening access is then a deliberate, logged decision, not the default.

## Verification

A released artifact carries a provenance record that an independent party can verify, and the generated code in it passed review, test, and scan on the record.

## Reference

### Development gates (same for generated, copied, and human-written code)

- Source control
- Review
- Test
- Dependency inventory
- Secrets scan
- Vulnerability scan
- Build provenance
- Release approval
- Rollback path

### The system must know what it runs — per artifact

- Source repository
- Commit
- Dependency list
- Builder
- Build command
- Build time
- Artifact hash
- Signer if available
- Deployment destination

---

Previous: https://mediatorsolutions.io/learn/#agentic-authority-boundaries
Next: https://mediatorsolutions.io/learn/#supplier-risk