i

Description

Porte de chambre forte d'une banque, avec ses gros verrous cylindriques et ses volants de manœuvre.

Source

auteur non indiqué (architectes York and Sawyer) · original page

Licence

PD Public domain

Original photo, unretouched. The background is a version of it stylised by the site.

Security

This domain measures the software’s and its build chain’s resilience to errors and attacks, from the developer’s perspective: secrets, dependencies, code vulnerabilities, threats…

In brief

This domain measures the software’s and its build chain’s resilience to errors and attacks, from the developer’s perspective: secrets, dependencies, code vulnerabilities, threats anticipated from the design stage, known composition of the deliverable (SBOM), artifact provenance. Data security (GDPR, privacy) belongs to the data matrix: 08 — Security, Privacy, and Compliance.

On this page

1. Why this domain
2. What this domain measures
3. Five-level table
4. Milestones by level
5. Detailed reading by level
   1. 🟢 Level 1 — Confident
   2. 🟢 Level 2 — Hygienic
   3. 🟡 Level 3 — Detected
   4. 🔴 Level 4 — Anticipated
   5. 🔴 Level 5 — Proven
6. Partial achievement and rating
7. Move to the next level
8. See also

Level: 🟢→🔴 · Domain code: SEC (DL matrix)

Why this domain#

The most costly security incidents rarely come from sophisticated attacks: a secret committed in history, a vulnerable dependency never updated, an over-privileged service account, SQL injection in a procedure built through concatenation. The software supply chain has become a target in its own right: compromising an upstream component affects all its consumers. The cost of ignorance is measured in response time: how many hours to know whether we are exposed to a new public vulnerability?

For SQL and admin scripts: parameterized dynamic queries, least-privilege principle for processing accounts, no secrets in scripts, connection strings outside the repository. These rules are plain and highly cost-effective.

What this domain measures#

• Axis: from “we fix it when it happens” to “we anticipate, detect, and prove provenance.”
• Key indicators: response time to a public vulnerability (from publication to the response “are we exposed?”); age of open vulnerabilities; share of components covered by an inventory (SBOM); secrets detected in history.
• Unit: hours/days; %; count.

Five-level table#

Milestones by level#

Detailed reading by level#

🟢 Level 1 — Confident#

• Signs: “no one wants our data”; connection strings in scripts; shared admin account.
• Gain: zero friction.
• Does not guarantee: anything, precisely. This is a level of unmeasured exposure.
• Difficulty: 1/5 · Effort: 1/5.

🟢 Level 2 — Hygienic#

• Signs: secrets moved out of code, individual accounts, rights review, parameterization of dynamic queries.
• Gain: elimination of most avoidable incidents.
• Does not guarantee: detection of new flaws; it is static.
• Difficulty: 2/5 · Effort: 2/5.

🟡 Level 3 — Detected#

• Signs: CI flags vulnerable components, secrets, and dangerous patterns. A secret already committed is considered compromised even after deletion: history still contains it; it must be revoked.
• Gain: known risk is handled before delivery.
• Does not guarantee: absence of unknown flaws, nor design threats.
• Difficulty: 3/5 · Effort: 3/5.

🔴 Level 4 — Anticipated#

• Signs: threats are considered before coding (who attacks, through what path, what impact; STRIDE categories: spoofing, tampering, repudiation, information disclosure, denial of service, privilege escalation). An SBOM makes it possible to respond in hours to a public alert on a library.
• Gain: fast response and informed decisions.
• Does not guarantee: prevention of attacks on the build chain itself.
• Difficulty: 4/5 · Effort: 4/5.

🔴 Level 5 — Proven#

• Signs: each artifact is signed with provenance attestation; dependencies are pinned by fingerprint; secret rotation is automatable; simulated attacks test the defense.
• Gain: verifiable trust and limited blast radius.
• Does not guarantee: invulnerability — this is risk reduction, not proof of absence of flaws.
• Difficulty: 5/5 · Effort: 5/5.

Partial achievement and rating#

Apply the rating rule.

• 0.5 on DL-SEC-3.1: dependency analysis runs, without blocking.
• 0.5 on DL-SEC-4.2: SBOM produced for the application, not for SQL/PowerShell scripts embedded in the kit.
• A partial 5: artifact signing in place, deployment-time verification not yet mandatory.

Move to the next level#

• 1 → 2: secret hunt, vault, individual accounts, rights review.
• 2 → 3: dependency and static analysis in CI, history detection, agreed fix lead times.
• 3 → 4: threat modeling workshops (1 hour per workstream), automatic SBOM, requirements framework.
• 4 → 5: signing and attestation, fingerprint locking, attack exercises.

See also#

• Neighbors: 05 CI/CD: Continuous Integration and Delivery · 06 Deployment and Operations · 08 Observability and Reliability · 02 Code Quality.
• Other matrices: Data — Security, Privacy, and Compliance · BI — RLS Security and Access · Project — Risk Management (RSK).
• Practice: CI/CD · Git In Depth · Project Management Pitfalls and Best Practices (Cross-Cutting Summary) · AI in Planning and Version Control Tools.
• Glossary · Rating: How to Read Scores, Ratings, and Legend.

✻ Written by Claude Sonnet 5.5