Security by Design — Part 3 of 3
If every team has to rediscover the same security settings, something is wrong with the platform, not necessarily with the teams.
We often describe security as a collection of things that people must remember to do. Enable this control. Restrict that permission. Rotate those secrets. Review the logs. The individual actions matter, but the model does not scale especially well.
I would rather see a system where the ordinary path is already the safer one.
Two very different starting lines
Imagine two development teams beginning the same small service. Both care about doing a good job.
The first starts with a template that works, but is permissive. Security appears as a collection of optional steps, tickets and late approvals. The second starts with a platform that provides a restricted service identity, protected secrets, sensible network policies and a working deployment pipeline.
Neither team is magically immune to mistakes. But only one is being asked to rebuild the same baseline from memory.
Secure defaults reduce the amount of security work each team must repeat. They do not remove the need to understand system-specific risks.
What should be built in?
| Decision | A useful starting default |
|---|---|
| Identity | Each person and workload has an appropriate identity; avoid shared privileged credentials. |
| Access | Deny unnecessary permissions and grant only the access the service requires. |
| Secrets | Use managed secret storage; do not place credentials in code, images or logs. |
| Network | Publish only required interfaces; separate external access from private services. |
| Data | Minimize collection and retention; protect sensitive data in transit and at rest where appropriate. |
| Delivery | Run relevant automated checks and keep the results visible to the team. |
| Observability | Record meaningful events while excluding sensitive payloads and credentials. |
These defaults are a beginning, not a substitute for an architecture review. A medical application, a public information page and an internal batch job will not share the same risk profile.
Good guardrails still leave room for engineering
There is an unhelpful version of security where every exception becomes an argument and every new tool becomes a months-long negotiation. The result is predictable: people look for ways around the process.
A better approach is to make the supported path clear, quick and well documented. Where a design genuinely needs something different, the exception should have an owner, a reason, a scope, an expiry or review point, and a visible residual risk. That is governance in service of delivery, not governance as a ceremony.
The CISA Secure by Design and Secure by Default guidance argues that providers should not transfer the security burden to their customers. The same idea applies inside an organization: the platform should do as much of the repeatable work as it can. The NIST SSDF and OWASP SAMM offer useful structures for improving that journey.
Measure the friction we remove
I find three questions more revealing than a long list of policy acknowledgements:
- Can a team start a new service using the secure baseline without opening a series of manual tickets?
- When a control is bypassed, can we understand why and whether the exception is still justified?
- When a vulnerability or an incident changes what we know, can the improved baseline reach the next service automatically?
None of these questions requires pretending that a platform is finished. A mature secure default is one that keeps learning.
Security should feel like good infrastructure
The best road has markings, signs and guardrails. Drivers still need to pay attention, but they are not expected to design the road before every journey.
That is the kind of security I want to help build: clear by default, safe by default, and flexible when there is a good reason to be different.
Start at the beginning: Security by Design Is Not a Final Gate.