chore(template): gouvernance/adaptation/feedback + sécurité (security-audit)
Some checks failed
CI - 4NK Node / Code Quality (push) Failing after 30s
CI - 4NK Node / Unit Tests (push) Failing after 29s
CI - 4NK Node / Integration Tests (push) Failing after 10s
CI - 4NK Node / Security Tests (push) Failing after 27s
CI - 4NK Node / Docker Build & Test (push) Failing after 8s
CI - 4NK Node / Documentation Tests (push) Failing after 4s
CI - 4NK Node / Security Audit (push) Successful in 3s
CI - 4NK Node / Release Guard (push) Has been skipped
CI - 4NK Node / Performance Tests (push) Failing after 27s
CI - 4NK Node / Notify (push) Failing after 2s

This commit is contained in:
Nicolas Cantu 2025-08-27 13:29:41 +02:00
parent 2e4feb03ca
commit e2dba09bbf
12 changed files with 187 additions and 15 deletions

View File

@ -0,0 +1,17 @@
---
alwaysApply: true
---
# Gouvernance du template 4NK
[portée]
Assurer que chaque projet adapte intelligemment le template et que les améliorations génériques reviennent dans `4NK_template`.
[directives]
- Conserver `security-audit` et `release-guard` dans tous projets.
- Adapter la CI, les docs et `AGENTS.md` au contexte local.
- En cas d'amélioration générique : ouvrir une issue "Template Feedback", prototyper, valider CI, mettre à jour `CHANGELOG.md`/`TEMPLATE_VERSION`.
[validation]
- Refuser un push/tag si l'adaptation a retiré les vérifications minimales (sécurité, tests, build, version/changelog/tag).
- Exiger une documentation claire dans `docs/TEMPLATE_ADAPTATION.md` et `docs/TEMPLATE_FEEDBACK.md`.

View File

@ -2,10 +2,10 @@
alwaysApply: true alwaysApply: true
--- ---
# Garde de release: tests, documentation, compilation, version, changelog, tag # Garde de release: tests, documentation, compilation, sécurité, version, changelog, tag
[portée] [portée]
Contrôler systématiquement avant push/tag: tests verts, docs mises à jour, build OK, alignement numéro de version ↔ changelog ↔ tag git, mise à jour de déploiement, confirmation utilisateur (latest vs wip). Contrôler systématiquement avant push/tag: tests verts, docs mises à jour, build OK, audit de sécurité OK, alignement numéro de version ↔ changelog ↔ tag git, mise à jour de déploiement, confirmation utilisateur (latest vs wip).
[objectifs] [objectifs]
@ -15,7 +15,7 @@ Contrôler systématiquement avant push/tag: tests verts, docs mises à jour, bu
[directives] [directives]
- Avant push/tag, exécuter: tests, compilation, lints (si configurés). - Avant push/tag, exécuter: tests, compilation, lints (si configurés), audit de sécurité (npm audit/cargo audit + scan secrets).
- Mettre à jour la documentation et le changelog en conséquence. - Mettre à jour la documentation et le changelog en conséquence.
- Aligner le fichier de version (VERSION ou TEMPLATE_VERSION), lentrée CHANGELOG et le tag. - Aligner le fichier de version (VERSION ou TEMPLATE_VERSION), lentrée CHANGELOG et le tag.
- Demander confirmation utilisateur: `latest` (release stable) ou `wip` (travail en cours). - Demander confirmation utilisateur: `latest` (release stable) ou `wip` (travail en cours).
@ -27,6 +27,7 @@ Contrôler systématiquement avant push/tag: tests verts, docs mises à jour, bu
- Refuser push/tag si: - Refuser push/tag si:
- tests/compilation échouent, - tests/compilation échouent,
- audit de sécurité échoue (vulnérabilités bloquantes ou secrets détectés),
- CHANGELOG non mis à jour, - CHANGELOG non mis à jour,
- VERSION/TEMPLATE_VERSION absent ou incohérent, - VERSION/TEMPLATE_VERSION absent ou incohérent,
- release type non fourni (ni latest, ni wip). - release type non fourni (ni latest, ni wip).
@ -34,4 +35,3 @@ Contrôler systématiquement avant push/tag: tests verts, docs mises à jour, bu
[artefacts concernés] [artefacts concernés]
- CHANGELOG.md, VERSION ou TEMPLATE_VERSION, docs/**, .gitea/workflows/**, scripts/**. - CHANGELOG.md, VERSION ou TEMPLATE_VERSION, docs/**, .gitea/workflows/**, scripts/**.

View File

@ -9,7 +9,8 @@
- 60-office-docs.mdc : lecture .docx via docx2txt + repli. - 60-office-docs.mdc : lecture .docx via docx2txt + repli.
- 70-frontend-architecture.mdc : React.lazy/Suspense, état global, couche de services. - 70-frontend-architecture.mdc : React.lazy/Suspense, état global, couche de services.
- 80-versioning-and-release.mdc : CHANGELOG, semver, confirmation push/tag. - 80-versioning-and-release.mdc : CHANGELOG, semver, confirmation push/tag.
- 85-release-guard.mdc : garde de release (tests/doc/build/version/changelog/tag; latest vs wip). - 85-release-guard.mdc : garde de release (tests/doc/build/sécurité/version/changelog/tag; latest vs wip).
- 05-template-governance.mdc : adaptation locale et feedback vers `4NK_template`.
- 90-gitea-and-oss.mdc : fichiers open source, .gitea, CI, Gitea remote. - 90-gitea-and-oss.mdc : fichiers open source, .gitea, CI, Gitea remote.
- 95-triage-and-problem-solving.mdc : boucle de diagnostic, REX, non-régression. - 95-triage-and-problem-solving.mdc : boucle de diagnostic, REX, non-régression.

View File

@ -268,11 +268,28 @@ jobs:
exit 1 exit 1
fi fi
security-audit:
name: Security Audit
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v3
- name: Ensure scripts executable
run: |
chmod +x scripts/security/audit.sh || true
- name: Run template security audit
run: |
if [ -f scripts/security/audit.sh ]; then
./scripts/security/audit.sh
else
echo "No security audit script (ok)"
fi
# Job de release guard (cohérence release) # Job de release guard (cohérence release)
release-guard: release-guard:
name: Release Guard name: Release Guard
runs-on: ubuntu-latest runs-on: ubuntu-latest
needs: [code-quality, unit-tests, documentation-tests] needs: [code-quality, unit-tests, documentation-tests, security-audit]
steps: steps:
- name: Checkout code - name: Checkout code
uses: actions/checkout@v3 uses: actions/checkout@v3

Binary file not shown.

View File

@ -206,6 +206,42 @@ Les règles opérationnelles détaillées sont précisées dans `.cursor/rules/`
--- ---
### Agent Sécurité (Responsable)
**Missions**
- Assurer une vigilance continue sécurité sur le code, la config et la CI.
- Orchestrer laudit de sécurité automatisé: `scripts/security/audit.sh` (cargo audit, npm audit, scan secrets).
- Interdire lintroduction de secrets en clair et exiger la rotation des secrets CI.
- Valider les permissions sensibles (clés, cookies, conf) et la non-exposition dendpoints privés.
- Bloquer toute release si laudit de sécurité échoue (intégré au `release-guard`).
**Artefacts**
- `scripts/security/audit.sh`, `.gitea/workflows/ci.yml` (job `security-audit`), `docs/SECURITY_AUDIT.md`, `docs/CONFIGURATION.md`.
---
### Agent Gouvernance du Template (Accountable)
**Missions**
- Garantir la cohérence densemble du template (règles Cursor, CI, scripts, docs).
- Examiner les issues « Template Feedback », arbitrer et prioriser.
- Orchestrer la montée de version du template (`TEMPLATE_VERSION`) et le `CHANGELOG.md`.
- Communiquer les changements aux projets consommateurs.
**Artefacts**
- `.cursor/rules/**`, `.gitea_template/**`, `docs/TEMPLATE_*`, `TEMPLATE_VERSION`, `CHANGELOG.md`.
---
### Agent Adaptation Projet (Responsable)
**Missions**
- Accompagner ladaptation locale du template (CI, docs, `AGENTS.md`).
- Sassurer que `security-audit` et `release-guard` ne sont pas retirés.
- Remonter en feedback toute amélioration générique.
**Artefacts**
- `.gitea/workflows/ci.yml`, `docs/INDEX.md`, `docs/SECURITY_AUDIT.md`, `AGENTS.md`, `LOCAL_OVERRIDES.yml` (si utilisé).
---
## Agents de synchronisation et dérogations ## Agents de synchronisation et dérogations
### Agent Synchronisation de template (Accountable) ### Agent Synchronisation de template (Accountable)

View File

@ -1,6 +1,6 @@
# 🚀 title # 4NK Project Template — Qualité, Sécurité et Open Source
desc Ce dépôt est le template de référence 4NK. Il formalise la démarche de qualité, de sécurité et dopen source applicable à tous les projets 4NK et fournit des supports initiaux (modèles CI/CD, règles Cursor, scripts, guides). Chaque projet doit ladapter à ses spécificités, et proposer des améliorations en retour (feedback) vers ce template.
## 📋 Table des Matières ## 📋 Table des Matières
@ -25,6 +25,9 @@ desc
### 📖 Guides Principaux ### 📖 Guides Principaux
- docs/TEMPLATE_ADAPTATION.md — Comment adapter ce template à votre projet
- docs/TEMPLATE_FEEDBACK.md — Comment proposer des améliorations au template
### 🔧 Guides Techniques ### 🔧 Guides Techniques
@ -107,6 +110,8 @@ desc
4. Push la branche (`git push origin feature/nouvelle-fonctionnalite`) 4. Push la branche (`git push origin feature/nouvelle-fonctionnalite`)
5. Créer une Pull Request 5. Créer une Pull Request
Pour les améliorations du template luimême (règles, CI, scripts), se référer à `docs/TEMPLATE_FEEDBACK.md` et utiliser le type dissue « Template Feedback ».
## 📄 Licence ## 📄 Licence
Ce projet est sous licence MIT. Voir le fichier LICENSE pour plus de détails. Ce projet est sous licence MIT. Voir le fichier LICENSE pour plus de détails.

View File

@ -11,6 +11,11 @@ Index complet de la documentation de l'infrastructure <PROJECT_NAME>.
### ⚙️ [Guide de Configuration](CONFIGURATION.md) ### ⚙️ [Guide de Configuration](CONFIGURATION.md)
### 🧭 [Adaptation du Template](TEMPLATE_ADAPTATION.md)
Comment adapter `4NK_template` à votre projet.
### 🔁 [Feedback vers le Template](TEMPLATE_FEEDBACK.md)
Processus pour remonter des améliorations génériques vers `4NK_template`.
## 🔧 Guides Techniques ## 🔧 Guides Techniques

View File

@ -5,7 +5,7 @@
**Date d'audit** : 19 décembre 2024 **Date d'audit** : 19 décembre 2024
**Auditeur** : Assistant IA **Auditeur** : Assistant IA
**Version du projet** : 1.0.0 **Version du projet** : 1.0.0
**Score de sécurité** : 85/100 ✅ **Score de sécurité** : à évaluer
## 📋 Éléments Audités ## 📋 Éléments Audités
@ -108,7 +108,7 @@ HOME=/home/bitcoin
## 🛡️ Recommandations de Sécurité ## 🛡️ Recommandations de Sécurité
### **Actions Immédiates** ### **Actions Immédiates (modèle)**
#### 1. **Permissions des Fichiers** #### 1. **Permissions des Fichiers**
```bash ```bash
@ -130,7 +130,7 @@ export BLINDBIT_API_KEY="your_api_key"
./tests/run_security_tests.sh ./tests/run_security_tests.sh
``` ```
### **Actions Recommandées** ### **Actions Recommandées (modèle)**
#### 1. **Chiffrement des Données** #### 1. **Chiffrement des Données**
- Chiffrer les cookies Bitcoin Core - Chiffrer les cookies Bitcoin Core
@ -160,22 +160,22 @@ export BLINDBIT_API_KEY="your_api_key"
| **Dépendances** | 80/100 | ✅ Dépendances sécurisées | | **Dépendances** | 80/100 | ✅ Dépendances sécurisées |
| **Documentation** | 85/100 | ✅ Bonnes pratiques documentées | | **Documentation** | 85/100 | ✅ Bonnes pratiques documentées |
### **Score Global : 85/100** ✅ ### **Score Global :** à établir
## 🚨 Plan d'Action ## 🚨 Plan d'Action
### **Phase 1 : Immédiat (1-2 jours)** ### **Phase 1 : Immédiat (1-2 jours) — modèle**
- [x] Audit de sécurité complet - [x] Audit de sécurité complet
- [x] Vérification des permissions - [x] Vérification des permissions
- [x] Nettoyage des fichiers GitHub - [x] Nettoyage des fichiers GitHub
- [ ] Tests de sécurité automatisés - [ ] Tests de sécurité automatisés
### **Phase 2 : Court terme (1 semaine)** ### **Phase 2 : Court terme (1 semaine) — modèle**
- [ ] Implémentation du chiffrement des cookies - [ ] Implémentation du chiffrement des cookies
- [ ] Ajout de certificats SSL/TLS - [ ] Ajout de certificats SSL/TLS
- [ ] Monitoring de sécurité - [ ] Monitoring de sécurité
### **Phase 3 : Moyen terme (1 mois)** ### **Phase 3 : Moyen terme (1 mois) — modèle**
- [ ] Authentification renforcée - [ ] Authentification renforcée
- [ ] Audit de sécurité automatisé - [ ] Audit de sécurité automatisé
- [ ] Formation sécurité équipe - [ ] Formation sécurité équipe

View File

@ -0,0 +1,34 @@
# Guide dadaptation du template 4NK
Ce document décrit comment adapter `4NK_template` à un projet concret.
## 1. Périmètre et langage
- Choisir les jobs CI pertinents (Rust/Node/Docker) et supprimer ceux non applicables.
- Conserver le job `security-audit` et le `release-guard`.
## 2. Sécurité
- Activer `scripts/security/audit.sh` (npm audit/cargo audit + scan secrets) et ajuster les seuils si nécessaire.
- Vérifier les permissions de fichiers sensibles et labsence de secrets en clair.
## 3. Versionnage & release
- Définir le fichier de version (`VERSION` ou `TEMPLATE_VERSION`).
- Tenir `CHANGELOG.md` comme source de vérité et intégrer au `release-guard`.
## 4. Documentation
- Adapter `docs/INDEX.md`, `INSTALLATION.md`, `USAGE.md`, `ARCHITECTURE.md` au contexte projet.
- Maintenir `docs/SECURITY_AUDIT.md` conforme à la réalité du dépôt.
## 5. Règles Cursor
- Conserver `.cursor/rules/*` puis affiner selon le langage et la structure du projet.
## 6. CI/CD (Gitea)
- Adapter `.gitea/workflows/ci.yml` (jobs, versions, caches) sans retirer `security-audit` ni `release-guard`.
- Ajouter des jobs spécifiques (e2e, perf) si nécessaire.
## 7. Gouvernance et open source
- Vérifier `LICENSE`, `CONTRIBUTING.md`, `CODE_OF_CONDUCT.md`, `OPEN_SOURCE_CHECKLIST.md`.
- Utiliser `AGENTS.md` pour clarifier les responsabilités.
## 8. Synchronisation avec le template
- Documenter toute divergence locale dans `LOCAL_OVERRIDES.yml` si utilisé.
- Proposer les améliorations génériques en feedback (voir `docs/TEMPLATE_FEEDBACK.md`).

22
docs/TEMPLATE_FEEDBACK.md Normal file
View File

@ -0,0 +1,22 @@
# Processus de feedback vers le template 4NK
Lobjectif est de canaliser les améliorations génériques découvertes dans les projets vers `4NK_template`.
## 1. Identifier une amélioration générique
- Règle Cursor utile à plusieurs dépôts
- Étape CI/CD généralisable
- Script ou guide documentaire réutilisable
## 2. Ouvrir une issue dédiée (Template Feedback)
- Décrire le contexte, limpact multiprojets et la proposition
- Joindre des diffs minimaux et des liens vers projets sources
## 3. Prototyper et valider
- Créer une branche sur `4NK_template`
- Ajouter les nouveaux artefacts (règles/scripts/docs)
- Valider via la CI (incluant `security-audit` et `release-guard`)
## 4. Finaliser et communiquer
- Mettre à jour `CHANGELOG.md` et `TEMPLATE_VERSION`
- Ajouter une note dans `docs/INDEX.md`
- Annoncer aux projets consommateurs (via issue/PR)

35
scripts/security/audit.sh Normal file
View File

@ -0,0 +1,35 @@
#!/usr/bin/env bash
set -euo pipefail
echo "[security-audit] démarrage"
ROOT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")"/../.. && pwd)"
cd "$ROOT_DIR"
rc=0
# 1) Audit Rust (si Cargo.toml présent et cargo disponible)
if command -v cargo >/dev/null 2>&1 && [ -f Cargo.toml ] || find . -maxdepth 2 -name Cargo.toml | grep -q . ; then
echo "[security-audit] cargo audit"
if ! cargo audit --deny warnings; then rc=1; fi || true
else
echo "[security-audit] pas de projet Rust (ok)"
fi
# 2) Audit npm (si package.json présent)
if [ -f package.json ]; then
echo "[security-audit] npm audit --audit-level=moderate"
if ! npm audit --audit-level=moderate; then rc=1; fi || true
else
echo "[security-audit] pas de package.json (ok)"
fi
# 3) Recherche de secrets grossiers
echo "[security-audit] scan secrets"
if grep -RIE "(?i)(api[_-]?key|secret|password|private[_-]?key)" --exclude-dir .git --exclude-dir node_modules --exclude-dir target --exclude "*.md" . >/dev/null 2>&1; then
echo "[security-audit] secrets potentiels détectés"; rc=1
else
echo "[security-audit] aucun secret évident"
fi
echo "[security-audit] terminé rc=$rc"
exit $rc