docs: convert pipeline, SAST, DAST, IAST and pre-commit diagrams to Mermaid (#89)

.pre-commit-config.yaml

@@ -37,6 +37,8 @@ repos:
         name: "general | check XML files"
       - id: check-yaml
         name: "general | check YAML files"
+        # mkdocs.yml uses the !!python/name tag for the Mermaid superfence
+        args: [--unsafe]
       - id: end-of-file-fixer
         name: "general | fix end of file"
       - id: forbid-new-submodules

current-version/0-Intro/0-2-Overview.md

@@ -25,6 +25,63 @@ A reasonable progression of controls to introduce:
 - **Compliance checks** — continuously verify controls against policy and regulation using policy-as-code tools so compliance state is always known, not discovered at audit time.
 - **AI-assisted development guardrails** — apply the same scanning gates to AI-generated code, restrict what coding agents and MCP servers can access, and verify suggested dependencies. See [IDE and AI-Assisted Development Security](../2-Process/2-2-Develop/2-2-2-IDE-and-AI-assisted-development.md).
 
+## The secure pipeline at a glance
+
+The diagram below shows how those controls fit together across an application pipeline and an infrastructure pipeline. Every scanner reports into a central vulnerability management platform, and scanning does not stop at deployment — registries, staging, and production are scanned continuously.
+
+```mermaid
+flowchart LR
+    subgraph APP["Application pipeline"]
+        subgraph APPCI["CI"]
+            A0[(Git<br/>AppCode)] --> A1[Pipeline init] --> A2[Secret<br/>scanning] --> A3[SAST] --> A4[SCA] --> A5[Container<br/>scanning]
+        end
+        subgraph APPCD["CD"]
+            A6[Deploy<br/>staging] --> A7[IAST] --> A8[DAST] -- No vulnerability --> A9[Deploy<br/>prod]
+        end
+        A5 -- "No vulnerability:<br/>push image" --> REG[(Container<br/>registry)] -- Pull image --> A6
+    end
+
+    subgraph INFRA["Infrastructure pipeline"]
+        subgraph INFCI["CI"]
+            I0[(Git<br/>InfraCode)] --> I1[Pipeline init] --> I2[Secret<br/>scanning] --> I3[IaC<br/>scanning]
+        end
+        subgraph INFCD["CD"]
+            I4[Deploy<br/>staging] --> I5[Infra<br/>scanning] -- No vulnerability --> I6[Deploy<br/>prod]
+        end
+        I3 -- No issue --> I4
+    end
+
+    subgraph ENV["Environments"]
+        STG((Staging))
+        PRD((Production))
+        PRD --> RT[Runtime<br/>security]
+        PRD --> CSI[Continuous<br/>infra scanning]
+    end
+
+    CVM[["Central Vulnerability Management"]]
+
+    A6 & I4 --> STG
+    A9 & I6 --> PRD
+    A8 -. Scan staging .-> STG
+    I5 -. Scan infra .-> STG
+
+    APPCI & APPCD & INFCI & INFCD -. Findings .-> CVM
+    REG -. Continuous<br/>image scanning .-> CVM
+    RT & CSI -. Findings .-> CVM
+
+    style CVM fill:#f5f5f5,stroke:#333,stroke-width:2px
+    style REG fill:#fde9d9,stroke:#e8713a
+    style STG fill:#fde9d9,stroke:#e8713a
+    style PRD fill:#fde9d9,stroke:#e8713a
+```
+
+Key takeaways from the picture:
+
+- **Two pipelines, same discipline** — infrastructure code gets secret scanning and IaC scanning just as application code gets SAST and SCA.
+- **Gates between CI and CD** — images and infrastructure only move to staging when the build-time scans pass, and only move to production when the test-time scans (IAST, DAST, infra scanning) pass.
+- **One place for findings** — every tool feeds a [central vulnerability management dashboard](../3-Governance/3-3-Reporting/3-3-2-Central-vulnerability-management-dashboard.md) so risk can be prioritized across sources.
+- **Scanning continues after deploy** — the registry, staging, and production are re-scanned as new CVEs are published, and runtime security watches production for active threats.
+
 ## A recommended introduction order
 
 | Priority | Control | Why first |

current-version/2-Process/2-2-Develop/2-2-1-Pre-commit/2-2-1-1-Pre-commit.md

@@ -2,6 +2,22 @@
 
 Pre-commit hooks are the **earliest possible shift-left gate** — they run on the developer's machine *before* code is even committed, giving feedback in seconds rather than minutes (CI) or days (review). Catching a leaked secret, a syntax error, or an obvious vulnerability here is the cheapest fix in the entire lifecycle.
 
+```mermaid
+flowchart LR
+    WD([Working directory]) -- git add --> ST([Staging])
+    ST -- git commit --> PC([pre-commit])
+    PC -.-> HOOKS["Secret scanning<br/>Linting<br/>..."]
+    HOOKS -. No issue .-> LR([Local repo])
+    HOOKS -. Issue: fix and re-stage .-> ST
+    LR -- git push --> RR[Remote repo]
+
+    style ST fill:#fff176,stroke:#333
+    style PC fill:#4a90e2,stroke:#333
+    style HOOKS fill:#e0e0e0,stroke:#555,stroke-dasharray:4 3
+    style LR fill:#aed581,stroke:#333
+    style RR fill:#e8713a,stroke:#333
+```
+
 ## What pre-commit hooks are
 
 Git supports client-side hooks that fire on events like `commit`, `push`, and `merge`. Managing these by hand across a team is painful and inconsistent: hooks live in `.git/hooks/`, which is not committed to the repository, so every developer's environment diverges over time.

current-version/2-Process/2-3-Build/2-3-1-Static-Analysis/2-3-1-1-Static-Application-Security-Testing.md

@@ -2,6 +2,14 @@
 
 Static Application Security Testing analyzes an application's **source code, bytecode, or binaries without executing it** — a white-box technique that examines the code from the inside. Because it runs early (in the IDE, at pre-commit, and in CI) and needs no running application, SAST is a cornerstone of shift-left security.
 
+```mermaid
+sequenceDiagram
+    participant S as SAST scanner
+    participant C as Application<br/>source code / bytecode / binaries
+    S->>C: Query for dangerous patterns
+    C-->>S: Potential vulnerability
+```
+
 ## How SAST works mechanically
 
 SAST tools use one or more of these techniques depending on their depth and language support:

current-version/2-Process/2-4-Test/2-4-1-Interactive-Application-Security-Testing.md

@@ -17,6 +17,15 @@ The combination of inside-view (like SAST) and runtime-view (like DAST) is what
 
 ## How it works
 
+```mermaid
+flowchart LR
+    EXT([External request]) --> APP
+    subgraph WAS["Web application server"]
+        APP[Target application] -- "Analyze stack and report<br/>back dangerous patterns" --> AGENT[IAST agent]
+    end
+    AGENT -- Potential vulnerability --> CONSOLE[IAST console]
+```
+
 An IAST agent is loaded into the application runtime — as a Java agent (`-javaagent`), a .NET profiler, a Node.js hook, or a Python middleware. From there it:
 
 1. **Instruments** method calls, framework hooks, and I/O operations at runtime.

current-version/2-Process/2-4-Test/2-4-2-Dynamic-Application-Security-Testing.md

@@ -2,6 +2,15 @@
 
 Dynamic Application Security Testing examines a **running application from the outside** — a black-box technique that sends crafted requests and observes responses, exactly as an attacker would. Because it tests the deployed, integrated application, DAST finds vulnerabilities that only appear at runtime: configuration issues, authentication and session flaws, and problems arising from how components interact.
 
+```mermaid
+sequenceDiagram
+    participant D as DAST scanner
+    participant T as Target application
+    D->>T: 1. Request with SQL payload: userId="select * from table"
+    T-->>D: 2. Response "SQL.Error unknown table..."
+    Note over D: Error signature suggests a<br/>possible injection point — verify
+```
+
 ## What DAST finds
 
 - Injection flaws (SQL, command, XSS) observable in responses

mkdocs.yml

@@ -51,7 +51,11 @@ markdown_extensions:
       permalink: true
   - pymdownx.highlight:
       anchor_linenums: true
-  - pymdownx.superfences
+  - pymdownx.superfences:
+      custom_fences:
+        - name: mermaid
+          class: mermaid
+          format: !!python/name:pymdownx.superfences.fence_code_format
   - pymdownx.tasklist:
       custom_checkbox: true