SomtechSolutionMAxime/vulnerability-scan

Vulnerability Scan

L'agent security-auditor exécute des scans périodiques pour identifier les vulnérabilités avant qu'elles ne soient exploitées en production. Un scan ne doit pas être un diagnostic ponctuel — c'est une surveillance continue qui capture l'état de santé sécurité du silo.

Calendrier de scan

| Type de scan | Fréquence | Fenêtre de temps | Rapport vers | |--------------|-----------|------------------|--------------| | Dépendances npm | Quotidienne | 02:00 UTC (off-peak) | Desk via security.dependency_check | | Secrets exposés | Quotidienne | 02:15 UTC (off-peak) | Desk via security.secret_scan | | Configuration Supabase | Hebdomadaire (lundi 03:00) | off-peak | Desk via security.supabase_check | | En-têtes HTTP & HTTPS | Hebdomadaire (mercredi 03:00) | off-peak | Desk via security.headers_check | | Scan complet | Mensuel (premier du mois 04:00) | off-peak | Récapitulatif consolidé |

Phase 1 : Dépendances npm

Détecter les packages avec des vulnérabilités connues (CVE).

Commandes

# Scan des dépendances — format JSON
npm audit --json > /tmp/npm-audit.json

# Alternative : vérifier aussi les dépendances directes des submodules
(cd frontend && npm audit --json) > /tmp/npm-audit-frontend.json
(cd backend && npm audit --json) > /tmp/npm-audit-backend.json

# Vérifier la version de npm (audit dépend de la version)
npm --version

Analyse du rapport

Extraire depuis le JSON :

{
  "audit_version": "npm audit version utilisée",
  "vulnerabilities": {
    "critical": [
      {
        "package": "lodash",
        "current_version": "4.17.19",
        "patched_version": "4.17.21",
        "vulnerability": "Prototype Pollution (CVE-2021-23337)",
        "severity": "critical",
        "affected_by_count": 3,
        "recommendation": "npm install [email protected] || update lodash in package.json"
      }
    ],
    "high": [...],
    "medium": [...],
    "low": [...]
  },
  "total_vulnerabilities": 5,
  "total_packages": 247,
  "audit_duration_ms": 1240
}

Seuils d'alerte

| Seuil | Action | Escalade | |-------|--------|----------| | 1+ vulnérabilités CRITICAL | Créer task P1 | Immédiate vers security-auditor | | 3+ vulnérabilités HIGH | Créer task P2 | Escalade de jour normal | | 10+ vulnérabilités MEDIUM | Créer task P3 | Escalade dans cycle normal | | 0 vulnérabilités | Log de confirmation | Aucune |

Template de rapport npm

{
  "task_type": "security.dependency_check",
  "from_agent": "security-auditor",
  "to_agent": "dev-orchestrator",
  "priority": "high",
  "payload": {
    "scan_timestamp": "2026-03-06T02:15:00Z",
    "scan_type": "npm_dependencies",
    "status": "vulnerable",
    "findings": [
      {
        "finding_id": "CVE-2021-23337",
        "package": "lodash",
        "current_version": "4.17.19",
        "patched_version": "4.17.21",
        "severity": "critical",
        "cvss_score": 9.1,
        "description": "Prototype Pollution in lodash - arbitrary code execution possible",
        "affected_components": ["frontend", "backend"],
        "remediation": "npm install [email protected]"
      }
    ],
    "summary": {
      "total_critical": 1,
      "total_high": 0,
      "total_medium": 2,
      "total_low": 3
    },
    "audit_trail_event": "security.scan"
  }
}

Phase 2 : Secrets exposés

Détecter les secrets (API keys, tokens, credentials) exposés dans le code.

Outils

# Scan avec truffleHog ou detect-secrets
npm install -g detect-secrets
detect-secrets scan --baseline .secrets.baseline

# Ou avec gitleaks (C++)
gitleaks detect --source . --verbose --report-path /tmp/gitleaks-report.json

# Ou avec trivy (scan containers et repos)
trivy config . --severity HIGH,CRITICAL

Types de secrets à détecter

| Pattern | Regex/Tool | Critère de match | |---------|-----------|-----------------| | AWS Keys | AKIA[0-9A-Z]{16} | Commence par AKIA, 16 alphanumérique | | Private Keys | -----BEGIN.*PRIVATE KEY----- | En-tête/pied-page standard | | Supabase Keys | sbp_.*[A-Za-z0-9] | Préfixe Supabase | | GitHub Tokens | ghp_[A-Za-z0-9_]{36} | Préfixe ghp_, 36 caractères | | API Keys génériques | api[_-]?key['\"]?\s*[:=]\s*['\"]?[A-Za-z0-9] | Pattern clé-valeur | | Mots de passe hardcodés | password['\"]?\s*[:=]\s*['\"][^'\"]{8,} | Mot "password" + valeur > 8 chars |

Exceptions autorisées

Certains patterns ressemblent à des secrets mais ne le sont pas (placeholders, exemples) :

# Ajouter au baseline
{
  "type": "Placeholder",
  "pattern": "AKIA0000000000000000",
  "location": "docs/examples.md",
  "reason": "Example AWS key for documentation"
}

Seuils d'alerte

| Seuil | Action | Escalade | |-------|--------|----------| | 1+ secrets réels exposés | P1 immédiate | Revoke immédiatement, log incident | | Pattern suspect (non confirmé comme secret) | P2 | Vérification manuelle par l'équipe | | 0 secrets | Log de confirmation | Aucune |

Template de rapport secrets

{
  "task_type": "security.secret_scan",
  "from_agent": "security-auditor",
  "to_agent": "dev-orchestrator",
  "priority": "critical",
  "payload": {
    "scan_timestamp": "2026-03-06T02:15:00Z",
    "scan_type": "secrets_in_code",
    "status": "finding_confirmed",
    "findings": [
      {
        "finding_id": "sec-secret-001",
        "type": "AWS_ACCESS_KEY",
        "file": "backend/config.js",
        "line": 42,
        "pattern_matched": "AKIA[0-9A-Z]{16}",
        "severity": "critical",
        "action_required": "Revoke AWS key, rotate credentials, check logs for unauthorized access",
        "exposed_since": "2 days (commit hash: a1b2c3d)"
      }
    ],
    "action_items": [
      "Revoke AWS key immediately",
      "Check AWS CloudTrail for unauthorized access",
      "Rotate all credentials in .env files",
      "Force-push cleanup commit (if repo is private)",
      "Notify AWS security team if key was used"
    ],
    "audit_trail_event": "security.finding"
  }
}

Phase 3 : Configuration Supabase

Auditer les policies RLS, paramètres de sécurité, et logs d'accès.

Checks automatisés

-- 1. Vérifier que toutes les tables user_data ont une policy RLS
SELECT table_name
FROM information_schema.tables
WHERE table_schema = 'public'
  AND table_name LIKE '%user%'
  AND NOT EXISTS (
    SELECT 1 FROM information_schema.role_based_access_control
    WHERE table_name = tables.table_name
  );

-- 2. Lister toutes les policies et vérifier qu'aucune n'est trop permissive
SELECT schemaname, tablename, policyname, permissive, qual
FROM pg_policies
WHERE schemaname = 'public';

-- 3. Vérifier les mots de passe par défaut dans auth
SELECT COUNT(*) FROM auth.users WHERE encrypted_password LIKE '%default%';

-- 4. Vérifier les API keys exposées dans la base
SELECT * FROM vault.secrets WHERE description LIKE '%exposed%' OR status = 'inactive';

Configuration RLS critique

| Check | Critère | Violation | Sévérité | |-------|---------|-----------|----------| | auth.uid() sur table user_data | Toute table avec user_id a une policy user_id = auth.uid() | Table trouvée sans policy | CRITICAL | | Pas de policies permissives par défaut | USING et WITH CHECK toujours définis | Policy sans USING ou WITH CHECK | HIGH | | Pas d'accès anonyme sur données sensibles | user_id/email/phone/ssn pas accessible aux rôles anon | Trouvé accessible | CRITICAL | | Enable RLS sur table | RLS activé sur ALTER TABLE ... ENABLE ROW LEVEL SECURITY | RLS désactivé trouvé | CRITICAL |

Template de rapport Supabase

{
  "task_type": "security.supabase_check",
  "from_agent": "security-auditor",
  "to_agent": "dev-orchestrator",
  "priority": "high",
  "payload": {
    "scan_timestamp": "2026-03-06T03:00:00Z",
    "scan_type": "supabase_config",
    "status": "finding_detected",
    "findings": [
      {
        "finding_id": "sec-rls-001",
        "table": "user_profiles",
        "check": "RLS Enabled",
        "result": "FAIL",
        "severity": "critical",
        "current_state": "RLS is disabled",
        "expected_state": "RLS must be enabled on all user tables",
        "remediation": "ALTER TABLE user_profiles ENABLE ROW LEVEL SECURITY;"
      },
      {
        "finding_id": "sec-rls-002",
        "table": "invoices",
        "check": "Policy audit_only",
        "result": "FAIL",
        "severity": "high",
        "current_state": "No read policy defined for role authenticated",
        "expected_state": "All tables must have explicit read policies",
        "remediation": "CREATE POLICY invoice_read ON invoices FOR SELECT USING (user_id = auth.uid());"
      }
    ],
    "summary": {
      "total_tables_scanned": 24,
      "tables_with_rls_enabled": 24,
      "tables_missing_policies": 1,
      "policy_violations": 2
    },
    "audit_trail_event": "security.scan"
  }
}

Phase 4 : En-têtes HTTP/HTTPS

Vérifier la configuration de sécurité des en-têtes de réponse HTTP.

Headers essentiels

| Header | Valeur attendue | Sévérité si absent | |--------|-----------------|-------------------| | Strict-Transport-Security | max-age=31536000; includeSubDomains; preload | HIGH | | X-Content-Type-Options | nosniff | MEDIUM | | X-Frame-Options | DENY ou SAMEORIGIN | MEDIUM | | X-XSS-Protection | 1; mode=block (deprecated, mais bon à avoir) | LOW | | Content-Security-Policy | Strict, avec nonce ou hash | HIGH | | Referrer-Policy | strict-origin-when-cross-origin | LOW | | Permissions-Policy | Restreindre géolocalisation, caméra, micro | MEDIUM |

Script de vérification

#!/bin/bash
# Vérifier les headers HTTPS

URL="https://aims.example.com"

for header in "Strict-Transport-Security" "X-Content-Type-Options" "X-Frame-Options" "Content-Security-Policy"; do
  curl -sI "$URL" | grep -i "^$header:" || echo "MISSING: $header"
done

Template de rapport headers

{
  "task_type": "security.headers_check",
  "from_agent": "security-auditor",
  "to_agent": "dev-orchestrator",
  "priority": "medium",
  "payload": {
    "scan_timestamp": "2026-03-06T03:00:00Z",
    "scan_type": "http_headers",
    "url_scanned": "https://aims.example.com",
    "status": "compliant_with_warnings",
    "findings": [
      {
        "finding_id": "sec-header-001",
        "header": "Strict-Transport-Security",
        "status": "present",
        "value": "max-age=31536000; includeSubDomains; preload",
        "severity": "ok"
      },
      {
        "finding_id": "sec-header-002",
        "header": "Content-Security-Policy",
        "status": "present",
        "value": "default-src 'self'; script-src 'self' 'nonce-abc123'; style-src 'self'",
        "severity": "ok"
      },
      {
        "finding_id": "sec-header-003",
        "header": "Permissions-Policy",
        "status": "missing",
        "recommended_value": "geolocation=(), microphone=(), camera=()",
        "severity": "medium"
      }
    ],
    "audit_trail_event": "security.scan"
  }
}

Phase 5 : Consolidation du rapport mensuel

À la fin du mois, l'agent consolide tous les scans précédents.

Metric de santé sécurité

{
  "month": "2026-03",
  "security_health_score": 87,
  "breakdown": {
    "dependencies": 95,
    "secrets": 100,
    "rls_policies": 92,
    "headers": 85,
    "overall": 87
  },
  "trend": "stable",
  "critical_findings": 0,
  "high_findings": 2,
  "remediation_pending": [
    {
      "finding_id": "sec-rls-002",
      "created": "2026-03-06",
      "days_open": 15,
      "target_resolution": "2026-03-13"
    }
  ]
}

Intégration avec audit-trail

Chaque scan génère un événement d'audit :

{
  "event_type": "security.scan",
  "resource_type": "silo_security",
  "resource_id": "security-auditor",
  "reason": "Periodic vulnerability scan — dependencies, secrets, RLS, headers",
  "decision_basis": "Scheduled weekly scan per security protocol",
  "meta": {
    "scan_type": "full_audit",
    "findings_count": 3,
    "critical_count": 0,
    "high_count": 2
  }
}

Intégration avec silo-logging

Chaque scan génère un log structuré pour monitoring :

{
  "timestamp": "2026-03-06T02:00:00Z",
  "log_level": "info",
  "log_type": "security_scan",
  "agent": "security-auditor",
  "action": "vulnerability_scan_started",
  "scan_type": "npm_dependencies",
  "meta": {
    "duration_ms": 2150,
    "packages_checked": 247,
    "vulnerabilities_found": 0,
    "status": "clean"
  }
}

Escalade automatique

Dès qu'un finding CRITICAL est détecté :

1. Créer une task Desk avec priority: "critical"
2. Envoyer vers dev-orchestrator via escalation.security_finding
3. Logger dans audit-trail avec trace_id
4. Notifier security-auditor pour suivi manuel
5. Ne pas attendre le prochain cycle — traiter immédiatement

{
  "task_type": "escalation.security_finding",
  "from_agent": "security-auditor",
  "to_agent": "dev-orchestrator",
  "priority": "critical",
  "payload": {
    "original_scan_type": "npm_dependencies",
    "finding_count": 1,
    "severity_levels": {
      "critical": 1,
      "high": 0,
      "medium": 0
    },
    "action_required": "Immediate remediation — update lodash to 4.17.21"
  }
}

Anti-patterns

• Ignorer les findings MEDIUM : Les vulnérabilités MEDIUM cumulent et créent des chaînes d'exploitation. Les auditer chaque mois.
• Faux positifs non documentés : Si une alerte est un faux positif, documenter dans le baseline avec raison. Ne pas juste ignorer.
• Scan manuel ad-hoc sans intégration : Tout scan doit créer une task Desk et un événement audit, sinon c'est du bruit.
• Pas de suivi des findings : Un finding ouvert depuis 30 jours sans remédiation est un problème de processus. Escalader vers management.
• Oublier les submodules : Si le repo contient des git submodules (dépendances privées), les scanner aussi — sinon les vulnérabilités y resteront cachées.