Showing posts with label Azure. Show all posts

Monday, September 8, 2025

Théâtre de la sécurité infonuagique: pourquoi les "meilleures pratiques" d'Azure ne vous sécurisent pas réellement (Avec blogueur invité Joshua Copeland)

Seule, une "checklist" ne vaut rien.

Joshua Copeland et Jean-Paul Lizotte

Image générée par l'IA.

Tout le monde aime une liste de contrôle (checklist). Microsoft les publie. Les consultants facturent par eux. Les RSSI s'accrochent à eux. Mais voici ce qu'on pense discrètement, mais dit à haute voix: les meilleures pratiques Azure consistent davantage à réussir les audits qu'à arrêter les attaquants.

Ils ont fière allure dans un rapport du conseil. Ils cochent la case de conformité. Mais ils ne reflètent pas la façon dont les adversaires se œuvrent, exploitent et pivotent réellement dans les environnements infonuagiques. Ce qui nous reste, c'est le théâtre de la sécurité; l'illusion de la sécurité sans la substance de la résilience.

Le problème des "meilleures pratiques"

Les "meilleures pratiques" semblent réconfortantes. Ce sont les garde-fous brillants que les vendeurs vous tendent, la case que tout vérificateur veut cocher, la phrase à laquelle chaque dirigeant s'accroche lorsqu'il ne comprend pas vraiment le risque. Mais voici le problème: la plupart des meilleures pratiques Azure ne sont pas conçues pour arrêter les attaquants, du moins pas les attaquants d'aujourd'hui, elles sont conçues pour créer une apparence de sécurité. Ils normalisent le minimum, et non le maximum. Ils résolvent l'optique de la conformité, pas la pression de l'adversaire. Et lorsque les organisations les traitent comme un évangile, elles finissent par construire des systèmes fragiles qui semblent sûrs sur papier, mais qui s'effondrent au moment où quelqu'un décide de vraiment les tester.

Il s'agit de marketing, pas de sécurité.

La plupart des "meilleures pratiques" d'Azure sont écrites pour montrer à quel point la plateforme est soignée, et non comment elle résiste réellement aux attaques. Il s'agit de configurations généralisées et conviviales destinées à avoir fière allure dans une présentation PowerPoint ou à satisfaire à un audit de conformité. Le problème? Les vrais adversaires ne se soucient pas des tableaux de bord propres ou des politiques bien alignées. Ils recherchent les exceptions, les anciens comptes que personne n'a touchés, le directeur de service mal configuré qui tient tranquillement l'administration globale. Les meilleures pratiques créent l'illusion d'une forteresse, mais trop souvent c'est une découpe en carton... parfaite pour une démonstration de vente, inutile en cas de brèche.

Un jeu de chat et souris.

Au moment de la publication des directives, les attaquants ont déjà changé de tactique. Les kits de contournement de l'authentification multifacteur, le vol de jetons et les fédérations d'identités mal configurées ne sont pas abordés dans les PDF sur papier glacé. Lorsque les menaces changent quotidiennement, elles ne seront jamais exactes au paysage actuel des menaces.

Ils mesurent la conformité, pas la résilience.

Réussir un benchmark de sécurité Azure, c'est comme réussir un examen à livre ouvert. Cela ne prouve pas que vous pouvez performer sous pression; Cela prouve que vous pouvez lire et trouver les réponses. Ce n'est pas mal, mais n'importe qui peut cliquer sur une liste de contrôle, activer quelques bascules et générer un rapport indiquant "sécurisé". Mais cela ne signifie pas que votre environnement peut résister au vol de jetons, à l'élévation de privilèges ou à un déplacement latéral à travers une identité mal configurée. La conformité montre que vous avez suivi la recette. La résilience prouve que vous pouvez improviser lorsque l'alarme incendie se déclenche et que la recette ne s'applique plus. Les attaquants ne se soucient pas de savoir si vous avez obtenu un score de 100% sur un point de référence, ils se soucient des espaces que vous avez laissés entre les lignes.

Le point de vue de JP: Bâtir une résilience réelle

Les bonnes pratiques sont des enjeux importants. Ce qui compte, c'est comment vous renforcez le système contre les défaillances, la dérive et les compromis. Cela nécessite de concevoir pour les attaquants, et non pour les auditeurs :

L'automatisation dans un souci de résilience. Ne vous contentez pas d'automatiser les bascules; Automatisez la récupération et l'auto-réparation. Les pipelines d'infrastructure qui détectent la dérive et corrigent automatiquement réduisent votre surface d'attaque plus rapidement que les correctifs manuels.
L'examen par les pairs comme contrôle de sécurité de première classe. Les déploiements automatisés nécessitent des frictions humaines aux bons endroits. L'examen par les pairs des changements d'architecture et des demandes de tirage IaC détecte les types d'erreurs qui mènent à l'élévation des privilèges. C'est moins tape-à-l'œil qu'un tableau de bord, mais beaucoup plus efficace.
Protection des données sur le terrain. Le chiffrement des disques et des objets blob est évident. Le chiffrement des champs sensibles dans les bases de données et les flux de messages est ce qui frustre les attaquants. Même s'ils pivotent, ce qu'ils tirent est inutile sans clés.
Exploitation forestière résiliente. Si vos journaux ne vivent que dans le même locataire que vous défendez, ils sont à un rm -rf de disparaître. L'expédition des journaux dans un environnement isolé garantit que vos services judiciaires survivent à l'atteinte.

C'est ainsi que vous passez du théâtre à l'ingénierie de la résilience.

Au-delà de la liste de contrôle: ce qui fonctionne réellement

Bases de référence axées sur les menaces

Analyse des journaux.
Enregistrez tout et ayez des outils qui analysent ces journaux pour détecter des modèles "inhabituels" répétés, y compris le volume d'accès.
Examinez fréquemment les registres.
Utilisez des pots de miel (honeypots) ou des ressources de tromperie pour détecter rapidement les sondages d'identité et les attaques brutes d'identifiants.
Alternez régulièrement les secrets et les clés des principaux de service, l'automatisation appliquant les horaires de rotation.
Créez des tableaux de bord de comportement "normaux" de base et alertez sur les tendances des écarts plutôt que sur des seuils bruts.
Tirez parti de l'IA pour signaler les tendances ou les indices cachés. Mais ne vous y fiez pas!

Contrôles du périmètre de l'abus d'identité

Prenez le temps d'y accéder.
L'accès anonyme devrait être refusé à la frontière.
Appliquez des politiques d'accès conditionnel qui évaluent la posture des appareils, l'emplacement du réseau et l'analyse comportementale.
Limitez l'accès "juste-à-temps" avec une expiration automatisée pour les rôles élevés (Privileged Identity Management dans Azure AD).
Cartographiez et élaguez les "identités fantômes" (comptes de service, utilisateurs invités obsolètes) à une cadence mensuelle.

Automatisation et responsabilisation

Tous les changements ont une intégration automatisée (CI).
Les résultats sont examinés par les pairs et signés par eux.
Appliquer « l'intégrité à deux personnes" pour les changements d'infrastructure sensibles: l'automatisation promulgue le changement, mais un deuxième pair signe numériquement.
Liez chaque modification d'infrastructure à un élément de travail ou à un ticket – le pipeline CI devrait échouer s'il ne peut pas lier la modification de code à l'intention.
Conservez des pistes d'audit immuables des actions d'automatisation dans un magasin de journaux externe (p. ex., blob d'ajout seul ou connecteur SIEM).

Rapports de conformité sur les tests de résilience :

Authentification et tests d'identité
Autorisation et contrôle d'accès
Protection des données et confidentialité
Configuration infonuagique et tests d'infrastructure
Sécurité des applications (OWASP + infonuagique spécifique)
Sécurité des réseaux et des API
Conformité et chaîne d'approvisionnement
Analyse de code (Snyk, Sonarqube)
Stockez les résultats dans un stockage cloud séparé, mettez en évidence tout changement de statut.
Effectuez des exercices qui simulent le vol de jetons, les mouvements latéraux ou la corruption des journaux: mesurez le temps nécessaire pour détecter et réagir.
Intégrez l'ingénierie de sécurité du chaos: par exemple, injectez délibérément des certificats expirés, des jetons révoqués ou désactivez l'authentification multifacteur pour tester si la détection et la récupération se déclenchent.
Testez la survie des données: simulez la perte de journaux de production et confirmez que votre environnement secondaire d'expédition de billes reste intact.
Automatisez l'équipe rouge dans une boîte: les analyses planifiées et les tentatives d'élévation de privilèges scritées s'exécutent en continu, avec des résultats intégrés au backlog.
Encore, tirez parti de l'IA pour signaler les tendances ou les indices cachés. Mais ne vous y fiez pas!

Les responsables de la sécurité aiment se vanter de "suivre les meilleures pratiques Azure". Les attaquants aiment que vous le fassiez aussi. Parce qu'ils savent que ces pratiques exemplaires n'ont pas été écrites pour eux. Ils ont été écrits pour vous vendre la tranquillité d'esprit.

Notre clôture

Les bonnes pratiques et les vérifications feront toujours partie du jeu. Ils ont posé le plancher, mais jamais le plafond. La vraie résilience survient lorsque vous allez au-delà des vérifications et que vous commencez à concevoir des systèmes pour survivre au contact avec les attaquants.

Cela signifie :

Automatisez en pensant à la récupération: des pipelines qui non seulement se déploient, mais auto-réparent les infrastructures et détectent les dérives.
Ajoutez des frictions humaines là où ça compte: évaluation par les pairs et intégrité de deux personnes pour les changements sensibles.
Protégez les données qui comptent le plus : chiffrement au niveau du terrain, sauvegarde et journalisation de survie dans des magasins isolés.
Testez l'échec, pas seulement la conformité: répétez les violations, semez le chaos et prouvez que vous pouvez vous remettre.

Les attaquants ne se soucient pas de votre note d'audit. Ils se soucient des fissures entre vos commandes. Combler ces lacunes est ce qui transforme le "théâtre de sécurité" en véritable résilience.

La vraie résilience commence lorsque vous cessez d'adorer les listes de contrôle et commencez à construire des systèmes que les attaquants détestent et que vous aimerez.

Alone a checklist is worthless.

Joshua Copeland and Jean-Paul Lizotte

Image generated by AI.

Everyone loves a checklist. Microsoft publishes them. Consultants bill by them. CISOs cling to them. But here's the quiet part out loud: Azure best practices are more about passing audits than stopping attackers.

They look good in a board report. They check the compliance box. But they don't reflect how adversaries actually move, exploit, and pivot in cloud environments. What we're left with is "security theater"; the illusion of safety without the substance of resilience. It's all for show.

The Problem With "Best Practices"

"Best practices" sound comforting. They're the shiny guardrails vendors hand you, the box every auditor wants checked, the phrase every executive clings to when they don't really understand the risk. But here's the problem: most Azure best practices aren't actually designed to stop attackers, at least not today's attackers, they're designed to create the appearance of security. They standardize the minimum, not the maximum. They solve for compliance optics, not for adversarial pressure. And when organizations treat them as gospel, they end up building fragile systems that look secure on paper but crumble the moment someone decides to really test them.

They're marketing, not security.

Most Azure "best practices" are written to showcase how polished the platform looks, not how it actually holds up under attack. They're generalized, vendor-friendly configurations meant to look great in a PowerPoint deck or satisfy a compliance audit. The problem? Real adversaries don't care about clean dashboards or neatly aligned policies. They look for the exceptions, the legacy accounts no one touched, the misconfigured service principal quietly holding global admin. Best practices create the illusion of a fortress, but too often it's a cardboard cutout…perfect for a sales demo, useless in a breach.

They lag reality.

By the time guidance is published, attackers have already shifted tactics. MFA bypass kits, token theft, and misconfigured identity federations aren't addressed in the glossy PDFs. Standards be the vendor, industry, or government take months to years to formalize. When the threats are changing daily, they will never be accurate to the current threat landscape.

They measure compliance, not resilience.

Passing an Azure security benchmark is like acing an open-book exam. It doesn't prove you can perform under pressure; it proves you can read and can find the answers. That isn't bad, but anyone can click through a checklist, enable a few toggles, and generate a report that says "secure." But that doesn't mean your environment can withstand token theft, privilege escalation, or a lateral move through a misconfigured identity. Compliance shows you've followed the recipe. Resilience proves you can improvise when the fire alarm goes off and the recipe no longer applies. Attackers don't care if you scored 100% on a benchmark—they care about the gaps you left between the lines.

JP's Take: Building Real Resilience

Best practices are table stakes. What matters is how you harden the system against failure, drift, and compromise. That requires designing for attackers, not auditors:

Automation with resilience in mind. Don't just automate toggles; automate recovery and self-healing. Infrastructure pipelines that detect drift and auto-correct reduce your attack surface faster than manual patching ever can.
Peer review as a first-class security control. Automated deployments need human friction in the right places. Peer review on architecture changes and IaC pull requests catches the kinds of mistakes that lead to privilege escalation. It's less flashy than a dashboard, but far more effective.
Field-level data protection. Encrypting disks and blobs is obvious. Encrypting sensitive fields inside databases and message flows is what frustrates attackers. Even if they pivot, what they pull is useless without keys.
Resilient logging. If your logs live only in the same tenant you're defending, they're one rm -rf away from disappearing. Log-shipping to an isolated environment makes sure your forensics survives the breach.

This is how you move from theater to resilience engineering.

Beyond the Checklist: What Actually Works

Threat-driven baselines

Log analysis.
Log everything and have tools that analyse those logs for repeated "unusual" patterns including volume of accesses.
Review the logs frequently.
Use honeypots or deception assets to catch identity probing and credential stuffing early.
Rotate service principal secrets and keys regularly, with automation enforcing rotation schedules.
Build baseline "normal" behavior dashboards and alert on deviation rather than raw thresholds.
Leverage AI to flag trends or hidden clues. But do not depend on it!

Identity abuse perimeter controls

Take the time to gate access.
Anonymous access should be denied at the border.
Apply conditional access policies that weigh device posture, network location, and behavioral analytics.
Limit "just-in-time" access with automated expiration for elevated roles (Privileged Identity Management in Azure AD).
Map out and prune "shadow identities" (service accounts, stale guest users) on a monthly cadence.

Automation with accountability

All changes have an automated integration (CI).
The outcomes are reviewed by peers and signed off by them.
Enforce "two-person integrity" for sensitive infrastructure changes: automation enacts the change, but a second peer signs off digitally.
Tie every infrastructure change to a work item or ticket — the CI pipeline should fail if it can’t link the code change to intent.
Keep immutable audit trails of automation actions in an external log store (e.g., append-only blob or SIEM connector).

Resilience testing Compliance reports:

Authentication & Identity Testing
Authorization & Access Control
Data Protection & Privacy
Cloud Configuration & Infrastructure Testing
Application Security (OWASP + Cloud Specific)
Network & API Security
Compliance & Supply Chain
Code Scanning (Snyk, Sonarqube)
Store the results in a separate cloud storage, highlight any changes in statuses.
Run tabletop exercises that simulate token theft, lateral movement, or log corruption — measure how long it takes to detect and respond.
Integrate chaos security engineering: e.g., deliberately inject expired certificates, revoked tokens, or disabled MFA to test if detection and recovery trigger.
Test data survivability: simulate loss of production logs and confirm your secondary log-shipping environment remains intact.
Automate red team in a box: scheduled scans and scripted privilege escalation attempts run continuously, with results fed into backlog.
Leverage AI to flag trends or hidden clues. But do not depend on it!

Security leaders love to brag about "following Azure best practices." Attackers love when you do too. Because they know those best practices weren't written for them. They were written to sell you peace of mind.

Our Close

Best practices and audits will always be part of the game. They set the floor, but never the ceiling. Real resilience comes when you move beyond passing checks and start designing systems to survive contact with attackers.

That means:

Automate with recovery in mind: pipelines that not only deploy, but self-heal and detect drift.
Add human friction where it counts: peer review and two-person integrity for sensitive changes.
Protect the data that matters most: field-level encryption, backup and survivable logging in isolated stores.
Test for failure, not just compliance: rehearse breaches, inject chaos, and prove you can recover.

Attackers don’t care about your audit score. They care about the cracks between your controls. Closing those gaps is what turns "security theater" into true resilience.

Real resilience starts when you stop worshipping checklists and start building systems that attackers hate and you will love.

With thanks to Joshua Copeland of Tulane University for his contributions to this article.

Friday, September 5, 2025

Augmenter nos pipelines SecDevOps sur Azure avec des agents IA (2/2)

Ce que nous augmentons (en termes simples)

Nous travaillons avec Azure DevOps et Azure Cloud depuis assez longtemps pour connaître cette vérité: nos pipelines produisent déjà les données/réponses dont nous avons besoin, mais ils les cachent dans des journaux, des métriques et des alertes répartis dans les outils. Les agents de l’IA nous aident à assembler cette histoire. Dans cet article, nous partageons un modèle simple et concret que nous utilisons chez JPSoftWorks pour augmenter SecDevOps sur Azure avec des agents qui surveillent, corrèlent et conseillent, sans gêner l’équipe.

Où l’agent se branche

Notre base de référence nous semble familière : Azure Repos ou GitHub, Azure Pipelines pour CI/CD, portes de sécurité pour SCA/SAST/DAST et déploiements d’atterrissage dans Azure Kubernetes Service (AKS) ou Azure App Service. L’observabilité réside dans Azure Monitor et Application Insights, Defender pour le cloud et Microsoft Defender pour DevOps alimentant les signaux de risque. Cette pile est solide, mais les gens se noient toujours dans l’information. La couche d’agent renverse le scénario en faisant trois choses pour nous:
Enrichir : Capturez les sorties du pipeline, les journaux et les résultats de sécurité; ajoutez du contexte comme les validations récentes, les différences de dépendance, la dérive de l’infrastructure et les tickets de modification.
Corréler : Relier les symptômes aux causes probables. Par exemple, associez un pic de temps de déploiement à un crochet Helm nouvellement ajouté, ou associez une augmentation des vulnérabilités faussement positives à une mise à jour de la règle d’analyse.
Conseiller : Proposer des actions qui s’adaptent à nos garde-fous. Il peut s’agir d’ouvrir automatiquement une PR pour resserrer une politique Azure, de suggérer un changement de parallélisme de test ou d’escalader un incident réel au bon canal d’équipe de service.
Nous plaçons l’agent d’IA sur le chemin d’événement qui existe déjà dans Azure :
Ingestion : Azure Pipelines publie des artefacts et des journaux de build/test dans Azure Blob Storage; les données de télémétrie sont transmises à Log Analytics via Azure Monitor et Application Insights. Les signaux de sécurité arrivent de Defender pour le Cloud et de Defender pour DevOps.
Bus : Nous reflétons les événements clés dans Event Hubs (ou Service Bus) pour garder l’agent découplé du pipeline (important).
Runtime de l’agent : un service léger sur Azure Functions ou un conteneur dans AKS s’abonne à ces événements.
Raisonnement + politiques : L’agent utilise nos invites (prompts), règles et playbooks internes, et lorsque nous avons besoin de capacités LLM, nous appelons Azure OpenAI avec un ancrage strict sur notre propre base de connaissances dans Azure AI Search ou un compte de stockage privé.
Action : L’agent réécrit les commentaires dans Azure DevOps (fils de discussion PR, résumés de pipeline), crée des branches Git avec des correctifs, file des éléments de travail ADO ou publie des alertes annotées dans Teams. Pour les problèmes d’exécution, il peut ouvrir un incident Sentinel avec des preuves enrichies.

Ce que cela change pour l’observabilité

Des journaux bruts aux récits : Au lieu de cinq alertes dans cinq outils, nous obtenons un récit : « Le déploiement a ralenti de 34% depuis le 20 août après l’ajout d’OWASP ZAP à l’étape de publication; envisagez de paralléliser les analyses ou de définir la portée des cibles.
Sensibilisation aux tendances : L’agent suit les lignes de base mobiles. Lorsque le temps de construction augmente de 5% par semaine pendant trois semaines, nous en entendons parler avant de le sentir.
Priorisation de la sécurité : Les résultats sont classés en fonction de l’exploitabilité, de l’exposition et du rayon d’explosion. Un chemin critique sur un code mort ne saute pas la file d’attente sur un support sur un service Internet.
Boucles de rétroaction : L’agent teste ses propres conseils. Si la réduction de la conservation des journaux nuit aux médico-légaux, elle annule la recommandation et explique pourquoi.

Un plan simple dans Azure

Voici un diagramme minimal que nous utilisons pour expliquer le modèle aux équipes. (cliquez pour agrandir)

Comment nous l’exploitons en toute sécurité
Les limites des données d’abord : l’agent ne voit que ce qu’il doit. Nous étendons les requêtes Log Analytics par service et nous acheminons les secrets via Key Vault. Les appels de LLM sont privés, et la consignation rapide et de réponse est effacée.
Expliquez, puis agissez : les conseils sont par défaut; les actions nécessitent soit un runbook avec des types de changements préapprouvés, soit une approbation humaine explicite dans la vérification de la demande de tirage ou du pipeline.
Connaissances versionnées : Les playbooks qui guident l’agent sont versionnés comme du code et validés dans des pipelines non producteurs.
Contrôle des coûts : Nous regroupons les événements, utilisons la génération augmentée de récupération uniquement lorsque cela est nécessaire et mettons en cache le raisonnement préalable pour les problèmes répétés.

Cas d’utilisation du jour 1:

Détecteur de dérive de pipeline : Alertez lorsque l’ordre des étapes, les conditions ou les budgets de temps changent considérablement; ouvrez un PR pour rétablir les normes.
Réducteur de bruit pour les analyses de sécurité : regroupez les doublons, supprimez les familles connues et reclassez-les par chemins d’exposition découverts à partir d’Azure Resource Graph.
Chien de garde SLO : surveillez les budgets d’erreurs à partir d’App Insights; si le taux d’utilisation dépasse la politique, l’agent met en pause les déploiements risqués et propose un retour en arrière avec des liens vers des traces défaillantes.
Coach en risque de dépendance : Lorsqu’un nouveau colis atterrit, l’agent vérifie les fenêtres de support et les vulnérabilités transitives, puis propose une solution de rechange ou une stratégie d’épinglage plus sûre.
Conclusion : nous conservons notre pile Azure existante. Nous ajoutons simplement un agent qui écoute plus attentivement, relie les points plus rapidement et nous pousse à prendre de meilleures décisions.

Augmenting SecDevOps Pipelines with AI Agents on Azure (part 2/2)

What we’re augmenting (in plain terms)

We’ve been hands-on with Azure DevOps and Azure cloud long enough to know this truth: our pipelines already produce the answers we need, but they hide them in logs, metrics, and alerts spread across tools. AI agents help us stitch that story together. In this post we share a simple, concrete pattern we use at JPSoftWorks to augment SecDevOps on Azure with agents that watch, correlate, and advise—without getting in the team’s way.

Where the agent plugs in

Our baseline looks familiar: Azure Repos or GitHub, Azure Pipelines for CI/CD, security gates for SCA/SAST/DAST, and deploys landing in Azure Kubernetes Service (AKS) or Azure App Service. Observability lives in Azure Monitor and Application Insights, with Defender for Cloud and Microsoft Defender for DevOps feeding risk signals. That stack is solid, but people still drown in information. The agent layer flips the script by doing three things for us:

Enrich: Capture pipeline outputs, logs, and security findings; add context like recent commits, dependency diffs, infra drift, and change tickets.
Correlate: Link symptoms to likely causes. For example, tie a spike in time-to-deploy to a newly added Helm hook, or associate a rise in false-positive vulns with a scanner rule update.
Advise: Propose actions that fit our guardrails. That might be auto-opening a PR to tighten an Azure Policy, suggesting a change in test parallelism, or escalating a real incident to the right service team channel.

We place the AI agent on the event path that already exists in Azure:

Ingest: Azure Pipelines publishes build/test artifacts and logs to Azure Blob Storage; telemetry flows into Log Analytics via Azure Monitor and Application Insights. Security signals arrive from Defender for Cloud and Defender for DevOps.
Bus: We mirror key events to Event Hubs (or Service Bus) to keep the agent decoupled from the pipeline.
Agent runtime: A lightweight service on Azure Functions or a container in AKS subscribes to those events.
Reasoning + policies: The agent uses our in-house prompts, rules, and playbooks, and when we need LLM capabilities we call Azure OpenAI with strict grounding against our own knowledge base in Azure AI Search or a private storage account.
Action: The agent writes comments back to Azure DevOps (PR threads, pipeline summaries), creates Git branches with fixes, files ADO work items, or posts annotated alerts to Teams. For runtime issues it can open a Sentinel incident with enriched evidence.

What it changes for observability

From raw logs to narratives: Instead of five alerts in five tools, we get one narrative: “Deployment slowed by 34% since Aug 20 after adding OWASP ZAP to release stage; consider parallelizing scans or scoping targets.”
Trend awareness: The agent tracks moving baselines. When build time creeps 5% weekly for three weeks, we hear about it before we feel it.
Security prioritization: Findings get ranked by exploitability, exposure, and blast radius. A critical on a dead code path doesn’t jump the queue over a medium on an internet-facing service.
Feedback loops: The agent tests its own advice. If shortening log retention hurts forensics, it rolls back the recommendation and explains why.

A simple Azure blueprint

Here’s a minimal diagram we use to explain the pattern to teams. (click to expand)

How we run it safely

Data boundaries first: The agent only sees what it must. We scope Log Analytics queries per service, and we route secrets through Key Vault. LLM calls are private, with prompt/response logging scrubbed.
Explain, then act: Advice is default; actions require either a runbook with pre-approved change types or explicit human approval in the PR or pipeline check.
Versioned knowledge: The playbooks that guide the agent are versioned like code and validated in non-prod pipelines.
Cost controls: We batch events, use Retrieval-Augmented Generation only when needed, and cache prior reasoning for repeated issues.

Day-one use cases

Pipeline drift detector: Alert when stage order, conditions, or time budgets change materially; open a PR to restore standards.
Noise reducer for security scans: Group duplicates, suppress known-benign families, and re-rank by exposure paths discovered from Azure Resource Graph.
SLO watchdog: Watch error budgets from App Insights; if burn rate exceeds policy, the agent pauses risky deploys and proposes a rollback with links to failing traces.
Dependency risk coach: When a new package lands, the agent checks support windows and transitive vulns, then proposes a safer alternative or pin strategy.

Bottom line: we keep our existing Azure stack. We just add an agent that listens harder, connects dots faster, and nudges us toward better decisions.

Monday, June 2, 2025

SecDevOps ou pas SecDevOps? C'est même pas une question!

SecDevOps + Zero-Trust : guide coquin pour les équipes qui « font déjà du DevOps »… ou pas !

TL;DR On ne cherche pas à remplacer DevOps; on l'enveloppe dans une armure fluo qui bloque ou révèle le risque, tout en laissant la gang à l’intérieur danser comme si c'etait 1999.

Qu’est-ce que SecDevOps, au juste ?

DevOps : faire circuler la valeur vite, apprendre, recommencer (« vraiment TLDR »).
SecDevOps : même chose, mais on branche des capteurs de risques dans la plomberie pour que le danger avertit avant de mordre. (Encore plus de shift-left !)
Zero-Trust : « Ne jamais faire confiance, toujours vérifier »… appliqué aux paquets, jetons, conteneurs, bref tout SAUF l’intention de vos collègues. Réseaux parano: humains optimistes.

Ensemble, ça donne un modèle de capacités qui se branche sur Scrum, Kanban, GitOps, SAFe, peu importe le beat que votre organisation suit, sans exiger une nouvelle religion.

Les quatre principes (gentiment) irrévérencieux

Tout ce qui bouge est journalisé, scanné ou sinon gueulé. Commits, conteneurs, changements IAM, on s’en fiche de qui a appuyé sur Enter.
Les garde-fous valent mieux que les gates (non, pas celles de Bill !). Une image de base endurcie évite bien des « oups »; un gros bouton rouge « ÉCHEC » un vendredi 16 h, ça fait grincer des dents.
Zero-Trust du système, confiance totale envers les humains (au boulot). On fait tourner les jetons aux heures, mais on fait tourner le blâme hors du post-mortem.
La visibilité = l’amour (gardez quand même vos vêtements). Si un risque peut se cacher, un succès aussi. Les tableaux de bord montrent le flux et les lacunes côte à côte. Les équipes avec une vraie sécurité psychologique et de bons métriques DORA surclassent leurs pairs.

Ça remplace DevOps ?

Ben non, c’est DevOps PLUS.
Imaginez DevOps comme un téléphone intelligent ; SecDevOps est l’étui blindé extra-robuste. Vos apps préférées tournent toujours, mais l’appareil survit aux chutes, aux cafés renversés et au hacker occasionnel.

Constat terrain	Quoi faire
Vous avez déjà un CI/CD	Greffez les contrôles de sécurité dans les mêmes étapes. Gardez la culture du "green bar", ajoutez juste une touche de violet pour les passes à la sécurité.
Les Ops craignent la surcharge	Automatisez d’abord, annoncez ensuite. Si le scanner réussit en silence 99 % du temps, personne ne crie.
La Sécurité redoute le « Far West »	Offrez-leur des tableaux de bord en lecture seule et un droit de veto sur les exceptions, les changements non-documentés, pas sur chaque déploiement.

Zero-Trust sans casser l’ambiance

Pilier Zero-Trust	Traduction « humaine-friendly »	Garde-fou pas gossant
Vérifier explicitement	« On te fait confiance… mais on double-vérifie le système. »	Toutes les requêtes API se ré-authentifient en douce; les échecs s’affichent à côté du compte de tests unitaires.
Moindre privilège	« Un plus petit rayon d’explosion = moins d’appels à 3 h du mat. »	Rôles « PIM » de 2 heures; l’audit se publie dans #sec-télémétrie.
Présumer l’intrusion	« Curiosité plutôt que blâme. »	Jeux de guerre trimestriels : fuite de faux secrets, beignes pour les gagnants, pas de recherches de coupables.

Starter kit (sprint d’une journée: avec zéro échantillon de code, promis !)

Activez les scanners intégrés. GitHub Advanced Security, SAST GitLab, analyseurs Azure DevOps, SonarQube… prenez ce que votre dépôt offre déjà gratuitement.
Montez un « Risk Radiator ». Un panneau Grafana interne qui fusionne déploiements, vulnérabilités et incidents en une vue bien bruyante et fière.
Activez les rôles Just-In-Time. Utilisez la fonction JIT/PIM de votre cloud pour que n’importe quel·le coéquipier·ère obtienne un accès temporaire sans passer par le service desk.
Planifiez une journée Purple-Team.* Un après-midi, simulez une fuite de jeton et exercez-vous à la trouver et à la corriger ensemble. Top-là: obligatoire.

*Bleu + Rouge = Purple (Violette) au cas ou c'est pas clair...

Métriques qui comptent (et qui gardent tout le monde honnête)

Flux	Sécurité	Culture
Gestion du changement	MTTR-V (correction des vulns)	Nb d’humains uniques ayant fermé un billet sécurité
Fréquence de déploiement	% de sessions privilégiées qui expirent auto	Nb de « kudos » pour détection de risque précoce
Points d’histoire livrés	Nouvelles mesures de sécurité mises en place	Amélioration continue documentée

Si un indicateur monte les équipes l’une contre l’autre, digérez le et jetez-le. S’il déclenche la collaboration, gardez-le.

Dernier mot

SecDevOps + Zero-Trust complète DevOps comme la ceinture de sécurité complète la voiture sport : la balade reste délirante, les accidents font moins mal, et personne ne prétend que la ceinture « remplace » le moteur.

Lancez-vous avec un scanner de vulnérabilités, un tableau de métriques et PIMez vous. Laissez les données parler, laissez les humains rire, et observez la vélocité sécuritaire devenir la nouvelle norme.

Allez hop! Ajoutez cette étincelle violette à vos pipelines, votre futur vous vous dira merci.

Vous voulez en parler? Pour en savoir plus? Contactez-nous, dans la section des commentaires ci-dessous.

To SecDevOps or not to. It isn't even a question.

SecDevOps + Zero-Trust: a Cheeky Field Guide for Teams That Already “Do DevOps”...or dont...

TL;DR — We’re not trying to replace DevOps, we’re giving it a shiny exoskeleton that blocks or exposes risk and still lets the people inside, boogie like it's 1999.

What is SecDevOps, Really?

DevOps: make value flow fast, learn, repeat. really TLDR.
SecDevOps: do the same thing but wire risk-sensors into the plumbing so danger lights up before it bites. (Shift left... again)
Zero-Trust: “Never trust, always verify”… applied to packets and tokens, code, containers, everything, EXCEPT colleagues’ motives. In other words, paranoid networks, optimistic humans. (NIST, csrc.nist.gov)

Put them together and you get a capability model that snaps onto Scrum, Kanban, GitOps, SAFe, whatever rhythm your org already claps to, without demanding a brand-new religion.

The Four Cheeky Principles

Everything That Moves Is Logged, Scanned, or Yelled At
Commits, containers, IAM changes, doesn’t matter who hit Enter.
Guardrails Beat Gates (no, no, not Bill!)
A pre-hardened base image prevents oopsies; a red “BLOCKED” button at 4 p.m. Friday enrages engineers.
Zero-Trust the System, Full-Trust the Humans, at work.
We rotate tokens every hour but rotate blame out of the post-mortem.
Visibility = Love (Keep your clothes on, though)
If a risk can hide, so can a win. Dashboards show flow and flaws side-by-side. Elite teams with strong psych-safety and good metrics outperform their peers on every DORA KPI. (InfoQ, Kodus)

Does This Replace DevOps?

Nope, it’s DevOps Plus.
Think of DevOps as the smartphone; SecDevOps is the ruggedized case and screen protector. Your favourite apps still run, but the device survives drops, spills, and the occasional hacker.

Reality Check	What to Do
You already have CI/CD	Bolt security checks into the same pipeline stages. Keep the green bar culture, just add a “purple sparkle” for security passes. (explanation forthcoming)
Ops teams worry about extra toil	Automate first, announce second. If the scanner’s silent-success rate is 99 %, nobody screams.
Security fears a “Wild West”	Give them read-only dashboards and veto power on exceptions and undocumented changes, not on every deploy.

How Zero-Trust Fits Without Killing the Vibe

Zero-Trust Pillar	Human-Friendly Translation	Non-Annoying Guardrail
Verify Explicitly	“We trust you, we double-check the system.”	All API calls re-auth transparently; failure shows up next to the unit-test count.
Least Privilege	“Smaller blast-radius = fewer 3 a.m. calls.”	2-hour click-to-elevate roles; audit trail posts to #sec-telemetry.
Assume Breach	“Curiosity over blame.”	Quarterly game-days inject fake secrets; winners get doughnuts, not finger-pointing.

Starter Kit (One-Day Sprint, No Code Samples: Promise!)

Turn On Built-In Scanners
GitHub Advanced Security, GitLab SAST, Azure DevOps Analyzers, SonarQube, or whatever your repo already gives you for free.
Spin Up a “Risk Radiator”
Internal Grafana panel that glues deployment, vulnerability, and incident metrics into one loud, proud place. Keep granular data about projects for diagnostics, but display the aggregate.
Enable Just-In-Time Roles
Use your cloud’s JIT/“break-glass”/PIM feature so any teammate can get short-lived access without service-desk limbo.
Schedule a Purple-Team* Game-Day
One afternoon, fake a token leak and practise finding & fixing it together. High-fives mandatory.

*Red+Blue = Purple, in case you needed the explanation

Metrics That Matter (and Keep Everyone Honest)

Flow	Safety	Culture
Lead Time for Change	MTTR-V (vuln fix)	# of unique humans who closed a security ticket
Deployment Frequency	% privileged sessions auto-expire	# shout-outs for spotting a risk early
Story points delivered	New safety measures put into place	continuous improvement

If a stat can pit teams against each other, digest it and dump it. If it sparks joint problem-solving, keep it.

Final Nudge

SecDevOps + Zero-Trust complements DevOps the way seatbelts complement sports cars: the ride stays thrilling, the crashes hurt less, and nobody argues that belts “replace” engines.

Start with one scanner, one metric board, and one JIT role.
Let the data speak, let the humans laugh, and watch safe velocity become the new normal.

Now go forth and add that purple sparkle to your pipelines: your future self already thanks you.

Want to talk about it? To know more? Hit us up, in the comment section below.

Sunday, June 1, 2025

Faire "Agile" de la bonne façon : les points et le contrat.

Au-delà des chiffres: Comprendre les Story Points comme un contrat tacite dans Azure DevOps: Adopter l'observabilité & SecDevOps

Introduction: Mise en contexte

Soyons honnêtes: l'idée des "story points" peut sembler un peu… eh bien, absurde au premier abord. C'est comme essayer de mesurer le ressenti d'une bonne tasse de café avec une règle. Mais les story points ne visent pas une mesure précise. Ils sont un outil de communication, de collaboration et, surtout, de compréhension de la complexité relative des tâches. Mais, si on les fait correctement, il ne s'agit pas de mesurer le temps ; il s'agit de tenir une promesse. Une promesse tacite, en fait, celle qu'on fait d'un coup d'œil complice et d'un haussement d'épaules un peu embarrassé. Il s'agit d'estimer l'effort, pas le temps. Utiliser les story points nous permet de prioriser efficacement et de suivre notre vélocité: en gros, à quelle vitesse nous avançons. C'est une approche étonnamment utile et c'est une pierre angulaire du DevSecOps.

L'écosystème interconnecté: Observabilité & SecDevOps

Imaginez un orchestre chaotique: où chacun joue un instrument différent, à n'importe quel cadence et où personne ne sait ce que font les autres. C'est à ça que ressemble le développement d'application sans un bon système. Azure DevOps, en revanche, ressemble à une symphonie magnifiquement orchestrée. Azure Boards (pour la planification), Azure Repos (pour le code), Azure Pipelines (pour les compilations et les déploiements) et Azure Artifacts (pour la gestion des packages): ils communiquent tous ensemble. Les changements dans le plan sont immédiatement reflétés dans le code, les compilations et les déploiements. Cela crée une boucle de rétroaction: un élément essentiel pour l'observabilité.

Voyez les choses de cette façon: un petit bug introduit pendant une compilation est immédiatement signalé, et l'équipe peut rapidement annuler les modifications. C'est un principe fondamental du SecDevOps: la sécurité proactive, la surveillance continue et la réponse rapide. Sans cette intégration, vous êtes essentiellement à l'aveugle. C'est comme essayer de réparer une fuite de canalisation, mais cette fois-ci avec une lampe de poche. La visibilité en temps réel est essentielle !

Observabilité et SecDevOps: Maintenir le contrat vivant

Sans observabilité, la capacité à comprendre ce qui se passe à l'intérieur de votre système, ce contrat tacite est fragile. Vous devez savoir pourquoi les choses se produisent. La surveillance, la journalisation et le traçage sont vos alliés. Les pratiques SecDevOps ne consistent pas seulement à ajouter de la sécurité ; elles visent à construire la résilience et la compréhension. C'est autant une question de manière de travailler que de ce que nous livrons !

Alors, qu'est-ce qu'une User Story ? (Et pourquoi c'est un accord secret)

Une user story, au fond, est un petit extrait de conversation. Ce n'est pas un document de spécification détaillé. Ce n'est pas un plan. C'est un point de départ. Une bonne user story ressemble à ceci: "En tant que [rôle utilisateur], je veux [objectif] afin que [bénéfice]." Exemple: "En tant que client, je veux pouvoir réinitialiser mon mot de passe afin de pouvoir accéder à mon compte si je l'oublie." Simple, non ?
Mais voilà le truc: ce ne sont pas seulement les mots. C'est l'accord implicite qui suit. C'est là que le côté "tacite" entre en jeu. C'est comme accepter de se voir pour un café: vous n'écrivez pas l'itinéraire exact, la température ou la marque de café préférée. Vous acceptez simplement de vous retrouver. Puis, vous vous débrouillez. Une user story bien rédigée est la base de cet accord.

L'art de moins de stress, plus de promesses

La documentation agile, et je ne parle pas d'un dossier de 100 pages, je parle de tout ce que l'on place simplement dans nos tableaux de travail, vise en réalité à réduire la pression sur l'équipe. Soyons réalistes, courir sans cesse après cette "spécification parfaite" ne fait qu'engendrer de l'anxiété. C'est un jeu de raffinement sans fin, et honnêtement, c'est épuisant. En adoptant une approche légère, on déplace l'accent de la documentation méticuleuse de chaque détail vers la simple capture d'assez d'informations pour que tout le monde reste aligné. Il s'agit d'une compréhension partagée, pas d'un contrat rigide.

Les éléments qui "verrouillent" la spécification (et pourquoi vous ne devriez pas les ignorer)

Décomposons ce qui fait réellement qu'une user story "tient". C'est plus que le format de base. Voici ce qui doit être présent pour que tout le monde soit sur la même longueur d'onde et pour créer cet accord puissant et silencieux :

Critères d'acceptation: Ce sont les règles de l'accord. Ce sont les éléments qui doivent être vrais pour que la story soit considérée comme "terminée". Ils ne sont pas optionnels. Exemple: "Étant donné que j'ai saisi une adresse e-mail valide, lorsque je clique sur ‘Réinitialiser le mot de passe', alors je devrais recevoir un e-mail avec un lien pour réinitialiser mon mot de passe."
Définition de Terminé (DoD): C'est la liste de contrôle plus large: scans de sécurité, revues de code, tests d'intégration, etc. C'est ce qui assure que la story est véritablement complète et fiable.
Valeur d'affaires": C'est la partie "… afin que …". C'est pourquoi nous faisons cela. C'est le lien avec l'objectif "business". Sans cela, vous construisez seulement des belles choses creuses sans but.
Considérations techniques: Parfois, l'équipe doit discuter des implications techniques. Ce n'est pas nécessairement une partie de la user story, mais il est important de le reconnaître.

Story Points: Engagements, pas échéances

Oubliez l'idée de mapper les story points aux heures. C'est une recette pour la frustration. Les story points sont des estimations relatives: parlons-nous d'une "petite modification" ou d'une "refonte majeure" ? Considérez-les comme un moyen de communiquer la complexité relative et le risque. Encore une fois, nous n'essayons pas de quantifier l'effort (c'est un piège !). Nous essayons d'établir une mesure relative de complexité et de risque. Une story estimée à environ 8 points est à peu près aussi complexe qu'une story à 13 points. L'important n'est pas le chiffre lui-même, mais la compréhension partagée qu'il représente.

La règle des 13 points: Quand décomposer

Voici un petit secret: tout ce qui est estimé à 13 ou plus devrait probablement être décomposé. Sérieusement. C'est un signal d'alarme rouge flamboyant qui vous dit que vous vous apprêtez à vous lancer dans quelque chose de potentiellement épineux. Les stories volumineuses sont souvent le symptôme d'un glissement de périmètre ou d'un manque de clarté.

Voyez les choses ainsi: si vous estimez une story à 13 points, vous dites essentiellement "Je ne suis pas tout à fait sûr de ce dans quoi je m'embarque." Et c'est tout à fait correct ! Mais cela doit être traité. Ne vous contentez pas de la confier à un développeur et d'espérer le meilleur.

La séquence de Fibonacci: Pourquoi une échelle relative ?

Vous avez probablement entendu l'histoire de Ron Jeffries et de la séquence de Fibonacci. Il essayait d'estimer l'effort sur un projet, et il s'est rendu compte que les tâches se répartissent souvent en catégories distinctes: certaines sont minuscules, d'autres énormes. La séquence (1, 2, 3, 5, 8, 13…) est une façon naturelle de représenter cela. C'est comme dire "D'accord, cette tâche est à peu près de la taille d'un petit chien, celle-ci est de la taille d'un Labrador…"

La valeur d'un point: Échelle, pas absolus

Ne tombez pas dans le piège de penser qu'un "3" signifie toujours la même chose. Lors du Sprint 1, un "3" peut être une entreprise énorme: réécrire une partie conséquente de l'application. Mais au Sprint 5, c'est probablement une tâche standard. La valeur d'un point se solidifie avec le temps à mesure que l'équipe acquiert de l'expérience et une compréhension partagée. Il s'agit de suivre la vélocité: la tendance de la rapidité avec laquelle vous avancez, pas d'un objectif rigide. Considérez cela ainsi: un marathonien expérimenté connaît mieux son rythme qu'un débutant.

Rigueur et flexibilité: Trouver l'équilibre

Bien qu'il soit important d'être réfléchi dans nos estimations, ne vous enfoncez pas dans les détails. La rigueur et la flexibilité doivent être équilibrées. Utilisez des techniques comme les rétrospectives de sprint et le planning poker pour affiner vos estimations au fil du temps. Adoptez l'auto-organisation et l'adaptation. N'oubliez pas que l'objectif est de communiquer efficacement et de délivrer de la valeur.

Azure Boards, Repos, Pipelines, Artifacts: Construire les "dents"

C'est là que la magie opère. Lorsque vous connectez vos Azure Boards, vos Git Repos, vos Pipelines et vos Artifacts, vous intégrez les dents dans ce contrat tacite.

Azure Boards: Fournit le cadre pour la story, le backlog et la planification du sprint.
Repos: La source de vérité pour le code.
Pipelines: Automatisent le processus de compilation, de test et de déploiement, garantissant une livraison cohérente.
Artifacts: Le livrable empaqueté, prêt à être déployé.

Cet écosystème intégré transforme une promesse vague en un résultat concret et vérifiable. Les pratiques de sécurité et DevOps (SecDevOps) sont cruciales ici. Pensez aux scans de sécurité automatisés dans vos pipelines, aux évaluations de vulnérabilité et à la surveillance continue.

Conclusion

En résumé: Les story points ne servent pas à mesurer le temps. Ils visent à instaurer la confiance, à favoriser la collaboration et à transformer des intentions vagues en résultats concrets. En connectant vos outils et en adoptant SecDevOps, vous pouvez transformer votre processus agile d'une série de suppositions en un pipeline de livraison fiable et reproductible.

Et en fin de compte, les story points sont un outil de communication et de collaboration, pas un système de mesure rigide. Adoptez l'approche du "contrat tacite": mettez l'accent sur la compréhension partagée et laissez les chiffres vous guider. Ne vous focalisez pas sur les chiffres ; concentrez-vous sur la livraison de la valeur.

Prêt à transformer vos pratiques DevSecOps ? Laissez-nous un commentaire ci-dessous pour planifier une consultation et découvrir comment nous pouvons vous aider à construire une équipe plus efficace et collaborative.

Prochainement: SecDevOps et Ingénierie de Plateforme.