Centre de securite

La securite d'une application web ne se resume pas a un bon mot de passe. Des ports peuvent etre exposes par erreur, des dependances peuvent contenir des failles, des certificats peuvent etre mal configures, des secrets peuvent se glisser dans le code source. Verifier tout cela manuellement serait fastidieux et sujet a l'oubli. Le centre de securite automatise cette surveillance en reunissant 19 outils d'analyse dans un tableau de bord unique, chacun specialise dans un aspect de la securite. Ensemble, ils constituent un "bilan de sante" complet de l'infrastructure, execute quotidiennement.

Chaque outil produit des findings (des observations de securite --- un port ouvert, une faille detectee, un header manquant). Ces findings sont classes par severite et dedupliques par empreinte SHA-256 (un meme probleme detecte deux fois n'apparait qu'une seule fois).

Page : /backoffice/security | Sidebar : Section "SECURITE" (rouge)

---

Architecture

Voici comment les 19 outils communiquent avec le centre de securite. Certains interrogent des API externes (Shodan, VirusTotal...), d'autres utilisent des containers Docker (ZAP, Nuclei...), d'autres encore analysent directement la base de donnees ou le code source :

                          APIS EXTERNES
  +---------+----------+----------+-----------+----------+-----------+----------+
  | Shodan  | Censys   | crt.sh   | VirusTotal|GreyNoise |AbuseIPDB  |  HIBP    |
  | api key | PAT/basic| gratuit  | api key   | api key  | api key   | api key  |
  +---------+----------+----------+-----------+----------+-----------+----------+
       |         |          |          |           |           |          |
  +----+----+----+-----+----+-----+----+------+----+-----+----+----+----+-----+
  |  ZAP   | Nuclei   | SSL Labs |Observatory|MXToolbox |  Trivy  | Gitleaks |
  | Docker  | Docker   | gratuit  | gratuit   | DNS local| Docker  | Docker   |
  +----+----+----+-----+----+-----+----+------+----+-----+----+----+----+-----+
       |         |          |          |           |         |         |
       |  npm audit (Docker exec)   Supabase (SQL RPC)               |
       |  CI Status (GitHub API)    Docker Ports (Docker API)        |
       |  Nuclei Templates (YAML)                                    |
       +------+------------------------------------------------------+
              |
    +---------+-----------------------------+
    | POST /api/admin/security/scan/[tool]  |
    | GET  /api/admin/security/scan/[tool]  |
    | - verifyAdminFromRequest()            |
    | - scan -> normalize -> save findings  |
    +---------+-----------------------------+
              |  credentials: "include" (HMAC admin cookie)
    +---------+-----------------------------+
    | SecurityCenterPanel.tsx               |
    | /backoffice/security                  |
    | Dashboard + 19 tool panels            |
    | useAutoRefresh polling 5min           |
    +--------------------------------------+

---

Navigation

Sidebar interne

La page utilise une navigation interne (sidebar gauche collapsible) qui organise les 19 outils par categorie, facilitant la recherche :

Section	Outils	Nombre
Dashboard	Vue globale (severity cards, grille outils, findings ouverts)	---
OSINT	Shodan, Censys, crt.sh, VirusTotal, GreyNoise, AbuseIPDB, HIBP	7
SCAN	OWASP ZAP, Nuclei, SSL Labs, Observatory, MXToolbox, Trivy, npm audit, Supabase Audit	8
SAST	Gitleaks	1
INFRA	CI Status, Docker Ports, Nuclei Templates	3

Responsive mobile/tablet

• Desktop (>=1024px) : sidebar visible a gauche, sticky, largeur fixe
• Tablet/Mobile (moins de 1024px) : sidebar en overlay absolute avec backdrop semi-transparent (clic en dehors = fermeture)
• Dashboard cards : 1 col (mobile) -> 2 cols (sm) -> 4 cols (md)
• Tool grid : 1 col (mobile) -> 2 cols (sm) -> 4 cols (md)

Dashboard

Le dashboard donne une vision d'ensemble avant de plonger dans le detail de chaque outil :

• 4 severity cards : Critical (rouge), High (orange), Medium (ambre), Low (bleu) --- comptent les findings ouverts par niveau de gravite
• Grille des outils : 19 cartes cliquables avec nom, icone, date du dernier scan, nombre de findings
• Findings ouverts : liste des problemes detectes non resolus avec filtres et actions en masse

---

Outils OSINT (7)

Les outils OSINT (Open Source Intelligence --- renseignement en sources ouvertes) permettent de voir BeePass "de l'exterieur", comme un attaquant le verrait. Ils interrogent des bases de donnees publiques pour decouvrir ce qui est visible depuis Internet : ports ouverts, sous-domaines, reputation du domaine et de l'IP. C'est un audit de l'exposition publique de l'infrastructure.

1. Shodan --- Exposition des ports

Shodan est un moteur de recherche specialise dans les appareils connectes a Internet. Il scanne en permanence les adresses IP du monde entier et repertorie les ports ouverts et les services qu'il detecte. L'utiliser sur notre IP permet de verifier qu'aucun port n'est expose par erreur (une base de donnees, un service de debug, etc.).

Element	Description
But	Decouvrir les ports ouverts et services exposes sur une IP publique
Input	Adresse IP (ex: 46.225.91.59)
API	GET api.shodan.io/shodan/host/{ip} (payant) ou fallback /dns/reverse + /shodan/host/count (free oss)
Cle API	SHODAN_API_KEY (plan free oss : fallback DNS reverse + port count ; plan payant : host details complets)
Timeout	30s
Resultats	Free-tier : ports (via facets), hostnames (DNS reverse). Payant : ports, services, versions, bannieres, organisation, ISP, CVE
Findings	Ports inattendus (hors 80/443/22) = severity medium, CVE detectes = severity high (payant uniquement)

Quand l'utiliser : Apres un changement d'infrastructure (nouveau service Docker, ouverture de port), pour verifier qu'aucun port n'est expose par erreur.

2. Censys --- Services et TLS

Censys est similaire a Shodan mais se concentre davantage sur les certificats et les versions TLS. Il est particulierement utile pour s'assurer que les anciennes versions de TLS (qui ont des failles connues) sont bien desactivees.

Element	Description
But	Inventorier les services et verifier les versions TLS sur une IP
Input	Adresse IP (auto-resolution DNS si domaine fourni)
API	GET api.platform.censys.io/v3/global/asset/host/{ip}
Cle API	CENSYS_API_ID (Personal Access Token Bearer, prefixe censys_, API v3)
Timeout	30s
Resultats	Services avec port, protocole, software, OS, localisation, ASN, DNS reverse
Findings	TLS deprecie (TLSv1.0, TLSv1.1, SSLv3) = severity high

Quand l'utiliser : Pour auditer les versions TLS et s'assurer que seuls TLS 1.2+ sont actifs.

3. crt.sh --- Transparence des certificats

Chaque fois qu'un certificat SSL est emis pour un domaine, il est enregistre dans des logs publics (les CT logs --- Certificate Transparency logs). crt.sh permet de consulter ces logs pour decouvrir tous les sous-domaines pour lesquels un certificat a ete emis. C'est utile pour detecter un ancien service oublie ou un sous-domaine cree a l'insu de l'equipe.

Element	Description
But	Decouvrir tous les sous-domaines via les logs de transparence des certificats
Input	Nom de domaine (ex: beepass.io)
API	GET crt.sh/?q=%25.{domain}&output=json
Cle API	Aucune (gratuit, illimite)
Timeout	20s
Resultats	Liste des sous-domaines avec date d'emission et emetteur du certificat
Findings	Sous-domaines inattendus (hors domaine principal, www, wildcard) = severity info

Quand l'utiliser : Pour verifier qu'aucun sous-domaine non autorise n'a ete certifie (shadow IT, ancien service oublie).

4. VirusTotal --- Reputation du domaine

VirusTotal agrege les resultats de dizaines de moteurs antivirus et de services de reputation. Si le domaine beepass.io est signale comme malveillant par un ou plusieurs moteurs, c'est un signal d'alerte : le site pourrait etre compromis, ou un faux positif a ete enregistre (dans ce cas, il faut le contester aupres du moteur concerne).

Element	Description
But	Verifier si le domaine est signale comme malveillant par les moteurs antivirus
Input	Nom de domaine
API	GET virustotal.com/api/v3/domains/{domain}
Cle API	VIRUSTOTAL_API_KEY (obligatoire, 500 req/jour gratuits)
Timeout	30s
Resultats	Score de reputation, statistiques d'analyse (malicious/suspicious/harmless), categories, registrar
Findings	Moteurs signalant le domaine comme malveillant = severity critical

Quand l'utiliser : Regulierement (hebdomadaire) pour s'assurer que le domaine n'est pas blackliste.

5. GreyNoise --- Reputation IP

GreyNoise observe le "bruit de fond" d'Internet : les scans automatiques, les bots, les tentatives d'attaque qui ciblent en masse toutes les IP. Si notre IP est classifiee comme "malicious" par GreyNoise, cela signifie qu'elle a ete observee en train d'envoyer du trafic suspect --- potentiellement signe d'un compromis.

Element	Description
But	Verifier si une IP est connue pour du bruit Internet (scans, bots, attaques)
Input	Adresse IP
API	GET api.greynoise.io/v3/community/{ip}
Cle API	GREYNOISE_API_KEY (optionnel, Community API gratuite)
Timeout	30s
Resultats	Classification (benign/malicious/unknown), noise status, RIOT flag, dernier vu
Findings	IP classifiee malveillante = severity high

GreyNoise Community API

L'API GreyNoise Community a un comportement specifique : HTTP 404 signifie "IP non observee" (resultat valide, pas une erreur), HTTP 429 signifie "rate limit" (25 requetes/semaine). Les deux cas sont geres comme des resultats normaux.

6. AbuseIPDB --- Reputation IP & signalements

AbuseIPDB est une base de donnees communautaire ou les administrateurs systeme du monde entier signalent les adresses IP qui les attaquent. Le score de confiance d'abus (0-100%) indique a quel point notre IP est signalee. Un score eleve signifie que notre serveur est percu comme source d'abus par d'autres administrateurs.

Element	Description
But	Verifier si une IP est signalee pour abus (spam, attaques, scans) par la communaute
Input	Adresse IP
API	GET api.abuseipdb.com/api/v2/check?ipAddress={ip}&maxAgeInDays=90&verbose
Cle API	ABUSEIPDB_API_KEY (Header Key, 1000 req/jour gratuits)
Timeout	30s
Resultats	Score de confiance abus (0-100%), nombre de signalements, utilisateurs distincts, ISP, pays, type d'usage
Findings	Score >=75% = severity critical, >=25% = high, >0% = medium, 0% = info

7. HIBP --- Fuites de donnees (Have I Been Pwned)

HIBP (Have I Been Pwned --- "ai-je ete pirate ?") verifie si des adresses email ou des domaines apparaissent dans des fuites de donnees connues. Si l'email admin de BeePass apparait dans une fuite qui contient des mots de passe, c'est un signal d'alerte critique : le mot de passe a peut-etre ete compromis et doit etre change immediatement.

Element	Description
But	Verifier si une adresse email ou un domaine apparait dans des fuites de donnees connues
Input	Adresse email (defaut: [email protected])
API (avec cle)	GET haveibeenpwned.com/api/v3/breachedaccount/{email}
API (free-tier)	GET haveibeenpwned.com/api/v3/breaches?domain={domain}
Cle API	HIBP_API_KEY ($3.50/mois, optionnel --- fallback free-tier sans cle)
Timeout	30s
Rate limit	Strict (1 req/1500ms). Retry automatique une fois apres 2s sur HTTP 429

Mapping de severite :

Contenu de la breach	Avec cle	Free-tier
Passwords	critical	high
Emails only	high	medium
Autre	medium	medium

---

Outils de scan (8)

Contrairement aux outils OSINT qui observent passivement, les outils de scan testent activement l'infrastructure : ils envoient des requetes, analysent les reponses, scannent les images Docker, verifient les configurations. C'est l'equivalent d'un test d'intrusion automatise.

8. OWASP ZAP --- Scanner de vulnerabilites web

ZAP (Zed Attack Proxy) est un scanner de vulnerabilites web maintenu par l'OWASP (la fondation de reference en securite applicative). Il explore le site comme un robot et teste chaque page pour des failles classiques : injections SQL, XSS (scripts malveillants), headers de securite manquants, etc.

Element	Description
But	Scanner une URL pour detecter les vulnerabilites web (XSS, CSRF, injections, headers manquants)
Input	URL cible (ex: https://beepass.io) + type de scan (spider / full)
Prerequis	Container Docker beepass-zap actif (daemon mode, port 8090)
Image	ghcr.io/zaproxy/zaproxy:stable
API	GET {ZAP_URL}/JSON/spider/action/scan/ (api.disablekey=true en Docker)
Timeout	60s (spider) / 120s (full scan actif)
Limites Docker	2 CPU, 2 Go RAM
Findings	Chaque alerte mappee sur severity high/medium/low/info

Types de scan :

• Spider (rapide, ~10s) : explore les liens du site et remonte les alertes passives (ce que ZAP detecte rien qu'en observant les reponses)
• Full (lent, ~2min) : spider + scan actif (teste activement les vulnerabilites en envoyant des payloads malveillants de test)

9. Nuclei --- Scanner de vulnerabilites avance

Nuclei est un scanner qui utilise des milliers de "templates" --- des fichiers YAML qui decrivent comment detecter une vulnerabilite specifique (un CVE, une mauvaise configuration, une page d'admin exposee). Il est complementaire a ZAP : la ou ZAP teste des categories generales de failles, Nuclei cible des vulnerabilites precises et connues.

Element	Description
But	Scanner une cible avec des milliers de templates de detection (CVE, misconfigs, expositions)
Input	URL cible + niveau de severite (critical, high, medium, low, info)
Image	projectdiscovery/nuclei:latest (containers ephemeres via Docker API)
Timeout	120s
Findings	Findings JSONL mappes directement depuis la sortie Nuclei

Fonctionnement : Nuclei ne tourne pas en daemon (en permanence). L'API cree des containers ephemeres a la demande via le Docker socket : pull image -> create container -> start -> wait -> read logs JSONL -> cleanup.

AutoRemove et logs Nuclei

Les containers Nuclei utilisent un cleanup explicite dans finally (stop + remove) au lieu de AutoRemove: true. Cela garantit que les logs peuvent etre lus avant la suppression du container --- sinon Docker supprime le container avant qu'on ait pu recuperer les resultats.

10. SSL Labs --- Audit SSL/TLS

SSL Labs (maintenu par Qualys) est la reference pour evaluer la configuration SSL/TLS d'un serveur. Il attribue une note de A+ (excellente) a F (critique) en verifiant les protocoles actifs, les suites de chiffrement, le certificat et les vulnerabilites connues (Heartbleed, POODLE, etc.).

Element	Description
But	Evaluer la configuration SSL/TLS d'un serveur (note A+ a F)
Input	Nom d'hote (ex: beepass.io)
API	GET api.ssllabs.com/api/v3/analyze?host=HOST&fromCache=on&maxAge=72
Cle API	Aucune (gratuit, rate limited)
Timeout	60s + polling
Cache	fromCache=on&maxAge=72 (reutilise un resultat des 72 dernieres heures si disponible)
Resultats	Note globale, certificat (sujet, emetteur, expiration), protocoles actifs, PFS, HSTS, vulnerabilites (Heartbleed, POODLE, FREAK, Logjam)
Findings	Note C/D/E = high, Note F/T = critical, protocoles deprecies = high

SSL Labs et surcharge (OVERLOADED)

L'API SSL Labs retourne un code 529 lorsqu'elle est surchargee (attente 15-30 minutes). Dans ce cas, l'outil retourne un statut OVERLOADED avec severite info au lieu d'echouer. Un retry automatique est effectue apres un delai de 5 secondes sur 529/429.

11. Observatory --- Headers de securite HTTP

Observatory (maintenu par Mozilla) evalue la qualite des headers de securite HTTP --- ces entetes invisibles que le serveur envoie avec chaque reponse et qui indiquent au navigateur comment se comporter (interdire l'integration dans une iframe, activer HSTS, definir une politique CSP, etc.).

Element	Description
But	Evaluer les headers de securite HTTP (CSP, HSTS, X-Frame-Options, etc.)
Input	Nom d'hote
API	POST observatory-api.mdn.mozilla.net/api/v2/scan?host=HOST
Cle API	Aucune (Mozilla, gratuit)
Timeout	30s
Resultats	Note (A+ a F), score /100, liste des tests passes/echoues avec impact
Findings	Score < 50 = high/medium, chaque header manquant = low/medium

12. MXToolbox --- Securite email (DNS)

Les emails sont un vecteur d'attaque majeur (phishing, usurpation d'identite). Trois mecanismes DNS protegent contre ces attaques : SPF (liste les serveurs autorises a envoyer des emails pour le domaine), DKIM (signature cryptographique des emails) et DMARC (politique de traitement des emails non conformes). MXToolbox verifie que ces trois protections sont en place.

Element	Description
But	Verifier les enregistrements DNS de securite email (SPF, DKIM, DMARC) + enregistrements MX
Input	Nom de domaine
API	Lookups DNS locaux via Node.js dns/promises (pas d'API externe)
Timeout	30s
Resultats	Statut SPF (valide/manquant), DKIM (selecteur trouve), DMARC (valide/manquant), serveurs MX
Findings	SPF manquant = high, DMARC manquant = high, DKIM non trouve = medium

Selecteurs DKIM verifies : brevo, google, default, selector1, selector2, k1

13. Trivy --- Scanner CVE images Docker

Chaque image Docker utilisee par BeePass contient un systeme d'exploitation et des bibliotheques qui peuvent avoir des failles de securite (CVE --- Common Vulnerabilities and Exposures). Trivy scanne ces images pour detecter les failles connues, comme un antivirus scannerait des fichiers.

Element	Description
But	Scanner les images Docker pour detecter les vulnerabilites connues (CVE)
Input	Nom de l'image Docker (ex: beepass-beepass-web)
Image	aquasec/trivy:latest (auto-pull via ensureImage())
Commande	image --format json --severity HIGH,CRITICAL {imageName}
Timeout	120s
Findings	Chaque CVE mappee : CRITICAL->critical, HIGH->high. Titre = CVE-ID in pkg@version

14. npm audit --- Vulnerabilites dependances

Equivalent de Trivy mais pour les dependances JavaScript (packages npm). Verifie si les bibliotheques utilisees par le frontend et les API ont des failles de securite connues.

Element	Description
But	Analyser les dependances npm pour detecter les vulnerabilites connues
Input	Nom du container Docker (ex: beepass-web)
Pattern	Docker exec dans un container actif (en cours d'execution)
Commande	npm audit --json --omit=dev
Timeout	60s
Mapping	npm critical->critical, high->high, moderate->medium, low->low

15. Supabase Audit --- Securite base de donnees

La base de donnees contient les donnees les plus sensibles de BeePass (profils, sessions, evaluations). Cet outil audite la configuration de securite de Supabase : les tables sont-elles protegees par RLS (Row Level Security --- le mecanisme qui garantit qu'un utilisateur ne peut voir que ses propres donnees) ? Des fonctions s'executent-elles avec des privileges trop eleves ? Des extensions dangereuses sont-elles installees ?

Element	Description
But	Auditer la securite de la base de donnees Supabase : couverture RLS, fonctions SECURITY DEFINER, extensions, grants anon/public, tables sensibles
Input	Aucun (audit automatique via SUPABASE_SERVICE_ROLE_KEY)
Pattern	SQL RPC audit_supabase_security() (SECURITY DEFINER, SET search_path = '')
Prerequis	Migration 20260308150000_audit_supabase_security.sql appliquee
Timeout	30s

7 verifications effectuees :

Verification	Description	Severite si echoue
Couverture RLS	Tables du schema public sans RLS active (donnees potentiellement accessibles a tous)	Critical
Policies permissives	Policies RLS avec USING (true) ou WITH CHECK (true) (RLS active mais qui autorise tout)	Low
Fonctions SECURITY DEFINER	Fonctions en SECURITY DEFINER dans le schema public (s'executent avec les droits du createur, pas de l'appelant)	Medium
Extensions dangereuses	Extensions installees (dblink, postgres_fdw, adminpack, file_fdw) qui permettent des acces externes	High
Tables sensibles	Tables avec colonnes password/secret/token/api_key sans RLS	Critical
Grants anon/public	Permissions INSERT/UPDATE/DELETE sur le role anon (un utilisateur non authentifie pourrait modifier des donnees)	High
Tables RLS sans policy	Tables avec RLS active mais aucune policy definie (RLS active = tout bloque, ce qui peut casser des fonctionnalites)	Medium

Pas de container Docker : Contrairement aux autres outils, Supabase Audit execute des requetes SQL directement via le client adminSupabase (service_role).

---

Outil SAST (1)

SAST signifie Static Application Security Testing --- l'analyse du code source sans l'executer. L'objectif est de detecter les problemes dans le code lui-meme, avant qu'il ne soit deploye.

16. Gitleaks --- Detection de secrets dans le code

Le risque numero un en securite du code : commiter accidentellement une cle API, un mot de passe ou un token dans le depot Git. Meme si le fichier est ensuite supprime, l'historique Git conserve tout. Gitleaks scanne le code source pour detecter ces secrets avant qu'ils ne posent probleme.

Element	Description
But	Scanner le depot Git pour detecter les secrets (cles API, tokens, mots de passe)
Input	Chemin du depot (defaut: /opt/beepass)
Image	ghcr.io/gitleaks/gitleaks:latest (auto-pull via ensureImage())
Flag	--no-git (scan working tree uniquement, pas l'historique --- plus rapide)
Timeout	120s

Mapping de severite :

Type de secret	Severite
secret, private_key, password	critical
token, key, api	high
Autre	medium

---

Outils Infrastructure (3)

Ces outils verifient que l'infrastructure elle-meme est correctement configuree : les pipelines CI/CD sont-ils en place ? Des ports sont-ils exposes par erreur ? Les templates de scan custom sont-ils a jour ?

17. CI Status --- Pipeline CI/CD GitHub Actions

La CI/CD (Continuous Integration / Continuous Deployment) est un ensemble de workflows automatiques qui verifient le code a chaque push sur GitHub. Cet outil verifie que les 7 workflows de securite attendus sont presents et fonctionnent correctement --- si un workflow est manquant, des verifications de securite pourraient etre silencieusement ignorees.

Element	Description
But	Verifier que tous les workflows de securite CI sont presents et passent au vert
API	GET api.github.com/repos/{owner}/{repo}/actions/runs
Cle API	GITHUB_TOKEN (optionnel --- fallback verification locale des fichiers workflows)
Timeout	30s
Mode avec token	Appel API GitHub Actions, retourne statut de chaque workflow (success/failure/pending)
Mode sans token	Lecture des fichiers .github/workflows/*.yml, verifie la presence des 7 workflows attendus
Findings	Workflow manquant = high, workflow en echec = medium, tous OK = info

7 workflows attendus :

Workflow	Fichier	Trigger
Gitleaks	security-gitleaks.yml	push/PR main
npm audit	security-npm-audit.yml	push/PR main (package-lock.json)
Trivy	security-trivy.yml	push/PR main (Dockerfile)
Headers	security-headers.yml	push/PR main (next.config.mjs, docker-compose.yml, traefik)
Port Audit	security-port-audit.yml	push/PR main (docker-compose.yml)
RLS Check	security-rls-check.yml	push/PR main (supabase/migrations)
Deps Review	security-deps-review.yml	PR main

18. Docker Ports --- Audit des ports exposes

Seuls les ports 80 (HTTP) et 443 (HTTPS) doivent etre accessibles depuis Internet. Si un autre port est mappe sur l'hote (par exemple le port 5432 de PostgreSQL), c'est une faille de securite potentiellement critique. Cet outil verifie automatiquement qu'aucun port inattendu n'est expose.

Element	Description
But	Verifier que seuls les ports attendus (80, 443) sont mappes sur l'hote
Input	Aucun (audit automatique de tous les containers running)
Pattern	Docker API GET /containers/json + GET /containers/{id}/json (inspect)
Prerequis	Docker socket accessible
Timeout	30s
Findings	Port host-mapped != 80/443 = severity high

19. Nuclei Templates --- Inventaire des templates custom

En plus des milliers de templates de la communaute Nuclei, BeePass utilise des templates custom ecrits specifiquement pour verifier des points de securite propres a l'application. Cet outil inventorie ces templates et verifie qu'ils sont bien configures.

Element	Description
But	Lister et verifier les templates Nuclei custom BeePass
Input	Aucun (lecture automatique du repertoire infra/nuclei-templates/)
Timeout	10s
Resultats	Liste des templates avec metadata : id, nom, severite, tags, description

2 templates disponibles :

Template	Fichier	Description
Auth Endpoints	beepass-auth-endpoints.yaml	Verifie que les endpoints admin retournent 401/400 sans auth (pas d'acces sans authentification)
Security Headers	beepass-security-headers.yaml	Verifie la presence de tous les headers de securite HTTP

---

Tableau recapitulatif des 19 outils

#	Outil	Categorie	API/Methode	Cle API	Timeout	Docker
1	Shodan	OSINT	REST API	Oui (free-tier fallback)	30s	Non
2	Censys	OSINT	REST API v3	PAT Bearer	30s	Non
3	crt.sh	OSINT	REST API	Aucune	20s	Non
4	VirusTotal	OSINT	REST API v3	Oui	30s	Non
5	GreyNoise	OSINT	REST API v3	Optionnel	30s	Non
6	AbuseIPDB	OSINT	REST API v2	Oui	30s	Non
7	HIBP	OSINT	REST API v3	Optionnel (free-tier)	30s	Non
8	OWASP ZAP	SCAN	Docker daemon API	Non (api.disablekey)	60-120s	beepass-zap
9	Nuclei	SCAN	Docker ephemere	Non	120s	Ephemere
10	SSL Labs	SCAN	REST API v3	Aucune	60s+poll	Non
11	Observatory	SCAN	REST API v2	Aucune	30s	Non
12	MXToolbox	SCAN	DNS local (Node.js)	Aucune	30s	Non
13	Trivy	SCAN	Docker ephemere	Non	120s	Ephemere
14	npm audit	SCAN	Docker exec	Non	60s	Exec
15	Supabase	SCAN	SQL RPC	service_role	30s	Non
16	Gitleaks	SAST	Docker ephemere	Non	120s	Ephemere
17	CI Status	INFRA	GitHub API	Optionnel	30s	Non
18	Docker Ports	INFRA	Docker socket	Non	30s	Socket
19	Nuclei Templates	INFRA	Filesystem	Non	10s	Non

---

Findings

Les findings sont le coeur du centre de securite. Chaque observation de securite --- qu'il s'agisse d'un port ouvert, d'un header manquant ou d'une faille dans une dependance --- est normalisee dans un format commun pour faciliter le tri, le suivi et la resolution.

Structure d'un finding

Champ	Description
Severite	critical (faille exploitable, action immediate), high (risque eleve), medium (a corriger), low (amelioration) ou info (observation)
Outil source	Nom de l'outil ayant detecte le finding
Titre	Description courte du finding
Description	Explication detaillee de la vulnerabilite ou du risque
Remediation	Instructions pour corriger le probleme
Fingerprint	SHA-256 de tool + title + affected_url pour la deduplication (empeche les doublons)
Composant	URL ou composant affecte
Premiere detection	Date a laquelle le finding a ete vu pour la premiere fois
Derniere detection	Date du dernier scan ayant confirme le finding

Statuts des findings

Le cycle de vie d'un finding suit ces etapes :

Statut	Description
open	Finding actif necessitant une action --- c'est l'etat par defaut a la detection
acknowledged	Finding reconnu --- l'equipe est informee mais la correction est differee (ex : il faut attendre une mise a jour de dependance)
false_positive	Faux positif confirme --- exclu des metriques de securite (l'outil a detecte un probleme qui n'en est pas un)
resolved	Finding corrige et verifie lors d'un scan ulterieur

Deduplication

Les findings sont dedupliques par fingerprint SHA256 : createHash('sha256').update(tool + ':' + title + ':' + (affected_url || '')).digest('hex'). Un meme finding ne sera pas cree en double meme si le scan est relance --- seule la date de derniere detection est mise a jour.

Index UNIQUE partiel : idx_security_findings_fingerprint ON fingerprint WHERE status != 'resolved' --- un finding resolu peut etre redetecte (nouvel enregistrement), ce qui permet de tracer les regressions.

Filtres

Les findings peuvent etre filtres par :

• Severite --- afficher uniquement les critical et high pour le triage prioritaire
• Outil --- isoler les resultats d'un scanner specifique
• Statut --- voir uniquement les findings open ou les false_positive

Actions en masse

Pour traiter efficacement un grand nombre de findings (apres un premier audit, par exemple), des actions en masse sont disponibles :

Action	Description
Acknowledge	Marquer plusieurs findings comme reconnus en une seule operation
Marquer faux positif	Declarer plusieurs findings comme faux positifs
Changer le statut	PATCH individuel via /api/admin/security/scan/findings

Faux positifs connus

Le fichier audit-scheduler.ts contient une liste de 7 faux positifs connus (KNOWN_FALSE_POSITIVES) automatiquement marques lors de chaque scan. Ces entries correspondent a des detections recurrentes qui ont ete analysees et confirmees comme non pertinentes pour l'environnement BeePass (par exemple, un header que Cloudflare ajoute et que l'outil de scan ne reconnait pas).

Gestion des faux positifs

Lorsqu'un finding est marque comme faux positif, il est exclu du calcul du score de securite et de la note globale. Documentez systematiquement la raison du classement en faux positif pour faciliter les audits de conformite --- un auditeur externe voudra savoir pourquoi ce finding a ete ecarte.

---

Cron automatique

Pour que la surveillance soit efficace, elle doit etre continue et automatique. Le cron (tache planifiee) execute les 19 outils chaque nuit, et un scan supplementaire est lance apres chaque deploiement pour verifier que les changements n'ont pas introduit de nouvelles vulnerabilites :

Declencheur	Horaire	Description
Cron quotidien	03:30 UTC	Execution des 19 outils de scan
Post-deploiement	Apres chaque deploy.sh	Audit declenche automatiquement via ?trigger=post_deploy

Authentification du cron

L'endpoint /api/cron/security-audit est protege par un Bearer token (CRON_SECRET). La verification utilise timingSafeEqual (comparaison a temps constant) pour prevenir les attaques par timing --- une technique ou un attaquant mesure le temps de reponse pour deviner le token caractere par caractere.

# Declenchement manuel
curl -sf -H "Authorization: Bearer ${CRON_SECRET}" \
  "http://localhost:3000/api/cron/security-audit?trigger=cron"

# Crontab serveur
30 3 * * * /opt/beepass/scripts/cron-security.sh >> /var/log/beepass-cron.log 2>&1

Score de securite

Apres chaque scan, un score global de 0 a 100 est calcule en fonction du nombre et de la severite des findings ouverts. Ce score donne une vision synthetique de la posture de securite, comparable d'un jour a l'autre :

Note	Score	Interpretation
A	90-100	Excellent --- aucune vulnerabilite critique ou haute
B	75-89	Bon --- quelques findings medium/low a traiter
C	60-74	Acceptable --- findings high presents, action recommandee
D	45-59	Insuffisant --- vulnerabilites significatives a corriger
E	25-44	Mauvais --- vulnerabilites multiples
F	0-24	Critique --- intervention immediate requise

Timeouts des outils

Chaque outil dispose d'un timeout specifique (10s a 120s). Si un outil ne repond pas dans le delai imparti, le scan de cet outil est marque en erreur sans bloquer les autres --- les 18 restants continuent normalement. Verifiez regulierement que tous les outils completent leur scan avec succes.

---

Cles API --- Configuration

Certains outils necessitent une cle API pour fonctionner. Si une cle est absente, l'outil affiche un message explicite ("XXX_API_KEY not configured") au lieu de planter --- il est simplement desactive.

Les cles sont dans .env.local (dev) et les env vars Docker beepass-web (prod) :

Variable	Service	Gratuit	Obligatoire
SHODAN_API_KEY	Shodan	Free-tier: DNS+port count	Non
VIRUSTOTAL_API_KEY	VirusTotal	500/jour	Non
GREYNOISE_API_KEY	GreyNoise	Community illimite	Non
CENSYS_API_ID	Censys	PAT Bearer, API v3	Non
ABUSEIPDB_API_KEY	AbuseIPDB	1000/jour	Non
HIBP_API_KEY	HIBP	Payant ($3.50/mois) ou free-tier	Non
ZAP_URL	ZAP	N/A	Non (defaut: http://beepass-zap:8090)
GITHUB_TOKEN	GitHub	PAT optionnel	Non (fallback local)
GITHUB_REPOSITORY	GitHub	Auto-detecte	Non
CRON_SECRET	Cron audit	N/A	Oui (prod)

Outils sans cle : crt.sh, SSL Labs, Observatory, MXToolbox, Nuclei, Trivy, npm audit, Gitleaks, Supabase Audit, Docker Ports, Nuclei Templates.

---

Infrastructure Docker Security Center

ZAP (daemon)

ZAP tourne en permanence en mode daemon (service d'arriere-plan), pret a recevoir des requetes de scan. Il n'est accessible que depuis le reseau Docker interne, d'ou la desactivation de la cle API :

beepass-zap:
  image: ghcr.io/zaproxy/zaproxy:stable
  command: zap.sh -daemon -host 0.0.0.0 -port 8090
  # api.disablekey=true : pas de cle API necessaire (reseau Docker interne)
  restart: unless-stopped
  deploy:
    resources:
      limits: { cpus: '2', memory: 2G }

Nuclei (on-demand)

Nuclei ne tourne pas en permanence. Son image est simplement pre-cachee sur le serveur pour eviter un telechargement lors du premier scan :

beepass-nuclei:
  image: projectdiscovery/nuclei:latest
  profiles: [security]    # Image pre-cachee, ne tourne pas

Les scans Nuclei sont executes via des containers ephemeres crees par l'API Docker socket.

---

Workflow recommande

Audit initial (premiere utilisation)

Lors de la premiere utilisation du centre de securite, lancez les outils dans cet ordre pour couvrir progressivement tous les aspects de la securite :

1. MXToolbox --- Verifier SPF/DKIM/DMARC (securite email)
2. SSL Labs --- Verifier la note SSL (objectif A+)
3. Observatory --- Verifier les headers de securite (objectif >= 75/100)
4. crt.sh --- Inventorier les sous-domaines
5. Shodan --- Verifier les ports exposes
6. VirusTotal --- Verifier la reputation du domaine
7. ZAP spider --- Scan rapide des vulnerabilites web
8. Trivy --- Scanner les images Docker
9. npm audit --- Verifier les dependances
10. Gitleaks --- Scanner le code pour les secrets
11. Supabase Audit --- Verifier la couverture RLS
12. CI Status --- Verifier les workflows CI
13. Docker Ports --- Verifier les ports exposes

Audit periodique (hebdomadaire)

Ces trois outils suffisent pour une surveillance reguliere entre les audits complets :

1. VirusTotal --- Reputation domaine (detecter un blacklisting)
2. GreyNoise --- Reputation IP serveur (detecter une compromission)
3. ZAP spider --- Vulnerabilites web (detecter de nouvelles failles)

Apres un deploiement

L'audit post-deploy est declenche automatiquement par deploy.sh. En complement, verifiez manuellement si le deploiement touche un domaine specifique :

1. ZAP spider --- Verifier les nouvelles pages
2. SSL Labs --- Si changement de certificat
3. Supabase Audit --- Si migration SQL appliquee
4. Docker Ports --- Si changement docker-compose.yml

Audit approfondi (mensuel)

Tous les 19 outils + revue des findings ouverts (trier, resoudre ou marquer false positive). C'est aussi le moment de revoir les faux positifs pour s'assurer qu'ils sont toujours pertinents.

---

Base de donnees

Tables

Table	Description
security_findings	Findings normalises avec fingerprint, severite, statut, raw_data JSONB (les donnees brutes de chaque outil)
security_scan_history	Historique des scans avec duree, nombre de findings, statut

Index

• idx_security_findings_fingerprint (UNIQUE partiel WHERE status != 'resolved')
• idx_security_findings_tool
• idx_security_findings_severity
• idx_security_findings_status
• idx_security_scan_history_tool

RLS

RLS active sur les 2 tables, aucune policy utilisateur --- acces exclusif via adminSupabase (service_role). Les donnees de securite ne sont accessibles qu'aux administrateurs.

---

Voir aussi : Rapports de securite | VPN WireGuard | Monitoring serveur