🧠 Mythos-like Models in Real Cyber Defense Workflows

Forces réalistes

• Lire rapidement beaucoup de documents techniques.
• Résumer un incident sous forme de timeline.
• Comparer un finding à des référentiels : CWE, OWASP, MITRE, NVD.
• Générer des hypothèses et demander les preuves manquantes.
• Proposer un patch défensif et des tests de non-régression.
• Adapter le langage au développeur, au SOC et au RSSI.

Finding scanner
                ↓
                Question IA utile :
                - Où est la preuve ?
                - Le composant est-il exposé ?
                - Qui peut l’atteindre ?
                - Quel actif métier est derrière ?
                - Patch ou mitigation ?
                - Comment valider ?

Interdits opérationnels

Dans un contexte professionnel, un modèle ne doit pas devenir un agent autonome qui agit sur la production. Il ne doit pas non plus recevoir des secrets bruts, des données clients non masquées ou un périmètre flou.

Maturité progressive

Maturité recommandée IDEO-LAB
                Résumé → Triage → PR patch → Validation staging → Reporting → Automatisation limitée

Pipeline de triage défensif

1. Importer SBOM, lock files, images containers et versions runtime.
2. Associer CVE aux composants réellement présents.
3. Vérifier exposition : endpoint public, interne, batch, admin.
4. Vérifier usage : import, code path, feature flag, service actif.
5. Croiser avec KEV, EPSS, advisories éditeurs.
6. Associer criticité métier : auth, paiement, PII, admin, prod.
7. Proposer action : patch, mitigation temporaire, monitoring, acceptation risque.

SBOM / requirements / package-lock
                ↓
                CVE matching
                ↓
                Runtime evidence
                ↓
                Exposure evidence
                ↓
                Threat intel
                ↓
                Business criticality
                ↓
                Remediation priority

Score contextualisé

contextual_priority =
                cvss_weight
                + epss_weight
                + kev_bonus
                + internet_exposure_bonus
                + auth_bypass_bonus
                + sensitive_data_bonus
                - mitigation_credit
                - non_reachable_credit

Le score doit rester explicable. Le but n’est pas d’inventer une formule magique, mais de rendre la priorisation transparente.

Exemple : application Django

Supposons un rapport indiquant une vulnérabilité dans une librairie d’upload ou de parsing. Le modèle doit éviter la conclusion automatique. Il doit demander : quelle vue utilise cette librairie ? L’endpoint est-il protégé ? Quelle taille de fichier est acceptée ? Où les fichiers sont-ils stockés ? Existe-t-il une validation MIME ?

Finding : librairie upload vulnérable
                ↓
                views.py : endpoint /documents/upload
                ↓
                Auth : user connecté seulement
                ↓
                Stockage : S3 privé
                ↓
                Validation : extension faible, MIME non vérifié
                ↓
                Priorité : haute
                ↓
                Actions : upgrade + validation MIME + limite taille + test

Prompt défensif utile

Tu es un analyste AppSec défensif. À partir des preuves fournies, trie ces CVE pour une application Django autorisée.

                Contraintes :
                - Ne propose aucune exploitation offensive.
                - Demande les preuves manquantes.
                - Priorise selon exposition réelle, usage du composant, KEV/EPSS, criticité métier.
                - Pour chaque finding : preuve, incertitude, action, test de validation.

                Entrées : SBOM, urls.py, views.py, settings, logs, rapport scanner.

Format de sortie attendu

Finding #1 — HIGH contextual risk
                Evidence:
                - Package X version Y in requirements.txt
                - Endpoint /upload uses module X
                - Endpoint reachable by authenticated users
                - No MIME verification found

                Why it matters:
                - Sensitive documents may be processed by vulnerable parser

                Recommended action:
                1. Upgrade X to fixed version
                2. Add server-side MIME verification
                3. Add file size limit
                4. Add regression test

                Uncertainty:
                - Need confirmation from production logs

Ce format permet au développeur d’agir, au RSSI de comprendre, et à l’auditeur de retracer la décision.

Revue Django ciblée

• Comparer urls.py et views.py pour identifier endpoints publics.
• Repérer les vues sans login_required ou permission checks.
• Inspecter les formulaires et serializers associés.
• Vérifier settings de sécurité : CSRF, session cookies, secure proxy SSL header.
• Repérer usages de mark_safe, safe, raw SQL, eval, subprocess.

Checklist Django AppSec
                [ ] DEBUG=False en prod
                [ ] ALLOWED_HOSTS explicite
                [ ] CSRF actif
                [ ] SESSION_COOKIE_SECURE=True
                [ ] CSRF_COOKIE_SECURE=True
                [ ] SECURE_SSL_REDIRECT selon proxy
                [ ] X_FRAME_OPTIONS configuré
                [ ] Pas de mark_safe non justifié
                [ ] Pas de raw SQL sans paramètres
                [ ] Permissions par objet si données sensibles

Auth, sessions et autorisation

Beaucoup de failles graves ne viennent pas d’un bug crypto mais d’une autorisation oubliée. Le modèle doit distinguer authentication (“qui es-tu ?”) et authorization (“as-tu droit à cette ressource ?”).

User authenticated
                ↓
                Access object /invoice/123
                ↓
                Question essentielle :
                invoice.owner == request.user ?

Templates, XSS et rendu

Django autoescape protège beaucoup, mais certaines pratiques contournent la protection : safe, mark_safe, inclusion de JSON dans script, attributs HTML construits dynamiquement.

À examiner :
                - 
                - mark_safe(...)
                - json_script absent pour données JS
                - href/src construits depuis données utilisateur
                - rich text HTML sans sanitizer

Patch sous forme de PR

Le modèle doit fournir une proposition minimale, lisible, testable. Pas un refactor massif. Chaque patch doit répondre à un finding précis.

Finding
                ↓
                Small patch
                ↓
                Unit test
                ↓
                Security regression test
                ↓
                PR description
                ↓
                Reviewer human approval

PR template
                Title: Security fix — enforce object-level permission on invoice view

                Why:
                - Endpoint allowed authenticated user to request arbitrary invoice id.

                What changed:
                - Query now filters by owner=request.user.
                - Added regression test for cross-user access.

                Validation:
                - pytest accounts/tests/test_invoice_access.py

Tests de sécurité

Timeline reconstruite

09:12 — Login from unusual ASN
                09:16 — MFA challenge accepted
                09:20 — Access key created
                09:24 — S3 ListBucket spike
                09:31 — GitHub secret scanning alert
                09:40 — First analyst ticket
                09:46 — Key disabled
                10:05 — Scope review started

La timeline est essentielle : elle permet de comprendre l’ordre causal, distinguer un faux positif d’une compromission, et mesurer la fenêtre d’exposition.

Hypothèses structurées

Actions de confinement

1. Désactiver la clé suspecte.
2. Forcer rotation credentials utilisateur.
3. Vérifier sessions actives et tokens.
4. Bloquer temporairement accès depuis ASN suspect si nécessaire.
5. Snapshot logs avant rétention.
6. Vérifier accès aux buckets sensibles.
7. Ouvrir ticket post-mortem et root cause.

Containment
                ↓
                Disable key
                ↓
                Preserve logs
                ↓
                Scope data access
                ↓
                Credential rotation
                ↓
                Hardening IAM
                ↓
                Lessons learned

Rapport incident

Incident summary
                Severity: High
                Status: Contained
                Initial vector: under investigation
                Assets affected: S3 buckets X/Y
                Data access: pending log review
                Actions taken: key disabled, sessions rotated
                Next steps: IAM hardening, GitHub secret controls, developer workstation review