Sujet : compliance
-
Journaux d'audit : quoi consigner, comment les garder intacts et qui peut les lire
Un journal d'audit indique qui a fait quoi, sur quel objet, quand et avec quel résultat ; l'application l'alimente pour chaque action pertinente pour la sécurité, le sépare des journaux de débogage, le protège contre les altérations en transférant rapidement ses entrées vers un stockage en ajout seul ou à écriture unique, et n'en autorise la lecture que dans le cadre d'accès restreints et consignés.
-
Préparer la gestion des vulnérabilités CRA d’un fabricant : réception, preuves et délais de notification
Une proposition de protocole de préparation relie la réception des signalements de vulnérabilités et les dossiers de composants à la décision de notification au titre du CRA. Elle distingue l’obligation de notification déjà applicable en 2026 des exigences plus larges de gestion des vulnérabilités applicables en décembre 2027.
-
Vérifier le cycle de vie du support d'un système d'exploitation avant d'automatiser des opérations sur celui-ci
Automatiser des workflows de correctifs, de mise à niveau ou de conformité sur un hôte dont le support est déjà terminé donne une fausse assurance : plus aucun correctif de sécurité ne viendra, quoi que rapporte l'automatisation. Cette méthodologie indique où chaque grand éditeur publie ses dates de cycle de vie et comment intégrer une vérification de fin de vie (EOL) dans une étape préalable.
-
Choisir une licence open source
Les licences permissives (MIT, Apache-2.0) autorisent la réutilisation avec attribution ; les licences à copyleft (GPL, AGPL) exigent que les œuvres dérivées restent ouvertes ; Apache-2.0 ajoute une concession de brevet. Le choix dépend de ce que les utilisateurs en aval doivent pouvoir faire, et nécessite de vérifier la compatibilité des dépendances.
-
Nomenclatures logicielles avec SPDX et CycloneDX
Une SBOM (nomenclature logicielle) est un inventaire exploitable par machine des composants d'un artefact logiciel ; SPDX et CycloneDX sont les deux formats largement utilisés, et en générer une par version facilite le rapprochement des vulnérabilités et la revue des licences.
-
Notifications CRA depuis septembre 2026 : faits déclencheurs, délais et plateforme de notification unique
Le CRA impose aux fabricants de notifier les vulnérabilités de produits activement exploitées et les incidents graves de sécurité des produits. Les deux procédures comportent des étapes à 24 heures et à 72 heures, mais les délais des rapports finaux partent d’événements différents.
-
Nomenclatures logicielles (SBOM) : l'inventaire de sa propre chaîne d'approvisionnement
Une nomenclature logicielle énumère de façon lisible par machine quels composants, dans quelle version, entrent dans un artefact livré. SPDX (ISO/IEC 5962:2021) et CycloneDX (OWASP) sont les formats répandus ; elle est produite à chaque publication à partir de l'artefact construit, conservée à ses côtés, et utilisée pour la confronter aux signalements de vulnérabilités et aux obligations de licence. Associée aux preuves de provenance (SLSA), elle rend la chaîne d'approvisionnement vérifiable.
-
Benchmarks CIS et STIG DISA comme référentiel de durcissement : présentation et application sélective
Les CIS Benchmarks et les STIG de la DISA sont deux ensembles de recommandations de configuration maintenus indépendamment, qui proposent des niveaux de profil au choix plutôt qu'une cible unique. Appliquer un profil en bloc sans consigner les exceptions est une manière courante de casser un service de production lors d'un durcissement.
-
Signalement des cyberattaques en Suisse et CRA : des obligations distinctes pour les exploitants et les fabricants de produits
Le signalement suisse relatif aux infrastructures critiques concerne les cyberattaques répondant aux critères légaux qui touchent les exploitants assujettis. Le CRA concerne les fabricants de produits fournis sur le marché de l’UE, y compris les fabricants suisses ; la similitude des premiers délais ne rend pas les destinataires ni les faits déclencheurs interchangeables.
-
CRA et open source : distinguer contributeurs, fabricants et intendants de logiciels
Une licence open source ne suffit pas à déterminer les obligations au titre du CRA. Le règlement distingue la fourniture commerciale de produits, les contributions à des logiciels hors de la responsabilité du contributeur et le soutien durable assuré par les intendants de logiciels libres et ouverts, dont les obligations de l’article 24 débutent en décembre 2027.
-
Analyser un hôte Linux par rapport à une référence de sécurité avec OpenSCAP
oscap xccdf eval exécute un profil SCAP Security Guide sur un hôte en fonctionnement ou sur une image hors ligne et produit un rapport lisible ; relire le script de remédiation généré avant de l'exécuter évite qu'une analyse automatisée ne provoque une panne automatisée.
Lisible par machine : JSON