Sécurité — Règles essentielles pour le développement

Règles de sécurité pour le développement d'applications de l'État, générées par la DINUM en s'appuyant sur le guide d'hygiène informatique ANSSI et des recommandations TLS.

Source : https://cyber.gouv.fr/reglementation/cybersecurite-systemes-dinformation/

Workflow d'audit

1. Analyser le projet (code source, configuration, infrastructure, CI/CD)
2. Parcourir les 12 domaines de la checklist détaillée dans [references/checklist.md](references/checklist.md)
3. Pour chaque règle, attribuer un statut :

- OK — Règle respectée - KO — Règle non respectée (identifier le problème et le risque) - NA — Non applicable (justifier) - Partiel — Partiellement respectée (préciser ce qui manque)

1. Qualifier l'exploitabilité de chaque KO : distinguer une faille exploitable (activable en l'état → chemin d'attaque réel) d'une bonne pratique manquante (défense en profondeur, sans exploitation directe). Cette qualification alimente la priorité.
2. Valider les non-conformités : avant de finaliser, re-vérifier chaque KO contre le code et la configuration réels. Écarter les faux positifs, ou requalifier le statut/l'exploitabilité si le constat ne tient pas. Ne conserver que les constats étayés par une preuve concrète (fichier, ligne, réglage).
3. Produire le rapport structuré selon le format défini dans [references/rapport.md](references/rapport.md)
4. Exporter le rapport : écrire le rapport dans un fichier Markdown ET l'afficher dans la conversation (règles d'export dans [references/rapport.md](references/rapport.md)). Une sortie structurée JSON optionnelle est disponible au format securite-developpement-AAAA-MM-JJ.json (schéma : [references/findings-schema.json](references/findings-schema.json)).

Références