security-alliance · mattaereal · May 7, 2026 · May 6, 2026
diff --git a/.markdownlint.json b/.markdownlint.json
@@ -42,7 +42,9 @@
       "DevOnly",
       "BadgeLegend",
       "ExportAllCerts",
-      "AttackSurfaceDashboard"
+      "AttackSurfaceDashboard",
+      "GovernanceSDLCPipeline",
+      "ChecklistItem"
     ]
   },
   "MD037": false,

diff --git a/docs/pages/certs/changelog.mdx b/docs/pages/certs/changelog.mdx
@@ -75,7 +75,8 @@ aggregates what changed, when, and why so protocols re-certifying after a revisi
 
 ### SFC - DNS Registrar (v1.0 → v1.1)
 
-- `dns-3.1.1` slimmed to reference SFC - Identity & Accounts for account management; DNS-specific registrar RBAC bullet retained.
+- `dns-3.1.1` slimmed to reference SFC - Identity & Accounts for account management;
+  DNS-specific registrar RBAC bullet retained.
 
 ### SFC - Incident Response (v1.0 → v1.1)
 

diff --git a/docs/pages/certs/sfc-dns-registrar.mdx b/docs/pages/certs/sfc-dns-registrar.mdx
@@ -193,7 +193,8 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, Cer
 
 *Revision {frontmatter.version} · Updated {frontmatter.revised} · [Changelog](/certs/changelog)*
 
-The SEAL Framework Checklist (SFC) for DNS Registrar provides best practices for securely managing domain names and DNS configurations.
+The SEAL Framework Checklist (SFC) for DNS Registrar provides best practices for securely managing
+domain names and DNS configurations.
 
 For more details on certifications or self-assessments, refer to the [Certification Guidelines](/certs/certification-guidelines).
 

diff --git a/docs/pages/config/contributors.json b/docs/pages/config/contributors.json
@@ -23,7 +23,7 @@
       { "name": "Issue-Opener-5", "assigned": "2024-08-22" },
       { "name": "Issue-Opener-10", "assigned": "2024-08-24" },
       { "name": "Issue-Opener-25", "assigned": "2024-09-25" },
-      { "name": "Active-Last-7d", "lastActive": "2026-04-23" }
+      { "name": "Active-Last-7d", "lastActive": "2026-05-05" }
     ]
   },
   "fredriksvantes": {
@@ -81,7 +81,8 @@
     "badges": [
       { "name": "Framework-Steward", "framework": "Community Management" },
       { "name": "First-Contribution", "assigned": "2025-01-29" },
-      { "name": "First-Review", "assigned": "2025-12-16" }
+      { "name": "First-Review", "assigned": "2025-12-16" },
+      { "name": "Active-Last-30d", "lastActive": "2026-04-07" }
     ]
   },
   "robert": {
@@ -155,7 +156,7 @@
       { "name": "Framework-Steward", "assigned": "2025-03-29", "framework": "ENS" },
       { "name": "First-Contribution", "assigned": "2025-05-29" },
       { "name": "First-Review", "assigned": "2025-08-09" },
-      { "name": "Dormant-90d+", "lastActive": "2025-08-11" }
+      { "name": "Active-Last-30d", "lastActive": "2026-04-23" }
     ]
   },
   "patrickalphac": {
@@ -184,7 +185,7 @@
     "twitter": "https://x.com/pinalikefruit",
     "website": null,
     "company": null,
-    "job_title": null,
+    "job_title": "Steward of the Wallet-Security framework",
     "role": "steward",
     "description": "Steward of Wallet-Security framework",
     "badges": [
@@ -231,7 +232,7 @@
       { "name": "First-Review", "assigned": "2025-08-11" },
       { "name": "Reviewer-10", "assigned": "2026-02-24" },
       { "name": "Reviewer-25", "assigned": "2024-03-01" },
-      { "name": "Active-Last-7d", "lastActive": "2026-04-20" }
+      { "name": "Active-Last-30d", "lastActive": "2026-04-20" }
     ]
   },
   "blackbigswan": {
@@ -337,7 +338,7 @@
     "description": "Founder & Engineer",
     "badges": [
       { "name": "First-Contribution", "assigned": "2025-06-02" },
-      { "name": "Active-Last-7d", "lastActive": "2026-04-21" }
+      { "name": "Active-Last-7d", "lastActive": "2026-05-05" }
     ]
   },
   "isaac": {
@@ -355,7 +356,7 @@
       { "name": "Framework-Steward", "assigned": "2025-12-17", "framework": "SEAL Certs" },
       { "name": "First-Contribution", "assigned": "2026-04-21" },
       { "name": "First-Review", "assigned": "2026-01-26" },
-      { "name": "Active-Last-7d", "lastActive": "2026-04-21" }
+      { "name": "Active-Last-30d", "lastActive": "2026-04-21" }
     ]
   },
   "geoffrey": {
@@ -448,7 +449,7 @@
       { "name": "First-Review", "assigned": "2025-08-12" },
       { "name": "Reviewer-10", "assigned": "2025-09-12" },
       { "name": "Reviewer-25", "assigned": "2026-03-20" },
-      { "name": "Active-Last-7d", "lastActive": "2026-04-23" }
+      { "name": "Active-Last-7d", "lastActive": "2026-05-06" }
     ]
   },
   "gunnim": {
@@ -667,8 +668,7 @@
     "description": "Steward of Monitoring framework",
     "badges": [
       { "name": "Framework-Steward", "assigned": "2026-03-17", "framework": "Monitoring" },
-      { "name": "First-Contribution", "assigned": "2026-03-16" },
-      { "name": "Active-Last-30d", "lastActive": "2026-04-16" }
+      { "name": "First-Contribution", "assigned": "2026-03-16" }
     ]
   },
   "tim-sha256": {
@@ -684,7 +684,7 @@
     "description": "Frameworks Contributor",
     "badges": [
       { "name": "First-Contribution", "assigned": "2026-04-05" },
-      { "name": "Active-Last-7d", "lastActive": "2026-04-21" }
+      { "name": "Active-Last-30d", "lastActive": "2026-04-21" }
     ]
   },
   "fvelazquez-x": {
@@ -733,8 +733,7 @@
     "description": "Frameworks Contributor",
     "badges": [
       { "name": "First-Contribution", "assigned": "2026-04-21" },
-      { "name": "New-Joiner", "lastActive": "2026-04-21" },
-      { "name": "Active-Last-7d", "lastActive": "2026-04-21" }
+      { "name": "Active-Last-30d", "lastActive": "2026-04-21" }
     ]
   },
   "welttowelt": {
@@ -750,8 +749,7 @@
     "description": "Frameworks Contributor",
     "badges": [
       { "name": "First-Contribution", "assigned": "2026-04-21" },
-      { "name": "New-Joiner", "lastActive": "2026-04-21" },
-      { "name": "Active-Last-7d", "lastActive": "2026-04-21" }
+      { "name": "Active-Last-30d", "lastActive": "2026-04-21" }
     ]
   },
   "iam0ti": {

diff --git a/docs/pages/devsecops/governance-proposal-security.mdx b/docs/pages/devsecops/governance-proposal-security.mdx
@@ -12,7 +12,7 @@
    users: [mattaereal]
 ---

 import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter, GovernanceSDLCPipeline, ChecklistItem } from '../../../components'

 <TagProvider>
 <TagFilter />
@@ -393,7 +393,8 @@
 Integration tests MUST exercise the exact deployment script that will run on mainnet — not a hand-written
 setup that looks equivalent. If `script/Deploy.s.sol` (or your equivalent) produces a different system state
 than your test harness parameterizes, then the suite that passed is testing a different system than the one
-that ships. That divergence is a well-documented source of false confidence and real security incidents where user funds have been stolen.
+that ships. That divergence is a well-documented source of false confidence and real security incidents
+where user funds have been stolen.
 Have the integration tests execute the deployment script itself, then run invariants and behavioral tests
 against the resulting state. The more complex the system, the more surface area exists for the script and
 the test to drift apart, so the more strictly this needs to be enforced.

diff --git a/docs/pages/devsecops/index.mdx b/docs/pages/devsecops/index.mdx
@@ -14,7 +14,8 @@ title: "Devsecops"
 - [DevSecOps](/devsecops/overview)
 - [Implementing Code Signing](/devsecops/code-signing)
 - [Securing CI/CD Pipelines](/devsecops/continuous-integration-continuous-deployment)
-- [Data Security & Contract Upgrade Checklist](/devsecops/data-security-upgrade-checklist)
+- [Data Security Checklist](/devsecops/data-security-upgrade-checklist)
+- [Governance Proposal Security Across the SDLC](/devsecops/governance-proposal-security)
 - [Securing Development Environments](/devsecops/integrated-development-environments)
 - [Repository Hardening](/devsecops/repository-hardening)
 - [Security Testing](/devsecops/security-testing)

diff --git a/docs/pages/dprk-it-workers/general-information.mdx b/docs/pages/dprk-it-workers/general-information.mdx
@@ -30,7 +30,8 @@ import { TagList, AttributionList, TagProvider, TagFilter, ContributeFooter } fr
     also unintentional actions like negligence (e.g. ignoring security updates) or accidents (e.g. sending sensitive
     document to the wrong email address) leading to security breaches and/or data leaks.
 2. DPRK IT workers are individuals from North Korea (the Democratic People's Republic of Korea) who engage in remote IT
-    work for foreign companies, often using false identities. Their work, while often appearing legitimate, is a source of
+    work for foreign companies, often using false identities. Their work, while often appearing
+    legitimate, is a source of
     revenue for the North Korean regime, may be involved in malicious activities, and constitutes a serious violation of
     international sanctions to send payments to North Korea. **"DPRK IT Workers" are synonymous with an "insider threat."**
 3. Read: [OFAC's North Korea Information Technology Workers

diff --git a/docs/pages/dprk-it-workers/mitigating-dprk-it-workers.mdx b/docs/pages/dprk-it-workers/mitigating-dprk-it-workers.mdx
@@ -37,7 +37,8 @@ limit the effects of a DPRK IT Worker infiltration and what you should do after
     all of your non-DPRK employees on these points, especially people responsible for hiring, developer relations, talent
     hunting, and community management.**
 2. Introduce a culture of background checks. Do not take a prospective developer's claims at face value. **Even the
-    most basic OSINT check can often discover deep inconsistencies. Check GitHub commit history, check Twitter history, and
+    most basic OSINT check can often discover deep inconsistencies. Check GitHub commit history,
+    check Twitter history, and
     Google the full name of the developer.**
      1. Is the work experience claimed in the CV reflected on GitHub?
      2. Does the potential employee indicate any physical presence anywhere?
@@ -97,7 +98,8 @@ limit the effects of a DPRK IT Worker infiltration and what you should do after
 1. Contact security professionals if you're unable to handle the situation alone. You can reach out to SEAL911
     (@seal_911_bot on Telegram).
 2. **You do not need to end the engagement abruptly. It's important to maintain a facade while you deal with access
-    revocation and mitigate any immediate risks to your organization.** Act normally, but start preparing an actionable plan
+    revocation and mitigate any immediate risks to your organization.** Act normally, but start
+    preparing an actionable plan
     immediately and aim to remove the DPRK IT Worker within the next few days at most. If your organization is properly
     siloed from insider threats, you shouldn't have much of an issue firing the worker almost immediately after
     conducting a post-mortem review.

diff --git a/docs/pages/dprk-it-workers/techniques-tactics-and-procedures.mdx b/docs/pages/dprk-it-workers/techniques-tactics-and-procedures.mdx
@@ -267,7 +267,8 @@ are used as cover. Incorporate unpredictable, interactive requests that a pre-re
         documentation along with poor language skills. **Run a background check on all the data.** Can you find a person
         with the same name whose identity was potentially stolen or borrowed? Is the address provided legitimate, or does
         it seem 'random' (e.g., an empty house, a business venue)? Google "(Full Name of your worker) + sentenced" to see
-        if the DPRK IT Worker bought a criminal's identity (an often-seen case with claimed US-based personas). Perform a
+        if the DPRK IT Worker bought a criminal's identity (an often-seen case with claimed US-based
+        personas). Perform a
         reverse image search on your worker's profile pictures/avatars. Are there more similar accounts using the exact
         same image? **Beware that DPRK IT Workers have no issues providing credible-looking KYC documentation; some of
         these documents even pass authentication checks on specialized services.**
@@ -277,7 +278,8 @@ are used as cover. Incorporate unpredictable, interactive requests that a pre-re
         entire company is composed of DPRK IT Workers if such tactics succeed).** Additionally, check if the potential
         DPRK IT Worker hasn't already added some of their 'friends' to your organization without your knowledge.
      8. **Proximity to other suspicious/spam accounts.** Don't be fooled by GitHub or Twitter accounts that are over
-        10 years old. DPRK IT Workers can easily source these. However, check if your worker has any meaningful history of
+        10 years old. DPRK IT Workers can easily source these. However, check if your worker has any
+        meaningful history of
         interaction with their followers/following. Or, do all accounts in proximity to your worker appear spam-like or
         like bots?
      9. **Poor social skills.** It's usually (but not always) the case that a DPRK IT Worker will have trouble with

diff --git a/docs/pages/front-end-web-app/third-party-script-security.mdx b/docs/pages/front-end-web-app/third-party-script-security.mdx
@@ -375,7 +375,8 @@ Beyond the core mechanisms above, consider these complementary measures:
   -> walkthrough on applying SRI to CDN-hosted assets
 - [MDN: Import Maps](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script/type/importmap)
   -> specification and usage guide
-- [MDN: Trusted Types](https://developer.mozilla.org/en-US/docs/Web/API/Trusted_Types_API) -> API reference and browser compatibility
+- [MDN: Trusted Types](https://developer.mozilla.org/en-US/docs/Web/API/Trusted_Types_API)
+  -> API reference and browser compatibility
 - [Google: Trusted Types Adoption Guide](https://web.dev/articles/trusted-types) -> step-by-step policy implementation guide
 
 ## Related Frameworks

diff --git a/docs/pages/intro/introduction.mdx b/docs/pages/intro/introduction.mdx
@@ -48,7 +48,8 @@ desire to foster a safer, more informed digital landscape. We do this by designi
 technologists, and coordinating on the social layer to ensure meaningful adoption.
 
 :::info[AI-friendly documentation]
-All framework content is available in LLM-friendly format following the [llms.txt](https://llmstxt.org/) standard - one file per framework, plus a routing index. See the [LLMs page](/intro/llms) for the full list.
+All framework content is available in LLM-friendly format following the [llms.txt](https://llmstxt.org/) standard -
+one file per framework, plus a routing index. See the [LLMs page](/intro/llms) for the full list.
 :::
 
 ---

diff --git a/docs/pages/intro/llms.mdx b/docs/pages/intro/llms.mdx
@@ -5,11 +5,16 @@ description: LLM-friendly documentation for the Security Alliance Frameworks, fo
 
 # LLMs
 
-The Security Alliance Frameworks documentation is available in LLM-friendly format following the [llms.txt](https://llmstxt.org/) standard. These files are generated at build time and designed to be fetched by AI assistants and coding tools to provide accurate, up-to-date framework content as context.
+The Security Alliance Frameworks documentation is available in LLM-friendly format following the
+[llms.txt](https://llmstxt.org/) standard. These files are generated at build time and designed to be
+fetched by AI assistants and coding tools to provide accurate, up-to-date framework content as context.
 
 ## How to use
 
-AI assistants should start with [`/llms.txt`](https://frameworks.securityalliance.org/llms.txt), the routing index. It lists every framework with a description and topic summary, so the AI can identify the best match and fetch the framework index file. From there, per-page files can be fetched for detailed content on a specific topic.
+AI assistants should start with [`/llms.txt`](https://frameworks.securityalliance.org/llms.txt), the routing
+index. It lists every framework with a description and topic summary, so the AI can identify the best match
+and fetch the framework index file. From there, per-page files can be fetched for detailed content on a
+specific topic.
 
 ## File structure
 
@@ -21,19 +26,24 @@ Three file types are available:
 /llms/{framework-name}/{page}.txt               per-page file —> full content of a single page
 ```
 
-The `{framework-name}` maps to the framework's folder name in the repository and `{page}` to the page's slug. For example, the Wallet Security seed phrase page lives at `docs/pages/wallet-security/seed-phrase-management.mdx` and its per-page file is at `/llms/wallet-security/seed-phrase-management.txt`.
+The `{framework-name}` maps to the framework's folder name in the repository and `{page}` to the page's slug.
+For example, the Wallet Security seed phrase page lives at `docs/pages/wallet-security/seed-phrase-management.mdx`
+and its per-page file is at `/llms/wallet-security/seed-phrase-management.txt`.
 
 ## What each file contains
 
 **`/llms.txt`** - routing index:
+
 - One entry per framework with its index file URL, description, and topic list
 
 **`/llms/{framework-name}.txt`** - framework index:
+
 - Header, description, and AI instructions
 - Full content of the overview page for immediate context
 - Links to all per-page files with one-line descriptions
 
 **`/llms/{framework-name}/{page}.txt`** - per-page file:
+
 - Full markdown content of that page
 - Source URL and framework attribution