From 5d717fc7205de3c3c2bde992bb47b561827999bf Mon Sep 17 00:00:00 2001 From: Jonny Brodie Date: Thu, 30 Jul 2026 17:15:11 +0100 Subject: [PATCH 1/9] Add "Secure by Design" principle Makes security an explicit engineering principle: consider how attackers could exploit a design, prefer secure defaults and existing solutions, and build interfaces that are difficult to misuse. Co-authored-by: Claude --- README.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/README.md b/README.md index e130c6f..941b065 100644 --- a/README.md +++ b/README.md @@ -40,3 +40,7 @@ Software Engineering is a team activity where we win and lose together: there is ### Prefer Small Changes Many small changes are less than the sum of their parts but they're easier to reason about. A small change is easier to give feedback on, easier to roll-back, can build confidence and comfort through frequent releases, and is harder to get “wrong”. Many small changes allow for many small improvements. And bluntly, 10KLOC PRs don’t get good reviews! + +### Secure by Design + +We’re all responsible for the security of our systems, holding them to a high bar to protect the data and money our customers trust us with. Consider how attackers, external or internal, could exploit weaknesses and unhappy paths in a design, and mitigate them before they ship. Prefer secure defaults and existing solutions over new ones, and design interfaces that are difficult to misuse rather than ones that rely on everyone using them correctly. For example, an internal service should still authenticate its callers rather than trusting the network it sits on. From 2d1018cc74b50bf0ec156517ba2c3ddcc2925a0e Mon Sep 17 00:00:00 2001 From: Jonny Brodie Date: Thu, 30 Jul 2026 17:18:11 +0100 Subject: [PATCH 2/9] Narrow scope to protecting customer data Co-authored-by: Claude --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 941b065..58a758d 100644 --- a/README.md +++ b/README.md @@ -43,4 +43,4 @@ Many small changes are less than the sum of their parts but they're easier to re ### Secure by Design -We’re all responsible for the security of our systems, holding them to a high bar to protect the data and money our customers trust us with. Consider how attackers, external or internal, could exploit weaknesses and unhappy paths in a design, and mitigate them before they ship. Prefer secure defaults and existing solutions over new ones, and design interfaces that are difficult to misuse rather than ones that rely on everyone using them correctly. For example, an internal service should still authenticate its callers rather than trusting the network it sits on. +We’re all responsible for the security of our systems, holding them to a high bar to protect the data our customers trust us with. Consider how attackers, external or internal, could exploit weaknesses and unhappy paths in a design, and mitigate them before they ship. Prefer secure defaults and existing solutions over new ones, and design interfaces that are difficult to misuse rather than ones that rely on everyone using them correctly. For example, an internal service should still authenticate its callers rather than trusting the network it sits on. From 4b3479db45a0de4f9c3bae67ec751523b88319f9 Mon Sep 17 00:00:00 2001 From: Jonny Brodie Date: Thu, 30 Jul 2026 17:36:57 +0100 Subject: [PATCH 3/9] Reference our engineering standards for security Co-authored-by: Claude --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 58a758d..0c5f8f1 100644 --- a/README.md +++ b/README.md @@ -43,4 +43,4 @@ Many small changes are less than the sum of their parts but they're easier to re ### Secure by Design -We’re all responsible for the security of our systems, holding them to a high bar to protect the data our customers trust us with. Consider how attackers, external or internal, could exploit weaknesses and unhappy paths in a design, and mitigate them before they ship. Prefer secure defaults and existing solutions over new ones, and design interfaces that are difficult to misuse rather than ones that rely on everyone using them correctly. For example, an internal service should still authenticate its callers rather than trusting the network it sits on. +We’re all responsible for the security of our systems, holding them to a high bar to protect the data our customers trust us with. Consider how attackers, external or internal, could exploit weaknesses and unhappy paths in a design, and mitigate them before they ship. Prefer secure defaults and existing solutions over new ones, and design interfaces that are difficult to misuse rather than ones that rely on everyone using them correctly. Our engineering standards for security describe what this looks like in practice, and following them is how we get there. For example, an internal service should still authenticate its callers rather than trusting the network it sits on. From 8440d8614af7d8ff7a5af544643139f84880662f Mon Sep 17 00:00:00 2001 From: Jonny Brodie Date: Thu, 30 Jul 2026 17:37:52 +0100 Subject: [PATCH 4/9] Drop secure-defaults sentence Co-authored-by: Claude --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 0c5f8f1..71ac847 100644 --- a/README.md +++ b/README.md @@ -43,4 +43,4 @@ Many small changes are less than the sum of their parts but they're easier to re ### Secure by Design -We’re all responsible for the security of our systems, holding them to a high bar to protect the data our customers trust us with. Consider how attackers, external or internal, could exploit weaknesses and unhappy paths in a design, and mitigate them before they ship. Prefer secure defaults and existing solutions over new ones, and design interfaces that are difficult to misuse rather than ones that rely on everyone using them correctly. Our engineering standards for security describe what this looks like in practice, and following them is how we get there. For example, an internal service should still authenticate its callers rather than trusting the network it sits on. +We’re all responsible for the security of our systems, holding them to a high bar to protect the data our customers trust us with. Consider how attackers, external or internal, could exploit weaknesses and unhappy paths in a design, and mitigate them before they ship. Our engineering standards for security describe what this looks like in practice, and following them is how we get there. For example, an internal service should still authenticate its callers rather than trusting the network it sits on. From 2300eec1223f4b330f286357f1d8fa45a3a56eae Mon Sep 17 00:00:00 2001 From: Jonny Brodie Date: Thu, 30 Jul 2026 17:39:25 +0100 Subject: [PATCH 5/9] Reword the threat-modelling sentence Co-authored-by: Claude --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 71ac847..884c856 100644 --- a/README.md +++ b/README.md @@ -43,4 +43,4 @@ Many small changes are less than the sum of their parts but they're easier to re ### Secure by Design -We’re all responsible for the security of our systems, holding them to a high bar to protect the data our customers trust us with. Consider how attackers, external or internal, could exploit weaknesses and unhappy paths in a design, and mitigate them before they ship. Our engineering standards for security describe what this looks like in practice, and following them is how we get there. For example, an internal service should still authenticate its callers rather than trusting the network it sits on. +We’re all responsible for the security of our systems, holding them to a high bar to protect the data our customers trust us with. Think about how someone could abuse a system, whether they’re outside the company or already inside it, and close those gaps before it ships. Our engineering standards for security describe what this looks like in practice, and following them is how we get there. For example, an internal service should still authenticate its callers rather than trusting the network it sits on. From af4280af88887236abd3722329274727fd6936a3 Mon Sep 17 00:00:00 2001 From: Jonny Brodie Date: Thu, 30 Jul 2026 17:42:33 +0100 Subject: [PATCH 6/9] Use "a high standard" instead of "a high bar" Co-authored-by: Claude --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 884c856..ba938dd 100644 --- a/README.md +++ b/README.md @@ -43,4 +43,4 @@ Many small changes are less than the sum of their parts but they're easier to re ### Secure by Design -We’re all responsible for the security of our systems, holding them to a high bar to protect the data our customers trust us with. Think about how someone could abuse a system, whether they’re outside the company or already inside it, and close those gaps before it ships. Our engineering standards for security describe what this looks like in practice, and following them is how we get there. For example, an internal service should still authenticate its callers rather than trusting the network it sits on. +We’re all responsible for the security of our systems, holding them to a high standard to protect the data our customers trust us with. Think about how someone could abuse a system, whether they’re outside the company or already inside it, and close those gaps before it ships. Our engineering standards for security describe what this looks like in practice, and following them is how we get there. For example, an internal service should still authenticate its callers rather than trusting the network it sits on. From 8b7e1ff7b71fc375f1a28fff23406cb9e8fcc45f Mon Sep 17 00:00:00 2001 From: Jonny Brodie Date: Thu, 30 Jul 2026 17:44:40 +0100 Subject: [PATCH 7/9] Drop the worked example Co-authored-by: Claude --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index ba938dd..7c3198b 100644 --- a/README.md +++ b/README.md @@ -43,4 +43,4 @@ Many small changes are less than the sum of their parts but they're easier to re ### Secure by Design -We’re all responsible for the security of our systems, holding them to a high standard to protect the data our customers trust us with. Think about how someone could abuse a system, whether they’re outside the company or already inside it, and close those gaps before it ships. Our engineering standards for security describe what this looks like in practice, and following them is how we get there. For example, an internal service should still authenticate its callers rather than trusting the network it sits on. +We’re all responsible for the security of our systems, holding them to a high standard to protect the data our customers trust us with. Think about how someone could abuse a system, whether they’re outside the company or already inside it, and close those gaps before it ships. Our engineering standards for security describe what this looks like in practice, and following them is how we get there. From 93ff9d43aedd3bddeb6d49807a13e0784834d926 Mon Sep 17 00:00:00 2001 From: Jonny Brodie Date: Thu, 30 Jul 2026 17:46:57 +0100 Subject: [PATCH 8/9] Refer to our engineering standards generally Co-authored-by: Claude --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 7c3198b..ec6e822 100644 --- a/README.md +++ b/README.md @@ -43,4 +43,4 @@ Many small changes are less than the sum of their parts but they're easier to re ### Secure by Design -We’re all responsible for the security of our systems, holding them to a high standard to protect the data our customers trust us with. Think about how someone could abuse a system, whether they’re outside the company or already inside it, and close those gaps before it ships. Our engineering standards for security describe what this looks like in practice, and following them is how we get there. +We’re all responsible for the security of our systems, holding them to a high standard to protect the data our customers trust us with. Think about how someone could abuse a system, whether they’re outside the company or already inside it, and close those gaps before it ships. Our engineering standards describe what this looks like in practice, and following them is how we get there. From e45ffd9ac37f7a750e767fd097fe1ce7b04abe2c Mon Sep 17 00:00:00 2001 From: Jonny Brodie Date: Fri, 31 Jul 2026 08:20:54 +0100 Subject: [PATCH 9/9] Add secure defaults sentence Co-authored-by: Claude --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index ec6e822..116bd66 100644 --- a/README.md +++ b/README.md @@ -43,4 +43,4 @@ Many small changes are less than the sum of their parts but they're easier to re ### Secure by Design -We’re all responsible for the security of our systems, holding them to a high standard to protect the data our customers trust us with. Think about how someone could abuse a system, whether they’re outside the company or already inside it, and close those gaps before it ships. Our engineering standards describe what this looks like in practice, and following them is how we get there. +We’re all responsible for the security of our systems, holding them to a high standard to protect the data our customers trust us with. Think about how someone could abuse a system, whether they’re outside the company or already inside it, and close those gaps before it ships. We prefer systems with secure defaults, leveraging existing solutions where possible. Our engineering standards describe what this looks like in practice, and following them is how we get there.