From 28e7848bd5d07e902f80cc29c473a3a48d11290f Mon Sep 17 00:00:00 2001 From: Farhan Ashraf <53370109+farhanashrafdev@users.noreply.github.com> Date: Fri, 16 Oct 2026 16:16:44 +0500 Subject: [PATCH 1/9] docs(pre-commit): add Mermaid pre-commit workflow diagram Converts the pre-commit.png flow (working directory -> staging -> pre-commit hooks -> local repo -> remote repo, with the issue/no-issue loop) into a version-controlled Mermaid flowchart on the current-version Pre-commit page. Refs #89 Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> --- .../2-2-1-Pre-commit/2-2-1-1-Pre-commit.md | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/current-version/2-Process/2-2-Develop/2-2-1-Pre-commit/2-2-1-1-Pre-commit.md b/current-version/2-Process/2-2-Develop/2-2-1-Pre-commit/2-2-1-1-Pre-commit.md index 5e42510..014114c 100644 --- a/current-version/2-Process/2-2-Develop/2-2-1-Pre-commit/2-2-1-1-Pre-commit.md +++ b/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
Linting
..."] + 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,color:#fff + style HOOKS fill:#e0e0e0,stroke:#555,stroke-dasharray:4 3 + style LR fill:#aed581,stroke:#333 + style RR fill:#e8713a,stroke:#333,color:#fff +``` + ## 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. From 258777f14c22b2a57bdaaf37392cd3d4fb9e5c56 Mon Sep 17 00:00:00 2001 From: Farhan Ashraf <53370109+farhanashrafdev@users.noreply.github.com> Date: Fri, 16 Oct 2026 16:17:15 +0500 Subject: [PATCH 2/9] docs(sast): add Mermaid SAST scanning diagram Converts sast_scanning.png (scanner queries code for dangerous patterns, code yields potential vulnerabilities) into a Mermaid flowchart on the current-version SAST page. Refs #89 Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> --- .../2-3-1-1-Static-Application-Security-Testing.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/current-version/2-Process/2-3-Build/2-3-1-Static-Analysis/2-3-1-1-Static-Application-Security-Testing.md b/current-version/2-Process/2-3-Build/2-3-1-Static-Analysis/2-3-1-1-Static-Application-Security-Testing.md index 6e960ca..109b4c9 100644 --- a/current-version/2-Process/2-3-Build/2-3-1-Static-Analysis/2-3-1-1-Static-Application-Security-Testing.md +++ b/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
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: From 9b0ea14646d8220e89f395a2f33f230b84a2bb5d Mon Sep 17 00:00:00 2001 From: Farhan Ashraf <53370109+farhanashrafdev@users.noreply.github.com> Date: Fri, 16 Oct 2026 16:17:43 +0500 Subject: [PATCH 3/9] docs(dast): add Mermaid DAST scanning diagram Converts dast_scanning.png (scanner sends a SQL payload, target returns a SQL error) into a Mermaid sequence diagram on the current-version DAST page. Refs #89 Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> --- .../2-4-2-Dynamic-Application-Security-Testing.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/current-version/2-Process/2-4-Test/2-4-2-Dynamic-Application-Security-Testing.md b/current-version/2-Process/2-4-Test/2-4-2-Dynamic-Application-Security-Testing.md index cc28c51..af073f0 100644 --- a/current-version/2-Process/2-4-Test/2-4-2-Dynamic-Application-Security-Testing.md +++ b/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 confirms
an injection point +``` + ## What DAST finds - Injection flaws (SQL, command, XSS) observable in responses From a1078bfc933f6df3724b9e64309269422e46870c Mon Sep 17 00:00:00 2001 From: Farhan Ashraf <53370109+farhanashrafdev@users.noreply.github.com> Date: Fri, 16 Oct 2026 16:18:09 +0500 Subject: [PATCH 4/9] docs(iast): add Mermaid IAST analysis diagram Converts iast_analysis.png (external request -> target app -> in-process IAST agent -> IAST console) into a Mermaid flowchart on the current-version IAST page. Refs #89 Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> --- .../2-4-1-Interactive-Application-Security-Testing.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/current-version/2-Process/2-4-Test/2-4-1-Interactive-Application-Security-Testing.md b/current-version/2-Process/2-4-Test/2-4-1-Interactive-Application-Security-Testing.md index c4d44c8..daf8038 100644 --- a/current-version/2-Process/2-4-Test/2-4-1-Interactive-Application-Security-Testing.md +++ b/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
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. From 15ab07a0a7fb5c42e033d06b9ee17928a5f0ee88 Mon Sep 17 00:00:00 2001 From: Farhan Ashraf <53370109+farhanashrafdev@users.noreply.github.com> Date: Fri, 16 Oct 2026 16:19:05 +0500 Subject: [PATCH 5/9] docs(overview): add Mermaid secure pipeline diagram Converts Pipeline-view.png into a Mermaid flowchart on the current-version Overview page: application and infrastructure CI/CD pipelines, the gates between them, deployments to staging/production, continuous scanning of the registry and environments, and all findings flowing to central vulnerability management. Vendor logos are replaced by vendor-neutral stage names. Refs #89 Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> --- current-version/0-Intro/0-2-Overview.md | 57 +++++++++++++++++++++++++ 1 file changed, 57 insertions(+) diff --git a/current-version/0-Intro/0-2-Overview.md b/current-version/0-Intro/0-2-Overview.md index 7cea035..60d8201 100644 --- a/current-version/0-Intro/0-2-Overview.md +++ b/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
AppCode)] --> A1[Pipeline init] --> A2[Secret
scanning] --> A3[SAST] --> A4[SCA] --> A5[Container
scanning] + end + subgraph APPCD["CD"] + A6[Deploy
staging] --> A7[IAST] --> A8[DAST] -- No vulnerability --> A9[Deploy
prod] + end + A5 -- "No vulnerability:
push image" --> REG[(Container
registry)] -- Pull image --> A6 + end + + subgraph INFRA["Infrastructure pipeline"] + subgraph INFCI["CI"] + I0[(Git
InfraCode)] --> I1[Pipeline init] --> I2[Secret
scanning] --> I3[IaC
scanning] + end + subgraph INFCD["CD"] + I4[Deploy
staging] --> I5[Infra
scanning] -- No vulnerability --> I6[Deploy
prod] + end + I3 -- No issue --> I4 + end + + subgraph ENV["Environments"] + STG((Staging)) + PRD((Production)) + PRD --> RT[Runtime
security] + PRD --> CSI[Continuous
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
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 | From 9568848e6aaaa8df50b817239ba7c544b99f8313 Mon Sep 17 00:00:00 2001 From: Farhan Ashraf <53370109+farhanashrafdev@users.noreply.github.com> Date: Fri, 16 Oct 2026 16:52:02 +0500 Subject: [PATCH 6/9] docs(mkdocs): enable Mermaid rendering on the published site Register a mermaid custom fence in pymdownx.superfences so MkDocs Material renders the new diagram-as-code blocks instead of showing them as source. Verified with a local mkdocs build: all five pages render SVGs. Refs #89 Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> --- mkdocs.yml | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/mkdocs.yml b/mkdocs.yml index 7571591..57a945d 100644 --- a/mkdocs.yml +++ b/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 From 87da96253c3d565b5bfacd57758554f685251b48 Mon Sep 17 00:00:00 2001 From: Farhan Ashraf <53370109+farhanashrafdev@users.noreply.github.com> Date: Fri, 16 Oct 2026 16:52:02 +0500 Subject: [PATCH 7/9] docs(pre-commit): use dark labels on coloured nodes for contrast White text on the blue and orange nodes was below the 4.5:1 WCAG AA ratio; default dark text gives 6.4:1 and 6.9:1. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> --- .../2-2-Develop/2-2-1-Pre-commit/2-2-1-1-Pre-commit.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/current-version/2-Process/2-2-Develop/2-2-1-Pre-commit/2-2-1-1-Pre-commit.md b/current-version/2-Process/2-2-Develop/2-2-1-Pre-commit/2-2-1-1-Pre-commit.md index 014114c..27beee3 100644 --- a/current-version/2-Process/2-2-Develop/2-2-1-Pre-commit/2-2-1-1-Pre-commit.md +++ b/current-version/2-Process/2-2-Develop/2-2-1-Pre-commit/2-2-1-1-Pre-commit.md @@ -12,10 +12,10 @@ flowchart LR LR -- git push --> RR[Remote repo] style ST fill:#fff176,stroke:#333 - style PC fill:#4a90e2,stroke:#333,color:#fff + 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,color:#fff + style RR fill:#e8713a,stroke:#333 ``` ## What pre-commit hooks are From 5cca3bfce5ab669c0ad7a2a48932d9e86e8e064c Mon Sep 17 00:00:00 2001 From: Farhan Ashraf <53370109+farhanashrafdev@users.noreply.github.com> Date: Fri, 16 Oct 2026 16:52:02 +0500 Subject: [PATCH 8/9] docs(dast): describe SQL error as a possible, not confirmed, injection point A SQL error alone does not prove injection; the note now says it suggests an injection point that needs verification. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> --- .../2-4-Test/2-4-2-Dynamic-Application-Security-Testing.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/current-version/2-Process/2-4-Test/2-4-2-Dynamic-Application-Security-Testing.md b/current-version/2-Process/2-4-Test/2-4-2-Dynamic-Application-Security-Testing.md index af073f0..ba9cb35 100644 --- a/current-version/2-Process/2-4-Test/2-4-2-Dynamic-Application-Security-Testing.md +++ b/current-version/2-Process/2-4-Test/2-4-2-Dynamic-Application-Security-Testing.md @@ -8,7 +8,7 @@ sequenceDiagram 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 confirms
an injection point + Note over D: Error signature suggests a
possible injection point — verify ``` ## What DAST finds From 3463676e8f6c38afe1d236726855400d27e49606 Mon Sep 17 00:00:00 2001 From: Farhan Ashraf <53370109+farhanashrafdev@users.noreply.github.com> Date: Fri, 16 Oct 2026 16:53:51 +0500 Subject: [PATCH 9/9] chore(pre-commit): allow custom YAML tags in check-yaml mkdocs.yml now uses the !!python/name tag required by the pymdownx Mermaid superfence, which the default safe loader rejects. --unsafe still validates syntax but tolerates custom tags. Refs #89 Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> --- .pre-commit-config.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/.pre-commit-config.yaml b/.pre-commit-config.yaml index e4c2123..d12ede5 100644 --- a/.pre-commit-config.yaml +++ b/.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